To create a SOC 2 Type 2 report, auditors will test compliance for a sample number from each of the populations described below. Auditors will also expect evidence of the security tasks described below being completed on a regular basis (usually quarterly or annually).

Populations

To prepare for your SOC 2 Type 2, Secureframe will help to provide complete lists of the populations below with the accompanying data details.

New hires

Be prepared to provide:

• Access onboarding ticket (tickets should track personnel name, start date, role, system permission grants, and final approval with a timestamp)
• Background checks
• Policy acceptance
• Security awareness training

Current employees

Be prepared to provide:

• Access role change and transfer ticket (personnel name, transfer date, system permission changes, and final approval with a timestamp)
• Policy acceptance
• Performance reviews (for employees that have been with the company for at least one year)
• Security awareness training

Terminated employees

Be prepared to provide:

• Access offboarding tickets (personnel name, end date, system permission revocations, and final approval with a timestamp), or
• Offboarding/exit checklists (rather than tickets)

Code/application changes

All code changes must have:

• Pull requests (PRs) that require branch protection/independent approval so that developers can’t push their own code,
• CI testing 
• Dependency testing, and/or SAST scanning prior to that code entering production. 

All code changes must be linked to a ticket with change context unless that context is provided sufficiently in the PR. If any changes are not regularly submitted for approval then they should be documented and labeled as such, for example emergency or pre-approved changes as defined by your policy. 

Infrastructure/system changes

Major/critical infrastructure 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

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. At closure, incidents must undergo a lessons learned exercise to reflect on incident findings and ways to prevent similar incidents in the future.

In the case that there are no incidents, this is a non-occurence. Please notify your auditor that you did not have any incidents during the audit window. 

Asset list

All cloud assets, code repositories, and user endpoints must have an owner assigned. 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, have firewall enforcement, and a screen lock policy.

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.

Customers

Be prepared to provide a maintained, signed contracts/MSAs for customers (unless signed up via terms of service).

Vendors

Be prepared to:

• Provide maintained, signed contracts/MSAs for vendors (unless signed up via their terms of service).
• Procure and upload SOC 2 reports or equivalents annually as new reports become available.
• Review reports and note any areas of concern on the respective vendor page. 

Scheduled tasks

These are tasks that a SOC 2 auditor will be looking for evidence of completion on a regular basis, usually annually or quarterly:

Business continuity and disaster recovery tabletop exercise

Complete a business continuity and disaster recovery (BCDR) tabletop exercise annually. Walk through the tabletop exercise with a handful of stakeholders from applicable departments including technology/engineering, cybersecurity, facilities, legal, human resources, and communications.

Backup restoration tests are often included as part of the BCDR and are also required annually if availability is in the scope of your audit.

Security incident response plan tabletop exercise

Complete a security incident response tabletop exercise annually. Walk through the tabletop exercise with a handful of stakeholders from applicable departments including technology/engineering, cybersecurity, facilities, legal, human resources, and communications.

Penetration tests

Penetration tests are required at least annually and should be done by an external provider. 

User Access Reviews

User access reviews are typically performed quarterly and should involve a review of all systems in the scope of your audit, including your organization's own platform. Be sure to date stamp and include a sign off to signal the completion date for the review as well as who the reviewer was. For any user indicated as needing to have their access modified or removed there should be associated tracking documentation for when that modification/removal took place.

External Vulnerability Scans

External vulnerability scans are typically done quarterly but the frequency is up to your organizations discretion. The reason why quarterly is a common cadence is to catch any vulnerabilities introduced by changes that have been made to your environment in the time between your annual penetration tests. There are organizations who will run vulnerability scans on a more frequent basis than that as well, the frequency of how often you want to perform vulnerability scans is typically determined by your organizations risk appetite when it comes to potential vulnerabilities.

Data Request List (DSR)

The DSR is a detailed document or checklist provided by auditors to the organization undergoing the audit. It outlines all the specific evidence, documentation, and data that the auditors need to assess whether the organization meets the requirements of the applicable SOC framework (SOC 1, SOC 2, or SOC 3). Again, the DRLs usually would come from an auditor, but the controls and tests in Secureframe can also act as a checklist of sorts if needed. 

Frequently Asked Questions (FAQ)

When should we start the SOC 2 renewal process?

• Depending on your internal resources, a general guideline here would be starting 6 months before your current report expires. This allows your team time for the following:
• Conduct a readiness assessment to address any gaps.
• Schedule the audit (auditors can book quickly).
• Gather compliance evidence that are now stale (e.g., logs, policies).
• Starting early prevents delays, stress, and ensures continuous compliance.