The Patterns Don't Lie
Over the course of working with companies on SOC 2 preparation, I've seen the same gaps appear over and over, regardless of company size, industry, or technology stack. The specifics differ — the gap is always slightly different — but the categories are almost always the same.
Here are the 12 most common, ranked roughly by frequency. Check each one against your current state before your observation period starts.
Gap 1: Terminated Employees Still Have Active Access
Frequency: Extremely common
Why it happens: HR sends an email to IT when someone leaves. IT disables the Okta account. But the engineer's GitHub personal account is still in the GitHub organization. Their AWS IAM user was never deleted. Their access to the staging database was granted via a key that was never revoked.
How to close it:
- Build a comprehensive offboarding checklist covering every in-scope system
- Assign one person accountable for verifying every item is completed
- Do a one-time audit of your current user lists — compare against your active employee list and remove orphaned accounts
●CC6.3 is the specific control being tested here.
Gap 2: No Quarterly Access Reviews
Frequency: Very common
Why it happens: Companies know they need access reviews. They plan to do them. They forget, or they do the first one and then miss the second because nobody owns the calendar reminder.
How to close it:
- Set calendar reminders for access reviews before your observation period starts — not during it
- Assign a specific owner (typically Head of Engineering or Security lead)
- Create a simple review template: system name, list of current users, reviewer, date, any removals made
- Save every completed review as a dated document
One missed access review during a 12-month observation period will almost certainly produce an exception.
Gap 3: MFA Not Enforced on All Production Systems
Frequency: Very common
Why it happens: MFA is required for Okta, but a legacy AWS IAM user was created before MFA enforcement was in place. Or MFA is required for engineers but not for the shared admin account. Or the AWS root account doesn't have MFA.
How to close it:
- Audit every authentication point for in-scope systems
- Enforce MFA at the identity provider level (not just policy — actually technically enforced)
- Delete shared admin accounts; use individual accounts with MFA
- Enable MFA on your AWS root account immediately if it's not already done
Gap 4: No Documented Risk Register
Frequency: Common
Why it happens: Risk management feels abstract. Most technical founders think about risks constantly but don't write them down in a structured way.
How to close it:
- Create a risk register with at minimum: risk description, likelihood (1-5), impact (1-5), risk score (likelihood × impact), owner, treatment (accept/mitigate/transfer/avoid), and current status
- Populate it with 15-20 risks that are genuinely relevant to your business
- Schedule a quarterly review
●CC3.1 and ●CC3.2 cover this area.
Gap 5: Vulnerability Scans With No Remediation Tracking
Frequency: Common
Why it happens: Companies run vulnerability scans (they have a scanner, they run it monthly). But findings from October haven't been remediated by December and there's no tracking or SLA.
How to close it:
- Define remediation SLAs by severity: Critical = 7 days, High = 30 days, Medium = 90 days, Low = next scheduled maintenance
- Track all findings in a ticketing system
- Document your SLA policy
- For any finding that can't be remediated within SLA, document the accepted risk and business justification
●CC7.1 covers vulnerability management.
Gap 6: No Documented Incident Response Plan
Frequency: Common
Why it happens: Teams handle incidents — they're good at it — but it's all in people's heads, not in a document.
How to close it:
- Write the IR plan (see previous post for the full structure)
- Run at least one tabletop exercise during the observation period
- Log every security event, even minor ones, in an incident log
Gap 7: Production Deployments Without Peer Review
Frequency: Common in engineering-led startups
Why it happens: Small teams. Move fast culture. "I'll merge my own PR because I know it's correct." Hotfixes pushed directly to production in emergencies.
How to close it:
- Enable branch protection rules in GitHub requiring at least one reviewer
- Document an emergency change process that still requires at minimum a same-day peer review
- Review your deployment logs and fix any instances where self-approval happened before the audit starts
●CC8.1 is the relevant control.
Gap 8: Policies That Were Never Communicated
Frequency: Very common
Why it happens: A consultant wrote policies. They went into a folder. Nobody read them.
How to close it:
- Create an employee acknowledgment record — even a simple Google Form works
- Make policy acknowledgment part of new hire onboarding
- Send an annual policy reminder with an acknowledgment mechanism
●CC2.2 and ●CC5.3 cover communication and policy deployment.
Gap 9: No Vendor Risk Register
Frequency: Common
Why it happens: Companies use dozens of SaaS tools. Managing vendor risk feels like administrative overhead.
How to close it:
- Identify your Tier 1 and Tier 2 vendors (see the vendor risk post in this series)
- Collect current SOC 2 reports from each Tier 1 vendor
- Build a simple register tracking vendor, risk tier, evidence collected, and review date
●CC9.2 is the relevant control.
Gap 10: No Disaster Recovery Test
Frequency: Common
Why it happens: Companies have a DR plan (or assume AWS handles it). But the plan has never been tested.
How to close it:
- Schedule and run a DR test before the observation period ends
- The test doesn't have to be a full production failover — a structured simulation with documented results is sufficient
- Document: what was tested, results, lessons learned, follow-up actions
●A1.3 covers DR testing.
Gap 11: AWS Root Account Used for Day-to-Day Operations
Frequency: Less common in well-run engineering teams, but still appears
Why it happens: The company started on AWS, the founder set up the root account, and it became the de facto admin account.
How to close it:
- Create individual IAM users or use AWS SSO for all operational access
- Lock the root account (no MFA = critical finding; MFA enabled and root not used regularly = acceptable)
- Document who has access to the root account credentials
Gap 12: Security Training Not Documented
Frequency: Common
Why it happens: Companies do informal security awareness. "We talked about phishing at an all-hands." But there's no record.
How to close it:
- Conduct at least one formal security awareness training session during the observation period
- Record attendance (even a sign-in sheet or Zoom attendee list)
- Document the topics covered
- Consider a simple annual phishing simulation — several free tools are available
Self-Assessment Checklist
Use this to evaluate your current state before the observation period starts:
- [ ] Offboarding checklist covers all in-scope systems
- [ ] Quarterly access reviews are scheduled and owned
- [ ] MFA enforced technically (not just as a policy) on all production systems
- [ ] Risk register exists, is current, and has a review owner
- [ ] Vulnerability scan findings tracked with SLAs
- [ ] Incident response plan documented and tested
- [ ] Branch protection enforced in production code repository
- [ ] Policies communicated with acknowledgment records
- [ ] Vendor risk register complete for Tier 1 and Tier 2
- [ ] DR plan tested and documented
- [ ] AWS root account locked or restricted
- [ ] Security training documented with attendance records
If you have more than 4 items unchecked, set aside 6-8 weeks of remediation time before starting your observation period.
What Comes Next
You've done the work. Your controls are in place. Your evidence is collecting. Now it's the day the auditor shows up — or rather, the day the formal evidence review begins. In the next post, we'll cover exactly what happens on audit day and how to make it as smooth as possible.
Rishabh's take: The companies I've seen pass SOC 2 with zero exceptions almost all share one trait — they completed a self-assessment like this list and fixed every item before the observation period started. The companies with exceptions usually started the observation period too early, before their controls were consistently operating.