The gap assessment isn't the destination — it's the starting line
Most SaaS companies complete a SOC 2 gap assessment, get a report full of findings, and then... stall. The report is long. The gaps feel overwhelming. Nobody knows who owns what. Months pass, the audit deadline moves, and the same gaps are still open.
This guide walks through a structured SOC 2 remediation approach: how to prioritise, who should own what, what evidence auditors actually need, and a 90-day plan to go from gap assessment to audit-ready.
What changes between gap assessment and audit
A gap assessment tells you what controls you're missing or need to strengthen. The audit tests whether those controls are actually in place and operating effectively over time (for Type II).
The gap between assessment and audit has three parts:
- Implement: Build or configure the controls you're missing (e.g., enable MFA, create an access review process, configure branch protection)
- Operate: Run those controls for a period of time (for Type II, at least 3-6 months — 12 months is common for enterprise buyers)
- Evidence: Collect proof that the controls operated effectively — the PBC (Prepared By Client) list is what the auditor samples
Many companies fail at the third step. They implement the control but don't collect evidence. The auditor arrives, asks for proof, and the company scrambles to reconstruct something that may or may not satisfy the auditor.
The Trust Service Criteria audit plays out in CC order
The AICPA TSC are structured around nine Common Criteria (CC1-CC9) plus optional criteria for Availability (A1), Confidentiality (C1), Processing Integrity (PI1), and Privacy (P1-P8). Understanding what each CC group tests helps you prioritise remediation.
| Criterion | What Auditors Focus On | Most Common Remediation Need |
|---|---|---|
| CC1 Control Environment | Code of conduct, org structure, management accountability | Signed code of conduct, management review minutes |
| CC2 Communication | Policy communication, security training completion | Policy acknowledgement records, training completion screenshots |
| CC3 Risk Assessment | Annual risk assessment, risk register | Documented risk assessment with date, risk register |
| CC4 Monitoring | Pen test, vulnerability scans, internal audit | Pen test report within 12 months, quarterly scan reports |
| CC5 Control Activities | Policy library, ITGC documentation | Policy document set with effective dates, approval records |
| CC6 Logical Access | Access provisioning, offboarding, MFA, encryption, network controls | Most heavily tested — access review records, offboarding tickets, MFA config |
| CC7 System Operations | Vulnerability management, monitoring, IRP, incident log | Patch records, SIEM dashboards, IRP test evidence, incident log |
| CC8 Change Management | PR records, branch protection, CI/CD logs, emergency changes | GitHub branch protection config, PR records, emergency change log |
| CC9 Risk Mitigation | BCP/DRP, vendor risk management, third-party reviews | BCP/DRP document + test records, vendor SOC 2 reports reviewed |
The 90-day remediation framework
The goal of the 90-day framework isn't to fix everything — it's to fix the things that will fail the audit if unresolved, create a clean audit period start, and position the company to maintain controls continuously rather than sprinting before each audit.
Days 1-30: Fix critical gaps and establish the control environment
The first 30 days should focus on the controls that auditors will test first and fail without — specifically CC6 (access controls) and CC8 (change management). These two criteria generate more audit findings than all the others combined.
Access control priorities (CC6):
- MFA enforcement: Enable MFA for all staff on SSO/IdP, cloud consoles (AWS, GCP, Azure), and code repositories. Export a screenshot of MFA enforcement settings as evidence. This takes hours, not days.
- Offboarding SLA: Define and document a same-day offboarding SLA. Create a checklist (SSO disable, email, GitHub, cloud access, SaaS apps). Run it next time someone leaves and keep the ticket as evidence.
- Access review: Conduct a quarterly access review. Export a user list from your IdP, cross-reference against your HR system, remove any stale accounts. Keep the export + removal record.
- Encryption at rest: Verify database encryption and S3 bucket encryption are enabled. Export configuration screenshots.
Change management priorities (CC8):
- Branch protection rules: Enable branch protection on
main: require pull requests, at least 1 reviewer, status checks passing, no force pushes, no direct commits. Screenshot the settings. - CI/CD log retention: GitHub Actions default is 90 days — this may not cover your entire audit period. Export or ship logs to S3/CloudWatch. Document the retention policy.
- Emergency change procedure: Create a short doc defining what an emergency change is, who can approve it, and that retroactive review is required within 24-48 hours. This covers auditor questions about the 1-3 times a year you bypass the normal process.
Days 31-60: Operations, monitoring, and policy documentation
With the critical access and change management controls in place, the second month focuses on CC7 (system operations), risk assessment (CC3), and ensuring the policy library is complete.
- Vulnerability scanning: Run a credentialed internal scan and an external scan. If you haven't done a pen test in the last 12 months, schedule one — this is an absolute requirement for SOC 2 CC4.1/CC7.1 and you cannot pass without it.
- IRP test: Conduct a tabletop exercise of your incident response plan. Even a 1-hour session with 3 people going through a breach scenario satisfies this requirement. Document who attended, the scenario, and the discussion outcomes.
- Risk assessment: Complete a formal risk assessment covering your key assets and threats. It doesn't have to be elaborate — even a spreadsheet with assets, threat scenarios, likelihood, impact, and treatment decisions will satisfy CC3.2.
- Policy library review: Ensure your core policy documents exist and have been reviewed within the last 12 months. The minimum set: Information Security Policy, Incident Response Plan, Change Management Policy, Access Control Policy, Vulnerability Management Policy, HR Security Policy.
Days 61-90: Evidence collection sprint
The third month is about systematically collecting and organising the evidence the auditor will request. Build your PBC (Prepared By Client) list before the auditor sends theirs. This saves significant time during fieldwork.
The PBC list typically covers:
| Evidence Type | Format | Freshness Required |
|---|---|---|
| Policy documents (full set) | PDF with effective/review dates | Reviewed within 12 months |
| User access list (IdP export) | CSV/screenshot with timestamp | Current-state (within audit period) |
| Quarterly access review evidence | Exported list + approval record | Quarterly (sampled by auditor) |
| Offboarding tickets/records | JIRA/ServiceNow export or screenshots | Within audit period (auditor will sample 3-5) |
| MFA enforcement configuration | Screenshot with date | Current-state |
| Pull request records (sample) | GitHub PR list export + branch protection screenshot | Throughout audit period (auditor will sample) |
| Vulnerability scan reports | Scan output PDF | Quarterly (at least 1 within audit period) |
| Penetration test report | Full report + remediation tracking | Within 12 months of audit |
| IRP tabletop exercise | Meeting notes with attendees, scenario, findings | Annually (within audit period for Type II) |
| Security training completion records | Completion report from training platform | Annual training within audit period, new-hire training within 30 days |
| Risk assessment | Risk register or assessment document | Annual review, evidence of review date |
| Backup testing evidence | Restoration test record with date, RTO/RPO validation | Annual (within audit period) |
| Vendor risk assessment records | Questionnaires sent + received, vendor SOC 2 reports | Annual review for critical vendors |
5 common remediation mistakes that delay SOC 2
1. Starting the audit period before all controls are in place
For SOC 2 Type II, the audit period is fixed — typically 3, 6, or 12 months. If you start the period with controls missing, the auditor will find gaps for those months. The fix: define the audit period start date as the day ALL controls are in place. Be conservative — add a buffer of 30 days after you think you're ready.
2. No evidence, just configuration
Implementing a control is not the same as having evidence for an auditor. The auditor needs to sample evidence from across the audit period. A screenshot taken the week before the audit doesn't show operating effectiveness for 12 months.
Build evidence collection into your operating rhythm: when you run an access review, export the list and record the approval. When you do a security training session, download the completion report. When you patch a critical vulnerability, document the timeline.
3. Unclear control ownership
The most common reason controls slip is that nobody owns them. Every SOC 2 control should have a named owner (not a team — a person), a documented frequency, and a reminder or automated trigger. Use your remediation tracker to assign and track this.
4. Patching findings just for the audit
Auditors are experienced at spotting controls that were just stood up for the audit. Evidence timestamps, PR dates, and system configuration history don't lie. Build controls that will operate permanently, not just for the audit period.
5. Treating CC6 as a checkbox
CC6 (Logical and Physical Access) accounts for more SOC 2 findings than all other criteria combined. The auditor will sample access provisioning, access reviews, offboarding, network controls, and encryption multiple times. Don't treat it as a single checkbox — build a systematic process for each sub-criterion.
What "audit-ready" actually means
You're audit-ready when:
- Every control in your control matrix is implemented and has been operating continuously
- For each control, you have evidence covering the full audit period — not just a current-state screenshot
- Your PBC list is pre-built and you can produce evidence within 24 hours of any auditor request
- Control owners know what they own and have run the controls at least once each
- You've addressed all findings from your gap assessment — or you have a documented exception with management sign-off
Use the free SOC 2 Remediation Tracker to track your control status, assign owners, and build your evidence collection plan. For the initial gap analysis, see the SOC 2 Gap Assessment Generator. Once you're tracking evidence, the SOC 2 Evidence Pack Generator helps build your PBC list.