SOC 2 readiness checklist for mid-market

SOC 2 readiness means building the controls and collecting the evidence before an auditor starts, so the report reviews how you already work rather than a scramble to invent evidence. For a mid-market company the work usually takes a quarter of preparation focused on five areas: access, change management, vendor risk, operations, and response.

The checklist below is the structure we use. It assumes the Security criterion is in scope, which is the common starting point, and it notes where the optional criteria change the work.

What SOC 2 actually is

SOC 2 is an attestation report issued by a licensed CPA firm against the AICPA Trust Services Criteria. The Security criterion is required; availability, processing integrity, confidentiality, and privacy are optional and included when customers ask. A Type I report covers controls at a point in time. A Type II report covers how those controls operated over a period, which is the report most buyers actually want.

One distinction matters in every deal: the auditor issues the opinion, and the company achieves the report. There is no such thing as being certified to SOC 2, and any vendor describing itself that way is describing the engagement loosely. We prepare the controls and the evidence; the CPA firm performs the audit.

The sequence

1. Define the scope: which systems, people, locations, and data are in. Write down what is out.
2. Choose the criteria and the report type. Decide Type I or Type II and pick the observation period.
3. Run a gap assessment against the criteria and record the gaps with evidence.
4. Fix the gaps. Policies are the easy part; operating controls is the real work.
5. Collect evidence during the period, not after it.
6. Select the auditor and run a readiness review.
7. Start the observation period and keep the evidence file current.

Access control

• Single sign-on for core systems, with multi-factor authentication enforced.
• Role-based access, with a documented approval for every grant.
• Quarterly access reviews with a record of who reviewed what.
• A joiner, mover, and leaver process with tickets that can be sampled.
• Privileged accounts identified, limited, and logged.
• Passwords and session rules written down and enforced by policy.

Change management

• Code in a repository with pull requests and at least one reviewer.
• Automated tests and a documented deployment approval.
• Separate development, staging, and production environments.
• A change record that ties a business request to a deployment.
• Emergency change process for outages, with a retrospective.

Vendor and third-party risk

• A vendor inventory with an owner for each entry.
• Tiering by data access and business criticality.
• A security review before signing, with the date and result recorded.
• Annual reviews for critical vendors, including their attestations.
• Contract clauses for breach notification, data return, and deletion.

Operations and security controls

• Endpoint protection on every company device, with coverage reported.
• Vulnerability scanning and a patch cadence with exceptions documented.
• Backups on a defined schedule, plus a restore test with a record.
• Logging with retention long enough to investigate an incident.
• An incident response plan with roles, contacts, and a tabletop exercise.
• A documented risk assessment, reviewed at least annually.

Organisation and people

• A written security policy set, approved by management and dated.
• Security awareness training assigned to everyone, with completion records.
• Background checks or screening where the business requires them.
• Defined security roles, including who owns the program.
• Evidence of management or board oversight, such as a review meeting record.

Collecting evidence once

The practical win is to collect evidence once and map it to several frameworks. An access review supports SOC 2, ISO 27001, and NIST CSF at the same time. Build a folder per control with the source system, the owner, and the date. Link to the system record where possible instead of storing screenshots, because a screenshot proves a moment while a system log proves the period.

Common failure modes

• Buying a compliance platform before defining what the controls are.
• Treating policy templates as controls, when the auditor asks for evidence of operation.
• Starting evidence collection after the observation period begins.
• No named owner, so every request lands on whoever is least busy.
• Scope creep, where every system gets included and the audit never closes.

How the work fits together

If a customer has asked for SOC 2, the shortest path is a readiness review that produces a control-gap list, a remediation plan, and an evidence architecture. The Compliance & Audit Readiness service covers SOC 2, ISO 27001, NIST CSF, HIPAA, and PCI DSS readiness with that shared evidence model. If the starting point is unclear, our paid Security & AI Risk Diagnostic produces the gap list and roadmap first.

Request a briefing and tell us who is asking for the report and by when. That one detail decides most of the sequencing.