A 600-person SaaS organization went into its first SOC 2 Type II observation window with policies, an MFA rollout, and a GRC platform configured for evidence collection. Six months in, the internal mock audit produced eleven observations. Nine of them were the same kinds of gaps auditors find in every program: stale access reviews, missing service-account ownership, change tickets without peer review, vendor records last refreshed two years ago.

The pattern is consistent across every SOC 2 readiness program. The Common Criteria (CC1 through CC9) are exhaustive, but auditors concentrate their fieldwork on a relatively small set of control areas where operating effectiveness is hardest to demonstrate. The same set of failures shows up again and again because the same handful of operational disciplines are usually under-engineered.

This article names those ten gaps, maps each to the AICPA Trust Services Criteria, explains why each one fails an audit, and gives you the engineering fix BluEnt applies during readiness engagements.

How SOC 2 Audits Actually Fail

A Type II report measures two things: whether controls were designed appropriately at the start of the observation window, and whether they operated effectively throughout it. Design is the easy part. Operating effectiveness, evidenced through sample testing across the six-to-twelve-month window, is where programs collapse.

Auditors do not usually fail a program because a policy is missing. They fail it because the policy was written, the control was designed, and then the control was not actually performed on the cadence the policy claims. The ten gaps below are the operating-effectiveness failures that produce qualified observations most reliably.

Where the gaps map: each is anchored to one or more of the AICPA Common Criteria (CC1 through CC9). For the full criteria framework, see the AICPA Trust Services Criteria published by the AICPA.

The 10 Gaps

Gap 1: Quarterly access reviews that were never actually performed

Control mapping: CC6.2 (Authorizes and modifies access)

What auditors find: A policy specifies quarterly access reviews. The control owner is named. But the actual review evidence (signed manager attestations, automated review reports, recorded revocations) does not exist for at least one of the quarters in the observation window.

Why it fails: The auditor will sample three to four quarters of the window and ask for the review artifacts. A missing quarter is a documented operating-effectiveness failure under CC6.2 and will appear in the report.

The engineering fix: Drive access reviews from your IGA tool (Entra ID Governance, Okta Identity Governance, or SailPoint where the engagement requires). Configure quarterly attestation campaigns with auto-revoke on non-response. Evidence is collected automatically and timestamped. BluEnt engineers this in Stage 3 of every readiness engagement.

Gap 2: Service accounts without named owners, MFA, or rotation

Control mapping: CC6.1 (Logical access security)

What auditors find: A spreadsheet (or worse, no spreadsheet) lists service accounts used by integrations, batch jobs, and legacy applications. Many have static passwords last rotated two years ago, no MFA enforcement, and no named human accountable for them.

Why it fails: Auditors single out service accounts under CC6.1 because they are the most common privilege-escalation path in incident post-mortems. Static, shared, or unowned service accounts are a near-automatic finding.

The engineering fix: Inventory every service account in a single registry (your IGA or PAM tool). Assign a named human owner. Migrate to managed identities (Azure Managed Identity, AWS IAM Roles, GCP Workload Identity) where possible. Vault remaining credentials with rotation cadence enforced. For the wider identity program, see our Identity and Access Management service page.

Gap 3: Change management without ticket-to-deploy traceability

Control mapping: CC8.1 (Authorizes, designs, develops, configures, documents, tests changes)

What auditors find: Production deploys land without a corresponding change ticket. Or tickets exist but were created retrospectively. Or peer review is documented in some cases but not others. Hot fixes are typically the worst offender.

Why it fails: The auditor samples deployments across the window and traces each back through ticket, peer review, test evidence, and approval. Any deploy without the full chain is an exception.

The engineering fix: Engineer the pipeline so deploys are physically blocked without a linked ticket and a recorded peer review (GitHub Advanced Security, GitLab Ultimate, ArgoCD, or equivalent). Hot fixes follow the same workflow with an emergency-change ticket type that requires retroactive review within 48 hours.

Gap 4: Vendor records stale or missing SOC 2 reviews

Control mapping: CC9.2 (Vendor and business partner risk management)

What auditors find: The vendor inventory exists but has not been refreshed in 18 months. Several Tier 1 vendors (handling production data) lack a current SOC 2 or equivalent assurance on file. Sub-processor flow-down is not enforced in contracts.

Why it fails: Vendor management failures are increasingly the most-cited SOC 2 observation because regulators (and customers) are paying more attention. Stale Tier 1 vendor records are particularly damaging.

The engineering fix: Configure your TPRM tool (OneTrust Vendorpedia, ProcessUnity, or ServiceNow VRM) with vendor tiering based on data sensitivity and integration depth. Tier 1 vendors get annual SOC 2 review with diary alerts on report expiry. Sub-processor flow-down is enforced via contract clauses authored once and reused.

Complete a 2-Minute Cybersecurity Assessment to Identify Security Gaps.

Gap 5: Backups run, but restores have not been tested

Control mapping: CC9.1 / A1.2 (System recovery)

What auditors find: Backup jobs run nightly. The completion success rate is 99.7%. But there is no record of a successful restore test within the observation window. The last documented restore was during the original deployment of the system.

Why it fails: CC9.1 and A1.2 require evidence of operating effectiveness, not just configuration. A backup that has never been restored cannot be evidenced as effective.

The engineering fix: Schedule restore tests per system on a defined cadence (monthly for tier-one, quarterly for tier-two). Restore into an isolated environment, measure actual recovery time, log the result. Adopt the 3-2-1-1-0 backup model with immutable storage. For broader continuity engineering, see our Business Continuity and Disaster Recovery service page.

Gap 6: Leavers retain access for days or weeks after termination

Control mapping: CC6.2 (Modifies access)

What auditors find: HRIS marks an employee terminated on Friday afternoon. The Active Directory account is disabled the following Tuesday by a manual ticket. SaaS accounts trickle off over the next month as individual application admins notice the user is gone.

Why it fails: Sample testing of leavers in the audit window will surface every account that took longer than the policy SLA to revoke. If the policy says same-day, every multi-day revocation is an exception.

The engineering fix: Engineer the Joiner-Mover-Leaver workflow so HRIS termination triggers automated deprovisioning across every connected system within the SLA window (typically same-day, four-hour for privileged users). Active session revocation on leaver. PAM credentials rotated automatically on admin departure. See the JML workflow on our Identity and Access Management service page.

Gap 7: Production console access without session logging

Control mapping: CC6.6 / CC7.2 (System operations and audit logging)

What auditors find: Engineers can SSH into production hosts or open cloud-console sessions in the production tenant. The activity is not centrally logged, or the logs are local to the host and never shipped to the SIEM.

Why it fails: CC6.6 and CC7.2 require auditable record of privileged activity. Production console access without centralized logging is a near-automatic finding.

The engineering fix: Enforce just-in-time elevation through the PAM tool (CyberArk, BeyondTrust, or HashiCorp Vault) with session recording. All console sessions logged centrally. SSH replaced with cloud-native session manager (AWS Systems Manager Session Manager, Azure Bastion) where possible. Privileged-session telemetry forwarded to your SOC for monitoring; the detection and response function remains with your chosen SOC and IR partner.

Gap 8: Inconsistent encryption at rest and in transit

Control mapping: CC6.7 (Encryption of data in transit and at rest)

What auditors find: Production databases are encrypted at rest, but the snapshots replicated to a secondary region use a different key model. Or some object stores use provider-managed keys (SSE-S3) while sensitive ones should use customer-managed keys (SSE-KMS). Or TLS 1.3 is enforced on the public endpoints but TLS 1.2 with weak cipher suites is still acceptable on internal endpoints.

Why it fails: Auditors trace data flows and test encryption at each stage. Any inconsistency in coverage, key model, or transport security is a CC6.7 exception.

The engineering fix: Standardize encryption posture: AES-256 at rest with customer-managed KMS keys on annual rotation; TLS 1.3 enforced at every load balancer with weak ciphers disabled; encryption verified per system. Automate the verification through CSPM (Wiz, Prisma Cloud, Microsoft Defender for Cloud). See our Cloud Security Services page for the platform engineering layer.

Gap 9: Security awareness training without tracked completion

Control mapping: CC2.2 (Communicates internal information including objectives, responsibilities, and security awareness)

What auditors find:Annual security awareness training is mandated in policy. An LMS or video platform hosts the content. But the completion rate is not tracked rigorously, and there is no quarterly phishing-simulation cadence with reporting.

Why it fails: CC2.2 requires evidence that security awareness is communicated and reinforced. Untracked completion (and missing phishing simulations) is a documented gap.

The engineering fix: Track completion in the LMS with auto-reminders and escalation for non-completion (manager-notified at 30 days overdue). Run quarterly phishing simulations through KnowBe4, Proofpoint Security Awareness, or equivalent. Report completion rates and phishing click rates to the audit committee on a defined cadence.

Gap 10: Risk register that is annual paperwork, not operational

Control mapping: CC3.1 / CC3.2 (Risk identification and assessment)

What auditors find: An enterprise risk assessment was performed at the start of the year. The risk registers lives in a spreadsheet on SharePoint. It has not been updated since the assessment. It is not connected to vendor management, change management, or vulnerability management.

Why it fails: CC3 expects an operational risk management capability, not an annual paperwork exercise. A static risk register that is not refreshed and not connected to other processes will produce observations.

The engineering fix: Migrate the risk register into your GRC platform (ServiceNow GRC, Archer, OneTrust, or Drata). Integrate with TPRM, vulnerability management, and change management, so risks are updated continuously as new threats, vendor changes, and architecture changes occur. Quarterly executive risk scorecards become a natural output.

Why a Mock Audit 30 to 60 Days Before Fieldwork Catches These Gaps

The single highest-impact step in SOC 2 readiness is an internal mock audit run 30 to 60 days before the external auditor begins fieldwork. The mock mirrors auditor procedures: walkthroughs, sample selection, evidence inspection, and exception logging.

The mock surfaces every gap above (and a few that are environment-specific) at a moment when there is still time to remediate. Remediation completed before fieldwork starts produces a clean report; remediation completed during fieldwork produces management responses and qualified observations.

BluEnt runs the mock as Stage 4 of the readiness engagement. The output is an exception register with named owners, target close dates, and a tracker that runs to zero before the auditor arrives. Independence rules require the mock to be performed by a firm distinct from the external auditor; BluEnt is the readiness partner, never the auditor.

Closing the Gaps Before Fieldwork

The ten gaps above account for the majority of qualified observations in SOC 2 reports. None of them are exotic. All of them are solvable with engineering rigor: drive controls into platforms, automate evidence collection, and run a real mock audit before the external auditor arrives.

BluEnt’s SOC 2 readiness engagement covers exactly this work: policy and procedure authoring, control engineering across Entra ID and Okta plus cloud platforms, GRC tool configuration for continuous evidence, and the Stage 4 mock audit that surfaces these gaps when there is still time to fix them. Your chosen CPA firm issues the report; BluEnt is the readiness partner, never the auditor.

For the full readiness methodology, control catalog mapped to CC1 through CC9, and the engagement structure, see ours SOC 2 Compliance Services page. For broader compliance across HIPAA, GDPR, and PCI DSS, see the Cybersecurity Compliance Services hub.