A SOC 2 readiness gap analysis is a pre-audit working assessment that compares your intended SOC 2 report scope with your current controls, operating practices, documentation, and available evidence. The goal is to answer one operational question: what must be fixed, evidenced, assigned, or clarified before we proceed to audit?
The useful output is not a completed checklist, it is a prioritized remediation roadmap, a gap register, and an evidence-backed view of whether the organization is ready for a Type 1 or Type 2 SOC 2 examination.
What is a SOC 2 readiness gap analysis?
A SOC 2 examination evaluates a service organization’s system description and controls relevant to security, availability, processing integrity, confidentiality, or privacy, according to the AICPA’s SOC 2 reporting guidance. A readiness gap analysis happens before that examination. Before the auditor tests anything. It checks whether the controls you intend to rely on are designed, operating, owned, documented, and supported by evidence.
For a Type 1 report, readiness focuses on whether the system description and control design are accurate as of a specified date. For a Type 2 report, readiness also needs to consider whether controls have operated consistently over the period the report will cover, because a Type 2 report also tests operating effectiveness over a specified period, as described in Deloitte’s overview of SOC report types.
This is different from post-audit remediation. A readiness analysis is designed to find and fix issues before the auditor tests the controls.
Define the audit scope before you look for gaps
A readiness assessment is only useful if it is scoped to the system and criteria you actually intend to include in the SOC 2 report.
Start by defining:
- The product, service, or platform in scope.
- The systems that support it, such as cloud environments, identity providers, code repositories, CI/CD tools, ticketing systems, endpoint management, monitoring, and logging platforms, as applicable.
- The data types and data flows relevant to the service.
- The teams and control owners involved in operating the system.
- Key vendors and outsourced services that affect the scoped system.
- Evidence sources, such as tickets, logs, access review records, approvals, training records, risk reviews, and policy acknowledgments.
SOC 2 uses the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is basically the required common category; additional categories should be included where they are relevant to the scoped service commitments, system requirements, and risks, based on the AICPA Trust Services Criteria and SOC reporting guidance.
Do not add categories because they sound broad. Consider documented service commitments, contracts, risk assessments, customer requests, and real data handling. A platform that processes regulated customer data may have different scope considerations than an internal workflow tool with limited data exposure.
Map current controls to selected Trust Services Criteria
Once the scope is defined, inventory the controls that already exist and map them to the selected criteria or control areas. The mapping should show not only that a control exists, but how it works and how it can be proven.
For each control, document:
- What risk or requirement the control addresses.
- Who owns it.
- How often it operates.
- Which system, team, or process it applies to.
- What evidence demonstrates design and operation.
- Where exceptions are tracked and resolved.
Common areas to review may include access management, change management, vulnerability management, incident response, logging and monitoring, vendor management, security training, backup and recovery, and policy governance, depending on the scoped service.
Use more than policy review. Interview control owners, inspect system configurations, sample tickets, review approvals, check logs, and compare stated procedures with actual operating evidence. The AICPA’s SOC 2 guidance addresses evaluating control design and effectiveness, so a readiness assessment should distinguish a written policy from actual control operation that can be evidenced.
A common readiness issue is a control that looks complete on paper but has no consistent proof. For example, an access review policy may require quarterly reviews, but if the team cannot produce review records, approver names, dates, exceptions, and removal evidence, the control is not ready to rely on without remediation.
Identify and classify readiness gaps
Use a practical working taxonomy so findings are specific enough to fix. These categories are internal assessment labels, not formal AICPA finding types. Most findings will fall into one category. More accurately, some will overlap, but the label should still point to the fix.
| Gap type | What it means | Example |
|---|---|---|
| Design gap | The control does not exist or does not address the relevant risk. | No defined process for reviewing privileged access. |
| Operating gap | The control exists but is not performed consistently. | Access reviews are required quarterly but only one review occurred. |
| Documentation gap | The control operates but the procedure is unclear or outdated. | Incident response steps exist in practice but are not reflected in the approved plan. |
| Evidence gap | The control may operate, but proof is missing or incomplete. | Deployment approvals happen in chat but are not retained with the change ticket. |
| Ownership/process gap | No clear owner, cadence, escalation path, or exception process exists. | Vulnerability remediation has no accountable owner or severity-based workflow. |
Write each finding so it can move directly into remediation. A usable finding includes:
- Condition: what is missing, inconsistent, or unclear.
- Affected TSC or control area.
- Risk or impact.
- Required remediation.
- Owner.
- Evidence needed for closure.
Example finding:
Condition: Quarterly user access reviews are documented in policy, but no completed review records were available for the production identity provider. Control area: Logical access. Risk/impact: Inappropriate access may remain active without detection. Remediation: Perform and document access review for in-scope groups; remove or approve exceptions. Owner: IT/security operations. Closure evidence: Review export, approver sign-off, exception list, removal tickets, and review date.
Score and prioritize gaps before building the remediation roadmap
Do not remediate in checklist order. Prioritize gaps based on risk, audit dependency, and the work needed to produce reliable evidence.
The following matrix is an internal planning aid. It is not an auditor-approved scoring method or a SOC 2 requirement.
| Factor | Score 1 | Score 2 | Score 3 |
|---|---|---|---|
| Risk/impact | Limited impact to scoped system or evidence quality | Meaningful control weakness or customer-facing process impact | Material weakness in a key control area or scoped system |
| Likelihood | Unlikely or isolated | Possible or recurring in limited areas | Likely, recurring, or systemic |
| Urgency | Can be remediated after higher-risk items | Needed before readiness decision | Blocks audit readiness or Type 2 operating evidence |
| Business impact | Low operational or customer impact | Affects internal delivery or customer assurance responses | Affects critical service commitments, contracts, or risk acceptance |
| Remediation complexity | Simple documentation or evidence cleanup | Requires process change, owner assignment, or tooling adjustment | Requires control redesign, engineering work, or cross-team coordination |
| Priority outcome | Low | Medium | High |
Use the scoring to sequence work:
- Fix high-risk, high-likelihood gaps first.
- Address design gaps and evidence blockers before cosmetic policy cleanup.
- Resolve dependencies before downstream controls. For example, if change tickets are not consistently created, deployment approval evidence will also be unreliable.
- Treat Type 2 operating evidence carefully. If a control needs to operate over the report period, late remediation may affect when that control can support the intended examination period.
Build the SOC 2 readiness gap register
The gap register is the single source of truth for remediation. It should connect each finding to an owner, due date, priority, required evidence, and readiness status.
| TSC/control area | Current control | Gap description | Gap type | Risk/impact | Likelihood | Priority | Remediation action | Owner | Due date | Required evidence | Closure status | Audit-readiness notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Logical access | Quarterly access reviews are required by policy for production systems. | No completed access review record was available for the production identity provider groups in scope. | Evidence gap / operating gap | Inappropriate production access may remain active without review. | Medium | High | Run access review for in-scope groups, document approvals, remove exceptions, and retain records. | Security operations lead | YYYY-MM-DD | User/group export, reviewer sign-off, exception list, removal tickets, review date. | Open | Do not mark ready until review evidence is complete and tied to scoped production groups. |
At minimum, include these columns:
- TSC/control area.
- Current control.
- Gap description.
- Gap type.
- Risk/impact.
- Likelihood.
- Priority.
- Remediation action.
- Owner.
- Due date.
- Required evidence.
- Closure status.
- Audit-readiness notes.
Review the register regularly until every high-priority item has closure evidence or a documented, accepted rationale. A gap is not closed because a task was marked done; it is closed when the required evidence supports the remediated control in the scoped system.
Collect evidence that proves remediation is closed
Treat “fixed” as a readiness standard: the control is designed, operating, documented, owned, and evidenced. This is conservative internal guidance, not a guarantee of audit outcome.
Depending on scope, closure evidence may include:
- Access reviews: review records, reviewer name, date, population reviewed, exceptions, approvals, and removal tickets.
- Change management: change tickets, approvals, test results, deployment logs, rollback notes, and emergency change reviews.
- Vulnerability management: scan results, triage records, severity decisions, remediation tickets, exception approvals, and retest evidence.
- Incident response: approved incident response plan, tabletop records or incident records, timelines, decisions, and post-incident review notes.
- Vendor management: vendor risk review, security documentation, approval records, contract or data processing documentation where applicable, and periodic review evidence.
- Security awareness: completion records, policy acknowledgments, assigned populations, and follow-up for incomplete training.
Before closing a gap, check that the evidence:
- Belongs to the scoped system or process.
- Covers the right date or period for the intended report type.
- Shows who performed or approved the control.
- Shows exceptions and how they were resolved or accepted.
- Can be retrieved and explained by the control owner.
If evidence exists but no one can explain the cadence, owner, or exception process, the gap may have shifted from an evidence gap to an ownership or process gap, at least for assessment purposes.
Validate automated findings with human review
Automation can support readiness work by organizing tasks, surfacing missing evidence, flagging configuration issues, and helping teams monitor control activity. It should not be treated as a substitute for readiness judgment.
AICPA ethics guidance on SOC tools notes that tools may support control design, operation, monitoring, and readiness activities, but the service auditor must retain judgment over scope, timing, evidence, deficiencies, and independence. Same idea in day-to-day work: a tool can point at a gap, but a person still has to decide whether it is actually a gap before it becomes a readiness finding.
Use this workflow:
- Review the automated finding.
- Confirm the system is in scope.
- Confirm the control owner.
- Determine whether the issue is real, accepted, compensated for, or out of scope.
- Attach supporting evidence.
- Update the gap register.
- Confirm remediation and closure evidence before marking the item ready.
For example, a tool may flag missing multi-factor authentication evidence for an application. Human review still needs to confirm whether the application is in scope, which user population matters, whether a compensating access control exists, and what evidence would support closure.
Decide whether you are ready to proceed to audit
Use the completed gap analysis to make a readiness decision, not just to show activity.
You are closer to proceeding when:
- The report scope is defined.
- Controls are mapped to selected Trust Services Criteria.
- High-priority gaps are remediated or have documented risk treatment.
- Closure evidence is complete and tied to scoped systems.
- Control owners, cadences, and exception paths are clear.
- Type 2 control evidence supports operation over the intended period.
- Automated findings have been validated by accountable owners.
- The remediation roadmap is current and defensible.
Pause before proceeding if major design gaps remain, key control evidence is missing, ownership is unclear, or the team cannot explain how critical controls operate. These conditions do not automatically determine the audit outcome, but they are strong signals that readiness work is incomplete.
A readiness consultant or platform can help prepare the organization, but the SOC 2 examination report is issued by an independent licensed CPA firm. Involve your auditor or a qualified advisor when scope, evidence sufficiency, or report timing is uncertain.
If you use Ciphrix to operationalize this workflow, keep the same discipline: map controls to the real environment, assign accountable owners, track remediation to evidence, and validate findings before treating them as audit-ready.