Priya Nair had twenty minutes to save a $2.3 million contract, and she was losing the argument.
Priya was VP of Engineering at Ledgerly, a payroll-advance fintech that had spent eighteen months building a slick product on top of a cloud infrastructure provider called Meridian Cloud. Ledgerly's SOC 2 Type II report — clean, unqualified, six months of evidence — sat open on her screen. Across the video call, Trellis Bank's third-party risk team had a single, deceptively simple question: "Your report says logical access controls restrict who can reach production data. Who patches the hypervisor those workloads run on — you, or Meridian?"
Priya didn't know. Neither did her compliance lead. Ledgerly's system description mentioned Meridian Cloud in a single sentence and moved on. The auditor's opinion was unqualified, but nobody at Ledgerly could actually draw the line between what Ledgerly's engineers controlled, what Meridian's infrastructure team controlled, and what Trellis Bank itself was supposed to be doing on its own side of the connection. The deal didn't die that day — but it stalled for six weeks while Ledgerly rebuilt its understanding of shared responsibility from scratch, re-papered its subservice organization relationship, and produced a control-mapping document Trellis Bank's risk team could actually use.
That six-week scramble is avoidable. It's also one of the single most common gaps I see in fifteen-plus years of guiding service organizations through SOC 2 — not a missing control, but a missing map of who owns which control. This article is that map.
Who this is for: engineering leaders, compliance managers, and founders at service organizations — especially SaaS companies built on cloud infrastructure — who need to understand the nine Common Criteria that anchor every SOC 2 report, and who needs to own each one when your stack has three or more layers of vendors underneath it. What you'll walk away with: a working knowledge of CC1 through CC9, a clear model for splitting control ownership across service organization, subservice organization, and user entity, and a set of matrices you can adapt to map your own environment before an auditor — or a customer's risk team — asks you to.
The Common Criteria Are Not Optional
One clarification before we go further, because I still hear it get muddled in board meetings: SOC 2 is an attestation — an examination performed by a licensed CPA firm that results in a report and an opinion — not a certification. Nobody "passes" SOC 2 the way a factory earns an ISO certificate; an auditor examines your controls and issues an opinion on whether they're suitably designed and, for a Type II report, operating effectively. That distinction matters here because shared responsibility isn't something a certification body checks off — it's something your own auditor tests by examining how well you understand and monitor it, which is exactly what this article walks through.
Every SOC 2 report, regardless of which optional Trust Services Criteria a service organization chooses to include, contains the Security category — better known in practitioner shorthand as the Common Criteria, or the CC-series. This baseline is defined by the AICPA under SSAE 18. You can add Availability, Processing Integrity, Confidentiality, or Privacy on top depending on what your customers care about and what commitments you've made, but Security is never optional. It is the floor every other criterion is built on.
The Common Criteria are organized into nine families, CC1 through CC9, and they map directly to the 17 principles of the COSO internal control framework — the same framework that underpins financial-reporting controls in the U.S., adapted here for information security and operations. That lineage matters practically: it's why SOC 2 auditors, most of whom come from a financial-audit background, structure their testing around control environment, risk assessment, and monitoring before they ever get to a firewall rule or an encryption key. The CC-series is COSO's skeleton with a security-specific nervous system layered on top.
Here is the full family, at a glance:
Table 1: The Nine Common Criteria (CC1–CC9) — Overview
CC Family | Name | Core Question It Answers | Typical Control Owner |
|---|---|---|---|
CC1 | Control Environment | Does leadership set the tone and structure for security? | Service organization (executive/board) |
CC2 | Communication & Information | Do people get the information they need to do their security jobs? | Service organization |
CC3 | Risk Assessment | Does the organization identify and analyze risks to its objectives? | Service organization (with subservice input) |
CC4 | Monitoring Activities | Does the organization check that controls are actually working? | Service organization |
CC5 | Control Activities | Are policies translated into enforced, repeatable actions? | Service organization |
CC6 | Logical & Physical Access Controls | Who can reach systems and data, and how is that restricted? | Shared: service org, subservice org, user entity |
CC7 | System Operations | Are systems monitored, and are incidents detected and handled? | Shared: service org, subservice org |
CC8 | Change Management | Are changes to systems controlled and tested before release? | Shared: service org, subservice org |
CC9 | Risk Mitigation | Are vendor and business-disruption risks actively managed? | Service organization (evaluates subservice orgs) |
Notice the "Typical Control Owner" column: CC1 through CC5 are overwhelmingly owned by the service organization itself — they're governance, culture, and process controls that don't get outsourced to a cloud provider. CC6 through CC9, by contrast, are exactly where shared responsibility gets complicated, because they touch infrastructure, operations, and change processes that may sit partly or entirely with a vendor. We'll come back to that split in detail once we've walked through each family.
Why the CC-Series Exists: The COSO Backbone
If you've ever wondered why a SOC 2 report spends pages discussing "the tone at the top" before it says a word about firewalls, the answer is COSO. The AICPA didn't invent the Common Criteria from scratch — it adapted COSO's five components (control environment, risk assessment, control activities, information and communication, and monitoring activities) and mapped its 17 principles onto CC1 through CC5, then added CC6 through CC9 as security-specific extensions the original COSO framework didn't cover.
Table 2: COSO Components and Principles Mapped to Common Criteria
COSO Component | # of Principles | Maps to CC Family | Security-Specific Extension |
|---|---|---|---|
Control Environment | 5 principles | CC1 | — |
Risk Assessment | 4 principles | CC3 | — |
Control Activities | 3 principles | CC5 | CC6 (access), CC7 (operations), CC8 (change) |
Information & Communication | 3 principles | CC2 | — |
Monitoring Activities | 2 principles | CC4 | CC9 (risk mitigation, vendor risk) |
The practical takeaway: CC1–CC5 are the "COSO-native" criteria — every SOC audit shares this backbone, including SOC 1 examinations. CC6–CC9 are the criteria the AICPA layered on specifically because financial-controls COSO didn't have anything to say about access control, system uptime, patching, or vendor infrastructure risk. That's also why CC6–CC9 are where subservice organizations show up most heavily in a system description — they're the operational, infrastructure-facing criteria, and infrastructure is exactly what gets outsourced to cloud providers, payment processors, colocation facilities, and managed service providers.
"New clients always want to jump straight to CC6 and start talking about firewalls. I make them sit through CC1 first, every time. If your control environment is weak — if nobody owns security, if the org chart doesn't reflect real accountability — every control downstream is standing on sand." — Elena Torres, Lead SOC 2 Auditor, Fairbank & Cole CPAs
CC1: Control Environment
CC1 asks whether the organization has built the governance foundation security depends on: a board or leadership team that oversees risk, defined lines of authority and responsibility, a commitment to competence in hiring and training, and accountability mechanisms that actually bite when someone ignores policy. It's the least technical of the nine families and the one auditors weight most heavily when deciding how much they trust everything that follows.
CC1 is squarely the service organization's job. You cannot delegate "does our leadership take security seriously" to a cloud provider. Even in a heavily outsourced infrastructure stack, the service organization must demonstrate its own board-level oversight, its own code of conduct, its own HR screening process, and its own security organizational structure.
Table 3: CC1 Control Environment — Example Controls
Control Area | Example Control | Evidence an Auditor Requests |
|---|---|---|
Board oversight | Quarterly security update presented to the board or audit committee | Board meeting minutes, security scorecard deck |
Organizational structure | Documented org chart showing security reporting lines | Current org chart, job descriptions for security roles |
Integrity & ethics | Code of conduct signed annually by all employees | Signed acknowledgment records, HRIS export |
Competence | Background checks and role-based security training before system access | Background check vendor logs, onboarding checklist |
Accountability | Documented consequences for policy violations, applied consistently | HR disciplinary case log (redacted) |
CC2: Communication & Information
CC2 is about whether the right information reaches the right people at the right time — internally, and with external parties like customers, regulators, and vendors. That includes how security policies are distributed and acknowledged, how incidents get escalated, and how the organization communicates its commitments (like its system description) to the user entities relying on it.
Like CC1, this is a service-organization-owned family. A cloud provider isn't responsible for whether your internal Slack channel actually gets security alerts routed to the right on-call engineer — but if you rely on a subservice organization, CC2 does require you to have a defined channel for their security communications to reach you (status pages, security bulletins, breach notifications), which is where the boundary starts to blur.
Table 4: CC2 Communication & Information — Example Controls
Control Area | Example Control | Evidence an Auditor Requests |
|---|---|---|
Internal policy distribution | Security policies published in a central, version-controlled repository | Policy portal access logs, version history |
Employee acknowledgment | Annual re-acknowledgment of the information security policy | Signed acknowledgment tracking report |
External communication | Published system description and security commitments available to customers | Customer-facing trust page, contract language |
Incident communication | Defined internal escalation path with named roles and SLAs | Incident response runbook, escalation matrix |
Subservice organization updates | Subscription to subservice org status/security bulletins | Status page subscription confirmation, bulletin log |
CC3: Risk Assessment
CC3 requires the organization to identify risks to its objectives — including fraud risk — analyze the likelihood and impact of those risks, and consider how changes in the business or environment (a new product line, a new subservice organization, a new region of operation) might introduce new risk. This is where a formal risk assessment process lives, typically performed at least annually and refreshed when something material changes.
CC3 is primarily service-organization-owned, but it has a critical dependency on subservice organizations: you cannot assess your own risk accurately if you don't understand what risks you've inherited by outsourcing infrastructure, payments, or identity to a third party. A mature CC3 process explicitly includes a review of subservice organization risk as an input — which is also where CC9 (risk mitigation) picks up the thread later.
Table 5: CC3 Risk Assessment — Example Controls
Control Area | Example Control | Evidence an Auditor Requests |
|---|---|---|
Annual risk assessment | Formal risk register reviewed and updated at least annually | Risk register, sign-off from risk owner |
Fraud risk consideration | Explicit fraud-risk scenarios included in the risk assessment | Fraud risk section of risk assessment document |
Change-driven reassessment | Risk reassessment triggered by major changes (new product, new region, new vendor) | Change log cross-referenced to risk register updates |
Subservice organization risk input | Subservice organization SOC reports reviewed as a risk input | Bridge letter or SOC report review log |
Risk treatment planning | Documented risk treatment decisions (accept, mitigate, transfer, avoid) | Risk treatment plan with owners and due dates |
CC4: Monitoring Activities
CC4 asks a deceptively simple question: how do you know your controls are actually working, on an ongoing basis, rather than just on paper? That covers both ongoing monitoring (dashboards, automated alerts, continuous control checks) and periodic, separate evaluations (internal audits, control self-assessments, readiness assessments ahead of the real thing). CC4 also requires that deficiencies get communicated to the people who can fix them, and tracked to resolution.
CC4 sits with the service organization for its own environment, but it has a second job in a layered stack: monitoring the subservice organization's controls too, typically through annual review of the subservice org's own SOC report, security questionnaire, or independent attestation. A service organization that never checks whether Meridian Cloud's own SOC 2 is still clean is failing its own CC4 obligations, not Meridian's.
Table 6: CC4 Monitoring Activities — Example Controls
Control Area | Example Control | Evidence an Auditor Requests |
|---|---|---|
Continuous monitoring | Security dashboards with automated alerting on control failures | Dashboard configuration, alert history |
Internal audit / self-assessment | Periodic internal control testing separate from day-to-day operations | Internal audit report, test scripts and results |
Deficiency tracking | Findings logged, assigned an owner, and tracked to closure | Findings/exceptions tracker (e.g., Jira/GRC tool export) |
Subservice organization monitoring | Annual review of subservice organization SOC reports | SOC report review checklist, sign-off |
Vulnerability monitoring | Recurring vulnerability scanning with tracked remediation SLAs | Scan reports, remediation tracking log |
CC5: Control Activities
CC5 is the family that turns policy into practice: it requires the organization to select and develop controls that actually reduce risk to an acceptable level, deploy those controls through policies and procedures, and — critically — assign clear accountability for who executes each control and when. Where CC1 asks "does leadership care," CC5 asks "did that caring turn into something operational."
CC5 also plays a coordinating role in the CC-series: it's the family that requires policies to exist for the more technical criteria that follow (CC6 through CC9). An organization can't have a defensible access-control program (CC6) without a CC5-level policy stating what access-control principles it follows, like least privilege.
Table 7: CC5 Control Activities — Example Controls
Control Area | Example Control | Evidence an Auditor Requests |
|---|---|---|
Policy-to-control translation | Written policies exist for each control domain (access, change, incident, vendor) | Policy library index with owners and review dates |
Technology-based controls | Automated policy enforcement (e.g., mandatory MFA, config baselines) | Configuration management tool output |
Segregation of duties | No single individual can both request and approve a sensitive change | Access matrix showing role separation |
Accountability assignment | Named control owners for each policy area, reviewed annually | RACI or control-ownership register |
Control activity documentation | Standard operating procedures for recurring control execution | SOPs, runbooks, checklists with revision history |
CC6: Logical and Physical Access Controls
CC6 is the largest and most technically dense of the nine families, and it's where most people's mental image of "SOC 2 security controls" actually lives: identity and access control, authentication, encryption of data at rest and in transit, physical security of facilities, and the processes for provisioning and de-provisioning access as people join, move within, and leave the organization.
CC6 is also the first family where shared responsibility becomes unavoidable rather than optional. Physical access to the data center, for instance, is almost never the service organization's job once it's running on a major cloud provider — that's the subservice organization's controls, referenced but not tested directly in the service organization's own report (more on how, below). Logical access to the application layer, by contrast, stays with the service organization no matter where the infrastructure lives.
Table 8: CC6 Logical & Physical Access — Example Controls
Control Area | Example Control | Typical Owner in a Cloud Stack |
|---|---|---|
User provisioning/de-provisioning | Access granted and revoked through a documented request/approval workflow | Service organization |
Multi-factor authentication (MFA) | MFA required for all production and administrative access | Service organization (enforced), subservice org (platform support) |
Encryption at rest | Customer data encrypted at rest using managed keys | Shared — subservice org provides capability, service org configures/enables it |
Encryption in transit | TLS enforced on all external and internal service-to-service connections | Service organization |
Physical data center security | Badge access, CCTV, and visitor logs at the hosting facility | Subservice organization |
Privileged access review | Quarterly review of administrative and privileged accounts | Service organization |
"The CC6 conversation that trips people up isn't encryption — everyone gets encryption right. It's the de-provisioning timeline. I've flagged more Type II exceptions for 'terminated employee retained access for 11 days' than for any missing technical control." — Marcus Webb, CISO, Meridian Cloud
CC7: System Operations
CC7 covers how the organization detects, responds to, and recovers from operational security events: vulnerability management, intrusion detection via a SIEM-style platform, incident response, and capacity management to prevent availability failures from becoming security incidents in their own right. It's the family that answers "if something goes wrong at 2 a.m., does anyone notice, and does anyone know what to do."
In a cloud-hosted environment, CC7 splits cleanly along a familiar line: the subservice organization operates and monitors the infrastructure layer (network-level intrusion detection, hardware failure response, hypervisor patching), while the service organization operates and monitors the application layer (application logs, business-logic anomalies, its own incident response process). Neither party's monitoring substitutes for the other's — a clean subservice organization SOC report says nothing about whether the service organization is watching its own application logs.
Table 9: CC7 System Operations — Example Controls
Control Area | Example Control | Typical Owner in a Cloud Stack |
|---|---|---|
Vulnerability management | Recurring internal and external vulnerability scans with SLA-based remediation | Service organization (app layer), subservice org (infra layer) |
Intrusion detection | Network-level anomaly and intrusion detection | Subservice organization |
Application/security logging | Centralized logging of application access and security events | Service organization |
Incident response | Documented, tested incident response plan with defined roles | Service organization |
Capacity management | Monitoring and alerting on resource utilization thresholds | Shared — subservice org exposes metrics, service org sets thresholds |
CC8: Change Management
CC8 requires that changes to infrastructure, software, and configurations — including emergency changes — go through a controlled process: authorization before deployment, testing prior to release, and a documented rollback path if something breaks. This is the family most closely tied to software delivery practice, and it's usually where DevOps and compliance either collaborate well or collide.
Change management is one of the cleanest shared-responsibility splits in the whole CC-series. The subservice organization manages change to the infrastructure it operates — patching the hypervisor, updating the managed database engine, rotating platform certificates — under its own change process, visible to the service organization only through its SOC report or release notes. The service organization manages change to everything it builds and deploys on top: application code, configuration, and infrastructure-as-code definitions within its own account boundary.
Table 10: CC8 Change Management — Example Controls
Control Area | Example Control | Typical Owner in a Cloud Stack |
|---|---|---|
Change authorization | Peer code review and approval required before merge | Service organization |
Pre-release testing | Automated test suite and staging environment validation | Service organization |
Emergency change process | Documented expedited path for urgent fixes, with retroactive review | Service organization |
Infrastructure patching | Underlying hypervisor, OS, and managed-service patching | Subservice organization |
Rollback capability | Documented and tested rollback procedure for failed deployments | Service organization |
CC9: Risk Mitigation
CC9 closes the loop on CC3: having identified risks, the organization must actively mitigate them, and — specific to this family — it must manage risk arising from its business relationships, including vendors and subservice organizations. CC9 is the family that most directly governs how a service organization is expected to evaluate, monitor, and hold accountable the third parties it depends on, and it's also where business continuity and disaster recovery planning typically live.
CC9 is a service-organization-owned family with a distinctive twist: its subject matter is largely about the subservice organization, even though the subservice organization doesn't own the control itself. A service organization can't outsource its CC9 obligation to "trust Meridian Cloud is fine" — it has to actively perform vendor risk management: reviewing subservice org SOC reports, tracking their audit period coverage, and maintaining its own business continuity and disaster recovery plans that account for a subservice organization outage.
Table 11: CC9 Risk Mitigation — Example Controls
Control Area | Example Control | Evidence an Auditor Requests |
|---|---|---|
Vendor risk assessment | New vendors screened for security posture before onboarding | Vendor security questionnaire, approval record |
Subservice organization oversight | Annual collection and review of subservice org SOC reports | SOC report tracker, review notes |
Business continuity planning | Documented BCP addressing subservice organization outage scenarios | BCP document, tabletop exercise records |
Disaster recovery testing | Recovery time/point objectives tested at least annually | DR test report, RTO/RPO results |
Insurance/contractual risk transfer | Cyber liability insurance and vendor contract indemnification clauses | Insurance certificate, contract excerpts |
The Shared Responsibility Model, Defined
With the nine families on the table, we can name the pattern that ran through nearly every one of them: no service organization operates in isolation. Every SOC 2 report exists inside a three-party structure, and understanding that structure is the single most useful mental model for anyone trying to make sense of a modern, cloud-hosted audit scope.
The three parties:
The service organization — the entity being examined. This is Ledgerly in our opening story: it owns the CC1–CC5 governance controls outright, and shares CC6–CC9 with whatever it depends on underneath.
The subservice organization — a vendor the service organization itself relies on to deliver its service. Meridian Cloud is Ledgerly's subservice organization: it owns physical security, hypervisor patching, and network-layer controls that Ledgerly's own report references but doesn't test directly.
The user entity — the service organization's customer. Trellis Bank is Ledgerly's user entity: it's expected to operate certain controls on its own side (who at the bank can log into Ledgerly's admin console, how the bank rotates its own API keys) that Ledgerly's controls were never designed to cover.
Table 12: Three-Party Responsibility Matrix — Who Owns What, By Default
Responsibility Area | Service Organization | Subservice Organization | User Entity |
|---|---|---|---|
Governance & control environment (CC1) | Owns fully | N/A (has its own, separately) | N/A |
Application-layer access control | Owns fully | Not involved | Manages its own users within the app |
Infrastructure/physical security | Relies on subservice org's controls | Owns fully | Not involved |
Data encryption configuration | Configures and enforces | Provides underlying capability | May hold its own encryption keys, if offered |
Network perimeter & hypervisor patching | Relies on subservice org's controls | Owns fully | Not involved |
Incident response for the application | Owns fully | Owns its own infra-layer response | Must report suspected incidents to the service org |
User account provisioning within the product | Provides the mechanism | Not involved | Owns fully (CUEC) |
MFA enforcement on user entity's own accounts | Can require/enforce technically | Not involved | Owns the decision to enable/use it (CUEC) |
Business continuity for its own operations | Owns fully | Owns its own BCP | Owns its own BCP |
That last row matters more than it looks: business continuity isn't something that gets outsourced up or down the chain. Every party in the stack needs its own plan, because a subservice organization's outage is the service organization's incident, and a service organization's outage is the user entity's incident, and each layer's BCP only covers what it directly controls.
Carve-Out Method vs. Inclusive Method
When a service organization relies on a subservice organization, it has to decide — and disclose in its system description — how that subservice organization's controls are handled in the report. There are two recognized approaches, and the choice affects both the cost of the audit and how much assurance a user entity actually gets.
Under the carve-out method, the subservice organization's controls are excluded from the scope of the service organization's own examination. The system description identifies the subservice organization and the functions it performs, and lists the Common Criteria the service organization is relying on the subservice organization to help satisfy — but the auditor does not test those controls directly. Instead, the user entity is expected to obtain assurance separately, typically by reviewing the subservice organization's own SOC report. This is by far the most common approach for major cloud infrastructure providers (AWS, Azure, GCP, and similar), because those providers already produce their own SOC 2 reports at massive scale and re-testing their controls inside every customer's audit would be redundant and prohibitively expensive.
Under the inclusive method, the subservice organization's controls ARE included within the scope of the service organization's examination — the auditor tests them directly, often by coordinating a joint audit or relying on direct access to the subservice organization's environment and evidence. This is far rarer, and generally only happens when the subservice organization is smaller, more tightly integrated, doesn't have its own SOC report, or when a service organization's biggest customers specifically demand end-to-end tested assurance rather than a referenced report.
Table 13: Carve-Out Method vs. Inclusive Method
Dimension | Carve-Out Method | Inclusive Method |
|---|---|---|
Subservice org controls tested directly by auditor? | No — referenced only | Yes — tested within scope |
Typical use case | Large cloud/IaaS providers (AWS, Azure, GCP-scale) | Smaller, tightly coupled vendors without their own SOC report |
User entity's assurance burden | Must independently obtain and review the subservice org's own SOC report | Assurance already included in the service organization's report |
Audit cost/complexity for service org | Lower | Higher — requires subservice org cooperation and evidence access |
System description disclosure | Names subservice org, functions performed, and relevant CC areas relied upon | Includes subservice org's controls directly in the description of the system |
Common failure mode | Service org never actually collects/reviews the subservice org's report (a CC9 gap) | Subservice org resists granting audit access, delaying the engagement |
In practice, most cloud-hosted SaaS companies use carve-out for their core IaaS/PaaS provider (because AWS, Azure, and GCP simply won't grant individual customers audit access — their own SOC reports are how they scale trust to thousands of customers at once) and reserve inclusive treatment, if used at all, for smaller or more specialized subservice organizations further down the stack, like a niche payments processor or a background-check vendor.
"Carve-out isn't a shortcut — it's a handoff. The service organization is explicitly telling its customers, 'go read this other report too.' The number of prospects who never actually do that, and then act surprised when their own auditor asks for it, is the most avoidable gap in this entire field." — David Kim, Director of Compliance, Ledgerly
Complementary User Entity Controls (CUECs)
The third leg of the shared responsibility stool is the one most often forgotten, because it's the one that doesn't show up in a vendor's marketing material: complementary user entity controls, or CUECs. These are controls the service organization's system description explicitly states the customer is expected to operate for the overall control objectives to be met. A service organization's controls are frequently designed with an assumption baked in — "assuming the user entity restricts who can access the admin console" — and if the customer never operates that control, the overall objective can fail even though the service organization did everything right on its end.
CUECs typically cluster around a predictable set of areas: managing the user entity's own user accounts and permissions within the service, protecting the user entity's own credentials and API keys, promptly notifying the service organization of terminated employees who need access revoked, and reviewing the service organization's own SOC report and complementary controls list at least annually.
Table 14: Example CUECs Mapped to Common Criteria Areas
CUEC (User Entity's Responsibility) | Related CC Area | Why It's the User Entity's Job, Not the Service Org's |
|---|---|---|
Restrict which of the customer's own employees have admin access to the platform | CC6 | Service org can't know who should have access inside the customer's org |
Enable and enforce MFA on user accounts where the service org makes it optional | CC6 | Service org provides the capability; enforcement decision is the customer's |
Promptly de-provision terminated employees from the platform | CC6 | Only the customer knows its own termination events in real time |
Review the service organization's SOC 2 report and CUEC list annually | CC9 | Ongoing vendor oversight is the customer's own risk-management duty |
Configure data retention/deletion settings appropriate to the customer's own regulatory obligations | CC3, CC5 | Regulatory obligations vary per customer; the platform can't assume them |
Report suspected security incidents involving the customer's own users promptly | CC7 | Only the customer has visibility into anomalies on its own account activity |
CUECs are also where the SOC 2 Complementary Controls: Client Implementation Requirements article in this series goes much deeper — worth a read if you're the one on the user-entity side trying to figure out what your own team is on the hook for.
Cloud as the Worked Example: IaaS, PaaS, and SaaS Layers
Nothing makes shared responsibility concrete faster than mapping it onto a real cloud stack, because cloud service models — Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) — are themselves defined by exactly where the responsibility line sits. The lower the layer you're consuming, the more you own; the higher the layer, the more your provider owns.
Picture Ledgerly's actual stack. At the bottom sits Meridian Cloud, an IaaS provider supplying virtual machines, storage, and networking — Meridian owns the physical data center, the hypervisor, and the underlying network fabric. One layer up, Ledgerly uses Northbeam Payments, a PaaS-style managed database and payment-processing platform — Northbeam owns the database engine, its patching, and its backup mechanics, while Ledgerly owns what it puts into that database and how it queries it. At the top, Ledgerly itself operates as a SaaS provider to Trellis Bank — Ledgerly owns the application, and Trellis Bank, as the user entity, owns how its own employees use it.
flowchart TB
UE["User Entity\n(Trellis Bank)\nOwns: CUECs — its own user\naccess, MFA enforcement,\nincident reporting"]
SO["Service Organization\n(Ledgerly — SaaS)\nOwns: CC1–CC5 governance,\napplication access control,\napp-layer logging & change mgmt"]
SUB_PAAS["Subservice Organization\n(Northbeam — PaaS)\nOwns: database engine patching,\nmanaged backups, platform\nconfig hardening"]
SUB_IAAS["Subservice Organization\n(Meridian Cloud — IaaS)\nOwns: physical security,\nhypervisor patching,\nnetwork fabric"]
UE -->|relies on / reviews SOC 2 report of| SO
SO -->|carve-out: relies on / reviews SOC 2 report of| SUB_PAAS
SUB_PAAS -->|carve-out: relies on / reviews SOC 2 report of| SUB_IAAS
SO -.CUECs flow down.-> UE
SUB_PAAS -.Complementary Subservice\nOrg Controls flow up.-> SO
SUB_IAAS -.Complementary Subservice\nOrg Controls flow up.-> SUB_PAASTwo things about that diagram are easy to miss on a first read. First, the responsibility chain doesn't stop at one subservice organization — Ledgerly's subservice organization (Northbeam) has its own subservice organization (Meridian), and Ledgerly's own system description should acknowledge that nested relationship even though Ledgerly has no direct contract with Meridian. Second, the arrows run both directions: user entity CUECs flow down as expectations, while each subservice layer's own complementary controls flow back up as dependencies the layer above must account for.
Table 15: Shared Responsibility Matrix by Cloud Layer × Common Criteria Area
CC Area | IaaS Layer (e.g., Meridian Cloud) | PaaS Layer (e.g., Northbeam Payments) | SaaS Layer (e.g., Ledgerly) | User Entity (e.g., Trellis Bank) |
|---|---|---|---|---|
CC1 Control Environment | Owns its own | Owns its own | Owns its own | Owns its own |
CC2 Communication | Publishes status/security bulletins | Publishes status/security bulletins | Publishes system description to customers | Reviews vendor communications |
CC3 Risk Assessment | Owns its own | Owns its own; factors in IaaS risk | Owns its own; factors in PaaS/IaaS risk | Owns its own; factors in SaaS vendor risk |
CC4 Monitoring | Monitors its own infra | Monitors platform + reviews IaaS SOC report | Monitors app layer + reviews PaaS SOC report | Reviews SaaS vendor's SOC report annually |
CC5 Control Activities | Owns its own | Owns its own | Owns its own | Owns its own internal policies |
CC6 Access Controls | Physical + hypervisor access | Database/platform access | Application access, identity | Its own users' access (CUEC) |
CC7 System Operations | Network/infra monitoring, infra incident response | Platform monitoring, platform incident response | App logging, app incident response | Reports suspected incidents (CUEC) |
CC8 Change Management | Infra patching, hardware lifecycle | Platform/engine patching | Application code changes | N/A (not a system operator) |
CC9 Risk Mitigation | Manages its own vendor risk | Manages IaaS vendor risk | Manages PaaS/IaaS vendor risk | Manages SaaS vendor risk (its own CC9) |
Read that table by column, not just by row, and the pattern jumps out: CC1, CC3, CC5, and CC9 repeat at every single layer — governance, risk assessment, control activities, and vendor risk management are never things a layer "gets to skip" because a lower layer already does them. Everyone in the stack does their own version. CC6 through CC8, by contrast, genuinely change hands as you move up the stack — physical and hypervisor access at the bottom, database and platform access in the middle, application access and identity at the top.
Mapping Specific Controls to Common Criteria Areas
Auditors and control-matrix templates typically work from a control inventory that cross-references each individual control to one or more CC areas, since a single technical control often satisfies several criteria at once. Here's a representative slice of that kind of mapping, useful as a starting template if you're building your own control matrix.
Table 16: Control-to-CC-Area Mapping (Representative Sample)
Control | CC1 | CC2 | CC3 | CC4 | CC5 | CC6 | CC7 | CC8 | CC9 |
|---|---|---|---|---|---|---|---|---|---|
Board security oversight meeting | ✔ | ||||||||
Annual risk register review | ✔ | ✔ | |||||||
MFA enforced on production access | ✔ | ✔ | |||||||
Centralized log aggregation & alerting | ✔ | ✔ | |||||||
Peer-reviewed change approval workflow | ✔ | ✔ | |||||||
Quarterly access recertification | ✔ | ✔ | |||||||
Subservice organization SOC report review | ✔ | ✔ | ✔ | ✔ | |||||
Encryption at rest on all customer data stores | ✔ | ✔ | |||||||
Documented incident response plan, tested annually | ✔ | ✔ | ✔ | ||||||
Business continuity/DR plan, tested annually | ✔ | ✔ |
Notice how few controls map to exactly one criterion. A quarterly access recertification satisfies both CC4 (you're monitoring whether access is still appropriate) and CC6 (you're enforcing the access-control principle itself) — which is exactly why a well-built control matrix, not a flat checklist, is the right tool for tracking this. It's also why our SOC 2 Control Matrix / RACI Template exists as a starting point rather than something you build cell-by-cell from scratch.
A RACI Model for a Three-Layer Stack
Once you've mapped controls to CC areas, the next practical step is assigning a RACI (Responsible, Accountable, Consulted, Informed) role to each party at each layer. This is the artifact I hand to every client that has more than one subservice organization in its stack, because "shared responsibility" as a phrase is true but useless until it's broken into who actually does the work, who signs off, who gets asked, and who just needs to know.
Table 17: RACI Matrix — Common Criteria Across a Three-Layer Cloud Stack
CC Area | IaaS Provider | PaaS Provider | Service Organization (SaaS) | User Entity |
|---|---|---|---|---|
CC1 Control Environment | R/A (own environment) | R/A (own environment) | R/A (own environment) | I |
CC3 Risk Assessment | R/A | C (feeds into SaaS assessment) | R/A | I |
CC6 Access Control | R/A (infra layer) | R/A (platform layer) | R/A (app layer) + C (reviews CUECs) | R (own users) |
CC7 System Operations | R/A (infra) | R/A (platform) | R/A (app) | I (reports incidents) |
CC8 Change Management | R/A (infra patching) | R/A (platform patching) | R/A (app changes) | I |
CC9 Risk Mitigation | R/A (own vendors) | R/A (own vendors) + I (to SaaS) | R/A (evaluates PaaS/IaaS) | R/A (evaluates SaaS) |
Read literally: for CC9, the service organization is Accountable for evaluating its own subservice organizations, while simultaneously being the subject of the user entity's own CC9 evaluation one layer up. Nobody is exempt from vendor risk management just because they also have vendors of their own — the obligation recurses at every layer.
Case Study: The Carve-Out Gap That Almost Cost Ledgerly Its Contract
Back to Priya Nair. When Ledgerly's team dug into the six-week-old question — who patches the hypervisor — they found the real problem wasn't a missing control. Meridian Cloud patched its hypervisors on a documented, tested schedule, and its own SOC 2 Type II report proved it. The real problem was that Ledgerly's system description never named Meridian Cloud as a subservice organization under the carve-out method, never listed which CC areas Ledgerly was relying on Meridian to help satisfy, and — worst of all — Ledgerly's compliance lead had never actually requested or reviewed Meridian's own SOC 2 report. CC9's subservice-organization-oversight control existed on paper but had never been executed.
Ledgerly's remediation took five weeks: formally documenting the carve-out relationship in its system description, establishing an annual process to request and review Meridian's SOC report (closing the CC4 and CC9 gap), and producing a one-page control-mapping document — essentially a simplified version of Table 15 above — that Trellis Bank's risk team could hand to their own examiners. The result: zero exceptions in Ledgerly's next Type II report, a signed $2.3 million contract, and a control-mapping artifact Ledgerly now sends proactively to every enterprise prospect, cutting an average of eleven days off vendor security review cycles.
"The fastest way to lose a six-figure deal isn't a bad control. It's not being able to answer a specific question about a control you're relying on someone else for. Customers don't expect you to run the data center. They expect you to know exactly who does, and to prove you're checking on them." — Priya Nair, VP of Engineering, Ledgerly
Case Study: When Inclusive Method Made More Sense
Northbeam Payments, the PaaS-style provider in our worked example, made a different scoping decision than Meridian. As a smaller, specialized payments-processing platform without the scale to publish its own broadly distributed SOC 2 report, Northbeam agreed to bring several of its largest SaaS customers — including Ledgerly — into an inclusive-method arrangement: Ledgerly's auditor was granted direct evidence access to Northbeam's change-management and access-control logs for the specific systems Ledgerly's data touched, and tested them as part of Ledgerly's own Type II examination rather than relying on a separate report.
The tradeoff was real. Coordinating evidence requests across two organizations added roughly three weeks to Ledgerly's audit timeline and required Northbeam to grant auditor access it wasn't structured to provide by default. But it also meant Ledgerly's own SOC 2 report could make a stronger, directly tested claim about payment-processing controls — a claim that mattered specifically because Trellis Bank, as a regulated financial institution, weighted payment-processing integrity controls more heavily than general infrastructure controls in its vendor risk scoring. For Ledgerly, the extra three weeks and coordination overhead were worth it for the deals where payment control assurance was the deciding factor.
Case Study: The CUEC Failure Nobody Saw Coming
Not every shared-responsibility failure sits with the vendor. Sarah Okonkwo's team at Anchorpoint HR — a SaaS payroll and benefits platform — had a clean SOC 2 report, a well-documented carve-out relationship with its own cloud infrastructure provider, and a mature CC6 access-control program. What it didn't have was visibility into whether its customers were actually operating the CUECs listed in its system description.
One mid-sized customer never enabled the optional MFA setting Anchorpoint made available — a CUEC explicitly listed in Anchorpoint's report — and a former employee's credentials, never revoked after termination because the customer also skipped the "promptly de-provision terminated employees" CUEC, were used to access payroll records for eleven days before anyone noticed. Anchorpoint's own controls had performed exactly as designed and tested; the control objective still failed, because the customer-side half of a shared control simply never got operated.
The fallout wasn't an audit exception for Anchorpoint — its own report was accurate — but it was a hard lesson in why CUEC communication can't just live in a system description PDF nobody reads. Anchorpoint's response was to build a quarterly CUEC attestation process: every customer now confirms, in writing, which complementary controls it has actually implemented, with unconfirmed items flagged to the customer's own account team. Since rolling that out, unconfirmed-CUEC flags have identified and closed eighteen similar gaps across Anchorpoint's customer base before they became incidents.
"We used to think our job ended at 'we told them in the report.' It doesn't. If a control only works when both sides operate their half, you have to actively check the other half is happening — not just disclose that it should be." — Sarah Okonkwo, VP of Security, Anchorpoint HR
Common Pitfalls in Managing Shared Responsibility
Across the engagements I've run, the same handful of mistakes account for most of the shared-responsibility findings and near-misses. None of them are exotic — they're all versions of "someone assumed someone else had it."
Table 18: Common Shared-Responsibility Pitfalls and Fixes
Pitfall | Why It Happens | Fix |
|---|---|---|
Never actually reviewing the subservice organization's SOC report | CC9 control exists on paper (["we require vendors to provide SOC reports"]) but nobody executes it annually | Assign a named owner and calendar reminder for annual SOC report collection and sign-off |
System description doesn't name the subservice organization at all | Written early, never updated as infrastructure changed | Review and update the system description every audit cycle, not just at initial scoping |
Assuming carve-out means "not my problem" | Misreading carve-out as removing the obligation rather than shifting the testing method | Treat carve-out relationships as an active CC9 monitoring obligation, not a scope exclusion |
CUECs listed in the report but never communicated to customers directly | System description treated as the only communication channel | Build a proactive CUEC attestation or onboarding checklist for customers |
Nested subservice organizations left undocumented | Service org only tracks its direct vendor, not that vendor's own vendors | Ask direct subservice organizations to disclose their own subservice organizations |
Confusing Type I coverage with Type II operating effectiveness for a subservice org | Reviewing an older Type I report and assuming continuous assurance | Confirm the subservice org's report type and audit period currency each review cycle |
No process for a subservice organization's own audit gap (bridge letter) | Subservice org's report period ends months before the service org's own report date | Request a bridge letter covering the gap period |
How Auditors Actually Test Shared Responsibility
It's worth demystifying what an auditor is doing behind the scenes when they evaluate a layered environment, because it changes what evidence you should have ready before fieldwork starts. Auditors don't re-perform a subservice organization's controls under carve-out — they test that the service organization's own monitoring of the subservice organization is operating, which is a subtly different thing.
Table 19: Evidence Types Auditors Request, by Party
Party | What the Auditor Tests Directly | What the Auditor Tests Indirectly (Via Documentation Review) |
|---|---|---|
Service organization (own controls) | Access logs, change tickets, HR records, policy acknowledgments, incident tickets — direct sampling | N/A — this is the primary subject of the examination |
Subservice organization (carve-out) | Nothing directly | The service organization's process for requesting, reviewing, and acting on the subservice org's SOC report |
Subservice organization (inclusive) | Evidence provided directly by the subservice org, sampled like the service org's own controls | N/A — treated as in-scope |
User entity (CUECs) | Nothing directly — user entities aren't examined | The service organization's system description listing CUECs; sometimes a sample of CUEC attestations if the service org collects them |
That table explains why the six-week scramble in Priya's story happened in the first place: Ledgerly's auditor wasn't going to test Meridian Cloud's hypervisor patching directly — carve-out means they never would have. What the auditor would test, and what Ledgerly hadn't built yet, was proof that Ledgerly itself was monitoring Meridian. The fix wasn't "get Meridian audited harder." It was "start doing Ledgerly's own CC9 job."
Building Your Complementary Subservice Organization Controls (CSOC) Tracking Process
The mirror image of a CUEC is sometimes called a Complementary Subservice Organization Control (CSOC) — a control the service organization's own system description states it is relying on a subservice organization to perform. Formalizing a CSOC tracking process is the single highest-leverage fix for the pitfalls above, and it doesn't need to be complicated to be effective.
A workable CSOC process has four steps, repeated on an annual cycle (or whenever a new subservice organization is onboarded): first, identify every subservice organization the service actually depends on, including nested ones a layer down; second, for each one, document which CC areas the service organization is relying on it to help satisfy; third, collect and review that subservice organization's own attestation — its SOC report, ISO 27001 certificate, or equivalent — checking report type, audit period coverage, and any noted exceptions; and fourth, record the review with a named owner and date, feeding any gaps found back into the risk register under CC3 and CC9.
Table 20: CSOC Tracking Template — Minimum Fields
Field | Purpose |
|---|---|
Subservice organization name | Identifies the vendor |
Function performed | What the service depends on it for (hosting, payments, identity, etc.) |
CC areas relied upon | Cross-references to Table 15/16-style mapping |
Method (carve-out / inclusive) | Determines testing approach and disclosure |
Latest attestation type and period | Confirms currency and coverage of assurance obtained |
Exceptions noted | Any qualified findings in the subservice org's own report |
Review owner and date | Accountability for the annual CC9 obligation |
Nested subservice organizations disclosed | Tracks dependencies one layer further down |
This is precisely the artifact our SOC 2 Trust Services Criteria Mapping Template is built to support — most teams that build one from scratch reinvent roughly this same eight-field structure within a quarter anyway. If you're building this from a blank page, our SOC 2 Readiness Checklist walks through the same subservice-organization inventory step as part of a broader pre-audit gap review.
What Good Subservice Organization Disclosure Looks Like
The gap between a system description that protects you and one that leaves you exposed usually comes down to specificity. "We use cloud infrastructure providers" tells a customer's risk team nothing they can act on. A well-written subservice organization section names the vendor, states the method, and lists exactly which CC areas the disclosure covers — which is the difference between Ledgerly's original one-sentence mention and the control-mapping document that eventually closed the Trellis Bank deal.
Table 21: Weak vs. Strong Subservice Organization Disclosure
Element | Weak Disclosure | Strong Disclosure |
|---|---|---|
Vendor identification | "We use industry-leading cloud infrastructure" | "Production infrastructure is hosted with Meridian Cloud (IaaS)" |
Method stated | Not mentioned | "Under the carve-out method" |
CC areas covered | Not mentioned | "Relied upon for CC6 (physical/network access) and CC7 (infrastructure monitoring)" |
Monitoring commitment | Not mentioned | "Meridian's SOC 2 Type II report is reviewed annually by [named role]" |
Nested subservice organizations | Not mentioned | "Meridian's own subservice organizations are disclosed in its SOC 2 system description, reviewed as part of our annual process" |
The strong-disclosure column isn't extra credit — every row in it corresponds to something CC2, CC4, or CC9 already requires you to be doing. Writing it down clearly is what turns compliance activity into a document a customer's procurement team can actually use, which is exactly the gap the SOC 2 Report Structure: Understanding the Auditor's Report article addresses from the report-reading side.
One pattern worth naming explicitly: don't wait for your next audit cycle to fix weak disclosure. System descriptions are usually only revisited once a year, at audit time, which means a vague subservice organization section can sit unnoticed for months while sales teams are actively losing time to exactly the kind of question Priya Nair got blindsided by. Treat the subservice organization section of your system description as a living document, reviewed whenever a new vendor is onboarded — not a once-a-year audit artifact.
A 90-Day Plan to Map Your Shared Responsibility Model
If everything above feels like a lot to tackle at once, here's the sequence I actually walk clients through, compressed into three phases. It assumes you're starting close to zero — no formal subservice organization inventory, no CSOC tracker, and a system description that's several revisions out of date.
Days 1–30: Inventory and classify. List every vendor touching production infrastructure, data storage, identity, authentication, or payment processing — not just your primary cloud provider, but every managed service layered on top of it. For each one, determine whether it's a true subservice organization (does the CC1–CC9 control set depend on it) or simply a software tool that doesn't touch your control environment. Classify each subservice organization by method: carve-out, inclusive, or "unknown, needs a decision." This phase is almost entirely internal — engineering, procurement, and compliance comparing notes, not vendor outreach yet.
Days 31–60: Collect and review. For every subservice organization classified as carve-out, request their latest SOC report (or ISO 27001 certificate, or equivalent attestation) and review it against the CSOC template in Table 20: report type, audit period coverage, noted exceptions, and their own disclosed subservice organizations one layer down. For anything classified as inclusive, or anything that can't produce any attestation at all, this is where you start the harder conversation — either negotiating audit access or documenting the risk of proceeding without it. This phase also includes reviewing and rewriting your own system description's subservice organization section against the weak-vs-strong pattern in Table 21.
Days 61–90: Formalize and communicate. Stand up the recurring process: a named owner for annual subservice organization review, a calendar-triggered CSOC refresh, and — critically — a CUEC communication mechanism your user entities will actually see, whether that's a quarterly attestation request, an onboarding checklist, or a dedicated section of your customer-facing trust page. By day 90, you should be able to hand a one-page responsibility map to any prospect's risk team and answer "who patches the hypervisor" without a scramble.
Table 22: 90-Day Shared Responsibility Mapping Plan — Milestones
Phase | Days | Primary Output | Owner |
|---|---|---|---|
Inventory & classify | 1–30 | Full subservice organization list with carve-out/inclusive classification | Compliance lead + engineering |
Collect & review | 31–60 | CSOC tracker populated; system description rewritten | Compliance lead |
Formalize & communicate | 61–90 | Recurring review process; CUEC communication mechanism live | Compliance lead + customer success |
Teams that run this sequence almost always find the same thing Ledgerly found: the technical controls were fine all along. What was missing was the connective tissue — the inventory, the review cadence, and the plain-language artifact that turns "we rely on several subservice organizations" into a map a customer's risk team can actually verify in the thirty minutes they've budgeted for it.
Shared Responsibility as a Business Advantage, Not Just an Audit Requirement
It's tempting to treat shared-responsibility mapping as pure audit overhead — something you do because CC9 requires it and move on. That undersells what a well-built responsibility map actually does for the business. Ledgerly's control-mapping artifact didn't just close an audit gap; it became a sales asset that shortened vendor security review cycles across their entire enterprise pipeline, because it answered the exact question every sophisticated buyer's risk team asks in the first thirty minutes of due diligence.
The organizations that get the most commercial value from their SOC 2 report are the ones that can explain their shared-responsibility model fluently, in one page, without making the prospect dig through a fifty-page system description. That's a genuine differentiator against competitors who can produce a report but can't answer "who patches the hypervisor" without a six-week scramble of their own. If you're also pursuing ISO 27001 alongside SOC 2 — a common combination for companies selling into both U.S. and international enterprise buyers — the ISO 27001, SOC 2 & NIST CSF Crosswalk: Control Mapping shows how the same underlying control work satisfies multiple frameworks' documentation requirements at once, so your CSOC tracking effort isn't duplicated per framework.
Getting this right also changes how audits themselves go. Auditors move faster, ask fewer follow-up questions, and issue cleaner opinions when a service organization walks into fieldwork with its subservice organization relationships and CUEC communications already documented — which is a direct line from the work in this article to the report quality covered in SOC 2 Report Structure: Understanding the Auditor's Report and to the ownership questions explored in SOC 2 Management Assertion: Taking Ownership of Your Controls.
Get Your Shared Responsibility Model Audit-Ready
If you're staring at your own stack right now trying to figure out where your subservice organizations start and your own controls end, you're doing exactly what Ledgerly, Northbeam, and Anchorpoint all had to do before their next clean report. PentesterWorld's compliance team builds shared-responsibility and control-mapping documentation for service organizations at every layer of the cloud stack — whether you're preparing for your first Type II report, untangling a nested subservice organization chain, or trying to turn your CC9 vendor oversight process from a checkbox into a sales asset. Reach out to start a readiness assessment that maps every Common Criteria control to its rightful owner before your auditor — or your next enterprise prospect — asks the question first. New to the terminology in this piece? Bookmark our SOC 2 Glossary for every term used above, in one place.