SOC 2 Readiness Checklist: A 90-Day Plan for Security, Evidence, and Audit Preparation

Overview

SOC 2 audit preparation asks an organization to demonstrate that its stated controls operate as intended. The exact scope depends on the services, systems, commitments, and Trust Services Criteria included in the engagement. Before building a checklist, confirm the intended scope with the relevant stakeholders and audit firm. A readiness plan should support that scope rather than attempt to document every process in the company.

The most useful readiness work connects four elements:

• Control: What risk is being addressed, and what activity is expected?
• Owner: Who performs, reviews, or approves the activity?
• Evidence: What record demonstrates that the activity occurred?
• Exception handling: What happens when the control is missed or produces an unusual result?

Use a central control and evidence register to track these elements. It can be a compliance platform, a structured spreadsheet, or another system that provides clear ownership, due dates, links to evidence, review notes, and remediation status. The tool matters less than consistent updates and a defensible record of decisions.

For a broader view of the process, see SOC 2 Readiness Checklist: A Practical Guide to Preparing for Your Audit. The checklist below focuses on a practical 90-day execution cycle.

Checklist by scenario

Days 1–30: Establish scope and identify gaps

Start with a short scoping workshop involving security, engineering, IT, legal or privacy, operations, and an executive sponsor. Record the service being assessed, relevant products, production environments, supporting systems, locations, personnel, and material third-party dependencies.

• Confirm which service and systems are in scope.
• Document the data flows that support the service, including important customer and employee information.
• List critical infrastructure, repositories, identity systems, monitoring tools, and support platforms.
• Identify control owners and backup owners for each process.
• Map existing policies and procedures to the selected control objectives.
• Open a risk register for missing controls, inconsistent practices, and unclear responsibilities.
• Record exclusions and the rationale for each exclusion.
• Define how evidence will be named, stored, reviewed, and retained.

Do not treat a policy inventory as a control assessment. A policy can describe an expected practice, but readiness also requires evidence that the practice is implemented. For example, an access control policy should connect to user provisioning records, periodic access reviews, termination records, and an escalation path for exceptions.

Use the risk register guide for compliance teams to structure risk descriptions, owners, treatment decisions, and target dates.

Days 31–60: Implement controls and collect operating evidence

Once gaps are prioritized, address the controls that affect security, access, change management, incident response, vendor oversight, and business operations. Prioritize controls that are both high risk and dependent on recurring human activity; these are more likely to fail when ownership or scheduling is unclear.

• Review employee and contractor access to production systems, source code, cloud environments, and sensitive business tools.
• Remove unnecessary access and document approvals for privileges that remain.
• Verify that joiner, mover, and leaver workflows have defined triggers and responsible teams.
• Confirm that changes to production systems are requested, reviewed, tested, approved, and traceable.
• Run or review an incident response exercise and record follow-up actions.
• Review vulnerability management, security monitoring, backup, and recovery workflows.
• Collect vendor due diligence, security documentation, contracts, and data processing terms where relevant.
• Test that security and compliance policies are distributed to the right personnel and that required acknowledgments are recorded.

Evidence should be specific enough for an independent reviewer to understand what happened, when it happened, who performed it, and whether exceptions were resolved. A screenshot without context may be difficult to interpret. Prefer exports, tickets, review logs, approval records, and system reports that preserve dates and responsible users.

For a more detailed evidence workflow, review how to prepare evidence for every Trust Services Criterion.

Days 61–90: Test, remediate, and prepare the audit room

The final phase should resemble a controlled internal review, not a document collection sprint. Sample evidence across the period under review, check that files are complete, and ask control owners to explain how the activity works without relying on a prepared script.

• Perform an internal walkthrough of each in-scope control.
• Check that evidence covers the required time period and frequency.
• Reconcile system inventories, user lists, vendor lists, and application owners.
• Review open risks and determine which items require remediation, acceptance, or disclosure.
• Resolve duplicate, stale, incomplete, or incorrectly labeled evidence.
• Prepare a request tracker for auditor questions and evidence follow-ups.
• Confirm who can answer questions about infrastructure, access, incidents, vendors, privacy, and business continuity.
• Run a leadership review of scope, material gaps, exceptions, and remaining decisions.

Keep an audit trail for late evidence and remediation. If a control was not operating consistently, document the cause, impact assessment, corrective action, owner, and completion date. A transparent explanation is more useful than silently replacing evidence or changing a record after the fact.

What to double-check

Before declaring the project audit ready, inspect the connections between systems and processes. These are common places where an otherwise organized program becomes difficult to validate.

• Scope consistency: Make sure the system boundary, architecture diagram, asset inventory, policies, and evidence register describe the same service.
• Access review quality: Check whether reviewers had enough information to identify inappropriate access, rather than merely signing a list.
• Evidence dates: Confirm that evidence falls within the relevant period and shows the required review or approval date.
• Ownership: Ensure every control has an accountable owner who understands the expected frequency and escalation process.
• Vendor dependencies: Identify where a critical service relies on a provider’s security documentation, contractual commitment, or availability.
• Change records: Compare deployment activity with change tickets or approvals so that the process reflects actual engineering practice.
• Exceptions: Check that exceptions are risk-assessed, approved by the right person, time-bound where appropriate, and tracked to closure.
• Privacy overlap: Where personal data is involved, align security controls with privacy procedures, retention decisions, and data-processing documentation. The GDPR compliance checklist for SaaS companies can help identify related privacy work.

Common mistakes

1. Writing policies before defining the operating model. Policies should describe practices the organization can actually perform and monitor.
2. Collecting screenshots without an evidence standard. Establish naming, date, owner, source, and context requirements before collection begins.
3. Assigning controls to a department instead of a person. A team may support a control, but a named owner should be accountable for completion.
4. Leaving vendor risk until the end. Third-party dependencies often affect scope, availability, confidentiality, and evidence expectations. Use a structured vendor risk assessment workflow early.
5. Assuming tools create compliance automatically. A compliance platform can schedule reviews and organize evidence, but it does not replace judgment, approvals, or remediation.
6. Ignoring recurring operations. A control that works once may still fail as a routine process. Test the cadence, not just the initial implementation.
7. Failing to record exceptions. Missing evidence should create a tracked issue with a decision, owner, and next step rather than disappearing from the register.

When to revisit

Use this SOC 2 readiness checklist before each audit planning cycle and whenever the underlying environment changes. Revisit it after a major product launch, new cloud or infrastructure provider, acquisition, organizational restructuring, material incident, identity-system change, or significant change to customer data flows.

At a minimum, schedule recurring reviews for access, vendors, risks, policies, incidents, changes, and evidence quality. The exact frequency should match the control design and your audit scope. Do not wait for an auditor request to discover that a review was missed.

For the next practical step, create a 90-day tracker with these columns: control, risk addressed, owner, required frequency, evidence source, last completed date, next due date, exception status, remediation owner, and reviewer notes. Assign the first control owners, populate known gaps, and schedule a short weekly review. That simple operating rhythm turns a one-time SOC 2 project into audit-ready compliance that can be maintained when workflows, systems, and tools change.