Principle 10: Selects and develops control activities that help mitigate risks

To meet the principle 10: selects and develops control activities that help mitigate risks requirement, you must translate your risk assessment into specific, owned, repeatable control activities that reduce risk to an acceptable level, and prove those controls operate through consistent evidence. Operationalize it by building “control cards,” defining an evidence bundle, and running recurring control health checks tied to remediation closure.

Key takeaways:

• Map top risks to control activities with clear owners, cadence, and execution steps ¹
• Define a minimum evidence bundle per control cycle so audits don’t fail on documentation gaps ¹
• Test control health routinely, track issues to validated closure, and keep a clean audit trail ¹

Principle 10 sits at the “do the work” layer of COSO: once you’ve identified risks, you need control activities that actually mitigate them in day-to-day operations. A policy that says “we secure data” does not satisfy Principle 10. Examiners, internal audit, external audit, and customer due diligence want to see a risk-to-control chain: risk identified, control selected, control designed to address the risk, control runs on a defined cadence, and evidence proves it ran as designed ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat each key control like an operational product: define what triggers it, who performs it, how exceptions are handled, and what artifacts exist after each run. Your goal is predictable execution. The most common failure pattern is simple: teams cannot show who owns the control, how often it runs, or which evidence proves it is operating ¹.

This page gives requirement-level implementation guidance you can put into a control library immediately, including step-by-step tasks, evidence expectations, audit questions, and a practical execution plan.

Regulatory text

Excerpt (provided): “COSO internal control principle 10 implementation expectation.” ²

Operator interpretation: Principle 10 expects you to select and develop control activities that mitigate the risks you’ve identified. In practice, that means:

• You don’t stop at a risk register. You convert prioritized risks into controls that prevent, detect, or correct failures.
• Controls must be designed at a level where an operator can execute them consistently, not interpret them differently each time.
• Control activities must be embedded into business processes and supported by documentation and evidence that demonstrates operation ¹.

How this shows up in reviews: Auditors will look for a coherent story across: risk assessment outputs, control design decisions, and control operation results ³.

Plain-English requirement

You must pick controls that match your risks, document how those controls work, assign accountable owners, and run them reliably. If you cannot prove a control ran (with traceable evidence), reviewers will treat it as not operating, even if the work happened informally.

Who it applies to

Entity types: Enterprise organizations implementing COSO-based internal control ².

Operational contexts where Principle 10 is usually tested hard:

• Financial reporting and close processes (journal entry controls, reconciliations, approval workflows)
• Technology and security operations (access provisioning, change management, monitoring)
• Third-party risk management (due diligence, contract controls, ongoing monitoring)
• Compliance obligations that require repeatable processes (complaints, investigations, training assignment and completion tracking)

Control population scope tip: Start with controls tied to your highest inherent risks and to processes with material impact (financial, operational resilience, customer data, regulatory commitments). Expand coverage once the operating model is stable.

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

1) Build a risk-to-control map you can defend

Create a simple matrix that links:

• Risk statement (cause, event, impact)
• Control objective (what the control is meant to achieve)
• Control activity (the specific preventive/detective action)
• Control type (preventive/detective/corrective; manual/automated; key/non-key)
• Residual risk expectation (what “good” looks like after the control runs)

Keep it practical. If a risk has no control mapped, that’s a conscious acceptance decision that should be documented and approved.

2) Create a “control card” for each key control

A control card is your fastest operationalization tool. Minimum fields:

• Control name and objective
• Risk(s) addressed (reference to risk register ID)
• Owner (role name) and backup
• Where performed (system, workflow, ticket queue)
• Trigger/cadence (event-based or recurring)
• Inputs (reports, logs, source systems)
• Execution steps (numbered runbook steps an operator can follow)
• Approvals/segregation of duties (who reviews, who cannot perform)
• Exception rules (what counts as an exception; escalation path)
• Output artifacts (what gets produced every run)
• Retention location (GRC tool, ticketing system, document repository)
• Control dependencies (upstream data quality, system access)

This aligns directly to the recommended practice of “Create a requirement control card with objective, owner, trigger events, execution steps, and exception rules.” ¹

3) Define the minimum evidence bundle ⁴

Audits commonly fail on evidence inconsistency. Standardize what “proof” means for each control. Your evidence bundle should include:

• Input evidence (source report extract, system query output, ticket list)
• Performance evidence (completed checklist, screenshot, signed attestation, system log)
• Review/approval evidence (approval record, second-person review, sign-off)
• Outcome evidence (reconciliation result, exception list, remediation ticket)
• Timestamp and performer identity (who, when)

This matches the recommended practice: “Define the minimum evidence bundle for each execution cycle (inputs, approvals, output artifacts, and retention location).” ¹

Practical rule: If evidence lives in email or DMs, you have an audit problem. Move it into a controlled repository, ticketing system, or GRC workflow.

4) Embed controls into the workflow (don’t leave them as documents)

Controls operate best when they are “hard to skip.” Examples:

• Access reviews routed through ticketing with required fields and approver gating
• Change management requiring peer review before deployment
• Reconciliations stored in a standardized template with locked fields for sign-off

Where automation is possible, document the automated logic and the monitoring control that confirms automation is functioning.

5) Run control health checks and manage issues to closure

Principle 10 is not a one-time design exercise. Establish a lightweight control monitoring loop:

• Track missed runs, late runs, and incomplete evidence
• Trend exceptions (type, root cause, recurrence)
• Create remediation items with owners and due dates
• Validate closure with evidence (not verbal confirmation)

This matches the recommended practice: “Run recurring control health checks and track remediation items to validated closure with due dates.” ¹

6) Prove governance: approval of control design and changes

For key controls, keep a record of:

• Who approved the control design (process owner, compliance, internal audit where applicable)
• When the control changed and why
• Testing performed after changes (spot check evidence from the first run post-change)

Required evidence and artifacts to retain

Use this as your “minimum audit binder” checklist:

• Risk-to-control matrix (current version and prior version history)
• Control inventory with designation of key controls
• Control cards/runbooks for key controls
• Evidence bundles for sampled periods (inputs, performance, approvals, outputs)
• Exception logs and remediation tickets with validated closure evidence
• Control change log (what changed, approval, effective date)
• Control health check results and management reporting

If you’re using Daydream, configure each control record to require the evidence bundle fields at close-out so operators cannot complete a cycle without attaching the minimum artifacts. That reduces last-minute evidence hunts during audits.

Common exam/audit questions and hangups

Auditors tend to probe the same weak points:

• “Show me how this risk is mitigated.” Expect to walk from risk register → control card → last execution evidence.
• “Who owns this control, and what happens if they’re out?” Backup ownership is frequently missing.
• “How do you know the control ran every time?” They want a complete population and a way to detect missed cycles.
• “What is the review standard?” A signature alone is weak; define what the reviewer checks.
• “How do you handle exceptions?” Mature programs show escalation criteria and remediation tracking.

Frequent implementation mistakes (and how to avoid them)

1. Controls described as policies. Fix by rewriting as operator steps with inputs/outputs and exception handling.
2. No defined evidence standard. Fix by publishing an evidence bundle checklist inside the control card ¹.
3. Controls that don’t match the risk. Fix by requiring a clear control objective and mapping to the risk statement; retire “feel-good” controls.
4. Manual controls with unclear review. Fix by defining reviewer procedures and thresholds for follow-up.
5. One-and-done implementation. Fix by scheduling control health checks and tracking remediation to validated closure ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, Principle 10 failures still create real exposure: if a material process fails and you cannot demonstrate the related controls were designed and operating, you face audit findings, customer trust failures, and weakened defensibility in incident response narratives ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize the control operating model)

• Identify your highest-priority risks and the processes they touch.
• Build the first version of the risk-to-control matrix for those areas.
• Draft control cards for the key controls in scope, including owners and backups.
• Define the minimum evidence bundle for each key control and the retention location ¹.

Days 31–60 (operate and collect proof)

• Run the controls using the control cards as the runbooks.
• Perform spot checks on evidence quality and completeness.
• Stand up an exceptions and remediation workflow (ticket-based preferred).
• Start a control change log for any refinements you make after initial runs.

Days 61–90 (monitor, test, and make it exam-ready)

• Perform the first formal control health check cycle and document results ¹.
• Close remediation items with validated evidence.
• Package an “audit-ready” binder for a sample of controls: last run evidence, exceptions, approvals, and closure proof.
• Calibrate control rationales: confirm each key control clearly mitigates a specific risk and has an operating history you can demonstrate.

Frequently Asked Questions

How detailed does a control activity need to be to satisfy Principle 10?

Detailed enough that a trained backup can execute it the same way and produce the same artifacts. If the control depends on tribal knowledge, rewrite it into a numbered runbook with defined inputs, outputs, and exception rules ¹.

Do automated controls still need evidence bundles?

Yes. Evidence may be system logs, configuration exports, workflow approvals, and monitoring alerts, but you still need proof the automation ran and proof someone would detect a failure ¹.

What if a risk is mitigated by multiple small controls rather than one key control?

Document the control set explicitly in the risk-to-control map and explain how the controls work together (prevent/detect/correct). Then define evidence bundles for the controls that provide the strongest proof of mitigation.

How do I handle controls owned by the business, not compliance?

Keep ownership with the process owner, but require a control card, an evidence bundle, and participation in health checks. Compliance should set the standard and validate operation through sampling, not perform the control.

What’s the minimum I need to show an auditor for control operation?

A clear control description (control card), evidence from recent executions, and a way to demonstrate completeness (no missed runs). Also show how exceptions were handled and closed with proof ¹.

How does this connect to third-party risk management?

Treat third-party due diligence, contract reviews, and ongoing monitoring as control activities tied to third-party risks. The same principles apply: defined steps, accountable owner, repeatable cadence, and retained evidence for each cycle.

Footnotes

1. COSO IC framework overview

2. COSO Internal Control guidance page

3. COSO IC framework overview; Weaver summary of COSO 17 principles

4. control, per cycle