Five SOC 2 control failures we see in almost every startup pre-audit

We run a gap analysis on every Polara customer before they go in front of a CPA. Same five issues show up at roughly the same rate regardless of stack, size, or industry. The good news: each one has a tight, well-understood fix. The bad news: each one will fail an auditor's test of design (Type 1) and their test of effectiveness (Type 2), so they need to be addressed before you sit for either examination.

Trust Services Criteria references in this article use the 2017 TSC numbering. CC = Common Criteria.

1. MFA enforced for humans, missing for service accounts

What auditors test (CC6.1, CC6.2): that logical access to information assets is restricted to authenticated and authorized principals, and that authentication uses multi-factor where appropriate.

What we find: SSO is wired through Okta or Google Workspace, every human enrolls MFA on day one, every login event shows the second factor. That part is solid. But the same organization will have two dozen static AWS IAM access keys for CI, backups, deploy scripts, and "that one thing the data team needs." Static keys are functionally a username/password with no second factor, and they don't rotate.

The fix: rotate every static key to a short-lived credential mechanism. For AWS, that's IAM Roles for Service Accounts (IRSA) on EKS, instance profiles on EC2, GitHub Actions OIDC federation for CI, and AWS SSO for human-driven CLI. Run aws iam list-access-keys across every account; for each key, document the consumer, the rotation cadence (or the replacement plan), and the principal of least privilege scope. Document the inventory in your access control policy.

Evidence the auditor expects: the inventory, screenshots of MFA enforcement settings, a sample of CI runs showing OIDC-issued tokens with no long-lived secret in the workflow log.

2. Code review enforced, but the review itself is not preserved

What auditors test (CC8.1): that changes to the production environment are authorized, reviewed, and documented.

What we find: branch protection requires one approving review and a passing CI run. Engineers are doing real reviews. But the PR descriptions are one line, the review comments get marked "resolved" and disappear from the default view, and the actual evidence ("this change was reviewed and approved by a qualified peer for impact and side effects") is implicit in the merge commit and not durable.

The fix: turn on GitHub's branch protection rule requiring at least one approving review with stale-review dismissal on new commits, AND require linear history so merges preserve the review. Enable the review-thread export in your repo settings so historical reviews are queryable. Document in your SDLC policy that PR descriptions must reference the work-tracker ticket (Linear, Jira) so the auditor can trace change → approval → deploy.

Evidence the auditor expects: screenshot of the branch protection rule with required reviewers and stale-review dismissal enabled, plus a random sample of 5-10 merged PRs from the observation window showing the full review history.

3. Encryption at rest "by default," no key management policy

What auditors test (CC6.7, CC6.8): that confidential information is protected during storage and transmission, including when at rest, and that cryptographic keys are managed.

What we find: S3 buckets have default encryption enabled. RDS instances were created with encryption checked. The team's posture is "AWS handles it." Which is mostly true, but the auditor isn't asking whether the bytes are encrypted, they're asking who controls the key, how it rotates, who can decrypt, and whether you have a documented procedure for any of that. "AWS handles it" is not a procedure.

The fix: create a customer-managed KMS key for each data tier (customer data, internal data, secrets). Enable automatic annual rotation. Restrict the kms:Decrypt permission to the specific IAM principals that need it; deny all else with a key policy. Write a cryptography policy that names the key tier, the rotation cadence, and the access matrix.

Evidence the auditor expects: the cryptography policy, AWS KMS key list with rotation status, a sample IAM key policy showing principal restriction, and your runbook for re-encrypting in the event of a key compromise.

4. Onboarding is tight, offboarding is "we'll get to it"

What auditors test (CC6.2, CC6.3): that user access is granted based on job responsibilities and is removed in a timely manner upon termination.

What we find: new hire access is well-handled. Okta provisions on day one based on group membership, the manager approves additional access via ticket, everything is documented. But when someone leaves, the access removal is asynchronous, manual, partial, and often not done at all. We've audited startups where a contractor offboarded 14 months prior still had an active GitHub Enterprise seat and a valid AWS console login.

The fix: build a termination runbook with same-day revocation for SSO (Okta/Workspace), GitHub, AWS, all production systems, plus 24-hour revocation for tertiary systems. Tie the termination event to a single source-of-truth in the HR system; when status flips to "terminated," an automation deprovisions SSO-federated apps and creates a checklist of manual revocations for everything else. Quarterly access reviews catch what falls through.

Evidence the auditor expects: the offboarding runbook, a sample of 3-5 terminations from the observation window with timestamps showing same-day SSO revocation, and the last two quarterly access review attestations.

5. Incident response policy exists; no one has ever tabletopped it

What auditors test (CC7.3, CC7.4, CC7.5): that the entity identifies, evaluates, and responds to security incidents, and that the response is tested.

What we find: there's a markdown file in the wiki called "Incident Response Plan." It was written for a previous framework, references roles that no longer exist, and has never been exercised. When we ask "when was the last drill?" the answer is usually a pause followed by "we had a real incident last spring, does that count?" The answer to that is "kind of, but the auditor wants a planned test, not an unplanned one."

The fix: update the IR plan to reflect current roles, on-call structure, and notification paths. Hold a 30-minute tabletop exercise: present a synthetic scenario (e.g., "we detected unusual S3 download volume from a customer-data bucket"), have the on-call lead walk through the response, document the discussion, and capture lessons learned. Do this twice a year minimum. The tabletop notes are the evidence.

Evidence the auditor expects: the updated IR policy, tabletop exercise notes from at least one exercise in the observation window, and (if applicable) post-incident reviews for any real incidents.

The pattern across all five

In every case the underlying control existed in some form. What was missing was a combination of: (a) policy documentation that named the control, (b) durable evidence that it fires, and (c) a recurring mechanism (review, drill, rotation) that demonstrates operating effectiveness. SOC 2 isn't a tooling problem. Most startups already have the tools. It's a discipline-of-documentation problem.

That's where a focused tool like Polara Labs earns its keep: we generate the policies that name the controls in your specific environment, we tell you the exact evidence the auditor will ask for, and we structure the remediation as a checklist instead of a consulting engagement.

Further reading

• NIST SP 800-53 Rev. 5 is the closest thing to a canonical control catalog; many SOC 2 controls map back to families here.
• CISA on MFA is the modern federal guidance on phishing-resistant MFA.
• OWASP ASVS is an application security verification standard, useful for the secure-development side of CC8.