COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks

COSO Principle 10: the entity selects and develops control activities that contribute to the mitigation of risks requirement is where many SOC 2 programs either become defensible or fall apart. You can have strong policies, a mature security team, and modern tooling, but if you cannot show that your control activities were deliberately selected to mitigate defined risks (and that they operated consistently), your audit file will read as “ad hoc.”

For a Compliance Officer, CCO, or GRC lead, the practical goal is simple: make your controls make sense on paper and in evidence. This principle sits in the “Control Activities” layer of the Trust Services Criteria and is tested through two lenses: (1) control design (does the control, if performed, mitigate the risk) and (2) control operation (did the control actually happen, for the period, with sufficient proof). ¹

This page gives requirement-level implementation guidance you can apply immediately: who should own what, how to build a risk-to-control mapping that auditors accept, what artifacts to keep, and how to run a 30/60/90-day execution plan that turns “we do this” into “we can prove this.” ¹

Regulatory text

Requirement (SOC 2 / Trust Services Criteria): “COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks.” ¹

Operator interpretation (what you must do):

• Identify risks that matter to your in-scope services and systems (the SOC 2 boundary). ¹
• Select and design control activities that reduce those risks to an acceptable level. ¹
• Implement those controls with clear ownership, frequency, inputs, and outputs so operation is repeatable. ¹
• Retain evidence that proves the controls operated as designed throughout the audit period. ¹

Plain-English interpretation of the requirement

This requirement asks: “Given your risks, did you put the right controls in place, and can you show they worked?” ¹

A control activity can be:

• Preventative, such as access approvals before granting permissions.
• Detective, such as log review that identifies anomalous access.
• Corrective, such as incident response steps that contain and remediate issues.

Auditors don’t need you to have every possible control. They need you to demonstrate that your controls are intentionally chosen, are appropriate for the risks, and are executed reliably. ¹

Who it applies to (entity and operational context)

Applies to: service organizations undergoing a SOC 2 examination for in-scope services and supporting systems. ¹

Where it shows up operationally:

• Cloud infrastructure and identity administration
• Application change management and SDLC
• Security monitoring and incident response
• Data handling, encryption, backups, and recovery
• Third-party dependencies that support the in-scope service (for example, hosting, ticketing, logging providers)

Who needs to be involved:

• GRC/Compliance owner: builds the mapping, defines evidence standards, runs the cadence.
• Control owners (Engineering, IT, Security, Support): perform controls and provide evidence.
• Risk owner (often Security/Engineering leadership): agrees risk acceptance and residual risk.
• Internal audit or equivalent reviewer (if you have one): spot-checks operation quality before the external auditor does.

What you actually need to do (step-by-step)

Step 1: Define the scope boundary and risk universe

1. Confirm the in-scope product/service, system components, and supporting tools. Tie this to your SOC 2 system description. ¹
2. List relevant risk categories (security, availability, confidentiality, processing integrity, privacy as applicable to your report). Keep it practical: risks should be testable against controls. ¹

Output: a scoped risk register for the SOC 2 boundary.

Step 2: Write risks as “cause → event → impact”

Auditors test whether controls mitigate a clear risk. Poorly written risks slow everything down.

Use a consistent format:

• Cause: Misconfigured IAM roles
• Event: Unauthorized access to production systems
• Impact: Data exposure or service disruption

Output: risks that can be mapped 1:many to controls.

Step 3: Build a risk-to-control matrix (the core artifact)

Create a matrix with these minimum columns:

Field	What “good” looks like
Risk ID + statement	Clear, scoped to the system
Control activity	A specific action, not a policy
Control type	Preventative / detective / corrective
Control owner	Named role/team (not “IT”)
Frequency	Event-driven or scheduled
Tool/system of record	Where evidence lives
Evidence produced	Screenshot, export, ticket, log, report
Link to procedure	How-to steps so it’s repeatable
Residual risk note	If control reduces but doesn’t eliminate risk

Decision rule: If you cannot describe the evidence for a control in one sentence, the control is not operationalized enough for audit. ¹

Step 4: Design controls to be testable

For each control, document “control design” in a short control narrative:

• Objective: which risk it mitigates
• Trigger: what starts it (schedule or event)
• Steps performed: concise and reproducible
• Approval/review: who validates it, if applicable
• Exceptions handling: what happens when it fails
• Evidence: what you will retain

This is the fastest way to avoid the common audit gap: “Control exists, but evidence is inconsistent.” ¹

Step 5: Standardize evidence collection (make it boring)

Pick an evidence standard per control type:

• Access controls: approval ticket + system screenshot/export showing provisioned access + periodic review sign-off.
• Change management: PR link + approval + test results + deployment record.
• Monitoring: alert records + triage ticket + resolution notes.
• Backups: backup job report + restore test record.

Keep evidence in a single system of record (GRC tool, secure folder structure, or ticketing system). Make naming conventions predictable so sampling is painless.

Where Daydream fits naturally: Daydream can act as the program system of record by tying each risk to each control, assigning owners, and generating evidence requests on a cadence so you don’t rebuild the audit trail at the end of the period.

Step 6: Operate controls on a documented cadence

Run an operational calendar:

• What control runs when
• Who performs it
• Who reviews it (if needed)
• Where evidence is stored

Cadence discipline is the difference between “we do this sometimes” and “operating effectively.” ¹

Step 7: Add a quality check before the auditor finds issues

Implement a lightweight internal check:

• Sample completed evidence for completeness and clarity
• Confirm timestamps cover the audit period
• Confirm reviewer sign-offs exist where the design says they should

Required evidence and artifacts to retain

Auditors commonly request artifacts that prove both design and operation. Maintain:

1. Risk register (scoped) tied to the SOC 2 boundary. ¹
2. Risk-to-control matrix with ownership, frequency, and evidence fields. ¹
3. Control narratives / procedures that describe how the control is performed. ¹
4. Operating evidence per control execution (tickets, exports, screenshots, logs, approvals). ¹
5. Exception records (missed control runs, failures, compensating actions, remediation). ¹
6. Management review evidence where applicable (sign-offs, review notes, meeting minutes with decisions). ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you selected this control to mitigate that specific risk.” ¹
• “Who owns the control, and how do you ensure it runs on schedule?” ¹
• “What happens when the control fails or is missed?” ¹
• “Provide a sample of evidence across the audit period.” ¹
• “Is this control manual or automated, and what are the dependencies?” ¹

Hangups that trigger follow-up testing:

• Evidence has no timestamp or doesn’t show the relevant system.
• Screenshots without context (no account name, no scope, no date).
• Controls described at a policy level, not an activity level.
• One person does and approves a sensitive control with no independent review.

Frequent implementation mistakes and how to avoid them

Mistake 1: “Controls as policies”

Symptom: You list “Access Control Policy” as a control.
Fix: Convert policy into testable activities: approvals, provisioning records, and periodic access reviews. Keep the policy as supporting documentation, not the control itself. ¹

Mistake 2: No traceability from risk to control

Symptom: A control library exists, but risks are generic or missing.
Fix: Build and maintain the risk-to-control matrix as your primary artifact. Update it when systems, threats, or processes change. ¹

Mistake 3: Evidence is inconsistent across teams

Symptom: Each engineer provides different artifacts for the same control.
Fix: Standardize evidence templates and specify “system of record” per control (ticketing system, CI/CD, IAM tool). ¹

Mistake 4: Controls run, but no one can prove they ran

Symptom: Verbal assurance, missing logs, missing approvals.
Fix: Make evidence retention part of the control steps. If it’s not captured, treat it as not performed. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. For SOC 2, the practical consequence of weak Principle 10 implementation is an unfavorable audit outcome: control exceptions, expanded sampling, or an inability to support a Type II opinion because operation cannot be evidenced. ¹

Operationally, weak control selection shows up as preventable incidents: unauthorized access, unreviewed changes, delayed detection, and incomplete incident response records. Even without public enforcement, these gaps increase customer due diligence findings and procurement friction.

A practical 30/60/90-day execution plan

Days 1–30: Build the traceability backbone

• Confirm SOC 2 scope boundary (systems, tools, teams). ¹
• Draft or refine the scoped risk register using “cause → event → impact.”
• Create the risk-to-control matrix with owners, frequency, and evidence definitions.
• Identify top gaps: risks with no controls, controls with no evidence plan.

Deliverables: risk register, risk-to-control matrix, initial control inventory with evidence requirements.

Days 31–60: Turn controls into repeatable operations

• Write control narratives for priority controls (start with access, change management, monitoring, incident response).
• Implement evidence standards and storage conventions.
• Train control owners on what “good evidence” looks like.
• Run a pilot: execute each key control at least once and collect evidence.

Deliverables: control narratives/procedures, evidence templates, pilot evidence set.

Days 61–90: Prove operating effectiveness and harden exceptions handling

• Start recurring control runs on the defined cadence.
• Add a monthly quality review (spot-check evidence, exceptions, and follow-ups).
• Document exception handling and compensating controls.
• Prepare an auditor-ready package: matrix, narratives, and a clean evidence index.

Deliverables: recurring evidence trail, exception log, readiness package aligned to SOC 2 testing. ¹

Frequently Asked Questions

How specific do my control activities need to be to satisfy COSO Principle 10?

Specific enough that a new control owner could perform the control from your procedure and produce the same evidence. If your “control” reads like a policy statement, it is probably not testable as an activity. ¹

Can one control mitigate multiple risks?

Yes, and auditors expect that mapping in mature programs. Keep the mapping explicit in the risk-to-control matrix so the relationship is defendable during walkthroughs. ¹

Do automated controls reduce evidence burden?

They can, but only if you retain reliable system-generated evidence and document the configuration that makes the control operate. Automation without retained outputs still fails an operating effectiveness test. ¹

What evidence is “good enough” for recurring controls like access reviews?

Evidence should show the population reviewed, the reviewer identity, the review date, decisions made, and follow-up actions with closure proof. A screenshot of a dashboard without scope or reviewer attribution usually triggers auditor follow-ups. ¹

How do I handle a missed control run during the audit period?

Record it as an exception, document root cause, implement remediation, and show compensating actions if relevant. Auditors evaluate how you detect and respond to misses, not only whether misses occurred. ¹

Where does a GRC tool like Daydream help the most for this requirement?

It helps by keeping risk-to-control traceability current, assigning control ownership and cadence, and centralizing evidence requests and retention. That reduces “end of period scrambling,” which is a common driver of incomplete evidence. ¹

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017