A SOC 2 readiness assessment is a pre-audit check of whether your scoped system, controls, policies, evidence, and operating processes are prepared for formal SOC 2 audit work. Use it to find gaps, assign remediation, verify fixes, and decide whether you are ready to move toward Type 1 or Type 2 examination activity. Before the audit clock really starts.
SOC 2 examines controls relevant to the security, availability, processing integrity, confidentiality, or privacy of systems used to provide products or services, according to the AICPA Trust Services Criteria. A readiness assessment helps you prepare for that examination, but it is not itself a SOC 2 report and does not guarantee the final audit outcome.
What Is a SOC 2 Readiness Assessment?
A SOC 2 readiness assessment is a management exercise performed before formal audit work. It evaluates whether the controls in scope are designed, implemented, evidenced, owned, and operating in a way that can support a future SOC 2 examination.
A formal SOC 2 engagement is an assertion-based examination of a service organization’s system description and relevant controls. Customers and business partners often request SOC 2 reports to obtain information about controls’ design, operation, and effectiveness. A readiness checklist or gap register is different, it is an internal preparation tool, not the independent service auditor’s report.
A practical readiness workflow is to define scope, assess current controls, map controls to applicable criteria, identify gaps, remediate them, and plan the attestation. Deloitte describes readiness assessment as a pre-audit activity used to understand control gaps and plan remediation before a future SOC attestation.
Before You Start: Define Scope, Audit Type, and Readiness Path
Before using the checklist, make three decisions. Otherwise, you may collect evidence for the wrong system, wrong control set, or wrong audit objective.
1. Define the audit scope
Document what is in scope:
- product, platform, or service
- system boundaries
- cloud infrastructure and supporting tools
- people and teams involved in operating the system
- locations, if relevant
- third parties that support the in-scope service
- customer commitments or system requirements that affect controls
Security is the required SOC 2 category. Availability, processing integrity, confidentiality, and privacy are additional categories selected for the engagement. Scope should account for the in-scope products and services, systems, locations, system boundaries, and relevant third parties.
Do not assume a category applies because of company type alone. Select additional categories based on the service provided, commitments made to customers, system requirements, and stakeholder needs.
2. Decide whether you are preparing for Type 1 or Type 2
The readiness evidence you need depends on the report type.
A Type 1 report addresses whether controls were suitably designed and placed in operation as of a specified date. A Type 2 report also addresses operating effectiveness over a specified period.
That distinction changes readiness work:
| Audit objective | Readiness focus | Evidence implication |
|---|---|---|
| Type 1 | Are controls designed and in place at a point in time? | Policies, control descriptions, configuration screenshots, ownership, approvals, and proof the control exists |
| Type 2 | Did controls operate over a period? | Recurring evidence across the period, such as access reviews, change approvals, backup records, monitoring alerts, incident records, and vendor reviews |
You do not need to publish a Type 1 before a Type 2 unless your audit plan requires it. The readiness question is whether your current evidence supports the report type you intend to pursue.
3. Choose a readiness path
You can run readiness internally, use an external readiness assessor, or use a platform-supported workflow. The right path depends on scope complexity, SOC 2 experience, and how distributed your evidence is. More accurately, it depends on which of those factors is most likely to slow the audit down.
Avoid planning from generic cost or timeline ranges. Readiness effort varies with scope, control maturity, selected criteria, reporting period, evidence quality, and advisor involvement.
Complete SOC 2 Readiness Assessment Checklist
Use this as an example readiness tracker. Tailor it to your in-scope system, selected Trust Services Criteria, service commitments, control design, and auditor procedures.
| Readiness area | What to check | Example evidence | Likely owner | Pass/fail indicator | Gap severity | Remediation action | Verification step |
|---|---|---|---|---|---|---|---|
| 1. Scope and system description | The system, services, boundaries, infrastructure, people, locations, and third parties are clearly defined. | Draft system description, architecture diagram, asset inventory, data flow diagram, third-party list | CTO, Head of Security, GRC lead | Pass if scope is documented, current, and approved by accountable owners. | Critical if audit scope cannot be supported. | Finalize system boundaries and remove ambiguity about included services or tools. | Review scope with executive owner, technical owner, and audit liaison. |
| 2. Governance and control ownership | Each control has an owner responsible for operation and evidence. | Control matrix, RACI, ownership register, policy approval records | GRC lead, COO, Security lead | Pass if every control has a named owner and backup. | High if controls exist but no one owns evidence or operation. | Assign owners and define evidence responsibilities. | Confirm each owner can explain the control and produce evidence. |
| 3. Policies and procedures | Required policies exist, are approved, and match actual operations. | Information security policy, access control policy, incident response plan, change management procedure, approval records | Security lead, Operations, HR | Pass if policies are approved, versioned, and operationally accurate. | Medium to High depending on missing policy relevance. | Update or create policies and obtain approval. | Compare policy requirements against actual workflow and evidence. |
| 4. Access control and identity management | User access is approved, role-based where appropriate, reviewed, and removed when no longer needed. | User access list, SSO/MFA configuration, access request tickets, access review records, termination checklist | IT, Security, Engineering managers | Pass if access is authorized, reviewed, and removable through a controlled process. | Critical or High for privileged access gaps. | Clean up access, enforce approval flow, complete access reviews. | Sample users from key systems and trace approval, review, and removal evidence. |
| 5. Change management | Production changes are reviewed, approved, tested, and traceable. | Pull requests, change tickets, deployment logs, approval records, test results | Engineering lead, DevOps | Pass if production changes have consistent records of review and approval. | High if changes lack approval or traceability. | Define change workflow and enforce required approvals. | Select recent changes and verify approval, testing, and deployment evidence. |
| 6. Infrastructure and cloud security | Cloud resources and infrastructure are configured according to approved security expectations. | Cloud configuration exports, network rules, encryption settings, vulnerability scans, infrastructure-as-code reviews | DevOps, Cloud engineering, Security | Pass if critical assets have documented secure configuration and review evidence. | Critical for exposed production assets or unmanaged privileged paths. | Remediate misconfigurations and document baseline settings. | Re-run configuration checks and retain before/after evidence. |
| 7. Logging, monitoring, and alerting | Relevant security and operational events are logged, monitored, and escalated. | SIEM or logging configuration, alert rules, escalation records, monitoring dashboards, alert tickets | Security, SRE, DevOps | Pass if key systems generate logs and alerts have an owner and response path. | High if critical systems lack logging or alert handling. | Enable logging, define alert ownership, document escalation. | Trigger or review sample alerts and verify response evidence. |
| 8. Incident response | The team has a defined process for identifying, escalating, investigating, and documenting incidents. | Incident response plan, incident tickets, post-incident reviews, escalation contacts, tabletop records | Security lead, Engineering, Operations | Pass if the process exists and responders know their roles. | High if no incident process exists. | Approve plan, assign roles, test escalation path. | Review a recent incident or tabletop and confirm documentation completeness. |
| 9. Risk assessment | Security and operational risks are identified, evaluated, assigned, and tracked. | Risk register, risk assessment meeting notes, treatment plans, risk owner list | Security lead, GRC lead, Executive sponsor | Pass if material risks have owners and treatment status. | Medium to High depending on untracked risk relevance. | Create or update risk register and assign treatment actions. | Verify high-priority risks have owner, decision, and follow-up evidence. |
| 10. Vendor and third-party risk | In-scope vendors are identified and reviewed based on their role in the service. | Vendor inventory, security questionnaires, SOC reports from vendors, risk ratings, renewal review records | Procurement, Security, Operations | Pass if relevant vendors have risk review evidence. | High if critical vendors are unreviewed. | Complete vendor reviews and document risk decisions. | Select critical vendors and verify review, approval, and current evidence. |
| 11. Data protection and confidentiality controls | Sensitive or confidential data is identified and protected according to commitments. | Data classification, encryption configuration, key management records, DLP settings, access restrictions | Security, Engineering, Data owner | Pass if protected data is identified and safeguards are evidenced. | Critical if sensitive data is unprotected or access is uncontrolled. | Document data flows, restrict access, validate encryption and handling controls. | Trace sample data stores to protection controls and access evidence. |
| 12. Availability, backup, and recovery controls | Availability commitments, backups, and recovery processes are documented and tested where applicable. | Backup logs, restore test records, uptime monitoring, incident records, recovery procedures | SRE, DevOps, Engineering | Pass if backup and recovery evidence aligns with commitments. | High if backups exist but cannot be restored or evidenced. | Define backup schedule, test restoration, document results. | Review backup history and verify a completed restore test. |
| 13. HR and employee lifecycle controls | Hiring, onboarding, role changes, training, and offboarding are controlled. | Background check records where applicable, onboarding checklist, policy acknowledgements, termination tickets, access removal evidence | HR, IT, Security | Pass if lifecycle events trigger required access and policy steps. | High if terminated users retain access. | Align HR events with IT access workflows and evidence capture. | Sample new hires and leavers and trace completed steps. |
| 14. Security awareness and training | Employees receive relevant security training and acknowledge required policies. | Training completion reports, policy attestations, phishing simulation records if used | HR, Security | Pass if assigned personnel have completed required training. | Medium if training records are incomplete; High if required roles are untrained. | Assign overdue training and retain completion records. | Export completion report and reconcile against employee list. |
| 15. Evidence collection and retention | Evidence is organized, current, and mapped to controls. | Evidence repository, control-to-evidence matrix, retention rules, evidence owner list | GRC lead, Control owners | Pass if each control has current evidence and a named evidence owner. | Medium to High if evidence exists but cannot be retrieved or mapped. | Build evidence index and remove stale or duplicate artifacts. | Walk through each control and confirm evidence is accessible and dated. |
| 16. Type 2 operating evidence, if applicable | Recurring controls have evidence across the review period, not only at the end. | Monthly access reviews, change approvals over time, backup logs, incident reviews, vendor reviews, risk review records | GRC lead, Control owners | Pass if operating evidence covers the intended review period. | High if control operated but evidence is missing; Critical if control did not operate. | Restart recurring control cadence and document exceptions. | Test samples across the period and confirm evidence consistency. |
Treat “pass” as readiness confidence, not audit approval. The CPA firm determines audit procedures and final report outcomes.
How to Prioritize and Remediate SOC 2 Readiness Gaps
Do not remediate checklist failures in the order you find them. Prioritize based on audit impact, risk, and whether the gap affects your ability to support Type 1 design or Type 2 operating effectiveness.
Use this as basically a simple internal prioritization model, not an AICPA scoring system:
| Severity | Use when | Remediation priority |
|---|---|---|
| Critical | A control is absent, audit scope cannot be supported, or high-risk evidence is missing for a core area such as privileged access or system boundaries. | Fix before audit activity proceeds. |
| High | A control exists but is inconsistent, undocumented, or lacks operating evidence. | Fix before fieldwork or before the Type 2 review period continues with weak evidence. |
| Medium | Evidence exists but is incomplete, stale, unmapped, or difficult to retrieve. | Fix before evidence requests begin. |
| Low | Formatting, ownership clarification, naming, or repository cleanup is needed. | Fix after higher-risk gaps, but before evidence packaging. |
Prioritize gaps that affect:
- the in-scope system boundary
- Security controls, because Security is required for SOC 2
- additional selected categories such as availability or confidentiality
- privileged access, production change, incident response, backups, or vendor dependencies
- customer commitments reflected in contracts or service descriptions
- Type 2 recurring evidence, because missing operation over time may not be fixable retroactively
Good remediation should produce more than a status update. Each gap should have:
- owner
- due date
- corrective action
- required evidence
- verification method
- current status
- final readiness decision
For Type 1, remediation usually focuses on whether the control is designed, approved, implemented, and evidenced as of the target date. For Type 2, remediation must also consider whether the control has operated consistently over the review period and whether exceptions were documented and addressed.
Sample SOC 2 Readiness Gap Register or Report Outline
A readiness gap register is the working output of the assessment. It should let leadership, control owners, and the audit liaison see what is blocking readiness and what evidence is still needed.
Use this as a sample internal gap register:
| Field | Example |
|---|---|
| Finding ID | SOC2-RA-004 |
| Finding summary | Quarterly access review evidence is missing for the production admin group. |
| Affected readiness area | Access control and identity management |
| Affected TSC/control area | Security / logical access controls |
| Risk level | High |
| Required evidence | Completed access review showing reviewer, date, population reviewed, exceptions, and remediation actions |
| Current status | In remediation |
| Owner | IT manager |
| Remediation action | Export current admin list, perform review, remove inappropriate access, document approval and exceptions |
| Target date | Insert internal target date |
| Verification method | Reconcile admin group membership to approved access review evidence |
| Final readiness decision | Not ready until review is completed and retained |
The same structure can be used for other findings, such as incomplete change approval records, missing backup restore evidence, or outdated policy approvals, and similar gaps.
Keep these deliverables distinct:
- Internal gap register: management tracker for findings, owners, evidence, and remediation status.
- External readiness findings summary: advisory output, if you use an external readiness assessor; format and content vary by provider and engagement.
- Audit evidence package: evidence prepared for the CPA firm’s audit procedures.
- Formal SOC 2 report: not produced by the readiness assessment. A formal SOC 2 report includes management’s assertion, a system description, and the independent service auditor’s report; Type 2 reporting also includes testing information and results.
Self-Assessment, External Readiness Assessment, or Platform-Supported Readiness?
Choose the execution model based on complexity, experience, and coordination needs. The point is to pick the path that matches the situation, not to make this more formal than it needs to be. This is a practical decision aid, not an audit requirement.
| Readiness path | May fit when | Main risk to manage |
|---|---|---|
| Internal self-assessment | Scope is simple, the team has SOC 2 experience, evidence is already organized, and leadership accepts the risk of internal blind spots. | Teams may overrate controls they operate themselves or miss evidence gaps. |
| External readiness assessment | The company is preparing for its first audit, scope is complex, customer pressure is high, or internal SOC 2 expertise is limited. | Findings still require management ownership and remediation. |
| Platform-supported readiness | Evidence is spread across cloud, identity, ticketing, HR, and engineering systems; multiple owners need coordinated remediation; or readiness needs to be tracked continuously. | Tooling does not replace control ownership, professional judgment, or the CPA firm’s audit procedures. |
If you are evaluating Ciphrix or another platform-supported approach, assess whether it can support the workflow you need: mapping evidence to controls, assigning owners, tracking remediation, and keeping evidence current across operational systems. Do not treat any platform as a substitute for management responsibility or independent audit work.
How to Know You’re Ready for SOC 2 Type 1 or Type 2 Audit Work
You may be ready to move toward Type 1 audit activity when:
- scope and system boundaries are documented
- selected Trust Services Criteria are identified
- controls are designed and placed in operation
- policies are approved and match actual processes
- control owners are assigned
- point-in-time evidence exists for relevant controls
- critical and high gaps are remediated or have a defensible plan
You may be ready to move toward Type 2 audit activity when:
- recurring controls have operated over the intended review period
- evidence exists across the period, not only at the end
- access reviews, change approvals, backups, incident reviews, risk reviews, and vendor reviews have retained records where applicable
- exceptions are documented, assessed, and addressed
- control owners can explain how the process operates and where evidence is stored
A readiness checklist can still reduce audit surprises, but it cannot guarantee SOC 2 success. Use the checklist to decide what to fix, what to verify, and what still needs to be discussed with your CPA firm before formal audit work begins.