To maintain readiness for your next SOC 2 Type 2 audit, please consider the following: 

For any controls/tests that you set as weekly or monthly, evidence needs to be retained for every week or month within the Type 2 window. 

Quarterly

For quarterly controls/tests, evidence needs to be refreshed for every quarter within the Type 2 window. 

• Secureframe test: User access reviews
  • Remember that this includes non-integrated in-scope tools and your developed application
• Secureframe tests: External vulnerability scanning, Internal vulnerability scanning
  • Remember that “external” refers to your web application and any public-facing endpoints. 

Annual

For annual and semi-annual controls/tests, you only need evidence at least once in the year prior to the end of the Type 2 window. In other words, these don’t need to be refreshed when going from a Type 1 to a Type 2 window shorter than a year (i.e. 3, 6, or 9 months). 

• Review workstations, assets, and cloud resources annually - see “Asset List” section below for continuous monitoring items
  • You can evidence this is to utilize tasks for "Cloud infrastructure asset inventory", "User endpoint inventory", and "Version control repository inventory" tests to indicate a review. 
• Secureframe test: Security incident tabletop exercises 
• Secureframe test: Business continuity and disaster recovery tabletop exercises
• Secureframe test: Backup restoration testing 
• Secureframe test: Board of directors meeting minutes
  • Or senior leadership meeting minutes if no board of directors
• Secureframe test: Annual performance review
  • For employees who have been with the organization for at least one year)
• Secureframe test: Annual security awareness training
• All policy acceptance-related tests as applicable under the ORG-16 control
• Secureframe test: Risk assessment
  • Review and update the risk register, and add any new risks as appropriate
• Secureframe tests: Vendor risk assessments, Vendor reviews
  • Procure and upload SOC 2 reports or equivalents annually as new reports come out. Review these reports and note any areas of concern on the respective vendor page. 
• Secureframe test: Penetration testing
• Secureframe test: Baseline configurations
  • Review server baselines and configurations for networking ports, protocols, services, and firewalls. 

Ad-hoc 

The following control areas will be sampled by the auditor for occurrences during the Type 2 window: 

• New Hires
  • Access Onboarding Tickets
    • Tickets should track personnel name, start date, role, system permission grants, and final approval with a timestamp. 
    • Secureframe test: User access tracking
  • Background Checks
    • Secureframe test: New hire screening
  • Security Training
    • Secureframe test: Security awareness training at hire
  • Policy Acceptance
    • Secureframe test: All policy acceptance-related tests as applicable under the ORG-16 control 
• Current Employees
  • Access Role Change and Transfer Tickets
    • Tickets should track personnel name, transfer date, system permission changes, and final approval with a timestamp. 
    • Secureframe test: User access tracking
      • Remember that this includes non-integrated in-scope tools and your developed application
• Terminated Employees
  • Access Offboarding Tickets
    • Tickets should track personnel name, end date, system permission revocations, and final approval with a timestamp. 
    • Secureframe test: User access tracking
      • Remember that this includes non-integrated in-scope tools and your developed application
• Code/Application Changes
  • All code changes must have pull requests that require branch protection/independent approval (dev can't push own code), CI testing, dependency testing, and SAST scanning prior to the code entering production. All code changes must be linked to a ticket with change context unless that context is provided sufficiently in the PR. 
    • Secureframe tests: Code change tracking, Code pull request approvals, Version control branch approval configurations, Code dependency testing, Code integration testing, Code static analysis security testing
• Infrastructure/System Changes
  • Major/critical infra changes made via infra as a code, management console, CLI, etc. must have a ticket providing context of the change along with formal change approval. Examples of major changes include: spinning up a new prod DB, exposing VPCs, configuring a firewall, etc.
    • Secureframe test: System change tracking and resolution 
• Security Incidents
  • All incidents must be assigned a priority and tracked to remediation via a ticketing system. Incident progression and updates should be documented in the ticket. Upon resolution, incidents must undergo a lessons learned process to reflect on incident findings and ways to prevent similar incidents in the future. Tracking should include any security concerns communicated internally or externally. 
    • Secureframe tests: Incident tracking and resolution, Address critical security incidents, Security incident lessons learned
• Asset List
  • All cloud assets, code repos, and user endpoints must have an owner assigned. 
    • Secureframe tests: User endpoint ownership, Version control repository ownership, Cloud infrastructure asset ownership 
  • User endpoints should be encrypted-at-rest, be compliant with company password policy, and have AV installed. It is also recommended to enforce security updates, screen lock policy, and firewall enforcement. 
    • Secureframe tests: Hard drive encryption for user endpoints, Password policy enforcement/monitoring for user endpoints, Automatic security update enforcement for user endpoints, Screen lock enforcement for user endpoints, Anti-malware enforcement for user endpoints, Firewall enforcement/monitoring for user endpoints
• Data Disposal List
  • Data disposal requests from customers, vendors, and other external parties must be addressed based on SLAs / regulatory obligations - these requests must be documented and tracked. 
    • Secureframe test: Deletion and retention of customer data
• Customers
  • Signed contracts / MSAs for customers (unless signed up via terms of service). 
    • Secureframe tests: Customer confidentiality and security requirements, Confidentiality requirements in agreements
• Vendors
  • Signed contracts / MSAs for vendors (unless signed up via their terms of service)
    • Secureframe test: Vendor confidentiality and security requirements

Configuration tests that required manual upload screenshots to pass (i.e. password screenshots) may need to be re-observed by the auditor with a time stamp dated within the Type 2 period. Be sure to set the test interval to annual so you can be prompted for an update during the next cycle. 

Integration and Platform tests: just keep them green throughout the year!