Principle 12: Bases controls on thorough policies and procedures

A common COSO failure mode is “controls by intention”: you have policy language that sounds right, but the control cannot be executed consistently, by different people, across cycles, with traceable evidence. Principle 12 fixes that by forcing rigor at the requirement-to-execution layer. It is where good governance becomes daily operations.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to standardize how you document controls and how you prove they ran. In practice, examiners, auditors, and customers look for the same pattern: clear ownership, a repeatable runbook, and an evidence trail that ties inputs to approvals to outputs. Principle 12 does not demand more controls by default; it demands controls that are actually runnable and auditable.

This page gives requirement-level implementation guidance you can apply immediately: a control-card template, a minimum evidence bundle, and a lightweight health-check cadence that keeps your documentation and execution aligned over time. Sources: COSO’s framework overview materials and summary references for the COSO 17 principles (COSO IC framework overview; COSO Internal Control guidance page; Weaver summary of COSO 17 principles).

Requirement: principle 12: bases controls on thorough policies and procedures requirement (plain English)

You must document and maintain policies and procedures that are detailed enough to implement control activities consistently, and you must keep them aligned to how the business actually operates. A “thorough” procedure answers five operator questions without improvisation:

1. What triggers the control?
2. Who performs it and who approves it?
3. What are the exact steps and decision points?
4. What exceptions are allowed and how are they handled?
5. What evidence proves completion and where is it stored?

If your team cannot show who owns the requirement, how often it runs, or which evidence proves operation, you have a Principle 12 gap (COSO IC framework overview).

Regulatory text

Framework excerpt (provided): “COSO internal control principle 12 implementation expectation.” (COSO Internal Control guidance page; Weaver summary of COSO 17 principles)

Operator interpretation: COSO expects control activities to be implemented through documented policies and procedures that:

• Communicate what must be done and by whom.
• Provide enough direction to produce consistent results.
• Create a reliable audit trail that supports internal and external assurance.

What this means in a walkthrough: If an auditor selects a control (for example, user access reviews), they should be able to (a) read your procedure, (b) observe the control owner perform it as written, and (c) inspect evidence that matches the procedure’s stated outputs.

Who it applies to

Entities: Any organization using COSO as its internal control framework, including public companies (ICFR/SOX contexts), private enterprises, and regulated firms adopting COSO-aligned internal control structures (COSO IC framework overview).

Operational contexts where Principle 12 shows up immediately

• SOX/ICFR and financial reporting controls: reconciliations, journal entry controls, close controls, segregation of duties.
• Security and privacy controls: access provisioning/deprovisioning, vulnerability management, incident response.
• Third-party risk management controls: due diligence, contract approvals, ongoing monitoring, offboarding.
• Operational resilience controls: backup/restore testing, change management, job scheduling and monitoring.

If a control is performed by a third party (for example, a payroll processor), Principle 12 still applies to your organization’s oversight procedure: who reviews reports, how exceptions are resolved, and what evidence you retain.

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

Step 1: Create a control inventory and map it to policy and procedure coverage

• List key controls (financial, operational, compliance, technology).
• For each control, identify the governing policy statement (what “must” happen).
• Confirm there is a procedure/runbook that explains how it happens.

Practical tip: If multiple teams execute the same control differently, treat that as a documentation defect. Principle 12 expects consistency, or a documented rationale for variants (by business line, system, or geography).

Step 2: Build a “requirement control card” for each key control

Create a one-page control card that operators can run without interpretation. This is a fast way to operationalize Principle 12 because it forces completeness.

Control card fields (minimum)

• Control objective: what risk it reduces and what outcome it assures.
• Control description: one paragraph, no buzzwords.
• Owner + backup: named role(s), not just a department.
• Cadence / trigger events: monthly, per change, per new third party, etc.
• Systems and inputs: reports, tickets, logs, data sources.
• Execution steps: numbered steps with decision points.
• Approvals and segregation: who reviews, who approves, what is prohibited.
• Exception handling: what counts as an exception, escalation path, timelines you set internally.
• Evidence bundle: exactly what artifacts are produced and where stored.
• Retention: align to your internal retention schedule.

This approach is directly aligned to recommended practice: “Create a requirement control card with objective, owner, trigger events, execution steps, and exception rules.” (COSO IC framework overview)

Step 3: Define the minimum evidence bundle for each execution cycle

Audits fail more often on evidence than on intent. For each control, define the smallest set of artifacts that proves operation end-to-end.

Minimum evidence bundle (pattern)

• Inputs: source report, system export, queue snapshot, or ticket list used to perform the control.
• Proof of performance: completed checklist, ticket updates, query output, reconciliation worksheet, sign-off.
• Approval/attestation: reviewer sign-off, workflow approval, or meeting minutes showing review occurred.
• Outputs: final report, updated access list, remediation ticket, approved exception.
• Traceability metadata: date/time, performer, reviewer, population covered, and scope boundaries.

This aligns to recommended practice: “Define the minimum evidence bundle for each execution cycle (inputs, approvals, output artifacts, and retention location).” (COSO IC framework overview)

Example (third-party due diligence control)

• Inputs: onboarding request + inherent risk rating worksheet.
• Proof: completed due diligence checklist + questionnaire results.
• Approval: documented risk acceptance/exception approval if gaps exist.
• Output: contract approval record + monitoring tier assignment.
• Location: GRC system record ID + linked repository folder.

Step 4: Convert “tribal knowledge” into procedures people will follow

Write procedures in an operator voice:

• Use numbered steps, not paragraphs.
• Include screenshots or exact report names where helpful.
• Put decision rules in tables (for example, “If risk rating is high, then require security review and legal review”).

Decision table example (exception handling)

Scenario	Allowed?	Required approval	Required evidence
Control missed due to system outage	Yes, with exception	Control owner + manager	Incident ticket + make-up run record
Population incomplete	No	N/A	Rerun required
Reviewer unavailable	Yes, with backup	Backup reviewer	Delegation record

Step 5: Implement recurring control health checks and remediation tracking

Principle 12 is not a one-time documentation exercise. Procedures drift as systems and org charts change.

Set up a lightweight “control health check” process:

• Verify the control card matches current systems, roles, and workflow.
• Sample recent evidence bundles for completeness.
• Confirm exceptions were handled per procedure.
• Track findings to closure with an owner and due date you set internally.

This aligns to recommended practice: “Run recurring control health checks and track remediation items to validated closure with due dates.” (COSO IC framework overview)

Where Daydream fits naturally: If you already run controls in multiple tools (ticketing, IAM, spreadsheets, shared drives), Daydream can centralize control cards, evidence requests, and remediation tracking so you can answer audits without scrambling across systems.

Required evidence and artifacts to retain

Keep artifacts that prove both design (what should happen) and operation (what did happen).

Design artifacts

• Policy documents and approval history.
• Control cards / procedures with version history.
• RACI or responsibility mapping for control ownership.
• Procedure training/enablement records (if you maintain them).

Operating artifacts

• Evidence bundles per execution cycle (as defined on the control card).
• Exception approvals and compensating control documentation.
• Control health check records and remediation tickets through validated closure.

Retention: Follow your internal retention schedule and ensure it covers at least the audit and regulatory lookback periods that apply to your organization. If retention is inconsistent across teams, standardize storage locations and naming conventions first; it is the fastest win during an audit.

Common exam/audit questions and hangups

Auditors and assessors typically probe for these gaps:

1. “Show me the procedure someone follows.”
   Hangup: you provide a policy statement or a risk/control matrix, not an executable runbook.

2. “Who owns this control, and who is the backup?”
   Hangup: ownership is a shared mailbox or a committee, with no accountable operator.

3. “What evidence proves the control operated for the full population?”
   Hangup: screenshots without scope, exports without timestamps, or samples without defined selection logic.

4. “How do you handle exceptions and missed runs?”
   Hangup: exceptions are handled ad hoc, with no documented approval or compensating steps.

5. “How do you keep procedures current?”
   Hangup: procedures were written once for an audit and never reviewed.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Writing procedures that restate policy.
  Fix: force step-by-step actions, required reports, decision points, and evidence outputs on the control card.

• Mistake: Evidence defined after the fact.
  Fix: define the evidence bundle upfront and test it by running a mock audit request against last cycle’s artifacts.

• Mistake: No traceability to population and period.
  Fix: require performers to record period covered, system of record, and population definition in the evidence (for example, “all active users as of date X”).

• Mistake: Ownership without empowerment.
  Fix: assign an accountable owner who can obtain inputs, enforce deadlines, and open remediation tickets.

• Mistake: Treating procedure updates as informal.
  Fix: implement version control and approvals for procedure changes tied to system changes, org changes, and control failures.

Enforcement context and risk implications

COSO is a framework, not a regulator, so Principle 12 is typically “enforced” through:

• External financial statement audits and ICFR/SOX testing programs.
• Customer and partner due diligence (SOC reports, questionnaires, onsite assessments).
• Internal audit and board oversight expectations.

The risk is operational and assurance-based: weak procedures create inconsistent execution, which creates control failures, which can cascade into reporting issues, security incidents, or inability to demonstrate compliance. Principle 12 is where you prevent “we did it, but we can’t prove it.”

Practical 30/60/90-day execution plan

First 30 days (stabilize and standardize)

• Pick a subset of highest-risk controls (financial close, access, change management, third-party onboarding).
• Create control card templates and publish a standard evidence bundle format.
• Run a mini “evidence drill”: request last run’s evidence for each selected control and document gaps.
• Assign accountable owners and backups; confirm they can access required systems and reports.

By 60 days (operationalize and test)

• Convert remaining priority controls into control cards with procedures and exception rules.
• Centralize storage: one system of record for control cards and evidence links.
• Pilot control health checks with internal audit or a second-line review; log remediation items with clear closure criteria.

By 90 days (prove sustainability)

• Expand health checks across the broader control set.
• Implement change triggers: require procedure review when systems change, process owners change, or controls fail.
• Produce an audit-ready package: control inventory, control cards, sample evidence bundles, exception log, remediation log.

(These timeboxes are a practical sequencing suggestion, not a sourced requirement.)

Frequently Asked Questions

Do we need a separate procedure for every control, even automated ones?

Yes for key controls. For automated controls, the procedure can be shorter, but it still must document the system, configuration owner, change controls, and what evidence proves the control ran as intended.

What counts as “thorough” policies and procedures under Principle 12?

“Thorough” means an informed operator can execute the control consistently, including handling exceptions, and produce a defined evidence bundle that proves scope, timing, and approval.

Can a ticketing workflow replace a written procedure?

Sometimes. If the workflow includes the steps, decision points, approvals, and produces retrievable evidence, it can function as the procedure. You still need a control card that explains the workflow, ownership, triggers, and evidence locations.

How do we handle controls performed by a third party?

Document your oversight procedure: what you receive from the third party, how you review it, what exceptions look like, and what you retain. Principle 12 focuses on your ability to execute and evidence your control activities, including oversight.

Our procedures are current, but teams don’t follow them. Is that still a Principle 12 problem?

Yes. If procedures are not used in operations, the control is not reliably performed. Treat it as a control operation issue and either rework the procedure to match reality or change the process to match the procedure.

What’s the minimum we should retain to survive an audit request?

Retain the control card, the last completed evidence bundle, and any exceptions with approvals and closure proof. If you cannot show population, period, performer, reviewer, and output, you will spend audit time rebuilding history.