Understanding the most common soc 2 gaps is the fastest way for software engineering teams, founders, and security practitioners to bulletproof their compliance preparation. When technology companies embark on their initial SOC 2 journey, leadership often imagines that auditors fail companies over esoteric cryptographic theory or cutting-edge architectural vulnerabilities.
The reality of audit fieldwork is starkly different. In practice, independent Certified Public Accountant (CPA) firms examine basic operational hygiene. The vast majority of audit exceptions, report qualifications, and fieldwork delays stem from simple, mundane breakdowns in everyday execution: an employee hired without a completed background check, a pull request merged directly to main to fix a production hotfix without peer review, or a quarterly access review that was skipped during a busy sprint.
By learning the recurring failure patterns that auditors uncover in report after report, technical teams can focus remediation efforts where they matter most. Before examining individual failure categories, evaluate your current control environment using our diagnostic SOC 2 Gap Analysis guide and reference our complete SOC 2 Controls List.
The Six Recurring Failure Patterns in SOC 2 Audits
Decades of attestation practice across technology companies reveal that control deficiencies cluster around six specific operational areas:
1. Missing, Delayed, or Retroactive Background Checks
Under Common Criteria CC1.4, organizations must verify employee competence and integrity prior to granting production or confidential data access. Background checks represent one of the most frequent test exceptions in Section IV of SOC 2 reports.
The Real-World Gap: A fast-growing startup rushes to hire engineers. The candidate signs an offer letter, starts on Monday, receives AWS and GitHub access on Tuesday, but HR forgets to initiate the background check until three weeks later.
Why Auditors Flag It: Background checks cannot be satisfied retroactively. An auditor samples 10 employee files, compares the hire date on the I-9/contract against the completion timestamp on the screening report from Checkr or GoodHire, and immediately notes an exception: "For 2 of 10 sampled employees, background screenings were completed subsequent to the employee commencement date."
Remediation: Establish a rigid policy gate in your HRIS: no employee or contractor receives production access or single sign-on (SSO) credentials until HR confirms a completed, satisfactory background check report.
2. Unprotected Branches and Unreviewed Pull Requests
Under Common Criteria CC8.1, organizations must design and operate controls ensuring that changes to production software are authorized, tested, and approved prior to deployment.
The Real-World Gap: While an engineering team maintains a written policy stating "all code changes require pull request review," repository settings in GitHub or GitLab allow developers to bypass protections. A senior engineer pushes a hotfix directly to main or approves their own pull request using administrator override privileges.
Why Auditors Flag It: During a Type 2 examination, auditors request a list of all production deployments during the observation window and sample 25 to 40 pull requests. If even one sample shows a commit pushed directly to the release branch without an approving review from a separate developer, the auditor flags a change management failure.
Remediation: Configure automated branch protection rules on all production branches: require pull request reviews before merging, require at least 1 approving review from non-authors, dismiss stale approvals when new commits are pushed, require status checks to pass, and strictly enforce rules on administrators.
3. Unencrypted Backups, Snapshots, and Cold Storage
Under Common Criteria CC6.6 and CC6.7, data must be protected against unauthorized access, loss, or corruption using appropriate cryptographic mechanisms.
The Real-World Gap: Engineering teams enable encryption at rest for their primary production databases (e.g., AWS RDS PostgreSQL instances). However, automated snapshot configurations, cross-region replication archives, or legacy Amazon S3 buckets storing database export dumps remain unencrypted.
Why Auditors Flag It: Auditors inspect cloud configuration policies directly. When querying AWS CLI or cloud configuration reports, unencrypted EBS snapshots or S3 buckets containing database dumps are flagged as technical control deviations.
Remediation: Enforce organization-wide AWS Service Control Policies (SCPs) or Azure Policies that deny creation of unencrypted EBS volumes, S3 buckets, or RDS instances by default.
4. Stale User Access and Missing Quarterly Access Reviews
Under Common Criteria CC6.2 and CC6.3, organizations must provision access based on least privilege and periodically re-evaluate whether existing access rights remain appropriate.
The Real-World Gap: Startups rarely struggle with provisioning access; they struggle with de-provisioning and periodic reviews. Contractors finish projects but retain AWS IAM credentials. Employees change roles from engineering to product management but retain production database keys. Furthermore, leadership forgets to perform and document quarterly access reviews.
Why Auditors Flag It: The auditor compares active user lists across Okta, Google Workspace, AWS, GitHub, and Jira against the company's official termination log. If a terminated contractor accessed a corporate system post-termination date, or if management cannot produce time-stamped proof of a quarterly access review with manager sign-offs, an exception is unavoidable.
Remediation: Automate de-provisioning via SCIM integrations that instantly revoke downstream access upon HRIS termination. Schedule calendar recurring quarterly reviews where department heads formally review and sign off on active access lists.
5. Missing or Undocumented Vendor Security Reviews
Under Common Criteria CC9.2, organizations must assess and manage risks associated with vendors, subservice organizations, and third-party service providers.
The Real-World Gap: A SaaS company relies on dozens of third-party tools: AWS for cloud hosting, Datadog for monitoring, Stripe for billing, SendGrid for transactional emails, and OpenAI for generative models. However, the company maintains no centralized vendor inventory and never requested or reviewed the annual SOC 2 reports of these vendors.
Why Auditors Flag It: Auditors request the company's Vendor Risk Register and sample 5 critical vendors. If the company cannot produce the vendor's current SOC 2 Type 2 report alongside documented management review notes (evaluating complementary user entity controls, or CUECs), a vendor management deficiency is logged.
Remediation: Maintain a living Vendor Risk Register categorizing vendors by data sensitivity. Annually request and review SOC 2 Type 2 or ISO 27001 reports for all Tier 1 vendors, explicitly documenting review dates and CUEC compliance.
6. Absent Incident Response Evidence and Tabletop Simulations
Under Common Criteria CC7.3 and CC7.4, organizations must detect, respond to, and document security incidents in accordance with defined procedures.
The Real-World Gap: An organization drafts a beautiful 20-page Incident Response Plan. When the auditor asks for evidence that the plan was tested, management responds: "We didn't have any security incidents this year, so we didn't need to use the plan."
Why Auditors Flag It: Having zero security incidents does not exempt an organization from proving that its response capabilities work. Auditors require annual proof that the incident response plan was tested through a formal tabletop exercise or that actual incidents followed documented post-mortem procedures.
Remediation: Conduct a documented annual incident response tabletop exercise simulating a realistic compromise scenario (such as a compromised developer credential or ransomware outbreak). Record attendance, timeline, lessons learned, and remediation action items.
7. Mobile Device Management (MDM) and Remote Endpoint Vulnerabilities
With the shift toward distributed and remote-first engineering workforces, endpoint security has become a focal point of AICPA audit fieldwork under CC6.1 and CC6.6.
The Real-World Gap: Employees and contractors use personal or company-issued laptops to access production environments, code repositories, or customer databases without centralized device management. Workstations lack enforced full-disk encryption, local firewalls remain disabled, and operating systems run outdated versions without automated patch management.
Why Auditors Flag It: Auditors request a fleet inventory of all employee laptops that access corporate networks. They sample 10 to 20 machines and demand evidence proving: (1) Full-disk encryption (FileVault for macOS, BitLocker for Windows) is permanently active; (2) An automated screen saver lock engages after 15 minutes of inactivity; (3) Operating systems are maintained within supported patch baselines; and (4) Endpoint detection and response (EDR) or anti-malware software is operational. If an organization cannot prove automated endpoint compliance, a test exception is documented.
Remediation: Deploy a centralized MDM solution (such as Kandji, Jamf Pro, or Microsoft Intune) across all corporate laptops, enforcing encryption, password complexity, automatic updates, and screen lock policies via non-removable configuration profiles.
8. Hardcoded Secrets, API Keys, and Source Code Sprawl
Under Common Criteria CC6.1 and CC6.7, credentials and API tokens must be protected from exposure or unauthorized access.
The Real-World Gap: Developers accidentally commit production AWS access keys, Stripe secret tokens, or database passwords into GitHub repositories during rapid feature prototyping. Even if the commit is quickly removed with a follow-up commit, the secret persists in Git history or public forks.
Why Auditors Flag It: Annual third-party penetration tests routinely scan repository history for leaked credentials. Furthermore, compliance automation scanners identify exposed tokens. If an auditor notes that production secrets were committed to source control or stored in plaintext configuration files, an audit finding is generated regarding inadequate credential governance.
Remediation: Implement automated pre-commit hooks (such as git-secrets or trufflehog) that prevent developers from pushing code containing high-entropy tokens. Migrate all production secrets to dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault, or Doppler) and configure automated credential rotation.
9. Inadequate Audit Logging and Log Retention Gaps
Under Common Criteria CC7.2, organizations must generate and maintain audit logs sufficient to enable the monitoring, analysis, and investigation of security events.
The Real-World Gap: While infrastructure services generate logs, the logs are stored locally on ephemeral containers, lack centralized aggregation, or have retention policies set to 30 or 60 days to reduce cloud storage bills.
Why Auditors Flag It: Enterprise audit standards mandate that security audit logs (such as AWS CloudTrail, identity provider login logs, and database access logs) must be retained for at least 365 days in a tamper-resistant datastore. If an auditor requests access logs from the beginning of a 12-month observation period and finds that logs were purged after 90 days, a severe monitoring exception is recorded.
Remediation: Centralize all audit telemetry into an immutable, dedicated logging bucket (e.g., AWS S3 with Object Lock or CloudWatch Logs) with lifecycle retention policies set to at least 365 days. Restrict write and delete permissions so that even root account administrators cannot alter historical audit records.
10. Business Continuity and Disaster Recovery Drill Deficits
Under Common Criteria CC9.1 and the Availability criterion, organizations must test disaster recovery plans to ensure operations can resume following an outage.
The Real-World Gap: Engineering teams rely on cloud provider snapshot features but never actually execute a restoration test. When the auditor asks for evidence that backups can be restored, the team has no documented dry-run logs.
Why Auditors Flag It: Having automated backups is only half of the control requirement. Auditors mandate that management perform and document at least one annual restoration test: restoring a database snapshot into an isolated sandbox environment, verifying data integrity, and timing the recovery against the company's stated Recovery Time Objective (RTO).
Remediation: Schedule an annual disaster recovery restoration drill. Document the start time, completion time, verified database record count, and lessons learned in a formal Disaster Recovery Test Report signed by the VP of Engineering.
The Psychology of Audit Fieldwork: How to Communicate with Auditors
A significant number of audit findings do not result from broken infrastructure, but from poor communication during auditor walkthrough interviews. Understanding how auditors think protects your organization from unnecessary findings:
- Auditors Are Bound by Professional Standards: Auditors do not enjoy issuing exceptions; however, AICPA Peer Review regulations require them to substantiate their opinions with verifiable workpapers. If you cannot provide documentation, the auditor has no legal choice but to record an exception.
- Answer Only the Question Asked: In walkthrough interviews, answer the auditor's specific query directly and concisely. Avoid providing rambling architectural narratives or discussing speculative future projects that might invite unrelated scoping questions.
- Never Manufacture Evidence Post-Facto: If an auditor asks for a Q2 access review and your team forgot to perform it, be honest. Explaining that the review was missed and demonstrating that Q3 and Q4 reviews were performed correctly results in an isolated exception. In contrast, manufacturing a backdated document is considered audit fraud and will trigger an immediate disclaimer of opinion or engagement termination.
How Auditors Evaluate Exceptions: Isolated Findings vs. Systemic Failures
When an auditor uncovers a gap during testing, how does it affect your final report? Auditors classify findings into two broad categories:
- Isolated Deviations (Test Exceptions): An isolated failure where 1 out of 35 sampled items failed, but compensating controls or subsequent evidence proves that the broader control objective was achieved. This results in a documented test exception in Section IV of the report, but management still earns an unqualified ("clean") opinion.
- Systemic Deficiencies (Qualified Opinions): Widespread, unmonitored failures where controls were absent across extended periods of the observation window. For instance, if no quarterly access reviews were conducted all year, or if branch protection was disabled for six months, the auditor cannot attest to control effectiveness. This triggers a qualified opinion in Section I.
To understand the profound commercial difference between an isolated test exception and a qualified opinion, review our definitive guide on Can You Fail a SOC 2 Audit? Opinions, Exceptions, and Next Steps.
Crafting Effective Management Responses for Section IV Exceptions
When an isolated control exception is identified during audit fieldwork, it does not mean your report is unusable. Section IV of your SOC 2 report provides management with an opportunity to publish an official written response directly beneath the auditor's finding. Enterprise vendor risk managers read these management responses carefully.
A well-structured management response should contain three components:
- Root Cause Identification: Acknowledge the isolated finding factually without defensive excuses (e.g., "Due to an unexpected transition in human resources personnel, the background check for one contractor was delayed.").
- Compensating Control Explanation: Explain why the failure did not compromise customer data security (e.g., "The contractor operated under supervised pairing and possessed no direct write permissions to production databases.").
- Permanent Remediation Implementation: Describe the automated or systemic safeguard enacted to prevent recurrence (e.g., "Management has updated the automated HRIS workflow to programmatically block single sign-on credential issuance until the screening report status is confirmed green.").
When enterprise procurement teams see a thoughtful, accountable management response demonstrating that the root cause was eliminated, an isolated exception rarely delays a deal.
Operational Pre-Audit Sanity Checklist
Before declaring your organization ready for independent CPA fieldwork, verify that these high-frequency failure points have been audited internally:
- Confirm that 100% of current employees and contractors have completed background check reports on file dated on or before their start dates.
- Verify that GitHub repository branch protection rules are locked, require peer review, and prevent administrator overrides.
- Confirm that multi-factor authentication (MFA) is strictly enforced on all cloud infrastructure, developer tools, and identity providers with zero SMS fallback.
- Inspect production databases and confirm that encryption at rest is enabled for all instances, snapshots, and automated backups.
- Confirm that quarterly user access reviews have been executed and formally signed off for every quarter of the observation window.
- Gather current SOC 2 Type 2 reports for all critical third-party vendors and document review notes for complementary user entity controls.
- Conduct and document an annual incident response tabletop simulation and an annual disaster recovery restoration drill.
Frequently Asked Questions: Common SOC 2 Gaps
Practical answers to the most common questions teams ask when resolving recurring audit deficiencies and control exceptions.
What is the single most common cause of failing an audit?
In technical terms, organizations do not "pass or fail" a SOC 2 audit—instead, licensed CPA firms issue an attestation opinion (unqualified, qualified, adverse, or disclaimer) and record specific control test exceptions in Section IV of the report. The single most common cause of an audit exception or qualified opinion is inconsistent control execution over time during a Type 2 observation window. While an organization may design robust written policies on paper, failing to consistently enforce controls—such as merging code without peer review approvals, missing quarterly access reviews, or onboarding employees without prior background check completion—creates documented testing failures that auditors must report.
What raises a red flag for an audit?
Several operational and behavioral indicators raise immediate red flags for SOC 2 auditors: (1) Retroactive evidence creation: generating policies, sign-offs, or access reviews dated immediately prior to auditor fieldwork rather than at their required cadence; (2) Inconsistencies between written policies and technical realities: such as policies mandating MFA while administrator consoles lack MFA enforcement; (3) Gaps in employee offboarding: discovering active corporate email or AWS accounts belonging to employees terminated months earlier; and (4) Unexplained exceptions in change logs: production deployments that bypass standard pull request workflows.
What not to say during an audit?
During audit interviews and evidence walkthroughs with an independent CPA firm, personnel should adhere to strict professional guidelines: (1) Never speculate, guess, or assume an answer—if you do not know the exact configuration or procedure, state that you will verify with the technical owner and provide documentation; (2) Never volunteer unrequested information or disclose unverified operational risks outside the specific control scope; (3) Never promise future controls as current reality; and (4) Never claim that a control is automated when it is executed manually, as auditors will request system-generated configuration proofs.
Do you need a pen test for SOC2?
Under the AICPA Trust Services Criteria (specifically Common Criteria CC4.1 and CC7.1), a penetration test is not explicitly mandated by statutory name; however, in standard audit practice, virtually all accredited CPA firms interpret the vulnerability assessment criteria as requiring an annual, independent third-party penetration test. Enterprise buyers, procurement teams, and corporate risk officers universally expect a SOC 2 Type 2 report to be supported by a professional network and application penetration test report demonstrating that external defenses have been validated.
Does SOC 2 require background checks?
Under Common Criteria CC1.4, organizations must implement procedures to evaluate whether candidate personnel possess the background, integrity, and competence necessary to perform their roles. In commercial audit practice, CPA firms universally verify that the company conducts formal pre-employment background checks on all full-time employees and contractors who possess logical access to production systems, source code, or confidential customer data. Crucially, background checks must be completed before or on the employee's official start date.
What will get flagged on a background check?
In the context of SOC 2 compliance, auditors inspect the background check process rather than making individual hiring judgments. What gets flagged by an auditor is: (1) Missing background check reports for sampled employees; (2) Background checks completed after the employee's hire date or after production access was provisioned; (3) Lack of documented management review and formal risk acceptance when a screening provider returns an adverse finding (such as financial or criminal history); and (4) Failing to apply screening standards consistently across international contractors.