Your control matrix looks finished. Every line item maps to a Trust Services Criterion. CC6.1 has an owner, CC7.2 has a policy, CC8.1 points at your change process. The mapping column is fully populated and the design review went clean.

Then the auditor asks for the access-review evidence for September, and you have it for March. You have it for the last six weeks because that's when someone finally turned the recurring task on. The control was designed correctly the entire time. It just wasn't operating — or more precisely, you can't prove it was operating — across the window the auditor is actually testing.

That is the SOC 2 readiness gap, and it is almost never a design gap. A control mapped to a criterion is not the same as a control evidenced as operating effectively throughout a Type II observation period. The mapping says the control should exist. The Type II opinion is about whether it ran, consistently, for every day of the period. Those are two different claims, tested two different ways, and teams that treat them as one claim get a surprise in the fieldwork.

This piece walks through why the gap exists in the structure of SOC 2 itself, which controls fall into it most often, and the exact sequence to close it before your observation window opens instead of after it has already swallowed half the months you needed.

What Does a SOC 2 Report Actually Attest — and Why Does the Trust Services Criteria Structure Matter?

A SOC 2 report is an attestation by a service auditor about the controls at a service organization, evaluated against the AICPA Trust Services Criteria (TSC). It is not a certificate and it is not a pass/fail checklist. The auditor expresses an opinion on whether your controls meet the criteria relevant to the categories in scope.

That framing matters because the TSC describe outcomes the controls should achieve, not a fixed list of controls you must implement. The criteria set the objectives; you choose the controls that meet them. Two organizations can both satisfy the same criterion with very different control sets, which is why the mapping step feels so much like design work — you are arguing that your control achieves the criterion's intended outcome.

But the auditor is evaluating two distinct things, and the SOC 2 framework is explicit about it. One is the suitability of the design of the control: is it built such that, if it operates as described, it would achieve the objective? The other is operating effectiveness: did the control actually operate that way over the period. The TSC glossary itself treats "effectiveness" as encompassing both the suitability of design and operating effectiveness together. Your mapping exercise addresses the first. It says nothing about the second.

This is the structural reason the readiness gap exists. The deliverable that looks like the finish line — a complete control-to-criteria map — only answers half of what a Type II tests.

How Are the Five Trust Services Categories Organized (and Why Is Security the One Everyone Shares)?

The TSC are organized into five categories: Security, Availability, Confidentiality, Processing Integrity, and Privacy. You don't have to be assessed against all five. You scope in the categories that match the commitments you make to customers.

Security is different from the other four. In SOC 2 terminology, Security is covered by the common criteria — the set of criteria shared across all five categories. The framework states that for the Security category, the common criteria are sufficient on their own; no additional control-activity criteria are needed to evaluate whether controls achieve the security objectives. That is why Security shows up in nearly every SOC 2 engagement and is often called the baseline category.

The other four categories each layer their own category-specific control criteria on top of the common criteria:

  • Availability adds the A-series criteria covering capacity, environmental protections, and recovery.
  • Confidentiality adds the C-series covering how confidential information is identified, protected, and disposed of.
  • Processing Integrity adds the PI-series covering whether processing is complete, valid, accurate, timely, and authorized.
  • Privacy adds the P-series covering notice, choice, collection, use, retention, disclosure, and data-subject handling.

The framework is clear that a category's criteria are considered complete only when all the criteria associated with that category are addressed by the engagement. You cannot scope in Confidentiality and then quietly skip the disposal criterion because evidence is inconvenient. Scoping a category in is a commitment to evidence every criterion under it.

The practical takeaway: the more categories you scope, the more period-long evidence streams you commit to maintaining. Each added category is not just more mapping. It is more recurring proof you have to produce, every month, for the entire window.

Where Do the Common Criteria CC1-CC9 Come From, and What Are the COSO-Aligned Criteria vs. the SOC-Specific Ones?

The common criteria are numbered CC1 through CC9, and they come from two different lineages. Knowing which is which tells you where your evidence is likely to be thin.

The first five series are aligned to COSO. The TSC were mapped to the 17 principles of the COSO Internal Control — Integrated Framework, and CC1 through CC5 carry those principles directly:

  • CC1 — Control Environment. Governance, integrity and ethics, board oversight, accountability.
  • CC2 — Communication and Information. Generating and communicating the information needed to support internal control, internally and externally.
  • CC3 — Risk Assessment. Specifying objectives, identifying and analyzing risk, considering fraud and change.
  • CC4 — Monitoring Activities. Ongoing and separate evaluations, and communicating deficiencies for correction.
  • CC5 — Control Activities. Selecting and developing control activities, including general controls over technology, deployed through policy.

The remaining four series are the SOC-specific supplemental criteria. These were added on top of the COSO principles to address the things a security and systems engagement actually cares about:

  • CC6 — Logical and Physical Access Controls. How access to systems, data, and facilities is restricted, granted, modified, removed, and protected.
  • CC7 — System Operations. How the entity runs the system, detects deviations and security events, and responds to incidents.
  • CC8 — Change Management. How changes are identified, authorized, made through a controlled process, and prevented when unauthorized.
  • CC9 — Risk Mitigation. How the entity mitigates risks from business disruption and from the use of vendors and business partners.

Here is the pattern worth internalizing. The COSO-aligned criteria (CC1–CC5) are heavily governance and process oriented, and a lot of their evidence is documentary and lower-frequency: a board charter, a risk assessment, a policy set. The SOC-specific criteria (CC6–CC9) are operational, and their evidence is high-frequency and event-driven: every access grant, every termination, every change ticket, every incident, every vendor review. That is exactly where the operating-effectiveness evidence gap lives. The governance criteria are easy to map and the operational criteria are hard to evidence continuously, and the Type II tests the continuity.

What Is the Real Difference Between a Type I and a Type II SOC 2 — Suitability of Design vs. Operating Effectiveness Over the Observation Period?

This is the distinction the whole readiness problem turns on, and the SOC 2 framework draws it sharply.

A Type I report addresses the suitability of the design of controls as of a specified date — a point in time. The auditor evaluates whether the controls, as described, are designed to achieve the relevant criteria. There is no opinion on whether the controls actually operated over a period, because there is no period. It is a snapshot.

A Type II report addresses suitability of design and operating effectiveness of controls throughout a specified period. The auditor's opinion covers whether the controls operated effectively across the entire observation period to achieve the entity's objectives based on the criteria. Critically, a Type II report also includes a description of the tests of controls the auditor performed and the results of those tests. The auditor doesn't just accept that the control exists. They sample evidence from across the window and test whether it ran.

That observation period is typically somewhere from three to twelve months depending on what you and the auditor agree to, and longer windows tend to carry more weight with customers. The length is the point: the longer the window, the more days on which each operational control has to have produced evidence that it operated.

So the two report types are not "small audit" and "big audit." They are two different questions:

  • Type I: Is this control built correctly, today? — suitability of design.
  • Type II: Did this control run correctly, every relevant time, all period? — operating effectiveness.

Your mapping exercise gets you to a credible Type I story. It does not, by itself, get you a Type II story, because the Type II story is made of evidence accumulated over time that the mapping document never required you to produce.

Why Does "Mapped to a Criterion" Fail in a Type II When There's No Evidence the Control Operated Throughout the Period?

Because the auditor tests operating effectiveness by sampling, and sampling does not care about your mapping column. It cares about your evidence trail.

Here is the mechanism that burns teams. A control is mapped to CC6.2 (user provisioning and de-provisioning) and CC6.3 (access modification under least privilege). Design review passes — your process is sound, the policy is written, the workflow exists. Then the auditor selects a sample of terminations from across the twelve-month period and asks for the de-provisioning evidence for each one. For the terminations in the last two months you have clean tickets. For the termination in month three you have nothing, because the control was being run informally then and nobody captured the artifact.

The control was mapped. It may even have been operating. But operating effectiveness in a Type II is an evidence claim, and absence of evidence for a sampled instance reads as a control exception. The auditor cannot opine on what they cannot test.

Three failure modes show up over and over:

  • Passes design, no period-long evidence. The control is well-designed and the design test passes, but there is no recurring artifact proving it ran on a cadence across the window. Common on access reviews, log reviews, and vendor reviews.
  • Sampling exposes the gaps the mapping hid. Because the auditor samples instances spread across the period, a control that "mostly" ran still fails when the sampled instance happens to land on a month with no evidence. Average performance does not survive sampling; the worst sampled instance sets the result.
  • Evidence only exists for the tail of the window. This is the most expensive one. A six-to-twelve-month observation period opens, the readiness work continues internally, and by the time controls are genuinely producing evidence you are four months in. Now you have evidence for the last month or two and nothing for the front of the period. You cannot retroactively manufacture an access review that you never performed in April. The window is unforgiving because it is already running.

The unifying point: the Type II does not test whether a control is good. It tests whether you can prove it ran, on every sampled occasion, across the whole period. Mapping proves the first. Only continuous evidence proves the second.

Which Controls Most Often Pass Design Review but Have No Operating Evidence — and How Do You Close That Gap Before the Window Opens?

The repeat offenders cluster in the operational criteria (CC6–CC9) and in the periodic-cadence controls everywhere. These are the ones that look complete on the matrix and have the thinnest evidence trail:

  • Quarterly or periodic access reviews (CC6.2, CC6.3). Designed correctly, run inconsistently, rarely with a dated artifact for every cycle in the window.
  • De-provisioning on termination (CC6.2). Fine when HR and IT are in sync, invisible in the evidence record when a termination is handled out-of-band.
  • Change management tickets and approvals (CC8.1). Emergency changes and "quick fixes" routinely bypass the controlled process and leave a gap exactly where the auditor samples.
  • Log and security-event review (CC7.2, CC7.3). Monitoring exists; proof that a human reviewed and acted on it on a cadence often does not.
  • Vendor and third-party risk reviews (CC9.2). Annual on paper, undated and unfinished in practice.
  • Backup, restore, and recovery testing (the Availability A-series, if scoped). Backups run automatically; restoration tests that were actually performed and documented are frequently missing.

Here is the sequence to close the gap before the observation window opens, not after:

  1. Pick the report type and lock the window deliberately. Decide Type I versus Type II up front, and if Type II, set the observation period start date as a real event you are ready for. Do not let the window start by accident while controls are still informal.
  2. Re-read each mapped control as an evidence question. For every control on the matrix, write down the artifact that proves it ran and the cadence it has to run on. If you cannot name the artifact, the control is mapped but not evidenced. Flag it.
  3. Separate the COSO-aligned criteria from the operational ones. CC1–CC5 evidence is mostly documentary and can be assembled. CC6–CC9 evidence accrues over time and cannot. Put your effort where the time-dependency is.
  4. Stand up the recurring artifact for every periodic control before the start date. Access reviews, log reviews, and vendor reviews need a dated, repeatable output that exists from day one of the window. A calendar reminder is not evidence; the completed, timestamped review is.
  5. Run a dry sample against month one. As soon as the window opens, pull a sample the way the auditor will and try to produce the evidence. If you cannot produce it for the first month, you have a gap that compounds every month you ignore it.
  6. Track coverage continuously, not at the end. Treat missing evidence as a live exception the moment it occurs, while you can still re-run the control, rather than discovering it in fieldwork when the period is closed and the instance is unrecoverable.

The gotcha to internalize from step 5: the front of the window is the part you will be tempted to skip, because the audit feels far away. It is also the part you can never fix later. Evidence you didn't capture in the first month of a twelve-month period is simply gone.

How Do You Turn Control-to-Criteria Mapping Into Continuous, Period-Long Evidence Instead of a Point-in-Time Snapshot?

The shift is from treating the mapping as the deliverable to treating the evidence stream behind each mapping as the deliverable. The map tells you which criteria each control serves. The evidence tells you whether the control served them every day the auditor will test.

Operationally that means three changes. First, every control on your matrix needs a named, dated artifact and a cadence, bound to the criterion it satisfies, so "mapped" and "evidenced" stop being separable. Second, that evidence has to accumulate from the first day of the observation period, not get assembled in a sprint before fieldwork, because the period has already locked. Third, coverage has to be queryable at any moment — you should be able to ask "show me every month of access-review evidence for CC6.3 across this window" and get an answer, not a scramble.

This is exactly the structural problem Aegis GRC is built to solve. Controls bind to obligations, obligations bind to the criteria, and every mitigation is evidence-backed with an immutable, dated audit trail. Existing evidence in your stack is referenced where it already satisfies a control, and new evidence is requested only where the gap is real, so the reviewer's job becomes review-and-confirm instead of collect-everything. When the auditor samples month seven, the audit pack is a query, not a project.

You can see your control-to-criteria coverage, the gaps where a control is mapped but not yet evidenced for the period, and the recurring evidence each criterion needs — mapped to the obligations that actually apply to you. Start at aegis-grc.com, and read more on evidence management and control mapping.

A SOC 2 Type II is not a test of whether your controls are well-designed. It is a test of whether you can prove they operated, throughout the period, on every occasion the auditor samples. Close that gap before the window opens. Afterward, the months you missed are not coming back.

FAQ: SOC 2 Readiness, Type II Observation Periods, and Evidencing Operating Effectiveness

Is a control mapped to a Trust Services Criterion enough to pass a SOC 2 Type II? No. Mapping a control to a criterion supports the suitability-of-design half of the evaluation. A Type II also tests operating effectiveness — whether the control actually operated throughout the observation period — and the auditor tests that by sampling dated evidence from across the window. A control with no period-long evidence trail can pass design review and still produce an exception when sampled.

What is the difference between suitability of design and operating effectiveness in SOC 2? Suitability of design asks whether a control is built so that, if it operates as described, it would achieve the criterion's objective. Operating effectiveness asks whether the control actually operated that way over the period. The SOC 2 framework treats overall "effectiveness" as encompassing both. A Type I covers design as of a point in time; a Type II covers design and operating effectiveness across a specified period.

How long is a SOC 2 Type II observation period? It is a specified period agreed with the auditor, commonly in the range of three to twelve months. Longer windows generally carry more weight with customers and require more accumulated evidence. The key constraint is that evidence must exist for the controls across the entire period, including the early months, which is why standing up recurring evidence before the window opens matters.

Which SOC 2 common criteria most often have evidence gaps? The operational, SOC-specific criteria — logical and physical access controls (CC6), system operations (CC7), change management (CC8), and risk mitigation including vendor reviews (CC9) — most often pass design review but lack continuous, dated evidence. Periodic-cadence controls like quarterly access reviews, log reviews, and annual vendor reviews are the most common offenders because the artifact proving each cycle ran is frequently missing.

Do I have to evidence all five Trust Services categories? No. You scope in only the categories that match your customer commitments. Security, covered by the common criteria (CC1–CC9), is the shared baseline in nearly every engagement. Availability, Confidentiality, Processing Integrity, and Privacy each add their own category-specific criteria. But once a category is in scope, every criterion under it must be addressed and evidenced — you cannot scope a category in and skip its inconvenient criteria.