A SOC 2 audit readiness checklist helps a SaaS company find missing evidence before fieldwork begins. This guide explains what to track, who should own each control, how to review recurring evidence, and when to repeat the gap assessment as systems, staff, and scope change.
Overview
SOC 2 preparation is not only a final document-collection exercise. It is an operating routine that connects security controls to accountable owners, repeatable activities, and evidence an auditor can evaluate. The exact requirements depend on the engagement scope, selected Trust Services Criteria, system description, audit period, and auditor instructions. Treat this article as a readiness workflow rather than a substitute for the engagement’s agreed testing plan.
Start by defining the in-scope services, production environments, supporting systems, offices, personnel, and third parties. Then create a control inventory that answers four questions for every control:
- What risk does the control address?
- Who performs or approves it?
- How often does it occur?
- What dated evidence demonstrates that it operated as intended?
Keep the control inventory separate from a general policy library. A policy may describe an expectation, but audit readiness also requires evidence that the organization followed the expectation during the relevant period. For broader framework context, see ISO 27001 vs. SOC 2 vs. NIST CSF.
What to track
1. Scope and system changes
Maintain a change log for production applications, cloud accounts, repositories, identity platforms, subprocessors, major data flows, and teams with administrative access. For each change, record the date, approver, affected control or system, and whether new evidence is required. Scope drift is a common readiness problem because a control may be documented for one environment while the service actually relies on another.
2. Access reviews and joiner, mover, and leaver activity
Track user access reviews for critical systems, privileged accounts, service accounts, and repositories. Evidence should make it possible to identify the reviewer, review date, population reviewed, exceptions found, and remediation status. Also retain samples or system records showing that new access, role changes, and termination-related access removal followed the approved process. Assign separate owners where appropriate: an identity administrator may produce system exports, while a system owner approves business access.
3. Security awareness and personnel records
Monitor completion of security training, policy acknowledgments, role-specific training, and onboarding or offboarding tasks. A useful tracker includes the assigned population, due date, completion date, outstanding items, and escalation owner. Avoid relying only on a presentation or training policy; the recurring completion record is usually more useful for readiness.
4. Change management and software delivery
Track production changes, approvals, testing results, deployment records, emergency changes, and post-release review where applicable. Link samples to tickets, pull requests, build records, or release notes. Confirm that the evidence identifies the change, requester, approver, test result, deployment date, and any rollback or exception decision. If a control depends on automated checks, retain configuration evidence and records showing the checks operated during the review period.
5. Vendor oversight and contracts
Maintain a vendor register with service description, data handled, criticality, review date, assigned owner, security documentation, open issues, and renewal or reassessment date. Track due diligence for vendors that support the scoped service, including relevant assurance reports, questionnaires, contractual commitments, and remediation follow-up. A vendor risk assessment template can help standardize the record.
6. Incident response and security monitoring
Track security alerts, incident tickets, severity decisions, investigation notes, communications, corrective actions, and closure approvals. If no qualifying incident occurred, preserve the monitoring or review record that supports that conclusion rather than leaving the evidence folder empty. Schedule tabletop exercises and record participants, scenarios, decisions, lessons learned, and assigned follow-up actions. See the incident response plan template for a practical evidence structure.
7. Risk assessments, policies, and approvals
Keep the current risk assessment, risk register, treatment decisions, policy versions, approval dates, and review history together. Track whether policy changes triggered communication, training, or control updates. A policy without an owner, approval record, or review date is difficult to defend during an audit. The information security policy template provides a starting point for organizing those records.
Simple responsibility matrix
| Readiness activity | Primary owner | Supporting evidence |
|---|---|---|
| Access review | System owner | User population, review decision, remediation ticket |
| Change sample | Engineering or release owner | Ticket, approval, test result, deployment record |
| Vendor review | Procurement or security owner | Register entry, assessment, contract or assurance report |
| Incident exercise | Security or incident lead | Scenario, attendance, timeline, action items |
| Policy approval | Security or executive approver | Version history, approval, communication record |
The person who performs a control is not always the person who owns the risk. Record both roles when that distinction matters.
Cadence and checkpoints
Use a cadence that matches how quickly the environment changes. A monthly review is useful for operational evidence such as privileged access, open remediation items, incidents, overdue training, and significant production changes. A quarterly checkpoint can cover vendor reassessments, risk-register updates, policy exceptions, disaster recovery or continuity exercises, and management review. Annual activities may include formal policy approval, organization-wide risk assessment, training refresh, and audit-scope confirmation.
Before the audit period begins, run a baseline readiness review. Confirm that every control has an owner, frequency, evidence location, and defined population. During the period, sample evidence rather than waiting until the end. At least one checkpoint should compare the control inventory with the current architecture and vendor register.
Use a status model that distinguishes evidence states:
- Green: the activity occurred, evidence is complete, and the owner verified it.
- Amber: evidence exists but is incomplete, late, inconsistently formatted, or awaiting review.
- Red: the activity did not occur, the evidence cannot be located, or the control owner cannot explain the exception.
- Not applicable: the control does not apply to the documented scope, with a recorded rationale and approval.
Store evidence with consistent names and dates. A useful naming pattern includes the control identifier, activity, system, and period. Preserve the original record where practical, and restrict access to sensitive audit material.
How to interpret changes
Do not judge readiness by the number of files in an evidence folder. Look for trends that reveal whether the control is operating consistently. Repeated late access reviews may indicate unclear ownership or an unrealistic frequency. A growing number of emergency changes may point to planning or release-process issues. Repeated vendor exceptions may require risk acceptance, contract updates, or a different monitoring approach.
For each gap, record the condition, affected control, root cause, risk, interim measure, accountable owner, target date, and closure evidence. Separate a missing document from a failed activity. Reconstructing a record after the fact may explain what happened, but it should not be presented as contemporaneous evidence. Escalate material or recurring gaps through the organization’s risk process and retain the decision.
Also compare changes against the audit scope. A new cloud account, identity provider, data store, subprocessor, or deployment workflow can affect several controls at once. A scope change should trigger an impact review, not merely an update to a diagram. For recurring operational metrics and control monitoring, see continuous compliance monitoring.
When to revisit
Repeat the SOC 2 readiness review on a monthly or quarterly schedule, depending on the size and change rate of the environment. Revisit immediately after a major product launch, acquisition, cloud migration, identity-system change, significant security incident, control-owner change, or expansion of the audit scope. Run an additional review before auditor fieldwork and after any substantial remediation effort.
Use this action sequence for the next checkpoint:
- Export the current system, user, vendor, and repository inventories.
- Compare them with the documented SOC 2 scope and control matrix.
- Ask each control owner to confirm the activity, evidence location, and latest completion date.
- Sample recurring evidence and mark gaps as green, amber, red, or not applicable.
- Assign remediation owners and due dates, then record risk acceptance for unresolved items.
- Update policies, procedures, training, and the audit request tracker when the underlying process changes.
Keep the checklist as a living audit-readiness record rather than a once-a-year project plan. A regular review makes missing evidence visible while there is still time to correct the process, clarify responsibility, and give the auditor a coherent record of how controls operate.
