Dana Okafor found out how expensive a missing signature could be on a Tuesday afternoon in March, three weeks before her Type II observation period closed.
Dana was the CISO at Ironclad Freight Analytics, a 140-person logistics-optimization SaaS company that routed freight for mid-market shippers. Ironclad's biggest prospect, Meridian Retail Group, had a $3.1 million, three-year contract sitting in legal review — contingent on a clean SOC 2 Type II report. Meridian's vendor risk team had been explicit: no exceptions in access management, no exceptions in change management, or the deal moved to a competitor that already had its report in hand.
Ironclad's auditor, a mid-sized regional firm, sent the first draft of findings on a Thursday. Two items stood out. First: of the twelve production deployments sampled during the six-month observation window, four had been pushed by an engineer who also approved their own pull request — a segregation-of-duties failure. Second: Ironclad's quarterly access review "policy" existed as a paragraph in a Confluence page, but there was no procedure describing who ran the review, what evidence they captured, or how removals were tracked — and no evidence had actually been produced for two of the six months in scope.
Both findings traced back to the same root cause: Ironclad had reasonable policies but no operationalized control activities behind them. They knew what they wanted to happen. They had never nailed down how it happened, who made it happen, or what proof it happened. That gap — between intention and operating evidence — is exactly what CC5, the Control Activities criteria, exists to close. Dana's team spent five weeks rebuilding their control activity register, wiring branch-protection rules that made self-approval technically impossible, and standing up a documented quarterly access-review procedure with ticket-based evidence. The re-test came back clean. The Meridian contract closed six weeks late, but it closed.
This article walks through CC5 the way Dana's team eventually built it: methodically, principle by principle, with the paper trail an auditor actually wants to see.
Who This Is For / What You'll Walk Away With
This is written for security leads, compliance managers, and engineering managers who own — or are about to own — the Control Activities section of a SOC 2 audit and need more than a definition. You should already have a rough picture of your Trust Services Criteria scope and have completed, or be completing, your SOC 2 risk assessment process. By the end, you'll be able to translate identified risks into specific, testable control activities; distinguish preventive from detective controls and know when you need both; design segregation of duties that survives a small headcount; build technology general controls across access, change, and operations; and turn a policy document into an operating procedure with evidence an auditor can sample against.
What CC5 Actually Covers: COSO Component 2, Principles 10–12
CC5 is the Common Criteria series mapped to COSO Component 2: Control Activities. Where CC3 (risk assessment) identifies what could go wrong and CC1 (control environment) sets the tone that makes people care, CC5 is where the organization decides — concretely — what it is going to do about the risks it has identified, and makes sure that "doing" actually happens, repeatedly, in a way someone else can verify.
CC5 rests on three COSO principles, and the AICPA's points of focus for each are the closest thing SOC 2 gives you to a checklist:
Principle 10 — The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
Principle 11 — The entity also selects and develops general control activities over technology to support the achievement of objectives.
Principle 12 — The entity deploys control activities through policies that establish what is expected and procedures that put policies into action.
Notice the deliberate structure: Principle 10 is the what (which risks need a control and what kind), Principle 11 is a special case of the what (technology, because nearly every modern service organization runs its business on it), and Principle 12 is the how — the mechanism by which a control activity stops being an idea and becomes something that happens on a Tuesday whether or not the CISO is watching. Auditors test CC5 by asking, for a sample of controls, three questions in sequence: Is this control activity mapped to a real risk? Is it designed to actually mitigate that risk (not just gesture at it)? And is there evidence it operated, consistently, across the whole review period? Miss any one of those three and you get an exception.
"The biggest misconception I run into is that a control activity is the same thing as a policy. It isn't. A policy is a sentence. A control activity is a repeatable, evidenced action. I can write 'we review access quarterly' in fifteen seconds. Proving twelve people actually reviewed 340 accounts in April is a different exercise entirely." — Sam Whitlock, Audit Partner, Halloran & Vance CPAs
Principle 10: Selecting and Developing Control Activities That Mitigate Risk
Principle 10 is where risk assessment output turns into action. If your SOC 2 risk assessment process produced a risk register with entries like "unauthorized production access," "undetected unauthorized code changes," or "service disruption from unmanaged capacity," Principle 10 asks: for each of those, what specific activity reduces the likelihood or impact to something the organization can live with?
The AICPA's points of focus for Principle 10 push you toward a few concrete habits. Controls should be a mix of types — you shouldn't rely entirely on detective controls (finding problems after the fact) if a preventive control (stopping the problem before it happens) is feasible and cost-effective. Controls should operate at multiple levels — entity-wide policy, process-level procedure, and transaction-level technical enforcement all working together rather than any one layer carrying the whole weight. And controls should account for segregation of duties as a first-class design consideration, not an afterthought bolted on when an auditor flags it.
In practice, this means every meaningful risk in your register should have at least one control activity attached to it, and that control activity should specify: the risk it addresses, the control type (preventive or detective), who owns it, how often it operates, and what evidence proves it operated. Here's what that mapping looks like in the register Dana's team eventually built:
Table 1: Risk-to-Control Activity Mapping (Illustrative)
Risk (from risk register) | Control Activity | Control Type | Owner | Frequency | Evidence Produced |
|---|---|---|---|---|---|
Unauthorized access to production database | Role-based access provisioning tied to HR system-of-record; quarterly access recertification | Preventive + Detective | IT Security Manager | Continuous (provisioning); Quarterly (review) | Provisioning tickets; signed recertification reports |
Self-approved production code deployment | Branch protection requiring 1+ independent code reviewer; CI blocks merge without approval | Preventive | Engineering Manager | Continuous (automated) | Git commit/PR logs with reviewer identity |
Undetected unauthorized configuration change | Infrastructure-as-code with mandatory pull request workflow; drift detection scan | Preventive + Detective | Platform Lead | Continuous (IaC); Weekly (drift scan) | PR history; drift scan reports |
Terminated employee retains system access | Automated deprovisioning triggered by HRIS offboarding event | Preventive | IT Operations | Continuous (event-driven) | Deprovisioning ticket with timestamp vs. termination date |
Service capacity exhaustion during peak load | Automated autoscaling with capacity alerting at 70%/85%/95% thresholds | Preventive + Detective | SRE Lead | Continuous | Alert logs; capacity dashboards; incident tickets if triggered |
Vendor-introduced vulnerability in third-party library | Automated dependency scanning in CI pipeline with blocking severity threshold | Detective + Preventive | Engineering Manager | Continuous (per build) | Scan reports; remediation tickets |
Backup failure preventing recovery | Automated backup job with daily success/failure verification | Detective | IT Operations | Daily | Backup job logs; monthly restore test evidence |
The pattern to internalize: a risk without a mapped control is a gap an auditor will find on their own, and a control without a stated risk is activity theater — busywork that looks compliant but that nobody can defend the purpose of when questioned. Every row in your register should survive the question "why does this control exist," answered in one sentence that names the risk.
Principle 11: General Control Activities Over Technology
Principle 11 exists because COSO — a framework originally built for financial reporting controls — recognized that modern organizations run almost everything through technology, and that technology has its own distinct risk surface: who can access systems, how changes get introduced, and whether operations run reliably. The AICPA groups these into what practitioners commonly call IT General Controls (ITGCs), organized around three domains that show up again and again in SOC 2 testing: access, change management, and operations.
The points of focus for Principle 11 ask the entity to determine the dependence between business processes and technology, establish technology infrastructure control activities, establish controls over technology's security management process, and establish controls over the acquisition, development, and maintenance of technology. In plain terms: know which systems matter, control who can touch them, control how they change, and control how they're operated day to day.
This is the principle most closely tied to CC6 (logical and physical access) and CC8 (change management) — CC5 sets the expectation that technology controls exist and are deliberately selected; CC6 and CC8 go deep on the specific mechanics of access and change. Think of Principle 11 as the bridge: it's the reason a SOC 2 report can't just say "we have good policies" — it has to demonstrate that the policies translate into enforced technical controls. We'll build out the full technology general controls picture in a dedicated section below, but the principle itself is really asking one question of your organization: for every system that matters to the services you deliver, can you show a deliberate, designed control — not a default, not luck — governing who gets in, what changes are allowed, and how operations are kept healthy?
"I tell engineering leaders: if a technology control only exists because 'nobody's gotten around to breaking it yet,' it's not a control. A control is something you designed on purpose and can point to." — Priya Chandrasekaran, VP Engineering, Fenwick Health Analytics
Principle 12: Deploying Control Activities Through Policies and Procedures
Principle 12 is where most immature programs quietly fail, because it's the principle that separates a document from an operating control. COSO's language is precise: the entity deploys control activities through policies that establish what is expected, and procedures that put those policies into action. A policy is a statement of intent and expectation — often written for a broad audience, reviewed and approved by leadership, relatively stable over time. A procedure is the operational instruction — specific, often role-specific, detailed enough that a new hire could follow it without improvising, and updated whenever the underlying process changes.
The failure mode Dana's team hit is the most common one in SOC 2 audits: a policy exists ("access is reviewed quarterly") but no procedure defines how — who pulls the access list, from which system, using what criteria to flag inappropriate access, how removals get requested and confirmed, and where the evidence of all of that gets stored. Auditors don't test policies. They test whether procedures were followed and whether that following left a trail. A beautifully written policy with no matching procedure produces zero usable evidence.
The points of focus for Principle 12 push the entity to establish policies and procedures to support deployment of management's directives, establish responsibility and accountability for executing them, perform them in a timely manner, take corrective action when needed, perform using competent personnel, and reassess policies and procedures periodically. That last point matters more than people expect: a procedure written two years ago for a team of 20 rarely still fits a team of 90, and an unreviewed procedure is one of the more common exceptions auditors cite even when the control nominally "worked."
Table 2: Policy-to-Procedure Mapping (Illustrative Examples)
Policy Statement (the "what") | Corresponding Procedure (the "how") | Responsible Role | Evidence It Generates |
|---|---|---|---|
"Access to production systems is granted based on least privilege and reviewed quarterly." | Step-by-step access recertification runbook: export access list from IAM tool by system owner, flag anomalies against role matrix, obtain sign-off, submit removal tickets within 5 business days | IT Security Manager | Signed recertification spreadsheet; removal ticket IDs and closure dates |
"All production code changes require independent review before deployment." | Git workflow procedure: branch protection rules, required reviewer count, CI gate configuration, emergency-change exception process with post-hoc approval | Engineering Manager | PR approval logs; emergency change tickets with retroactive sign-off |
"New employees receive security awareness training before system access is granted." | Onboarding checklist: HR triggers training assignment in LMS on offer acceptance, IT holds access provisioning pending training completion confirmation | HR Operations Lead | LMS completion certificates timestamped before provisioning tickets |
"Vendors handling customer data are assessed for security risk before onboarding." | Vendor risk procedure: security questionnaire sent, SOC 2 report or equivalent requested, risk tier assigned, contract clauses attached based on tier | Procurement / Vendor Risk Owner | Completed questionnaires; risk tier assignment log; executed contracts with security addenda |
"Systems are patched according to defined severity timelines." | Patch management runbook: vulnerability scan cadence, severity-to-SLA mapping, ticket creation and tracking, exception approval for missed SLAs | IT Operations | Scan reports; patch ticket closure timestamps against SLA; documented exceptions |
"Backups are performed and tested for recoverability." | Backup and restore procedure: daily automated job, weekly log review, quarterly restore drill with documented outcome | IT Operations | Backup job logs; quarterly restore test report |
Notice that every procedure in the right-hand column ends in a specific, dateable artifact. That's the design discipline Principle 12 is really asking for: write the procedure backward from the evidence you'll need to produce, not forward from the policy's good intentions.
CC5 Principles 10–12 at a Glance: Controls and Evidence
Auditors working from the AICPA's 2017 Trust Services Criteria will map each control activity they test back to a specific principle and its points of focus. It helps to keep a single reference table that shows, principle by principle, the kind of control activity expected and the evidence category an auditor will ask for. This is the table Dana's team pinned above their control-register spreadsheet for the remainder of the audit cycle.
Table 3: CC5 Principles 10–12 — Controls and Evidence Summary
Principle | Core Question | Typical Control Activities | Evidence Auditors Sample |
|---|---|---|---|
Principle 10 — Select and develop control activities | Does every identified risk have a proportionate, deliberately chosen control? | Risk-to-control mapping; mix of preventive/detective controls; segregation of duties design; multi-level controls (entity, process, transaction) | Risk register with control cross-references; control activity register; SoD matrix; control design rationale documentation |
Principle 11 — General control activities over technology | Are access, change, and operations of technology deliberately controlled? | Access provisioning/deprovisioning workflows; change approval and CI/CD gates; capacity and availability monitoring; vulnerability and patch management | Access logs and recertification records; change tickets and deployment logs; monitoring/alerting configuration and incident tickets; scan and patch reports |
Principle 12 — Deploy through policies and procedures | Do documented policies translate into followed, evidenced procedures? | Written and approved policies; role-specific operating procedures/runbooks; defined accountability and escalation paths; periodic policy/procedure review cycle | Approved policy documents with version history; procedure runbooks; ticketing system records showing procedure execution; policy review/approval log |
Preventive vs. Detective Controls: Why You Need Both
One of the fastest ways to fail a CC5 test is to build a program that's entirely detective — good at catching problems after they happen, bad at stopping them in the first place. The reverse failure is less common but real too: an organization so confident in its preventive controls that it never verifies they're actually working, and only discovers a gap when a detective control (or an incident) finally catches it.
Preventive controls stop an undesired event before it occurs. They tend to be built into systems and workflows rather than performed as a periodic check: a firewall rule that blocks a port, a branch protection rule that makes self-approval technically impossible, an IAM policy that never grants standing production access in the first place. Detective controls identify that an undesired event has already occurred, or that a preventive control has failed, so it can be corrected. Log review, quarterly access recertification, vulnerability scanning, and reconciliation checks are all detective by nature — they look backward at what happened.
Mature CC5 programs pair the two deliberately. A quarterly access review (detective) exists precisely because provisioning workflows (preventive) sometimes drift — someone gets a temporary elevated role for an incident and it's never revoked, or a role definition in the identity provider quietly becomes too broad over time. The detective control is the safety net under the preventive control's tightrope.
Table 4: Preventive vs. Detective Controls — Side-by-Side Comparison
Dimension | Preventive Controls | Detective Controls |
|---|---|---|
Timing | Operates before the undesired event | Operates after the undesired event |
Primary goal | Stop the risk from materializing | Identify that the risk materialized (or a preventive control failed) |
Typical examples | MFA enforcement, least privilege provisioning, branch protection, input validation, firewall rules | Log review, access recertification, vulnerability scanning, reconciliation, anomaly alerting |
Cost profile | Often higher upfront design/engineering cost, lower ongoing labor | Often lower upfront cost, higher ongoing labor (someone has to review) |
Failure mode if used alone | Silent drift — control degrades and nobody notices until an incident | Reactive posture — damage may already be done by the time it's caught |
Auditor testing approach | Inspect configuration/system settings; attempt to reproduce control logic | Sample periodic review evidence; verify findings were remediated |
Best paired with | A detective control that verifies it's still functioning | A preventive control that reduces how often the detective control has to catch something |
"Preventive controls are what keep you out of the newspaper. Detective controls are what keep your preventive controls honest. I've never seen a CC5 section pass cleanly with only one or the other." — Théo Bergstrom, Director of Internal Audit, NorthPeak Financial
Segregation of Duties: The Control Activity Auditors Love to Test
Segregation of duties (SoD) is the principle that no single individual should be able to both execute and approve (or execute and conceal) a sensitive action end-to-end. It's a favorite audit-sample target because SoD failures are easy to test objectively — pull the deployment log, check whether the author and approver fields ever match — and because SoD gaps are exactly the kind of finding that correlates with real fraud and error risk, which is what COSO Component 2 was originally built to address in financial reporting.
Ironclad's finding — an engineer approving their own pull request — is close to the single most common SoD exception in SOC 2 Type II reports for software companies. It's rarely malicious; it's almost always operational convenience that nobody flagged until the sample review. The fix is usually structural rather than punitive: make self-approval technically impossible (branch protection with required reviewer count greater than zero, configured so the PR author cannot satisfy their own requirement) rather than relying on a policy that says "please don't."
Segregation of duties gets genuinely hard at small headcount, and auditors know this — a five-person engineering team can't always have a fully independent reviewer for every change. The accepted mitigation is compensating controls: if true separation isn't feasible, add a detective control (post-deployment review by someone outside the change, logged and dated) that catches what prevention couldn't stop.
Table 5: Segregation of Duties Matrix — Illustrative Functions
Function | Incompatible Pairing (should NOT be same person) | Compensating Control if Team Size Prevents Full Separation |
|---|---|---|
Code development vs. code deployment approval | Developer who wrote the code approving their own PR for production | Automated branch protection blocking self-approval; if unavoidable, mandatory post-deploy peer review logged within 24 hours |
User access provisioning vs. access approval | IT admin who provisions access also being the sole approver | Second approver required in IAM workflow (manager or security team) |
Financial transaction initiation vs. approval | Same employee initiating and approving vendor payments | Dual-approval threshold in finance system above a defined dollar amount |
Security control administration vs. security control monitoring | Security engineer who configures firewall rules also being sole reviewer of firewall logs | Independent internal audit or GRC function periodically samples firewall change logs |
System backup execution vs. backup verification | Same admin performs backup job and signs off it succeeded | Automated success/failure alerting routed to a second team member; quarterly restore test performed by someone outside daily backup ops |
Vendor selection vs. vendor risk approval | Procurement owner both selecting vendor and approving its security risk acceptance | Vendor risk approval routed to a security/compliance approver independent of procurement |
Mapping Risk to Control Activity: The Ironclad Worked Example
Going back to Dana Okafor's remediation gives a concrete look at how Principle 10's abstract "select and develop control activities" plays out under deadline pressure. After the draft findings landed, her team ran a focused two-week sprint structured around exactly the risk-to-control discipline described above.
For the deployment self-approval finding, the risk was "unauthorized or unreviewed code reaches production." The chosen control activity was preventive: GitHub branch protection on the main branch requiring at least one approving review from someone other than the PR author, with the rule applied to all repositories tied to the production system boundary — not just the one where the exception was found. They paired it with a lightweight detective control: a weekly automated report cross-referencing PR author and approver fields, flagging any anomaly (including bot-merged emergency changes) for the engineering manager to review and annotate.
For the access review finding, the risk was "terminated or role-changed employees retain inappropriate system access." The control activity became a documented quarterly procedure: on the first business day of the quarter, the IT Security Manager exports the current access list from the identity provider for all seven in-scope systems, cross-references it against the HRIS active-employee list and current role assignments, flags discrepancies, opens a removal ticket for each, and closes the review with a signed summary attached to the compliance evidence folder. They also fixed the underlying gap that had caused two quarters of missing evidence: the review had previously depended on one person's calendar reminder, so they moved ownership into a recurring, assigned ticket in their ticketing system with a hard due date and an escalation to Dana if it went unaddressed for five business days.
Both fixes were re-tested by the auditor on a walkthrough plus a sample of subsequent activity, and both cleared. The Meridian contract's security addendum specifically required "no material weaknesses or unremediated exceptions related to access management or change management" — language that, six weeks earlier, would have killed the deal.
Table 6: Ironclad Remediation Outcomes (Illustrative)
Finding | Root Cause | Remediation | Time to Close | Result |
|---|---|---|---|---|
Self-approved production deployments (4 of 12 sampled) | No technical enforcement of independent review | Branch protection + weekly automated author/approver cross-check | 9 days | Re-tested clean; zero self-approvals in follow-up sample |
Missing quarterly access review evidence (2 of 6 quarters) | Manual, unassigned, calendar-dependent process | Documented procedure + recurring assigned ticket with escalation | 12 days | Re-tested clean; evidence produced for both missed quarters retroactively via compensating review |
Contract impact | — | — | — | $3.1M three-year Meridian contract closed 6 weeks after original target |
Technology General Controls: Access, Change, and Operations
Principle 11's "general control activities over technology" is best understood as three interlocking domains. Nearly every technology-related exception in a SOC 2 report falls into one of these buckets, and nearly every auditor's technology walkthrough is organized around them.
Access controls govern who can get into systems and what they can do once inside — provisioning, authentication strength, privileged access management, and deprovisioning. Change management controls govern how modifications to production systems, infrastructure, and code are proposed, reviewed, approved, tested, and deployed. Operations controls govern the ongoing health of the technology environment once it's running — monitoring, capacity management, backup and recovery, incident detection, and job scheduling.
These three domains map closely to two other Common Criteria sections you'll want to read alongside this one: access controls are the heart of CC6 (logical and physical access controls), and change management controls are the heart of CC8 (change management). CC5 is where you establish that these controls exist and are deliberately selected as part of your overall control activity design; CC6 and CC8 are where the depth and specificity of testing happens.
Table 7: Technology General Controls (ITGC) by Domain
Domain | Representative Control Activities | Common Tooling | What Breaks Without It |
|---|---|---|---|
Access | Role-based access control tied to job function; multi-factor authentication on all privileged accounts; automated deprovisioning on termination; quarterly access recertification | IAM/SSO platform, HRIS integration, PAM tooling | Orphaned accounts, privilege creep, terminated employees retaining access |
Change management | Mandatory peer review before merge; CI/CD pipeline gates (tests, security scans); documented emergency-change process; change advisory review for high-risk changes | Git platform branch protection, CI/CD pipeline, change management ticketing | Unreviewed code reaching production, undocumented configuration drift, outages from untested changes |
Operations | Automated monitoring and alerting with defined thresholds; capacity planning and autoscaling; backup execution with verified restore testing; documented incident response runbooks | SIEM, APM/observability platform, backup software, on-call/paging tooling | Undetected outages, capacity exhaustion, unrecoverable data loss, delayed incident response |
"Technology general controls are where I spend eighty percent of my testing time on a SOC 2 walkthrough, because they're where the theoretical policy meets the actual system configuration. You can't fudge a branch protection setting — it's on or it's off." — Sam Whitlock, Audit Partner, Halloran & Vance CPAs
Building Your Control Activity Register
If risk registers are the output of CC3, the control activity register is the output of CC5 — and it's the single artifact I ask every client to build before we touch a policy template. A control activity register is a living inventory: one row per control, cross-referenced to the risk(s) it mitigates, its type, its owner, its frequency, and the evidence location. Without it, control activities live scattered across policy documents, tribal knowledge, and whichever engineer set up a script eighteen months ago and then left the company.
The register does double duty. Internally, it's the map your team uses to know what needs to operate, when, and who's accountable if it doesn't. Externally, it's very often the first document an auditor asks for at the start of fieldwork, because it lets them plan their sampling strategy before they start pulling evidence.
Table 8: Sample Control Activity Register Structure
Control ID | Control Description | Related Risk(s) | Type | Owner | Frequency | Evidence Location | Last Tested |
|---|---|---|---|---|---|---|---|
CA-014 | Quarterly access recertification across in-scope production systems | Unauthorized/stale access | Detective | IT Security Manager | Quarterly | GRC platform — Access Reviews folder | 2026-04-02 |
CA-021 | Branch protection requiring independent code review before merge to main | Unreviewed/unauthorized code changes | Preventive | Engineering Manager | Continuous | Git platform audit log | 2026-06-15 |
CA-033 | Automated dependency vulnerability scanning on every build | Vulnerable third-party components | Detective | Engineering Manager | Per build | CI/CD pipeline scan reports | 2026-07-01 |
CA-040 | New hire security awareness training prior to system access | Untrained personnel with sensitive access | Preventive | HR Operations | Per hire | LMS completion records | Ongoing |
CA-052 | Automated deprovisioning triggered by HRIS termination event | Terminated employee retains access | Preventive | IT Operations | Continuous | IAM/HRIS integration logs | 2026-05-20 |
CA-061 | Encrypted backups with monthly restore verification | Data loss / unrecoverable backups | Detective | IT Operations | Monthly | Backup platform reports | 2026-06-30 |
CA-070 | Vendor security risk assessment prior to onboarding | Third-party introduced risk | Preventive | Vendor Risk Owner | Per vendor | GRC platform — Vendor Risk module | Ongoing |
A well-maintained register also makes the periodic reassessment that Principle 12 calls for tractable: instead of re-reading every policy document annually, you review the register, flag controls whose "last tested" date is stale or whose owner has left the company, and prioritize those first.
Evidence Auditors Actually Test for CC5
The gap between "we have a control" and "we can prove the control operated" is where most Type II findings live. Auditors testing CC5 aren't grading your intentions; they're sampling transactions and asking for audit evidence artifacts. Knowing what evidence category maps to which control type lets you design the evidence trail into the control from day one, rather than reverse-engineering it during fieldwork under time pressure — which is exactly the trap Ironclad fell into with its quarterly access reviews.
Table 9: Evidence Artifacts by Control Activity Type
Control Activity Type | Evidence an Auditor Will Sample | How to Make It Sampling-Ready |
|---|---|---|
Access provisioning/deprovisioning | Ticket showing request, approval, and completion timestamps; comparison against HRIS start/end dates | Use a ticketing system that timestamps every state change automatically; never rely on verbal or Slack-only approvals |
Access recertification | Signed review report; list of accounts reviewed, flagged, and remediated; removal ticket closure evidence | Export system-of-record access lists rather than manually compiled spreadsheets; retain prior quarters for trend comparison |
Change management / code review | PR/commit history showing distinct author and approver identities; CI pipeline logs; emergency change tickets with retroactive approval | Configure the git platform to block merges without independent approval so evidence is generated automatically, not manually logged |
Vulnerability/patch management | Scan reports with severity ratings; remediation ticket with closure date measured against SLA | Integrate scanning into CI/CD so every build produces a dated report without manual initiation |
Monitoring and alerting | Alert configuration screenshots/exports; sample of triggered alerts with response timestamps; on-call escalation logs | Route alerts through a system that retains history (not just live dashboards that overwrite) |
Backup and recovery | Backup job success/failure logs; periodic restore test report with outcome and duration | Schedule restore tests as a recurring calendar/ticket item, not an ad hoc "someday" task |
Segregation of duties | Role/permission matrix; system logs showing initiator vs. approver identity for sampled transactions | Build SoD checks into the system itself (e.g., workflow tools that reject same-user approval) rather than relying on manual policy adherence |
Common CC5 Exceptions (and How to Avoid Them)
Across the audits I've supported, a small number of CC5 exceptions recur so often they're nearly predictable. Most share the same DNA as Ironclad's findings: a policy exists, but the operational discipline behind it doesn't, or the evidence trail was never designed into the process.
Table 10: Common CC5 Exceptions and Remediation Patterns
Common Exception | Why It Happens | Remediation Pattern |
|---|---|---|
Segregation of duties failure (self-approved changes) | No technical enforcement; policy relies on trust | Enforce via system configuration (branch protection, workflow approval rules) rather than policy alone |
Access review performed inconsistently or with missing evidence | Manual, calendar-dependent process with no accountable owner | Assign ownership to a role (not a person), automate the trigger via ticketing, and store evidence centrally |
Policy exists with no corresponding procedure | Policy written for audit optics rather than operational use | Write every policy paired with a procedure that names a role, a cadence, and an evidence artifact |
Control activity not reassessed after organizational change (headcount growth, new system, acquisition) | Static procedure documentation, no review trigger | Set a recurring review cadence (at minimum annually) and trigger ad hoc review on material org changes |
Evidence retained inconsistently across the observation period | Evidence stored in personal folders/email instead of a central system | Centralize evidence in a GRC platform or dedicated evidence repository from day one of the observation period |
Control activity too broad or vague to test | Control written as an aspiration ("we monitor systems") rather than a specific action | Rewrite controls with a defined frequency, owner, and artifact — testable, not aspirational |
New system/vendor added mid-period without extending existing controls | Control activities scoped to original system inventory, not maintained as inventory grows | Tie control activity scope to a living asset/system inventory, reviewed at least quarterly |
From Risk to Evidence: The CC5 Control Activity Flow
The relationship between a risk, the control activity chosen to address it, the policy and procedure that deploy it, and the evidence an auditor eventually tests is sequential — and visualizing it helps teams spot where their own process breaks down. Most CC5 findings occur at exactly one of the arrows below: a risk with no mapped control, a control with no procedure, or a procedure with no retained evidence.
flowchart LR
A[Identified Risk<br/>from CC3 risk assessment] --> B[Control Activity<br/>Principle 10: selected & designed<br/>preventive and/or detective]
B --> C1[Policy<br/>Principle 12: the 'what'<br/>expectation & ownership]
B --> C2[Procedure<br/>Principle 12: the 'how'<br/>step-by-step operating instructions]
C1 --> D[Control Operates]
C2 --> D
D --> E[Evidence Generated<br/>tickets, logs, reports, sign-offs]
E --> F[Auditor Sample & Test<br/>CC5 walkthrough + operating effectiveness]
F -. exception found .-> G[Remediation<br/>feeds back into control design]
G -. redesign .-> BEvery stage of that flow should be traceable in both directions: given a risk, you should be able to name its control, policy, procedure, and evidence location; given a piece of evidence, you should be able to trace it back to the risk it exists to mitigate. That bidirectional traceability is, in practice, what "audit-ready" means for CC5.
"I ask clients to do a five-minute exercise: pick any control on your register and walk it backward to the risk. If you can't do that in under a minute, the control was probably designed to satisfy a checklist, not to actually reduce risk." — Renata Souza, Compliance Automation Lead, BrightLedger Payments
Case Study: Segregation of Duties on a Nine-Person Engineering Team
Marcus Kwan founded Driftwood Analytics, a seven-employee (later nine) marketing-analytics startup, and hit his first SOC 2 Type I readiness assessment fourteen months after incorporating. His auditor's readiness review flagged the obvious problem immediately: with two backend engineers total, there was no way to guarantee an independent reviewer for every production change without freezing deployment velocity the company couldn't afford.
Rather than pretending the problem away, Marcus's team designed a compensating-control approach that auditors are generally comfortable accepting when true segregation isn't feasible at small scale. Every production deployment still required a review — from Marcus himself when the two engineers' schedules didn't overlap with a third qualified reviewer — but they added a detective layer: a weekly "change log review" where all deployments from the prior week were re-examined against the original ticket and requirements, with any deployment lacking a distinct approver flagged and formally documented as an accepted, compensating-controlled exception with Marcus's sign-off as the accountable executive.
The auditor's Type I report noted the compensating control explicitly rather than issuing a qualified opinion, because the design showed deliberate risk acceptance with documented oversight rather than an unaddressed gap. By the time Driftwood's Type II observation period started eight months later, headcount had grown enough to implement true segregation for the majority of changes, and the compensating control remained in place only for the narrow set of emergency hotfixes where waiting for a second reviewer wasn't operationally realistic.
Table 11: Driftwood Analytics — Segregation of Duties Timeline
Stage | Team Size | SoD Approach | Auditor Outcome |
|---|---|---|---|
Pre-readiness assessment | 7 | No documented SoD control; ad hoc review | Readiness gap flagged |
Type I preparation | 9 | Compensating control: weekly change log review + executive sign-off on exceptions | Type I issued, compensating control noted, no qualification |
Type II observation period start | 16 | True independent review for ~85% of changes; compensating control retained for emergency hotfixes only | On track for clean Type II opinion |
Case Study: Rebuilding Technology General Controls After a Near-Miss
BrightLedger Payments, a payments-infrastructure company handling card-not-present transaction routing for mid-sized e-commerce merchants, had passed two prior SOC 2 Type II cycles without incident. In its third cycle, a near-miss changed how seriously leadership took Principle 11. An engineer, troubleshooting a production incident at 2 a.m., made a direct configuration change to a load balancer outside the normal change management pipeline — bypassing peer review because "it was an emergency and nobody else was awake." The change fixed the immediate problem but introduced a routing misconfiguration that went undetected for nine days until a customer complaint surfaced it. No data was lost and no customer was billed incorrectly, but the incident retroactively fell inside the SOC 2 observation window, and BrightLedger's compliance lead, Renata Souza, knew the auditor would find it in the change management sample regardless of whether BrightLedger disclosed it proactively.
They disclosed it proactively — which auditors and prospective customers both tend to respond to far better than a change management sample turning up an undocumented emergency change on its own. Renata's team used the incident to formalize what had previously been an unwritten "use your judgment" emergency-change practice: a documented emergency change procedure requiring the acting engineer to log the change in the ticketing system within one hour (even retroactively), notify a second engineer for asynchronous review within four hours, and route every emergency change through a weekly change advisory review regardless of whether an incident resulted. They also implemented configuration-as-code for the load balancer layer specifically, closing the "direct console access" path the engineer had used, so that even emergency changes flowed through a reviewable pull request rather than an unreviewable console session.
The auditor's report reflected the incident as a documented exception with a described remediation and a favorable assessment of the corrective action — a materially better outcome than an undisclosed exception discovered independently during sampling, which auditors and enterprise customers alike treat as a credibility problem distinct from the underlying technical issue.
Table 12: BrightLedger Payments — Before and After Emergency Change Controls
Dimension | Before | After |
|---|---|---|
Emergency change path | Direct console access to load balancer | Configuration-as-code via pull request, even under time pressure |
Documentation timing | Ad hoc, sometimes not logged | Logged within 1 hour, retroactive if necessary |
Independent review | None required for emergencies | Second engineer async review within 4 hours; weekly CAB review of all emergency changes |
Auditor treatment | N/A (first occurrence) | Documented exception with described remediation; no qualified opinion |
Automating Control Activities: Where Tooling Helps (and Where It Doesn't)
Compliance automation platforms have made a real dent in the manual burden of CC5 evidence collection, particularly for continuous technical controls: pulling access lists on a schedule, screenshotting configuration states, aggregating CI/CD pipeline logs into a single evidence feed. For controls where the underlying system already produces a reliable log — git platforms, IAM tools, ticketing systems — automation is close to strictly better than manual evidence gathering, because it removes the risk of someone forgetting to capture proof a control ran.
Where automation tends to overpromise is judgment-based control activities: vendor risk management tiering decisions, exception approval, and the kind of "does this configuration change make sense given what we know about the business" review that a human still has to perform. Tooling can surface the data and even flag anomalies, but it can't sign off on whether a flagged access grant is legitimate — that decision still needs a named, accountable human, and the evidence trail needs to show that a human, not just a script, made the call. The organizations that get the most value from automation are the ones that use it to eliminate evidence-collection toil while keeping decision-making explicitly human and explicitly logged.
A second caution: automated evidence collection is only as good as its coverage. If a compliance platform monitors seven of your nine in-scope systems because the other two use an unsupported integration, you have a false sense of completeness that an auditor's manual walkthrough will expose. Treat your system inventory, not your tooling's default integration list, as the source of truth for what needs a control activity.
Building a Quarterly Control Activity Testing Cadence
Control activities that only get attention once a year, right before the auditor arrives, produce exactly the evidence gaps Ironclad and BrightLedger both hit. A quarterly internal testing cadence — separate from the annual external audit — catches gaps early enough to fix them without deadline panic, and gives management ongoing assurance that CC1's tone-at-the-top commitments are actually being operationalized.
Table 13: Illustrative Quarterly Control Activity Testing Cadence
Quarter Activity | What Gets Tested | Who Performs It | Output |
|---|---|---|---|
Q1 — Access domain deep dive | Access provisioning, deprovisioning, and recertification for all in-scope systems | IT Security Manager + internal audit function | Access control testing report; remediation tickets for findings |
Q2 — Change management deep dive | Sample of production changes reviewed for independent approval, CI gate compliance, emergency change handling | Engineering Manager + compliance lead | Change management testing report |
Q3 — Operations domain deep dive | Backup/restore testing, monitoring/alerting configuration review, capacity threshold validation | SRE/IT Operations lead | Operations testing report |
Q4 — Full register review + policy/procedure refresh | Entire control activity register reviewed for staleness, ownership changes, and organizational changes since last review | CISO/compliance lead with control owners | Updated control register; refreshed policies/procedures ahead of external audit fieldwork |
Running this cadence internally also means that when the external auditor's sample lands, it's very rarely the first time anyone has looked at that evidence — which is the difference between an audit that feels like an interrogation and one that feels like a confirmation of work already done.
Who Does What: A RACI for Control Activity Execution
One question I ask every client building out their CC5 program for the first time: if I picked any control activity in your register at random, could you tell me, without checking, who's Responsible for performing it, who's Accountable if it fails, who needs to be Consulted before it changes, and who just needs to be kept Informed? Most organizations can answer this for two or three flagship controls — access reviews, usually — and go blank on the other forty. A RACI matrix built at the domain level, not the individual-control level, is usually enough to close that gap without turning the register into a bureaucratic exercise.
The pattern worth borrowing: keep Accountable narrow (one role, ideally one person, per domain) even when Responsible is shared across a team, because auditors — and more importantly, your own leadership — need a single name to go to when a control activity is found deficient. Diffuse accountability is one of the quieter reasons control activities decay over time; if three people are each fifty percent responsible for the quarterly access review, the honest math is that nobody is.
Table 14: Illustrative RACI for Control Activity Domains
Control Activity Domain | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Access provisioning/deprovisioning | IT Operations | IT Security Manager | HR (on hire/term events), Engineering Managers | CISO |
Access recertification | System owners (per application) | IT Security Manager | Internal Audit | CISO, Executive team |
Code review / change management | Engineering team leads | VP Engineering | Security team (for high-risk changes) | CISO |
Vulnerability and patch management | IT Operations / Platform team | Engineering Manager | Security team | CISO |
Vendor risk assessment | Procurement | Vendor Risk Owner (Compliance) | Legal, Security team | CISO, Finance |
Backup and recovery testing | IT Operations | IT Operations Lead | Engineering (for restore validation) | CISO |
Policy and procedure review | Compliance/GRC lead | CISO | Legal, department heads | Executive team, Board (annually) |
Control activity register maintenance | Compliance/GRC lead | CISO | All control owners | Auditor (at fieldwork) |
Reviewing this table once a quarter alongside the testing cadence in Table 13 catches the other common form of drift: a control whose named owner left the company four months ago and whose accountability quietly reverted to nobody in particular.
CC5 Maturity: From Ad Hoc to Optimized
Not every organization needs — or can afford — a fully automated, continuously monitored control activity program on day one. What matters is knowing honestly where you sit on the maturity curve and having a credible plan to move up it, because auditors calibrate their skepticism accordingly: a five-person startup with manually-evidenced controls that are consistently followed will often test better than a two-hundred-person company with an expensive GRC platform nobody actually uses.
I generally describe four stages. Ad hoc is where Ironclad started: policies exist, controls happen inconsistently, evidence is whatever someone remembers to screenshot. Defined is where most companies land in their first Type I cycle: control activities are documented in a register, procedures are written, evidence is collected but often manually and close to the audit deadline. Managed is where recurring internal testing (the quarterly cadence above) becomes routine, evidence collection is partially automated for system-generated controls, and the control activity register is treated as living documentation rather than an audit artifact. Optimized is where most of the evidence collection for continuous technical controls is automated end-to-end, control effectiveness metrics feed into leadership reporting, and the register itself drives risk-based prioritization of where to invest next — the stage BrightLedger Payments was aiming for after its third-cycle remediation.
Table 15: CC5 Control Activity Maturity Model
Maturity Stage | Control Design | Evidence Collection | Typical Audit Outcome |
|---|---|---|---|
Ad hoc | Inconsistent; controls exist informally or only where an incident forced attention | Manual, reactive, often incomplete for parts of the observation period | High risk of exceptions; common in first Type I readiness assessments |
Defined | Documented in a register; policies and procedures written and approved | Manual but consistent; collected close to audit fieldwork | Type I typically achievable; Type II often surfaces evidence gaps |
Managed | Register actively maintained; quarterly internal testing cadence in place | Partially automated for technical controls; manual for judgment-based controls | Clean Type II achievable with minor, well-remediated exceptions |
Optimized | Register drives risk-based investment; control design reviewed against changing risk landscape | Largely automated with centralized evidence repository; human sign-off retained for judgment calls | Consistently clean opinions; control evidence reused for sales/procurement cycles |
Most organizations don't need to reach "optimized" to satisfy an auditor — "managed" is a perfectly respectable, sustainable target for a mid-sized service organization, and jumping straight to heavy automation before your control design is even stable tends to produce expensive tooling wrapped around an immature process.
How CC5 Connects to the Rest of the Common Criteria
Control Activities doesn't operate in isolation — it's the hinge between the criteria that come before it and the ones that come after. Control environment (CC1) sets the organizational commitment and accountability structure that makes people actually follow the procedures CC5 requires; without genuine tone-at-the-top support, control activities tend to exist on paper but erode under delivery pressure, which is exactly what happened inside Ironclad's engineering org before the Meridian near-miss forced the issue upward. Risk assessment (CC3) is the direct upstream input to Principle 10 — you cannot select and develop control activities that mitigate risk if you haven't first identified and analyzed what those risks are. Monitoring activities (CC4) is the downstream check on CC5 itself: it's the mechanism by which the organization periodically evaluates whether its control activities are still designed appropriately and still operating, which is where the quarterly testing cadence above earns its keep. And information and communication (CC2) is what makes sure the procedures underlying CC5 controls are actually documented and accessible to the people who need to perform them, rather than living in one engineer's head.
Two Common Criteria sections outside the COSO-mapped CC1–CC5 series deserve a direct mention because CC5's Principle 11 leans on them so heavily: CC6 (logical and physical access controls) is where the specific mechanics of access control activities get tested in depth, and CC8 (change management) does the same for change control activities. If you're building your program section by section, treat CC5 as the design layer and CC6/CC8 as the implementation depth for two of its three technology domains.
For a broader foundation before diving into any single Common Criteria section, it's worth reviewing the SOC 2 security criteria control implementation guide, which frames how all nine CC-series sections fit together under the mandatory Security category.
"CC5 is the criteria that makes or breaks a smooth audit, because it's downstream of everything else. Weak risk assessment gives you the wrong controls. Weak tone at the top means the controls don't get followed. Weak monitoring means nobody catches it until the auditor does." — Dana Okafor, CISO, Ironclad Freight Analytics
Control Activities as a Business Opportunity, Not Just an Audit Line Item
It's tempting to treat CC5 as pure audit overhead — a set of hoops between your engineering team and a signed report. The organizations that get the most commercial value out of SOC 2 treat it differently: a well-designed control activity register is genuinely useful operational infrastructure, independent of the audit. Knowing exactly which risks map to which controls, who owns each one, and how you'd prove it operated is the same discipline that shortens enterprise security questionnaires, speeds up vendor risk reviews from prospective customers, and gives your own leadership team a real answer when the board asks "how do we know this is actually working" — a question that gets asked more often after a competitor's breach makes headlines than at any other time.
For organizations pursuing both frameworks, CC5's discipline maps closely onto ISO 27001's operational controls, and the overlap is worth exploiting rather than duplicating. If you're weighing ISO 27001 vs SOC 2 and which one you need, or already committed to running ISO 27001 and SOC 2 together, a single control activity register mapped across both frameworks — using a crosswalk between ISO 27001, SOC 2, and NIST CSF — avoids maintaining two parallel evidence trails for what is functionally the same operational control. Teams new to the broader information security management concept behind ISO's approach may also find it useful to start with what ISO 27001 actually is before mapping the two frameworks against each other.
The commercial case is the one Dana made to her own leadership after the Meridian near-miss: the five weeks her team spent rebuilding the control activity register didn't just fix an audit finding, it removed a recurring source of friction in every subsequent enterprise sales cycle, because the same evidence that satisfied the auditor now satisfies procurement teams asking nearly identical questions.
"Once we had a real control activity register, our sales engineering team started using it to answer security questionnaires in a fraction of the time. The audit stopped being the only thing it was good for." — Dana Okafor, CISO, Ironclad Freight Analytics
Get Your Control Activities Audit-Ready
If you're staring at a CC5 gap — or trying to avoid discovering one three weeks before your observation period closes — start with a control activity register mapped directly to your risk assessment, not with a policy rewrite. PentesterWorld's SOC 2 Control Matrix / RACI Template gives you a structured starting point for exactly the risk-to-control-to-evidence mapping this article walks through, and the SOC 2 Policy Pack pairs each policy with the operating procedure language auditors expect to see behind it. If you're not yet sure where your gaps are, the SOC 2 Gap Analysis Tool will flag missing or underdeveloped control activities against the full Common Criteria before an auditor does it for you — and our SOC 2 Glossary keeps the terminology straight for anyone new to the framework joining your compliance effort mid-project.