The 10 Most Common SOC2 Control Failures (and How to Remediate Them)
These 10 controls fail with disproportionate frequency in SOC2 Type 2 audits. For each: what the failure looks like in practice, why auditors flag it, how to remediate it, and a realistic timeline.
Most SOC2 qualified opinions trace back to a small set of control categories. They are not obscure or technically complex — they fail because they require consistent operational execution over 12 months, not just a policy document. Access reviews, offboarding, change approvals: these are calendar-dependent controls that slip when nobody owns them explicitly. The list below covers the failures by their Trust Services Criteria reference, in order of how frequently auditors cite them.
Access Review Failures
User access is not reviewed on the schedule defined in your access control policy — typically quarterly. The auditor finds no evidence that access reviews were performed, or finds them performed only once or twice in a 12-month observation period.
Auditors test this by requesting evidence of each review — typically a dated export from your identity provider showing accounts reviewed, with a sign-off. If the evidence is missing for any review period, it is an exception. This is the single most common failure because it requires consistent operational execution, not just a policy document.
Perform access reviews on the defined schedule and retain evidence: a dated CSV export of active user accounts, a comparison against HR records, and a documented approval from the access review owner. Automate the evidence collection with your identity provider (Okta, Azure AD) to generate a timestamped export.
Terminated Employee Access Not Removed Promptly
Former employee accounts remain active in your production systems, cloud infrastructure, or SaaS tools after their termination date. The auditor cross-references your HR termination log against access provisioning records and finds accounts that were not revoked within your defined SLA.
This is both a process failure and a high-severity security finding. Auditors pull a sample of terminations from the period and verify that access was revoked within the timeframe specified in your offboarding policy (typically 24–48 hours). Even one miss in the sample can generate an exception.
Integrate HR offboarding with IT access revocation. The minimum: HR notifies IT on termination date, IT revokes access and logs the ticket, and both are retained as paired evidence. Automate with tools like Okta Lifecycle Management or Rippling if volume warrants it.
Change Management Without Documented Approval
Code or infrastructure changes are deployed to production without documented approval from an authorized reviewer. The auditor reviews a sample of production deployments and finds commits merged without pull request approvals, or tickets closed without sign-off.
Auditors look for evidence that every production change went through an approval step before deployment. The evidence is typically: PR approval history in GitHub/GitLab, deployment pipeline configuration showing required approvals, or JIRA/Linear ticket approval status. Hotfixes pushed directly to main without a PR are common exception triggers.
Enforce branch protection rules requiring at least one approval on all pull requests to main/production. Document the configuration. Retain deployment logs showing the approval chain. For infrastructure changes, require approval tickets in your ITSM tool.
Missing or Incomplete Risk Assessment
The annual risk assessment was not performed, or was performed but lacks documentation of identified risks, risk ratings, and risk treatment decisions. Auditors ask for the most recent formal risk assessment and find either no document or a document that was never reviewed and approved.
CC3.1 requires that management perform a risk assessment to identify risks to the achievement of objectives. Auditors look for: a dated risk register, risk owner assignments, risk severity ratings, and evidence that management reviewed and approved the assessment.
Perform a formal risk assessment annually. Use a template if you do not have one: list all assets, identify threats and vulnerabilities, assign likelihood and impact ratings, determine treatment (accept, mitigate, transfer, avoid), and get sign-off from a named owner. Date and version the document.
Security Awareness Training Lapses
Not all employees completed annual security awareness training during the observation period. The auditor requests an LMS completion report and finds employees hired during the year who completed training late, or long-tenured employees who missed the annual cycle.
CC1.4 requires that the organization communicate information security responsibilities to personnel. Auditors test this with an LMS (or equivalent) export showing every active employee's training completion date. Any active employee with no training record for the period is an exception.
Enroll new hires in security awareness training within their first 30 days and document completion. Run annual training for all employees on a calendar cycle. The LMS should retain dated completion records per employee. If you use a manual approach (PDF acknowledgment), retain signed records.
Inadequate Incident Response Documentation
The incident response policy exists, but there is no evidence that it was ever exercised. No incident log entries exist (even for minor events), no tabletop exercise was conducted, and no post-incident reviews are documented.
An empty incident log is itself a finding — auditors are suspicious that incidents occurred but were not logged, or that the incident response process is theoretical rather than operational. CC7.4 requires detection, containment, and recovery processes. Evidence of execution is required, not just the policy.
Log every incident — including minor events like failed login alerts, brief service interruptions, or phishing simulation results. Conduct at least one tabletop exercise annually with a written agenda, attendee list, and findings summary. Retain all evidence.
Vendor and Subservice Organization Reviews Missing
The company uses critical third-party services (cloud infrastructure, SaaS tools that process customer data) but has no evidence of reviewing those vendors' security posture. No SOC2 reports from subservice organizations were obtained or reviewed during the period.
CC9.2 requires monitoring of vendors who provide services that affect your controls. For cloud-native companies, this primarily means obtaining and reviewing SOC2 or ISO 27001 reports from AWS, GCP, Azure, and critical SaaS vendors annually. If you cannot produce a dated review for each critical vendor, it is an exception.
Build a vendor inventory with criticality ratings. For critical vendors (those with access to production data or infrastructure), obtain their current SOC2 or ISO 27001 report annually. Document your review with a dated memo noting the opinion, scope, and any exceptions in the vendor's report relevant to your environment.
Encryption Gaps
Data at rest is not encrypted, or encryption is implemented but not documented in the system description. Alternatively, the system description claims encryption is in place but auditors cannot find configuration evidence confirming it is enabled.
CC6.7 covers protecting information from unauthorized disclosure. Auditors look for: database encryption settings (RDS encryption, disk encryption), object storage encryption (S3 bucket settings), backup encryption, and encryption key management practices. A claim in the policy without configuration evidence is an exception.
Audit your actual encryption settings against your stated controls. Enable encryption at rest for all databases, object storage, and backups if not already done. Document the configuration with dated screenshots or infrastructure-as-code settings. For key management, document your KMS configuration.
Backup Testing Not Performed
Backups exist and run automatically, but there is no evidence that a restore was ever tested. The auditor asks for proof of backup restoration testing and finds none — or finds a test performed three years ago.
A1.2 (Availability TSC) requires that recovery procedures are tested. An untested backup is not a control — it is an assumption. Auditors require at minimum one documented restore test per year, including the date, what was restored, and confirmation that the restoration was successful.
Perform a documented restore test. Use a non-production environment. Test full database restore from backup. Record: backup date used, restore start time, restore completion time, confirmation that data integrity was verified, and name of person who performed the test. Repeat annually.
Monitoring and Alerting Gaps
Security monitoring tools are running, but there is no evidence that alerts were reviewed and acted upon. Log aggregation exists but nobody reviewed the logs. Intrusion detection is configured but there is no documented process for who reviews alerts and what constitutes an escalation.
CC7.2 requires ongoing monitoring of the environment to detect potential security events. Auditors test this by asking for evidence of alert review — typically ticket records for alerts, a monitoring dashboard with usage history, or documented on-call procedures. Tool existence without evidence of review is an exception.
Establish a documented alert review process: who reviews alerts, at what frequency, and what the escalation criteria are. Retain records of alert review activities — even a weekly log of 'reviewed, no action required' creates a defensible evidence trail. Route critical alerts to a ticketing system where response is automatically logged.
Frequently Asked Questions
How many control exceptions typically result in a qualified opinion?
There is no hard number — auditors exercise judgment about the materiality and pervasiveness of exceptions. A single severe exception (encryption not implemented across all production databases) can result in a qualified opinion. Multiple minor exceptions (access reviews performed 3 out of 4 quarters) may or may not, depending on the auditor's risk assessment. Generally, 3–5 exceptions in the same control domain signal a pervasive control weakness and increase the likelihood of qualification.
Can I fix control failures during the audit to avoid an exception?
Auditors test controls as they operated during the observation period — not as they operate on the day of fieldwork. If your quarterly access review was not performed in Q2, implementing it on the day auditors ask for evidence does not retroactively eliminate the exception. The control failed to operate effectively during the period. You can note remediation in the management response section of the report, which some buyers factor positively into their evaluation.
Which of these failures is considered most severe by enterprise buyers?
In procurement reviews, encryption gaps (CC6.7) and terminated employee access (CC6.1) are treated as highest severity because they represent operational security failures, not documentation gaps. Access review failures (CC6.3) and missing backup tests (A1.2) are also taken seriously but are more commonly understood as process maturity issues. Missing training records (CC1.4) and missing risk assessment documentation (CC3.1) are typically viewed as administrative gaps.
How can I avoid these failures between audits?
The controls that fail most often are all calendar-dependent: they require someone to do something at a regular interval and retain evidence of having done it. The most reliable prevention method is a compliance calendar with explicit owners and evidence artifacts defined for each task. Many companies use compliance automation platforms (Vanta, Drata, Thoropass) that automatically collect evidence and alert when recurring tasks are overdue.