SOC 2 Gap Analysis: What Auditors Want in Your First Year

Your first SOC 2 audit is the audit where the gap analysis stops being abstract. Every assumption you made about "we'll fix that later" turns into a finding on a report that enterprise buyers will read. Here are the eight readiness gaps first-time founders hit most often — and how to spot each one before your auditor does.

1. Policies that exist on paper but not in practice

You have an Information Security Policy signed by your CEO. It's beautifully formatted. It references frameworks by name. It also describes a company that doesn't exist.

This is the single most common finding in a first-time SOC 2 — what's sometimes called the "paper-policy syndrome." The policy says your company enforces device encryption, but half the team uses personal laptops with no MDM. The acceptable use policy says personal USB drives are prohibited; everyone has one. The password standard says 14 characters with rotation every 90 days; a quick Slack scroll shows three people with single-word passwords from 2023.

Auditors don't rely on your documentation alone. During the observation period, they pull a sample: ask for the same evidence your policy describes you collect. If the policy says you run quarterly access reviews and you can only produce two of the last four quarters, the policy isn't a working control — it's a finding.

What to fix: Shorten your policies. The 60-page ISP you copied from a Fortune 500 template is worse than a 4-page ISP that reflects what your team actually does. Add a "Policy revision log" with the date of last review and the name of the approver. And whatever you commit to in the policy, run it twice before the observation period starts.

2. Shared accounts and missing SSO on production systems

If there's one technical gap auditors find in every first-year audit, this is it. You have a shared "dev-prod" AWS account that's logged into by four engineers. You have a shared GitHub organization with three personal accounts having owner permissions. You have one root email that everybody uses to receive security alerts.

Shared accounts break the SOC 2 model because the model is built around attribution: who did what, when, with which privilege. If your production database was accessed at 2 AM on a Tuesday and the log shows "admin_user" rather than "alice@company.com," the auditor can't satisfy the attribution requirement. That's a finding, full stop.

The same problem applies to shared credentials in your infra. A secret in 1Password called "Stripe — Production" used by three people. An SSH key that everyone in the team added to the bastion. A "dev" database user that gets used during incident response by whoever is on call.

What to fix: Issue unique human accounts on every system that touches production. Enforce SSO via your IdP for AWS, GCP, GitHub, and any other privileged system. Disable root account use entirely except for break-glass recovery (and log break-glass use as a P0 event). For shared secrets, use short-lived service accounts or per-human API keys rather than a single shared token.

3. No documented onboarding/offboarding access flow

An engineer joins your team. They get added to Slack, GitHub, AWS, Stripe, Notion, Datadog, and a half-dozen other tools. There's a Notion page that lists the order. There's no SLA. There are no timestamps.

Now imagine that same engineer leaves three months later. Their access in some of those tools gets revoked "when we notice." Their personal tokens in CI/CD are still active for another two weeks. Their customer data is still searchable in the analytics warehouse. The auditor asks: "How long does it take you to terminate access when an employee leaves?" You say "a couple of days." The auditor pulls the timestamps from your IdP and they show 14 days.

What to fix: Write down the access-grant flow with timestamps and an SLA. "Within 2 business hours of start date, accounts are provisioned in [list] with role [list]." Write down the revocation flow with an explicit SLA — recommend ≤24 hours for production systems. Automate the parts you can (SCIM provisioning from your IdP for the major tools). And keep the access log somewhere you can produce on demand.

4. Vendor reviews that never happened (or have no evidence trail)

Your vendor inventory says you use 47 third-party services. Your Vendor Management Policy says each one went through security review before being added. Your evidence? A few PDFs named "Vendor-Review-2024.pdf." Most of those are you clicking through a vendor's trust page and writing "looks fine."

Auditors test vendor reviews the same way they test any other control: they pick a sample — usually the 5-10 most critical vendors — and ask for the review file. They check four specific things:

• Was the review done before the vendor was in production? A review from January 2025 on a vendor you started using in March 2025 is a finding.
• Did it cover the data the vendor processes? Reviewing Stripe for security is meaningless if you didn't note that Stripe holds primary card data.
• Was the risk classification documented? A vendor without a clear "critical / important / standard" classification can't have an appropriate review.
• Was the review signed? By whom, on what date, with what authority.

Reviews that don't exist, or reviews that exist but lack any of those four elements, are findings.

What to fix: Start with your top 10 vendors — the ones with the most data access or the most critical availability impact. Write a one-page review for each. From then on, make the review a precondition of vendor onboarding, not a task you do later. Most Vanta/Drata/Secureframe workflows support this; the question is whether you're filling it in, not whether the tool is.

5. Quarterly access reviews skipped because "we're small"

"We're 8 people. We know who has access." This is the line that gets SOC 2 founders in trouble.

Auditors hear it constantly and they don't accept it. The quarterly access review isn't about catching malicious behavior in your team — it's about proving that the access provisioning process from section 3 keeps producing correct results. If you review every quarter, you find the orphan service accounts from a contractor who left 9 months ago. You find the GitHub team membership that nobody maintains. You find the "read" credentials in the data warehouse that should have been read-only in production, not admin.

The size of the team is irrelevant. The process is what matters.

What to fix: Pull access lists from each critical system on a fixed schedule — every 90 days. For each user, document what access they have, who approved it, and whether they still need it. Sign it. Store it. If a system has more than 25 users, sample — you don't need to review every account, but you need to review every privileged account.

6. Incident response plans missing the on-call rotation and 72-hour notification clause

Most early-stage companies have an Incident Response Plan because someone told them they needed one to comply with SOC 2. What most of them don't have is the actual operational detail auditors look for:

• An on-call rotation. Not a philosophy about "everyone is responsible" — a real rotation with names and dates, plus a backup.
• An incident commander. A specific person who decides severity, declares incidents stopped, runs post-mortems.
• A 72-hour notification clause. For GDPR-breach scenarios, this is regulatory, not optional. For customer-facing incidents, this is contractual.
• An escalation matrix. What severity gets called to the CEO at 3 AM and what can wait until morning.
• A post-incident review process. Not "we'll have a meeting" — a template with named fields, stored with the incident.

The ironic part: incident response is the control auditors care most about — and the one most founders leave at "we'll figure it out." If your plan is two pages long and contains no rotation, no timeline, and no commander, the auditor will ask you to demonstrate the response to a hypothetical incident and you'll fail in real time.

7. Logging/MFA gaps on admin-tier cloud accounts

This is the gap where auditors see your AWS console, your GitHub org, and your DNS provider for the first time. Three places to look:

AWS root account. MFA on root is table stakes. But the audit goes deeper: are CloudTrail logs forwarded to a separate account (so an attacker who compromised your main account can't erase their tracks)? Are root API keys disabled? Is the root email monitored by a team distribution list rather than a single person?

GitHub organization owners. Auditors ask: "Who has org owner?" If your answer is "three engineers" and the audit grab of your org settings shows five, you have an undocumented access path. Two-factor enforcement should be org-wide. SSH key lists should reconcile against your team roster.

DNS, monitoring, and billing. Domains are an underrated attack surface. People forget that whoever controls the DNS controls the customer's perception of your product and (in some scenarios) the certificate issuance for your endpoints. Logging on DNS changes and on billing-role actions in the cloud console are increasingly part of the SOC 2 control set.

What to fix: Run an admin audit across AWS, GCP, Azure, GitHub, and your DNS provider. Document who has what, with what MFA. Consolidate log forwarding to a single security account. Set calendar reminders for re-auditing this list every quarter, not just annually.

8. Risk assessments that haven't been refreshed since pre-product fit

Your risk assessment is from 2022. It identifies threats around your MVP at the time: leaked database credentials, a single cloud account, manual deployment processes. You've since raised a Series A, launched three major features, onboarded a 100% remote team across six time zones, integrated with five new third-party APIs, and started handling customer payment data.

The risk assessment hasn't changed. Auditors will notice.

The risk assessment is the artifact that ties everything else together. It documents what threats you considered, what decisions you made about each one, and who owns mitigating them. If your risks no longer match your product or your team, every procedure downstream starts to look out of date.

What to fix: Schedule a 90-minute review with your leadership team. Walk through the risk register. Update anything that no longer reflects reality. Add anything new — AI features, third-party data processors, customer data categories. Sign it, date it, and store it where the auditor can find it.