SOC 2 Security Criteria: Comprehensive Control Implementation

Owen Marsh found out how unforgiving the Common Criteria are three weeks before his auditor's fieldwork was supposed to close.

Owen is the VP of Security at Cascadia Health Analytics, a Seattle-based healthtech company that turns claims data into risk-adjustment insights for regional hospital networks. Cascadia had spent eleven months chasing a $4.2 million, four-year contract with Highline Regional Health System — a deal that would double the company's enterprise book of business, but only if Cascadia could produce a clean SOC 2 Type II report before Highline's board met to finalize the vendor selection. Owen's team had built what they believed was a solid control environment: single sign-on everywhere, a documented risk assessment, a change management process nobody had complained about in over a year. The report, they assumed, was a formality.

Then the auditor's interim testing letter arrived. Two findings, both squarely inside the Common Criteria. First, a terminated contractor's VPN credentials had stayed active for eleven days after his last day — a CC6.2 logical access exception, caught because the auditor sampled exactly that termination out of a population of forty-one. Second, three of twenty-five sampled production changes had no documented approval before deployment — a CC8.1 change management exception, because two engineers had pushed hotfixes directly and backfilled the Jira tickets afterward. Neither finding involved a breach. Neither finding involved data loss. Both findings were still going to appear in Section IV of the report, in writing, for Highline's audit committee to read.

"You have three weeks to remediate before we finalize testing," the audit partner told Owen on the call. "I can't erase what already happened during the period — the exceptions will be documented regardless. But I can document your remediation alongside them, and that's a very different report than one where nothing changed." Owen spent the next three weeks doing what he should have built into the control design from day one: an automated deprovisioning workflow tied to the HR termination trigger, and a hard block in the CI/CD pipeline that would not let code reach production without a linked, approved change ticket. The report that reached Highline's board showed two exceptions and a documented, verifiable remediation for each — dated, evidenced, and closed before the report was issued. The deal closed on schedule. But Owen has told that story to every new hire on his team since, because it is the cleanest illustration he has of a truth that catches a lot of first-time SOC 2 companies off guard: the Security criteria aren't a checkbox category. They're the floor the entire report stands on, and there is no version of SOC 2 where you get to skip them.

Who this is for and what you'll walk away with

This article is for the person actually responsible for making the Common Criteria real — implementing controls, generating evidence, and standing behind them when an auditor samples your population and asks you to prove it. You'll walk away with a control-by-control breakdown of all nine CC areas (CC1 through CC9), concrete implementation examples for each, the specific evidence artifacts auditors expect to see, how the Common Criteria map to the underlying COSO framework, the exceptions that show up most often in real Type II testing, and a phased roadmap for building this out if you're starting close to zero. Eighteen tables, a diagram of how the nine areas fit together, three case studies with quantified outcomes, and the vocabulary you need to have a precise conversation with your auditor instead of a vague one.

Security isn't one of five options — it's the floor everything else stands on

Every SOC 2 report is built on the Trust Services Criteria — five possible categories an organization can be examined against: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only one of those five is mandatory. The Common Criteria, also called the Security criteria or the CC-series, must appear in every single SOC 2 report, Type I or Type II, regardless of industry, regardless of what a company sells, regardless of what the sales team promised a prospect during a demo. There is no version of a SOC 2 engagement where a service organization opts out of the Common Criteria the way it can opt out of Availability or Privacy. If you've read our companion piece on SOC 2 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy, you already know that broader shape. This article goes deep on the one category every service organization has to implement regardless of scope decisions.

The other four TSC categories are additive — you select them based on the commitments you've made to customers and the nature of your system. A company that stores customer files selects Confidentiality. A company processing financial transactions selects Processing Integrity. A company with uptime SLAs selects Availability. A company handling consumer personal data at scale may select Privacy. None of those decisions change what's required in the Security criteria, because the Common Criteria answer a different, more fundamental question than any of the optional categories: does this organization have a functioning system of internal control at all? Everything else in a SOC 2 report is evaluated against a control environment the Common Criteria establish first.

Nearly every scoping conversation I've run with a first-time SOC 2 client starts with a version of "which criteria do we need?" The honest answer is that Security isn't a decision — it's the baseline. The decision is which of the other four to layer on top, and that decision doesn't touch a single control described in this article.

The nine Common Criteria areas, at a glance

The Common Criteria are organized into nine lettered-and-numbered areas, CC1 through CC9, each broken into numbered points of focus (for example, CC6.1, CC6.2, and so on through CC6.8). The first five areas, CC1 through CC5, map directly onto the five components of the COSO internal control framework. The remaining four, CC6 through CC9, are AICPA-specific additions that extend COSO's general control principles into the technical territory a SOC 2 examination actually has to test — access, operations, change, and third-party risk.

Think of CC1 through CC5 as the governance and organizational scaffolding — the kind of thing an auditor could largely evaluate through interviews, policy review, and board minutes. CC6 through CC9 are where the scaffolding gets tested against real systems: can you show, with logs and tickets and configuration exports, that access is actually controlled, operations are actually monitored, changes are actually reviewed, and vendors are actually managed. Most of the exceptions I see in Type II reports concentrate in CC6 through CC9, not because CC1 through CC5 don't matter, but because governance controls are easier to design correctly on paper than technical controls are to operate consistently for six to twelve months straight.

"New clients almost always underestimate CC6 through CC9 and overestimate CC1 through CC2. They'll show up with a beautiful information security policy and no idea whether their last twenty account terminations actually got deprovisioned on time. I'd rather see the reverse — sloppy policy language backed by airtight access logs — because I can help you fix wording in an afternoon. I can't retroactively create six months of access review evidence you never ran." — Renata Kucera, Audit Partner, Kucera & Ames CPAs

How the Common Criteria map to COSO's 17 principles

The AICPA didn't invent the underlying logic of the Common Criteria from scratch. It adopted the COSO Internal Control – Integrated Framework, the same framework auditors have used for financial-reporting internal controls for decades, and mapped its five components and seventeen principles directly onto CC1 through CC5. If you've worked in internal audit or financial controls before moving into security compliance, this mapping will look immediately familiar. If you haven't, it's worth internalizing, because it explains why CC1 through CC5 read the way they do — less like technical security controls and more like classic governance controls, because that's exactly their lineage.

Notice there's no principle mapped to CC6, CC7, CC8, or CC9 — because there isn't one. COSO's seventeen principles are deliberately technology-agnostic; they were written to apply to any organization's internal control system, financial or otherwise. The AICPA added CC6 through CC9 specifically because a trust-services examination has to test something COSO alone doesn't require: whether the technical implementation of access, operations, change, and vendor risk actually functions the way the governance layer says it should. CC1 through CC5 tell you whether the organization is structured to manage risk. CC6 through CC9 tell you whether that structure produces working controls on real systems.

CC1: Control Environment

CC1 establishes the tone, structure, and accountability that every other control in the report ultimately rests on. Auditors evaluate CC1 largely through document review and interviews, but "largely through interview" doesn't mean "hard to fail" — I've seen CC1 exceptions from companies that had strong technical controls everywhere else, simply because nobody could produce evidence that leadership had formally reviewed and approved the security policy in the last twelve months.

"The most common CC1 exception I write isn't 'no policy exists.' It's 'the policy exists but nobody can show me it was reviewed this year.' Policies expire the moment they stop being read by the people responsible for them. Put a review date and an owner on every policy document, or that document becomes a liability instead of an asset the day an auditor asks for the last approval." — Renata Kucera, Audit Partner, Kucera & Ames CPAs

CC2: Communication and Information

CC2 tests whether the organization actually gets the right information to the right people — internally, so employees know what's expected of them, and externally, so customers and other stakeholders understand relevant commitments. It's the criteria area most often reduced to "did people watch the training video," and that reduction is exactly how CC2 evidence ends up too thin to survive sampling.

A trust portal is worth calling out specifically here, because it does double duty: it satisfies part of the CC2 external-communication expectation and it's increasingly what enterprise prospects check before a sales call even happens. If you're building or updating one, make sure the content actually reflects your current control environment — a trust portal describing controls you retired eighteen months ago is its own kind of CC2 problem.

CC3: Risk Assessment

CC3 asks a deceptively simple question: does the organization identify and analyze the risks to its objectives, including fraud risk, on an ongoing basis? The exception I see most in this area isn't "no risk assessment exists" — it's "the risk assessment exists but was performed once, two years ago, and never updated when the business changed."

"I ask every client the same question during readiness work: 'What changed in your business this year, and did your risk assessment change with it?' If they launched a new product, hired a hundred people, or moved to a new cloud region and the risk register looks identical to last year's, that's not a stable control environment — that's a risk assessment nobody actually revisits." — Priya Chandrasekaran, GRC Lead, Bramwell Data

CC4: Monitoring Activities

CC4 tests whether the organization checks its own work — through ongoing operational monitoring, periodic separate evaluations, or both — and whether deficiencies it finds actually get communicated and fixed. This is the criteria area that turns every other control area from "designed" into "verified as operating," which is exactly why Type II auditors care about it so much: CC4 evidence is often the clearest proof that a control ran consistently across the whole audit period, not just on the day someone remembered to check.

The rise of continuous-control-monitoring platforms has changed what "good" CC4 evidence looks like. A screenshot from a point-in-time review used to be acceptable; increasingly, auditors expect to see a system that was checking control status continuously across the period, with a queryable history — because that's a fundamentally stronger form of evidence than a person remembering to run a manual check once a quarter.

CC5: Control Activities

CC5 is where COSO's control-activities component gets operationalized: the organization selects and develops the specific controls — including technology controls — that actually mitigate the risks identified in CC3, and deploys them through documented policies and procedures. In practice, CC5 is the connective tissue between "we know what our risks are" (CC3) and "here's exactly how CC6 through CC9 address them" — auditors use CC5 evidence to confirm that control selection was deliberate, not accidental.

"CC5 is where I can usually tell within the first ten minutes of a walkthrough whether a company's control environment is going to hold up. If the person in the room can point to a control matrix and tell me, without looking anything up, who owns each control and when it was last reviewed, the rest of the engagement tends to go smoothly. If they have to go find someone else to answer that, we're going to be talking again." — Renata Kucera, Audit Partner, Kucera & Ames CPAs

CC6: Logical and Physical Access Controls

CC6 is the largest and most technically dense of the nine areas, and it's where I see the highest concentration of real-world exceptions — not because companies don't understand access control conceptually, but because CC6 demands consistent operation across dozens or hundreds of individual access events over the entire audit period, and consistency is harder to sustain than good design. CC6 spans eight points of focus, from logical access infrastructure through physical security and malware prevention.

The multi-factor authentication question deserves its own callout, because it's the single most common access-control gap I still find during readiness assessments. MFA enforced for standard user accounts but exempted for admin, service, or "break-glass" accounts is a pattern auditors specifically test for, precisely because those exempted accounts are the ones with the most damage potential if compromised. The control statement that survives sampling is "MFA is enforced for all accounts, including privileged and service accounts, without exception" — not "MFA is enforced for user accounts."

Privileged accounts deserve a control layer of their own, separate from standard user access. A dedicated privileged access management tool — vaulting admin credentials, issuing time-boxed elevated sessions instead of standing admin rights, and recording privileged session activity — closes a gap that generic IAM controls alone don't reach, and it's increasingly what I expect to see when I ask a CC6.1 walkthrough question about how admin access to production is actually granted. The broader architectural direction worth aiming for, especially for companies re-platforming access controls from scratch, is zero trust: treat every access request as unverified by default, authenticate and authorize it explicitly regardless of network location, and pair it with network segmentation so that a compromised credential or device in one segment can't reach production data by default. None of this is required by name in the Common Criteria — the criteria are outcome-based, not architecture-prescriptive — but zero trust and segmentation are the design patterns that make CC6.1, CC6.3, and CC6.6 dramatically easier to satisfy and evidence consistently, rather than fighting a flat network and standing admin access every audit cycle.

"The deprovisioning gap is the single most common CC6 finding I write, and it's almost never a technology failure. It's a communication failure — HR processes the termination in the HRIS, and nobody's workflow tells IT to pull access at the same moment. The fix isn't a better ticketing system. It's connecting the HR termination event directly to the deprovisioning trigger so there's no human handoff step to drop." — Renata Kucera, Audit Partner, Kucera & Ames CPAs

CC7: System Operations

CC7 covers the operational discipline that keeps a system secure day to day: detecting vulnerabilities, monitoring for anomalous activity, and responding to security events when they occur. Like CC6, this area rewards evidence of sustained operation over the period rather than a single well-documented policy — an incident response plan nobody has tested is a CC7 gap even if it reads beautifully.

Patch management sits underneath CC7.1 in practice and deserves an explicit SLA rather than an informal "we patch when we can" approach — the pattern I see hold up best under testing is a tiered SLA (for example, critical vulnerabilities remediated within 15 days, high within 30, medium within 90), tracked in a dashboard that shows actual remediation time against the SLA, not just a list of patches applied. Auditors will pull a sample of vulnerabilities identified during the period and check whether each one was actually closed within the committed window — a policy stating an SLA that the evidence doesn't support is worse than no stated SLA at all.

"Every incident response plan looks competent on paper. What separates the plans that survive an actual incident from the ones that don't is whether the team has run it — a tabletop exercise, even a short one, twice a year. I've watched teams with excellent written plans freeze during a real event because the plan existed only as a document, never as a rehearsed muscle memory. That gap shows up in the audit too: 'when was this plan last tested' is a question every CC7.4 walkthrough asks." — Devon Ashby, Director of Security Engineering, Ridgeline Payments

CC8: Change Management

CC8 has a single point of focus, CC8.1, but don't let the short numbering fool you — change management generates more sampled exceptions in my experience than any Common Criteria area besides CC6. The criteria requires that changes to infrastructure, data, and software — from a one-line config tweak to a major release — are authorized, designed, developed, configured, documented, tested, and approved before implementation.

The exception pattern that caught Owen Marsh's team at Cascadia — engineers pushing hotfixes directly and backfilling tickets afterward — is close to the most common CC8.1 finding I see across engagements. The fix isn't a policy rewrite; it's a technical control that makes the unapproved path impossible rather than merely discouraged. A pipeline that physically cannot deploy without a linked, approved ticket produces evidence by construction. A policy that asks engineers to remember to open a ticket produces evidence only when everyone remembers, every time, for the entire audit period — and over a six-to-twelve-month Type II window, someone eventually won't.

"I tell every engineering team the same thing during change management remediation: stop trying to get people to comply with the process and start making the non-compliant path technically unavailable. Every CC8 exception I've helped a client fix for good involved moving the control from a human habit into the pipeline itself." — Devon Ashby, Director of Security Engineering, Ridgeline Payments

CC9: Risk Mitigation

CC9 closes out the Common Criteria with two points of focus that often get underinvested relative to their real-world importance: mitigating the impact of business disruptions, and managing risk introduced by vendors and business partners. If you've read our piece on SOC 2 Complementary Controls: Client Implementation Requirements, you know vendor risk also intersects with how subservice organizations are handled in report scoping — CC9.2 is the control-level counterpart to that scoping decision.

A practical detail worth flagging: CC9.2 evidence quality depends heavily on tiering. Reviewing every vendor with the same depth — from the payroll processor to the office coffee subscription — wastes effort and dilutes the evidence auditors actually care about. A defensible program tiers vendors by data access and system criticality, then applies proportionate scrutiny: critical vendors (those touching production data or in-scope systems) get a documented risk assessment, a collected SOC 2 report or equivalent attestation, and a signed security addendum; low-risk vendors get a lighter intake questionnaire. Cyber insurance, while not a control in the traditional sense, also belongs in most CC9.1 discussions as a risk-transfer mechanism auditors increasingly ask about during walkthroughs, even though it's rarely a tested control itself.

"Vendor risk is the CC9 area companies treat as an afterthought until a critical subprocessor has an incident and the first question from a customer is, 'did you know this vendor could access our data, and what did you do to vet them?' A tiered vendor register with SOC 2 reports on file for every critical vendor turns that conversation from a scramble into a five-minute lookup." — Sana Whitfield, Enterprise Security Architect, Northfield Cloud Systems

Control-to-evidence: what an auditor actually pulls, area by area

Every control example in the tables above is only as good as the evidence behind it. Auditors work from four broad evidence-gathering techniques — inquiry (asking), observation (watching a control happen live), inspection (reviewing documents/logs/configurations), and reperformance (independently redoing the control to confirm the result). Type II testing leans heavily on inspection and reperformance because those techniques produce evidence that a control operated consistently, not just that it exists. The table below maps one representative control per CC area to the evidence technique an experienced auditor is most likely to use, and why that technique fits the control.

Reperformance is the technique that trips up the most companies, because it's the one where "we have a dashboard that says we're compliant" isn't sufficient on its own — the auditor is independently recalculating the answer from raw data. If your internal tooling reports a 100% on-time deprovisioning rate but the auditor's own recalculation from HR and IAM timestamps finds an exception, the dashboard's number doesn't win. Build your evidence collection so the underlying raw data (timestamps, logs, tickets) is exportable and auditable on its own — not just the summary dashboard sitting on top of it.

Common exceptions by CC area — and how to prevent them

Type II testing exceptions cluster in predictable places once you've seen enough audit cycles. None of the exceptions below are exotic; all of them come from a gap between what a policy says should happen and what the evidence actually shows happened, consistently, across the full period.

"Nearly every exception I write traces back to the same root cause across all nine CC areas: a control that depends on a human remembering to do something manually, with no system-level backstop if they forget. The clients with the cleanest reports aren't the ones with the most elaborate policies — they're the ones who removed as many manual dependencies as possible and let the systems themselves generate the evidence." — Renata Kucera, Audit Partner, Kucera & Ames CPAs

Implementation roadmap: building the Common Criteria from close to zero

Companies rarely build all nine CC areas simultaneously, and trying to is usually a mistake — governance controls (CC1 through CC5) need to exist before technical controls (CC6 through CC9) can be evaluated meaningfully, and technical controls need to run for weeks or months before they generate the evidence history a Type II examination requires. The roadmap below reflects the sequence I recommend to companies building the Common Criteria for the first time, whether they're headed toward a Type I report first or straight into a Type II observation period.

Phases overlap deliberately — CC6 and CC7 work typically start before CC1 through CC5 documentation is fully signed off, because the technical build takes longer and needs the runway. The phase that companies most often try to skip or compress is Phase 5, the internal dry run, and it's the one I'd protect hardest if time gets tight elsewhere. A mock audit against your own evidence — pulling the same samples an external auditor would pull — routinely surfaces exactly the kind of gap that becomes a real exception if it isn't caught first internally.

Building an evidence collection calendar

The single biggest predictor of a clean Type II report I've observed across engagements isn't control sophistication — it's whether evidence collection is scheduled and owned, or left to whoever remembers before fieldwork starts. Every control example in this article implies a cadence, and the moment that cadence isn't calendared against a named owner, it quietly slips. Building a single evidence calendar that spans all nine CC areas turns nine separate compliance conversations into one operational rhythm the business can actually sustain across a six-to-twelve-month observation period.

Notice that the calendar deliberately separates "continuous/automated" from every other cadence, because that row is where the biggest evidence-quality gains come from. Anything a system can generate on its own — a deprovisioning timestamp, an MFA enforcement check, a SIEM alert — should never depend on a person remembering to capture it manually. Reserve human-owned cadences for the judgment-based activities that genuinely require a person: reviewing a risk assessment, signing off on an access review, running a tabletop exercise. That division of labor is exactly what separates Bramwell Data's three-day audit prep from the six-week version it replaced.

"I tell every client building their first evidence calendar to ask one question per control: 'if I disappeared for two months, would this evidence still get generated?' If the answer is no, that control isn't ready for a twelve-month observation period — it's ready for a two-week demo. The calendar isn't the deliverable. The automation behind the calendar is." — Marcus Delacroix, Compliance Automation Lead, Fenwick Analytics

Sizing the Common Criteria for company stage

A ten-person startup and a five-hundred-person enterprise both have to satisfy all nine CC areas — there's no size-based exemption in the criteria themselves, as the FAQ below reiterates — but what a proportionate control looks like scales sharply with headcount, system complexity, and customer expectations. Companies that copy an enterprise-grade control design too early waste scarce engineering time; companies that stay lightweight too long walk into their first Type II audit with controls that can't survive sampling once the population of access events, changes, and vendors grows past what informal tracking can handle.

The mistake I see most often isn't picking the wrong approach for a company's actual stage — it's picking last year's approach for this year's headcount. A company that just crossed 200 employees but is still running access reviews from a spreadsheet three people maintain informally isn't behind because the spreadsheet is a bad tool; it's behind because the population of access events has outgrown what a spreadsheet can track reliably enough to survive an auditor's sample. Revisit this sizing table whenever headcount, system count, or customer base crosses a meaningful threshold, not just when the next audit cycle forces the conversation.

Case study: Cascadia Health Analytics closes a $4.2 million deal despite two exceptions

The cold open of this article left Owen Marsh's team three weeks from fieldwork close with a CC6.2 deprovisioning exception and a CC8.1 change-approval exception already baked into the audit period — neither one erasable, both about to appear in Section IV of the report Highline Regional Health System's audit committee would read. What changed the outcome wasn't the exceptions disappearing. It was what Cascadia did next, and how thoroughly they documented it.

Owen's team built two things in three weeks. First, an automated deprovisioning workflow that subscribed directly to the HRIS termination event and disabled VPN, SSO, and application access within minutes rather than depending on a support ticket someone might forget to open — closing the CC6.2 gap at its root cause rather than adding a reminder to an existing manual process. Second, a hard gate in the CI/CD pipeline that rejected any deployment without a linked, approved change ticket, converting CC8.1 from a policy expectation into a technical impossibility to bypass. Both fixes were operating, and generating evidence, before fieldwork closed — which meant the auditor could test the remediation directly rather than take Cascadia's word for it.

The report Highline's board received disclosed both exceptions honestly — SOC 2 doesn't let you hide a finding that occurred during the period — but paired each one with dated, verified remediation evidence. Highline's vendor risk team told Owen afterward that the remediation narrative, not the absence of findings, was what moved the deal forward: it demonstrated Cascadia could detect a gap and close it quickly, which is arguably a stronger signal of a mature control environment than a report with no findings at all from a company that's never been tested hard enough to find one.

Case study: Ridgeline Payments learns CC7 the hard way

Ridgeline Payments, a payments infrastructure company, had strong CC1 through CC6 controls and an incident response plan that read well on paper — but had never run a tabletop exercise, and its SIEM alert rules hadn't been tuned since initial deployment eighteen months earlier. Three months into their first Type II observation period, a misconfigured API key with excessive scope was exposed in a public code repository for six hours before an automated secret-scanning tool outside the company caught it and notified Ridgeline's security team.

The underlying exposure was real but limited — the key was scoped to a non-production environment, and forensic review confirmed no customer data was accessed. The CC7 problem wasn't the exposure itself; it was what happened next. Because the SIEM's alert rules hadn't been tuned to flag credential-pattern exposures, Ridgeline's own monitoring never caught the leak — an external party did. And because the incident response plan had never been rehearsed, the on-call engineer spent almost two hours determining who had authority to revoke the key and rotate downstream credentials, well past what the documented plan's timeline implied.

Ridgeline's auditor issued the Type II report with the exception disclosed — an unqualified opinion was still achievable because the exception was isolated, the impact was limited, and the remediation was documented and partially verified within the same period. But Devon Ashby, who led the remediation, is candid that the incident reshaped how the company thinks about CC7: monitoring and incident response aren't controls you finish building once. They're controls you have to actively rehearse, or the first real test of them happens during an actual incident instead of a tabletop — which is a far more expensive way to find the gap.

Case study: Bramwell Data cuts audit prep from six weeks to three days

Bramwell Data, a mid-market analytics SaaS company, had passed two consecutive SOC 2 Type II examinations using an entirely manual evidence-collection process: spreadsheets, screenshots, and a compliance lead — Priya Chandrasekaran — who spent roughly six weeks before each audit cycle chasing down access review sign-offs, vulnerability scan exports, and change ticket approvals from a dozen different systems by hand.

The manual process wasn't just slow; it was fragile. A missed screenshot, an access review performed but never formally signed off, a change ticket closed without the approval field filled in — each was individually minor, but collectively they created exactly the kind of exceptions this article's tables describe, because evidence that exists somewhere in a system isn't the same as evidence that's been captured, dated, and organized for an auditor's sample. Bramwell's third audit cycle nearly produced a CC4 exception when Priya discovered, two days before fieldwork, that a quarter's access review had been performed on time but the sign-off had been recorded in a Slack thread instead of a trackable system.

Bramwell's fix wasn't a policy change — it was investing in continuous monitoring tooling that pulled evidence directly from source systems (the IAM platform, the vulnerability scanner, the CI/CD pipeline, the HRIS) on an ongoing basis rather than reconstructing it from memory before fieldwork. Priya's compliance role shifted from evidence archaeologist to evidence reviewer — a meaningfully different, and far less stressful, job. The lesson generalizes well beyond Bramwell: every control example in this article's tables gets dramatically cheaper to prove once the evidence is generated automatically by the system operating the control, rather than manually assembled by a person remembering to document it after the fact.

"I used to dread audit season. Now it's a Tuesday. The difference wasn't working harder during those six weeks — it was never letting six weeks of undocumented evidence accumulate in the first place." — Priya Chandrasekaran, GRC Lead, Bramwell Data

The Security criteria as a business asset, not just an audit requirement

It's easy to treat the Common Criteria as a compliance tax — nine areas of control overhead that exist because a customer's procurement team demands a report before signing a contract. That framing isn't wrong, exactly, but it undersells what a well-implemented Security criteria program actually produces. Every table in this article — the CC6 access control matrix, the CC7 vulnerability remediation SLA, the CC9 vendor risk register — is also a sales asset the moment a prospect's security team starts asking hard questions during due diligence. Cascadia Health Analytics didn't just close a deal despite two exceptions; they turned a remediation story into evidence of organizational maturity that a company with a spotless but never-stress-tested report couldn't have told as convincingly.

The companies that get the most business value out of their Security criteria implementation are the ones that stop thinking of CC1 through CC9 as nine separate audit checkboxes and start thinking of them as nine components of one operating system for trust. Access control, monitoring, change management, and vendor risk aren't just what an auditor samples once a year — they're the daily operational discipline that actually prevents the incident that would otherwise cost you the deal, the customer, or the headline. Get the Common Criteria right, and the Type II report becomes a byproduct of how you already run the business, not a separate project bolted on before renewal season.

If you're building out your Security criteria implementation from scratch or hardening an existing one, our SOC 2 Control Matrix / RACI Template gives you a starting structure for mapping controls to owners across all nine CC areas, and our SOC 2 Trust Services Criteria Mapping Template helps you connect each control back to the specific point of focus it satisfies. If you're earlier in the process and still assessing where your gaps are, run our SOC 2 Gap Analysis Tool against your current control environment, or take the "Are You SOC 2 Ready?" quiz for a faster gut check before committing to a full readiness engagement. And if you want the full policy language to pair with the technical controls described here, our SOC 2 Policy Pack covers the CC1 and CC2 documentation most teams underinvest in relative to the technical work.

For a broader view of how the Security criteria fit alongside the optional Trust Services categories, revisit our SOC 2 Complete Guide: Understanding AICPA Trust Services Criteria, and if your organization is weighing SOC 2 against a certifiable framework, our cross-pillar piece on ISO 27001 vs SOC 2: which one do you need walks through how the two approaches differ in practice — or, if you're pursuing both, Running ISO 27001 and SOC 2 Together shows where the control work in this article overlaps with Annex A implementation instead of duplicating it.