SOC 2 Common Criteria: Universal Requirements for All SOC 2 Reports

Maria Ferreira had one slide left in the board deck, and it was the only one that mattered. Lumen Ledger, the invoice-automation SaaS platform she'd co-founded four years earlier, had a $2.4 million enterprise contract sitting in a procurement queue at a regional bank — a deal that would nearly double the company's annual recurring revenue overnight. The bank's third-party risk team had sent back a two-line email: "We cannot proceed without a SOC 2 Type II report covering the Security category. Please advise on timeline."

Maria's first instinct was relief. Lumen Ledger didn't process payments or store health records, so she assumed the "Security" ask would be light — maybe a firewall diagram and a password policy. Her second instinct, twenty minutes into a scoping call with an audit firm, was closer to panic. The auditor didn't ask about firewalls. She asked about board-level oversight of ethics violations, whether risk assessments considered fraud scenarios, how deprovisioning was evidenced for terminated employees, and whether Lumen Ledger's most recent production deployment had a documented rollback plan. None of that appeared anywhere in Lumen Ledger's thin security policy binder.

What Maria was colliding with, without yet having a name for it, was the Common Criteria — the nine groups of controls, numbered CC1 through CC9, that make up the Security category of the Trust Services Criteria. She would learn, over the following weeks, that these nine groups are not a menu item she could pick and choose from. They are the floor. Every SOC 2 report ever issued — whether for a two-person fintech startup or a hyperscale cloud provider, whether it also covers Availability or Privacy or nothing else — includes the Common Criteria in full. There is no version of a SOC 2 without them.

This article is the map Maria wishes she'd had on that first call: a complete, structural tour of CC1 through CC9, how they trace back to a 1990s internal-control framework called COSO, and how they connect to everything else in the SOC 2 world — the optional categories, the evidence auditors want, and the exceptions that sink first-time examinations.

Who this is for: security leaders, compliance managers, and engineering directors — like Maria — who are staring down their first SOC 2 scoping call and need to understand what the Common Criteria actually require before they promise a board or a customer a delivery date. What you'll walk away with: a working mental model of all nine CC groups, their COSO lineage, how they differ from the optional Trust Services Categories, and where to find the deep-dive article for each one when you're ready to implement.

The Common Criteria Are Not Optional — They're the Floor

Here's the structural fact that trips up almost every first-time SOC 2 buyer: the Trust Services Criteria is a set of five categories — Security, Availability, Processing Integrity, Confidentiality, and Privacy — but only one of those five, Security, is required in every report. The other four are add-ons, selected based on the service organization's scope and the commitments it has made to customers. Security is not selectable. It is the baseline every auditor's opinion is built on, and its formal name inside the criteria itself is the Common Criteria — so called because the same nine groups of controls are "common" to every SOC 2 report regardless of which other categories get bolted on.

I've scoped over 60 SOC 2 engagements in the past fifteen years, and I still watch smart, technical founders make the same mistake Maria made: they assume "Security" means firewalls, encryption, and maybe a penetration test. In reality, the Common Criteria span governance, ethics, HR practices, risk assessment methodology, vendor oversight, incident response, change control, and business continuity — a far wider net than most engineering teams expect walking in. If you remember one thing from this article, make it this: you cannot buy your way out of the Common Criteria by choosing a narrow scope. Every single SOC 2, from the leanest Type I to the most exhaustive multi-category Type II, contains all nine CC groups in full.

If your organization is scoping its very first engagement, the SOC 2 Complete Guide to the AICPA Trust Services Criteria is the right starting point before this one — it explains the whole framework end to end. This article goes one level deeper, into the Common Criteria specifically, because that's where every organization's real work begins.

Who Actually Demands the Common Criteria

Maria's board assumed the bank's request was a one-off box-check. It wasn't. In fifteen years of scoping engagements, I've watched the list of parties who explicitly ask for Common-Criteria evidence grow steadily longer, and it rarely stops at the customer's procurement desk.

Once you see the full list, the Common Criteria stop looking like a single customer's odd request and start looking like the common language every stakeholder in your business will eventually want you to speak fluently.

Where the Common Criteria Come From: COSO

The Common Criteria didn't appear out of nowhere. The AICPA built the first five groups — CC1 through CC5 — directly on top of the COSO Internal Control–Integrated Framework, a model originally developed for financial reporting controls by the Committee of Sponsoring Organizations of the Treadway Commission. COSO organizes internal control into five components, each broken into a set of principles, seventeen in total. The AICPA mapped those five components one-to-one onto CC1–CC5, then added four more groups — CC6 through CC9 — that are specific to information systems and don't have a COSO analog. That's why, structurally, the Common Criteria feel like two different things stitched together: a governance layer borrowed from enterprise risk management, and a technical layer built for the realities of cloud infrastructure, application code, and IT operations.

"The first time I explain COSO to an engineering team, I watch their eyes glaze over — until I tell them CC1 through CC5 is basically 'how does your company make decisions and hold people accountable,' and CC6 through CC9 is 'how does your company run its systems.' Once that clicks, the whole framework stops feeling arbitrary." — Renata Silva, Audit Senior Manager, Halden & Ostrow LLP

The seventeen COSO principles map to specific point-of-focus numbers inside CC1–CC5, and auditors will reference both when they write findings. Knowing this mapping ahead of time saves you from being blindsided by a request that sounds like it belongs to HR or the board, not IT.

The Nine-Part Structure: CC1 through CC9 at a Glance

Before we walk each group individually, it helps to see the whole shape of the thing. Nine groups, roughly 33 total points of focus (the specific sub-requirements auditors test against), split cleanly into a governance half and an operations half.

Notice the visual break in the diagram: CC1–CC5 trace to COSO, CC6–CC9 don't. That break isn't cosmetic — it changes how you evidence each half, which we'll come back to later.

CC1 — Control Environment

CC1 is where most first-time SOC 2 candidates get their first uncomfortable surprise, because it has almost nothing to do with technology. It asks whether the organization has a genuine culture of accountability: documented code of conduct, a board or governance body that exercises real oversight (not just a rubber stamp), clear organizational structure with defined reporting lines, evidence that competence is a hiring and development priority, and consequences when people don't meet expectations.

"Founders love to tell me their culture is great. I don't want a culture — I want a signed acknowledgment log, board minutes that mention security at least quarterly, and a disciplinary process that's actually been used once. CC1 punishes companies that can't produce a paper trail for the culture they claim to have." — Tom Reyes, CISO, Fielder Analytics

For a full implementation walkthrough of this group — including sample charters and board reporting cadences — see SOC 2 Control Environment: Tone at the Top and Governance.

CC2 — Communication and Information

CC2 asks a deceptively simple question: does relevant information about your control environment actually move to the people who need it, both inside the company and out? That includes internal reporting (does engineering know when a policy changes?) and external communication (do customers and auditors get accurate information about your system, incidents, and commitments?).

Lumen Ledger's own gap, when Maria's team finally mapped it, sat squarely in CC2.3 — there was no defined process for telling customers about a security incident, and no template ready to go. Building that from scratch under deadline pressure is exactly the kind of scramble this article is meant to help you avoid. The dedicated deep dive is SOC 2 Information and Communication: Documentation and Reporting.

CC3 — Risk Assessment

CC3 is the group auditors lean on hardest to judge whether an organization actually understands its own exposure, rather than just having a security policy someone downloaded off the internet. It requires specified objectives against which risk can be measured, a documented process for identifying and analyzing risk, explicit consideration of fraud risk (not just external attackers), and a process for evaluating risk introduced by significant change — new products, new vendors, new infrastructure.

"I ask every client the same question in the kickoff meeting: 'Show me the last time your risk register changed because your business changed.' If they can't answer, CC3 is going to be a rough quarter for them." — Priya Raman, SOC 2 Program Lead, Vantage Logistics Cloud

Full walkthrough: SOC 2 Risk Assessment Process: Identifying and Managing Risks.

CC4 — Monitoring Activities

CC4 asks whether the organization checks its own work. Two points of focus, deceptively small in number but broad in reach: are controls being evaluated on an ongoing or periodic basis, and are deficiencies actually communicated to the people who can fix them — not buried in a spreadsheet nobody reopens.

This is also where a lot of organizations discover the gap between having controls and knowing whether those controls are working — a distinction that becomes the whole subject of SOC 2 Monitoring Activities: Ongoing Assessment and Improvement.

CC5 — Control Activities

CC5 closes out the COSO-based half of the Common Criteria by asking how the organization actually selects, builds, and rolls out its controls — including the general controls over the technology that everything else depends on.

"CC5 is where I tell clients: stop writing policies nobody reads and start writing procedures your team actually follows on a Tuesday afternoon. The gap between the two is where most control activities findings come from." — Dana Okafor, Director of Security Compliance, BrightLedger Technologies

Deep dive: SOC 2 Control Activities: Day-to-Day Operational Controls.

Why CC1–CC5 Feel Different From CC6–CC9

If you've made it this far, you've probably noticed a shift in tone. CC1 through CC5 read like governance and management-system language — board oversight, competence, accountability, risk methodology. CC6 through CC9 are about to read like a security engineer's checklist — access provisioning, encryption, patching, incident detection, change tickets, disaster recovery. That's not an accident of how I've written this article; it reflects the real architecture of the Common Criteria. The AICPA took COSO's five general-purpose internal-control components and layered four IT-specific groups on top, because COSO was never written with cloud infrastructure or application code in mind. In practice, this means CC1–CC5 findings tend to come from documentation and governance gaps, while CC6–CC9 findings tend to come from technical configuration and operational-discipline gaps. Most engineering-led organizations are stronger on the second half and weaker on the first — which is exactly the inverse of what they expect walking in.

CC6 — Logical and Physical Access Controls

CC6 is the largest group in the entire Common Criteria — eight points of focus — and the one most people mentally associate with "SOC 2 security" before they've read the framework. It covers how access to systems and facilities is granted, authenticated, restricted, monitored, and revoked.

This is exactly where Maria's auditor found her deprovisioning gap: three former Lumen Ledger contractors still had active credentials to a staging environment ninety days after their contracts ended. It became a documented exception in the readiness assessment — and, quietly, the single most expensive line item in the whole remediation project, because it required rebuilding the entire offboarding workflow, not just revoking three accounts.

"CC6.5 is the point of focus that finds you, not the other way around. Every audit I've run in the last decade has surfaced at least one lingering account that should have been killed weeks earlier." — Marcus Webb, VP Engineering, NimbusCare Health

The full control-implementation walkthrough for this and the rest of the Security category lives in SOC 2 Security Criteria: Comprehensive Control Implementation.

CC7 — System Operations

CC7 covers how the organization runs its production systems day to day: detecting anomalies, responding to incidents, recovering from disruption, and managing vulnerabilities before they become breaches.

CC7 is also where penetration testing results and vulnerability remediation timelines get evaluated most closely — auditors want to see not just that scans run, but that findings get triaged and closed on a defined schedule.

CC8 — Change Management

CC8 has only one point of focus, but don't let the low number fool you — it's one of the most frequently cited sources of exceptions in Type II reports, because it requires consistent, evidenced behavior across every single production change during the entire audit period, not just a policy that reads well.

"CC8.1 is a one-liner in the framework and a full-time job in practice. I've seen engineering teams with beautiful CI/CD pipelines fail this point of focus because nobody could produce evidence that a hotfix deployed at 2 a.m. on a Saturday had gone through the same approval gate as everything else." — Chidi Nwosu, Founder/CTO, PayRail Systems

CC9 — Risk Mitigation

CC9 closes the framework by asking how the organization plans for disruption — both risk originating inside the business and risk introduced by the vendors and subservice organizations it depends on.

CC9.2 is the point of focus that ties the Common Criteria directly to your supply chain — every cloud provider, payroll vendor, and SaaS tool your organization relies on becomes, in some small way, part of your own audit exposure.

How Auditors Actually Test Each CC Group

Understanding the nine groups conceptually is one thing; understanding how a CPA firm will actually verify them is another, and it changes what evidence you should be collecting from day one. Auditors rely on four standard testing procedures, and which one gets used depends heavily on whether you're in a Type I or Type II engagement and which half of the Common Criteria is under review.

For a Type II report, auditors don't test once — they pull a sample of instances across the entire observation period. If CC8.1 requires every production change to be authorized and tested, the auditor won't look at one deployment; they'll pull a statistically meaningful sample from the full period and expect every single one to show the same evidence trail. This is the mechanic behind why CC6 and CC8 generate so many exceptions: a single missed step, even once in eleven months, can surface in the sample.

"New clients are always surprised that I don't just want to see your policy. I want to see the policy, then I want to watch you follow it, then I want to pull three random weeks from the middle of your audit period and see the same thing happened there too." — Tom Reyes, CISO, Fielder Analytics

How the Common Criteria Relate to the Optional Trust Services Categories

Once you understand that the Common Criteria are mandatory and the other four categories are add-ons, the next natural question is: how do they relate to each other in practice? The honest answer is that the optional categories don't replace or duplicate the Common Criteria — they extend the audit into commitments the Common Criteria don't fully cover, while quietly relying on CC6–CC9 as their technical foundation.

In other words, an organization never "does Availability instead of Security" — it does the Common Criteria, always, and then optionally layers Availability, Processing Integrity, Confidentiality, or Privacy on top of that same foundation. Auditors will often test a single piece of evidence — a disaster recovery test, for instance — against both CC7.5 and an Availability criterion simultaneously, because the underlying control satisfies both.

"Clients ask me all the time whether they can 'skip' the Common Criteria if they only care about Availability. I tell them the same thing every time: Availability doesn't exist without Security underneath it. You can't rent the roof without buying the house." — Renata Silva, Audit Senior Manager, Halden & Ostrow LLP

If your organization is evaluating whether to add one of the optional categories, the companion article — SOC 2 Additional Criteria: Optional Trust Services Categories — walks through the decision framework in full, including how customer commitments typically drive the choice. And if you haven't yet read the category-by-category primer, SOC 2 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy is the companion piece to this one.

Evidence Auditors Expect for Each CC Group

Every point of focus needs a matching evidence artifact, or it doesn't exist as far as the auditor's opinion is concerned. Here's the evidence map I hand every client at kickoff, organized by CC group rather than by point of focus, because that's how most compliance teams actually organize their evidence libraries.

The best practitioner teams I've worked with build this evidence map into their continuous compliance tooling before the audit even starts, so evidence accumulates automatically across the audit period instead of getting reconstructed from memory in the final week.

The Common Criteria Aren't Entirely Yours to Control

One detail that surprises almost every first-time client: not every point of focus in CC1–CC9 is something your organization can satisfy entirely on its own. Two related concepts sit underneath the Common Criteria and explain why.

First, complementary user entity controls — controls your customers are responsible for operating, even though they appear inside your system description. If CC6.2 requires proper authorization before granting access, and your platform allows customer administrators to provision their own users, then part of that control's effectiveness depends on the customer actually reviewing who they've granted access to. Your auditor will note this as a CUEC, and your report will explicitly list it as an assumption underlying your own control's design.

Second, complementary subservice organization controls — the mirror image, but pointed at your vendors. If you use a cloud infrastructure provider and you've scoped their physical security controls out of your own audit under the carve-out method, CC6.4 (physical access restriction) is partially satisfied by controls you don't operate and can't directly evidence — you're relying on your provider's own SOC 2 report instead.

Both concepts thread through nearly every CC group, but they concentrate most heavily in CC6 (access), CC7 (operations), and CC9 (vendor risk). Getting this distinction right — knowing which points of focus are fully yours, which are shared with customers, and which depend on a vendor's own attestation — is foundational scoping work that belongs early in the process, not discovered mid-audit. The two dedicated articles on this topic are SOC 2 Complementary Controls: Client Implementation Requirements and SOC 2 User Entity Controls: Client Responsibility Documentation.

Common Mistakes When Scoping the Common Criteria

Before we get into what goes wrong during the audit itself, it's worth pausing on what goes wrong even earlier — during scoping, before a single control has been tested. These are the scoping mistakes I see most often, and unlike control exceptions, they're entirely avoidable with a half-day workshop before the engagement letter gets signed.

I've watched more first-time engagements go over budget from scoping mistakes than from actual control failures — get the boundary and the readiness timing right, and the Common Criteria stop being a moving target.

Common Exceptions and Findings Across the Common Criteria

After enough audits, patterns emerge. These are the findings I see most often, by CC group, across first-time and even second-year SOC 2 engagements.

CC6 and CC8 exceptions are, in my experience, the two most expensive to remediate mid-audit, because they require process change rather than a one-time documentation fix — and process change takes weeks to prove is actually operating, not just written down.

What Happens When a Point of Focus Fails

An exception doesn't automatically sink a SOC 2 report, and it's worth understanding the actual mechanics so a single finding doesn't turn into unnecessary panic. When testing surfaces a gap — say, one terminated contractor's access wasn't revoked within the expected window — the auditor documents it as a noted exception tied to the specific point of focus, typically CC6.5 in that example. Management then has the opportunity to write a formal response describing the root cause and the remediation taken.

A small number of isolated exceptions, promptly remediated and honestly disclosed, usually still results in an unqualified opinion with the exceptions and management's response documented in the report — sophisticated customers read these sections and often view a well-handled exception as a sign of a mature program, not a red flag. It's a pattern of unremediated or recurring exceptions across an entire CC group, or an exception so significant it undermines confidence in the whole control, that pushes a report toward a qualified opinion. Adverse opinions and disclaimers are rare in SOC 2 practice and generally reflect either pervasive control failure or an inability to gather sufficient evidence at all.

"I tell clients: I'd rather see three honest exceptions with a clear root cause and a fix already in motion than a report claiming zero findings that I don't fully believe. Customers who actually read these reports feel the same way." — Dana Okafor, Director of Security Compliance, BrightLedger Technologies

This is exactly the dynamic NimbusCare Health lived through — two real exceptions in their first Type II, handled transparently, followed by a documented remediation story that became a selling point rather than a liability the following year.

Type I vs. Type II and the Common Criteria

The Common Criteria themselves don't change between a Type I report and a Type II report — the same nine groups and roughly 33 points of focus apply either way. What changes is what the auditor tests against them.

This is precisely why most customers — and most enterprise procurement teams, like the one reviewing Maria's contract — insist on Type II. A Type I report proves you built the house; a Type II report proves you've lived in it responsibly for months without letting anything slide. For the full comparison, read SOC 2 Type I vs Type II: Choosing the Right Audit Type.

Where the Common Criteria Show Up in the Report Itself

It's worth knowing exactly where CC1–CC9 land once the audit is finished, because the report is what your customers will actually read — and different readers care about different sections. A finished SOC 2 report has four standard sections, and the Common Criteria run through three of them.

Most customer security reviewers skip straight to the fourth section — the tests-of-controls table — because it's the only part of the report that shows, point of focus by point of focus, exactly what was tested and whether it passed cleanly. If you want to know what a reviewer at a bank like the one evaluating Lumen Ledger is actually going to scrutinize, it's that table, mapped directly back to CC1 through CC9. The full breakdown of every report section lives in SOC 2 Report Structure: Understanding the Auditor's Report.

Who Owns Each CC Group? A RACI View

One of the fastest ways to blow a SOC 2 timeline is to leave CC ownership ambiguous until the auditor asks a question nobody can answer. Here's a simplified RACI I use to kick off engagements — adapt the names to your own org chart, but keep the shape.

"The single best predictor of a smooth audit isn't the size of the security team — it's whether every CC group has one named owner who can produce evidence without a scavenger hunt across four departments." — Priya Raman, SOC 2 Program Lead, Vantage Logistics Cloud

A Simple Maturity Model for the Common Criteria

Not every organization needs to gold-plate all nine CC groups on day one. What I use with clients instead is a three-stage maturity model — it helps prioritize where to spend the first month of effort versus where "good enough" documentation will pass a first Type I comfortably.

Stage 1 is generally sufficient for a first Type I report. Stage 2 is the realistic minimum for a clean first Type II. Stage 3 is where organizations stop treating the audit as an event and start treating it as a byproduct of how they already run the business — which is where NimbusCare and Vantage Logistics Cloud both ended up after their remediation work.

Case Study: Lumen Ledger's $2.4 Million CC6 Wake-Up Call

Back to Maria Ferreira. Once Lumen Ledger's readiness assessment came back, the picture was clear: CC1 and CC2 needed documentation work (board minutes, a customer incident-notification template), but CC6 and CC8 needed real process change. The company had never formalized offboarding — when a contractor's engagement ended, someone on the team was supposed to remember to revoke access, but nothing enforced it. Three stale accounts, ninety days stale, became a documented exception risk in the pre-audit gap review.

Maria's team spent six weeks building an automated deprovisioning workflow tied to their HR system, so access revocation fired the same day a contract ended rather than depending on someone's memory. They also stood up a lightweight change-approval gate in their CI/CD pipeline so emergency hotfixes routed through the same authorization trail as planned releases — closing the CC8.1 gap an early mock audit had flagged. The Type II observation period ran six months. The final report carried an unqualified opinion with zero exceptions in CC6 or CC8. The bank's procurement team signed off nine days after receiving the report. The $2.4 million contract closed, and two smaller deals that had been quietly waiting behind it closed within the following quarter.

Case Study: NimbusCare Health's First-Audit CC7/CC8 Failure

NimbusCare Health, a remote patient-monitoring platform, walked into its first SOC 2 Type II confident that its engineering rigor would carry the day — the team shipped multiple times a day with a mature CI/CD pipeline. The auditor's draft report told a different story: two exceptions, both concentrated in CC7 and CC8. Vulnerability scan findings were sitting unremediated for an average of 47 days with no defined SLA (a CC7.1 gap), and roughly 15% of production deployments during the audit period lacked a recorded code-review approval because engineers occasionally pushed directly to production during incident response (a CC8.1 gap).

"We thought our deploy speed was a strength. The auditor showed us it was actually hiding a control gap — fast doesn't mean evidenced." — Marcus Webb, VP Engineering, NimbusCare Health

NimbusCare's leadership treated the exceptions as a 90-day sprint rather than a failure. They implemented a 14-day remediation SLA for critical and high vulnerability findings, added an automated gate that blocked any production deployment without a linked, approved change ticket — including incident hotfixes — and ran a bridge-period internal audit to prove the new controls operated consistently before the next observation window opened. Their following year's Type II report came back clean, and the compliance team used the story as a case study in their own sales enablement material — turning a first-audit failure into a credibility asset with prospective customers who asked pointed questions about incident handling.

Case Study: Vantage Logistics Cloud Scales CC6 With Automation

Vantage Logistics Cloud grew from 40 to 260 employees during a single 12-month Type II observation period — exactly the kind of headcount growth that turns CC6 access reviews into a nightmare if they're done manually. Under their old process, a quarterly access review meant a compliance analyst manually cross-referencing a spreadsheet of active employees against permissions in eleven different systems. At 260 employees, that process was projected to take three full working weeks per quarter.

Priya Raman's team instead built an automated access-review pipeline that pulled live identity data from their IAM system and flagged any account whose access hadn't been reviewed or recertified within 90 days, or whose owner had left the company. The quarterly review dropped from three weeks of manual cross-referencing to roughly two days of exception handling. More importantly, the automation caught two access anomalies mid-period — including one departing employee whose access had been missed by the standard offboarding ticket — well before the audit period closed, turning what could have been a CC6.5 exception into a documented detect-and-correct story that the auditor cited approvingly in the report's control descriptions.

How the Common Criteria Show Up Differently by Business Model

The nine CC groups apply identically on paper to every service organization, but which ones tend to generate the most work varies noticeably by business model. Knowing your category's typical pressure points before you start helps you budget remediation time realistically.

None of this changes what the framework requires — every organization still needs all nine groups — but it does change where I tell clients to spend their first month of effort. A fintech spending its readiness budget polishing CC2 communication templates while its vendor risk program (CC9) is nonexistent has its priorities backward.

Preparing Your Team for a Common Criteria Evidence Request

The single most common reason a Type II observation period gets stressful in month ten isn't a control failure — it's an evidence request that lands on someone's desk who has no idea what's being asked or why. A little pre-work fixes most of this.

Teams that do this prep work up front consistently describe their Type II observation period as "quiet" — evidence requests become a five-minute pull from an existing log rather than a fire drill.

Budgeting and Timeline for Common Criteria Readiness

Every organization's starting point is different, but after enough engagements a rough shape emerges. Here's the timeline I sketch for clients scoping their first Common-Criteria-only Security-category SOC 2 — figures are illustrative and will shift with headcount, existing tooling, and how much of CC1–CC5's documentation already exists.

Organizations that automate evidence collection early — tying continuous monitoring tooling directly to CC6–CC9 evidence needs — consistently cut the observation-period workload by more than half compared to teams still pulling screenshots manually in month eleven.

The Common Criteria Don't Stop at the First Report

First-time clients tend to picture the Common Criteria as a project with a finish line — pass the audit, frame the report, move on. In practice, every one of the nine groups keeps running long after the report is issued, because most customers expect a new Type II report annually, and gaps between observation periods have to be accounted for somehow.

That's where a bridge letter comes in — a short interim letter, usually covering the weeks or months between the end of one Type II audit period and the start of the next, confirming that no material changes occurred to CC1–CC9 controls in the gap. Customers who need continuous assurance between annual audits (a bank's ongoing vendor monitoring program, for instance) frequently ask for this letter directly, and being able to produce one within days — rather than scrambling to reconstruct months-old evidence — is a direct dividend of the evidence habits described earlier in this article. The dedicated articles on this lifecycle are SOC 2 Observation Period: Understanding the Review Timeframe and SOC 2 Bridge Letter: Maintaining Continuous Compliance.

Organizations that treat the Common Criteria as a standing operating discipline, rather than an annual fire drill, consistently spend less each year on remediation and more of their audit budget on scope expansion — adding Availability or Confidentiality, for instance, once the Security foundation is solid.

How the Common Criteria Compare to ISO 27001 and NIST CSF

If your organization is also considering ISO 27001 certification, or benchmarking against the NIST Cybersecurity Framework, it helps to see roughly where the Common Criteria sit relative to those structures. The frameworks aren't identical — SOC 2 is an attestation against criteria, ISO 27001 is a certifiable management-system standard, and NIST CSF is a voluntary risk-management framework — but the underlying security domains overlap heavily, which is why so many organizations end up pursuing more than one.

Treat this table as directional, not a formal crosswalk — the point is to show that a control you've already built for one framework, like a documented change-management process, is rarely wasted effort if you later pursue the other. Organizations running both programs simultaneously typically map a single piece of evidence to both frameworks rather than duplicating the work. For the detailed control-by-control mapping, see the ISO 27001, SOC 2 & NIST CSF Crosswalk, and for the strategic question of whether to pursue one framework or both, ISO 27001 vs SOC 2: Which One Do You Need.

A 12-Question Readiness Self-Check Before You Call an Auditor

Before Maria's team booked their first formal readiness assessment, I'd have handed them this list. It won't replace a proper gap analysis, but it will tell you in about twenty minutes whether you're closer to Stage 1 or Stage 3 on the maturity model above — and which CC groups deserve your attention first.

If you answered "no" or "not sure" to more than three of these, budget for a full readiness assessment before setting an audit date — walking into fieldwork with unresolved gaps in half the Common Criteria is how a six-month project turns into a fourteen-month one.

The Common Criteria as a Business Opportunity, Not Just an Audit Line Item

It's easy to treat CC1 through CC9 as a compliance tax — nine hurdles between your team and a signed contract. I'd push back on that framing, because I've watched it play out the other way too many times. Maria Ferreira's team didn't just close a $2.4 million deal; they came out of the process with an offboarding workflow that eliminated a real security exposure, a documented risk register that actually gets updated, and a customer-communication process that made every subsequent security questionnaire faster to answer. NimbusCare turned a first-audit failure into sales enablement material. Vantage Logistics Cloud built access-review automation that would have paid for itself in engineering time alone, SOC 2 or not.

The organizations that get the most value out of the Common Criteria are the ones that stop asking "what's the minimum we need to pass" and start asking "which of these nine groups, if we actually built them well, would make our business more resilient regardless of the audit." CC3's risk assessment discipline catches real business risk, not just audit risk. CC9's vendor review process catches real supply-chain exposure. CC6's access hygiene closes real attack surface. The audit is the forcing function; the resilience is the actual prize.

If your organization is early in this journey, start with a structured readiness assessment that maps your current state against all nine CC groups before you commit to an audit date — it's the single highest-leverage step in the entire process, and it's exactly the kind of gap analysis PentesterWorld's compliance team builds for clients moving from "we think we're ready" to "we can prove it."

Ready to Map Your Own CC1–CC9 Gaps?

You don't have to reconstruct the Common Criteria evidence map from scratch the way Maria's team did under deadline pressure. Start with the SOC 2 Readiness Checklist to benchmark your current state against all nine CC groups, use the SOC 2 Control Matrix / RACI Template to assign ownership before your kickoff call, and pressure-test your understanding with the "Are You SOC 2 Ready?" Quiz. If you're weighing which optional categories to add on top of the Common Criteria, the SOC 2 Trust Services Criteria Mapping Template will save you a full week of scoping meetings, and the SOC 2 Glossary is worth bookmarking before your first auditor call — you'll hear half these terms in the first ten minutes.