Control Activities Selection and Development

To meet the COSO control activities selection and development requirement, you must translate your risk assessment into a defined set of preventive and detective controls, assign ownership, and prove those controls are designed appropriately and operating as intended. Your fastest path is a risk-to-control mapping, control standards for key processes and systems, and audit-ready evidence for each control. ¹

Key takeaways:

• Build a risk-to-control mapping that shows each material risk is mitigated to an acceptable level with specific controls. ¹
• Define control activity “standards” (what good looks like) for manual, automated, and IT-dependent controls, then assign accountable owners. ¹
• Retain evidence that proves design and operating effectiveness, not just policies. ¹

“Control Activities Selection and Development” is where your risk assessment becomes something an auditor, regulator, or board can rely on: actual controls embedded in processes and systems, with clear ownership and repeatable execution. COSO’s expectation is straightforward: once you know your risks, you select and develop control activities that reduce those risks to acceptable levels, across the organization and at the process level. ¹

For a CCO or GRC lead, the practical challenge is not brainstorming controls. It’s proving alignment and completeness: that every key risk has a corresponding set of controls; that the controls are appropriately designed (preventive vs. detective, manual vs. automated); and that you can produce evidence of operation without scrambling at exam time. Weaknesses here usually show up as “paper programs”: policies with no embedded controls, controls with no owners, controls that cannot be tested, or controls that do not address the actual risk scenario.

This page gives requirement-level implementation guidance you can operationalize quickly: scope, steps, artifacts, audit questions, common failure modes, and a pragmatic execution plan you can run with your process owners and internal audit.

Regulatory text

Requirement (COSO Principle 10 – Control Activities): “The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.” ¹

Operator interpretation (what you must do):

• Identify the risks that could prevent achievement of objectives (financial reporting, compliance, operational, strategic), then choose controls that directly mitigate those risks to a level management accepts. ¹
• Develop those control activities so they are implementable and testable: define who performs them, how often, what evidence is produced, what tools are used, and what happens when exceptions occur. ¹
• Ensure control activities exist at the right layers: entity-level controls (governance, oversight), process-level controls (e.g., procure-to-pay), and technology-enabled controls (application and IT-dependent controls). ¹

Plain-English requirement: what this means in practice

You are expected to show a clean line from:

1. objective → 2) risk → 3) control activity → 4) evidence.

If your risk register says “unauthorized payments,” you need specific controls (e.g., approval workflow, vendor master change controls, payment run review) and proof those controls are performed. If your risk is “third party data exposure,” you need controls across onboarding, access provisioning, monitoring, and offboarding, plus evidence that those checks happened for real third parties.

A strong program is boring. It is standardized, repeatable, and easy to test.

Who this applies to (entity and operational context)

This requirement applies to any organization using COSO as its internal control framework, including organizations building internal control programs for financial reporting, compliance, and operational risk management. ¹

Common operational contexts:

• SOX / ICFR environments: control activities that support reliable financial reporting (e.g., revenue recognition, journal entries, access controls). ¹
• Compliance programs: controls that prevent/detect regulatory violations (e.g., sanctions screening, complaints handling, training completion, surveillance). ¹
• Third-party risk management: controls covering due diligence, contracting, ongoing monitoring, and termination. This is often a high-risk gap because ownership spans procurement, security, legal, and the business. ¹
• Technology-heavy operations: automated and IT-dependent controls that require coordination between GRC, IT, and system owners. ¹

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

1) Confirm scope and objectives

• List the objectives your control system must support (financial reporting, compliance obligations, operational resilience, data protection).
• Define “acceptable levels” of risk in a practical way: what issues trigger escalation, what residual risk is tolerated, and who approves exceptions.

Deliverable: Objectives and risk appetite/acceptance statements aligned to governance.

2) Build (or refresh) your risk-to-control mapping

• Start with your risk assessment output (risk register, process risk and control matrices, third-party risk taxonomy).
• For each material risk, document:
  • risk scenario (what could happen, where, and why)
  • existing controls
  • residual risk after controls
  • gaps (no control, weak design, weak evidence, unclear owner)

Deliverable: Risk-to-control mapping (often a RCM), with clear traceability. ¹

3) Select control types deliberately (preventive/detective; manual/automated)

Use a simple decision matrix you can defend in audit:

Risk characteristic	Control preference	Why auditors like it
High impact, frequent	Preventive + automated where feasible	Lower error rate, easier to test
High impact, infrequent	Preventive + detective monitoring	Catches rare events and control drift
Complex judgment	Manual control with documented criteria + second review	Shows governance over discretion
IT-dependent process	Automated control + ITGC dependencies documented	Clarifies reliance on systems

Deliverable: Control selection rationale per key risk/control. ¹

4) Develop each control into a testable control specification

For each control activity, write a control spec that an operator can execute and an auditor can test. Minimum fields:

• Control name and objective (which risk it mitigates)
• Process and system(s) in scope
• Control type (preventive/detective; manual/automated; IT-dependent)
• Frequency or triggering event
• Performer and approver (owner, backup)
• Inputs, steps, and decision criteria (what “good” looks like)
• Evidence produced (artifact type, where stored)
• Exception handling (what happens on failures; escalation path)
• Dependencies (upstream data feeds, IT general controls, third parties)

Deliverable: Control library / control narratives. ¹

5) Embed controls into workflows (don’t leave them as documents)

• Put approvals in the system workflow where possible (ticketing, ERP approval chains, IAM tooling).
• Add required fields/checklists to forms used by the first line (e.g., third-party onboarding form requires risk tier, due diligence completion, security review).
• For manual reviews, standardize templates so evidence is consistent.

Deliverable: Updated procedures + configured workflow evidence (screenshots/config extracts) where applicable.

6) Assign accountable ownership and establish governance

• Name a control owner in the first line for each control.
• Assign a second-line oversight owner for monitoring and issue management where needed.
• Define how control failures are reported, tracked, remediated, and re-tested.

Deliverable: Control ownership roster + issue management workflow. ¹

7) Validate design and operating effectiveness (lightweight but real)

• Design check: Does the control, as written, actually mitigate the risk scenario?
• Evidence check: Can the owner produce evidence without heroic effort?
• Operating check: Sample executions and confirm the control was performed as specified.

Deliverable: Control testing plan and results (internal audit, compliance testing, or self-assessments), plus remediation records. ¹

8) Close gaps and document residual risk acceptance

• If a risk has no effective control, decide: implement a new control, improve an existing control, or formally accept the residual risk.
• Document approvals for risk acceptance and set review dates.

Deliverable: Remediation plans, risk acceptances, and management approvals.

Required evidence and artifacts to retain

Auditors will ask for proof that controls exist, are appropriate, and run consistently. Retain:

• Risk assessment outputs and approvals (risk register, risk ratings)
• Risk-to-control mapping / RCM with traceability ¹
• Control specifications (control library), including owner, frequency, evidence type ¹
• Process narratives and flowcharts for key processes
• System configurations that implement controls (approval workflows, access rules) where feasible
• Control operation evidence (reports, tickets, approvals, reconciliations, review sign-offs)
• Exception logs, investigation notes, and corrective actions
• Testing results (design/operating) and remediation tracking

Evidence rule of thumb: If you cannot produce consistent artifacts for a control, treat it as a design gap, not a documentation gap.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the linkage from your top risks to specific control activities.” ¹
• “Which controls are key controls, and why?”
• “Which controls are automated vs. manual? What are the IT dependencies?” ¹
• “Who owns this control? What training do they have? Who is the backup?”
• “Walk me through the last time the control ran. Show evidence.”
• “How do you know controls operate consistently across business units?”
• “What happens when the control fails? Show issues and remediation.”

Hangups usually come from unclear control definitions (“review is performed”) with no criteria, missing evidence, or mismatched frequency.

Frequent implementation mistakes and how to avoid them

1. Controls don’t map to the risk scenario.
   Fix: require each control spec to cite the risk it mitigates and describe the failure it prevents/detects. ¹

2. Overreliance on manual controls with weak evidence.
   Fix: standardize templates; move approvals into systems; require artifact storage locations in the control spec.

3. IT-dependent controls with undocumented dependencies.
   Fix: document system reports used, access restrictions, change management expectations, and how report completeness/accuracy is assured.

4. No clear owner or backup.
   Fix: add RACI and HR position titles, not just names, so ownership survives turnover.

5. “Control library” exists, but operations don’t follow it.
   Fix: embed control steps in SOPs and workflows, and run periodic walk-throughs with owners.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement. Practically, weak control activity selection and development creates predictable outcomes: control failures, inability to evidence compliance, and audit findings that cascade into broader conclusions about internal control effectiveness. Use that reality to prioritize controls tied to your highest-risk objectives and most material processes. ¹

Practical 30/60/90-day execution plan

First 30 days: establish traceability and stop the bleeding

• Confirm objectives and define what “acceptable risk” means for control design decisions.
• Build a risk-to-control mapping for your highest-risk processes (start where failures would be most material).
• Identify controls with missing owners or missing evidence; assign owners and define evidence locations.
• Draft control specs for the top set of key controls.

Where Daydream fits: Use Daydream to centralize the control library, map risks to controls, and standardize evidence requests so control owners produce consistent artifacts without email sprawl.

Days 31–60: standardize control design and make controls testable

• Roll out a control spec template and require it for all in-scope controls.
• Standardize evidence (templates, required screenshots, report exports, ticket fields).
• Document IT dependencies for automated/IT-dependent controls.
• Run walkthroughs with control owners; fix controls that cannot be executed as written.

Days 61–90: prove operation and remediate gaps

• Execute design and operating effectiveness testing for the top controls.
• Open remediation items for control failures; track to closure with re-test evidence.
• Formalize residual risk acceptances where controls are intentionally not implemented.
• Build an audit-ready package: RCM + control library + evidence samples + issue log.

Ongoing: add change triggers (new system, process change, new third party type) that force a review of control activities, so the mapping stays current. ¹

Frequently Asked Questions

What counts as a “control activity” under COSO Principle 10?

A control activity is a specific action embedded in a process or system that prevents or detects a risk event and supports achieving objectives. It must be defined enough that someone can perform it consistently and produce evidence. ¹

Do policies and procedures satisfy the requirement by themselves?

Policies help, but COSO’s expectation is control activities that mitigate risk in practice, with evidence of execution. If the policy does not translate into a performed control with artifacts, expect audit pushback. ¹

How do I show that controls reduce risk to “acceptable levels”?

Document residual risk after controls and show management’s acceptance criteria or sign-off for remaining exposure. The cleanest approach is a risk-to-control mapping with residual risk ratings and approvals. ¹

What’s the fastest way to make manual controls auditable?

Write explicit review criteria, standardize a checklist/template, and require dated sign-off plus retained inputs/outputs. Store evidence in a consistent repository linked to the control in your control library.

How should I handle automated controls that rely on IT systems?

Treat them as IT-dependent controls: document the system configuration that performs the control, the report/query logic if applicable, and key dependencies like access management and change control. Make sure evidence includes configuration extracts or system logs that show operation. ¹

We have strong third-party due diligence, but weak ongoing monitoring. Is that a Principle 10 issue?

Yes, if your risk assessment includes ongoing third-party risk, your control activities must address it with periodic monitoring controls and escalation paths. Map the risk scenario to monitoring controls and retain evidence that monitoring actually happened for your in-scope third parties. ¹

Footnotes

1. COSO IC-IF (2013)