Principle 14: Communicates internally to support controls

Principle 14: communicates internally to support controls requirement means you must establish, document, and run reliable internal communication channels so control owners and operators receive the right information, at the right time, in a usable form, to design, perform, escalate, and evidence internal controls. Operationalize it by defining control ownership, required messages, delivery mechanisms, escalation paths, and proof of communication.

Key takeaways:

• Build a control-to-communication map: each key control has an owner, audience, message, cadence trigger, and escalation route.
• Treat “communication” as a control dependency: if people do not receive instructions or exceptions, the control is not operating.
• Keep evidence: artifacts must show what was communicated, to whom, when, and how it affected control execution.

A control can be well-designed on paper and still fail in practice because the people responsible for operating it never received the policy update, did not understand a new approval threshold, or did not know how to escalate an exception. Principle 14 is COSO’s way of making internal communications auditable: information must flow across the organization so internal controls are executed consistently and issues are surfaced quickly. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest route to implementation is to stop thinking of internal communications as general “culture” work and start treating it as a concrete enablement layer for specific controls. That means you define who needs what information to perform a given control, how they will get it, how they confirm receipt/understanding where needed, and what happens when the information indicates a control failure or exception.

This page gives requirement-level guidance you can apply immediately: scope, roles, a step-by-step build, evidence to retain, common audit questions, and a practical execution plan. It also frames where tools like Daydream fit naturally: maintaining the control-to-communication mapping, automating evidence capture, and keeping auditors out of your inbox.

Regulatory text

Framework excerpt (provided): “COSO internal control principle 14 implementation expectation.”
Principle summary: “Principle 14: Communicates internally to support controls.” ²

Operator meaning (what you must do)

You must implement internal communication processes that:

1. Deliver control-relevant information to the right internal roles (control owners, operators, approvers, reviewers, system admins, and leadership).
2. Support the operation of internal control by enabling people to perform controls as designed and to recognize and escalate exceptions.
3. Create evidence that communication occurred and was effective enough to support control execution (for example, attestation, training completion, ticket workflows, meeting minutes with decisions, or system notifications tied to control events).

COSO does not mandate a single channel (email vs. ticketing vs. policy portal). It expects a functioning system of communication that supports internal control effectiveness. ¹

Plain-English interpretation of the requirement

Principle 14 requires you to answer, in an auditable way:

• What information do people need to run each key control?
• Who must receive it (and who must approve or acknowledge it)?
• How is it delivered and how do you know it was received/understood where that matters?
• How do issues, exceptions, and control failures get escalated quickly and consistently?

A practical test: if a new hire stepped into a control operator role tomorrow, could they find the procedure, know the threshold, understand how to evidence the work, and know how to escalate an exception without relying on tribal knowledge?

Who it applies to (entity and operational context)

Entities: Any organization using COSO as its internal control framework baseline, including public companies, private enterprises, and regulated firms that map internal controls to COSO concepts. ¹

Operational contexts where Principle 14 is commonly tested

• SOX / ICFR environments: controls span finance, ITGC, and application controls; internal comms failures create inconsistent operation across locations or teams.
• Central compliance with distributed operations: policy updates and control changes must reach sites, business units, and subsidiaries.
• High change velocity environments: system migrations, reorgs, and new products; control design changes require controlled internal rollouts.
• Third party-heavy processes: procurement, AP, outsourcing; internal stakeholders must know the control expectations for onboarding, monitoring, and offboarding third parties.

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

Step 1: Set scope around “key controls” and “control-dependent communications”

Define the population:

• Controls in scope for your internal controls program (finance, ITGC, operational, compliance).
• Communications that directly enable those controls (procedure updates, exception criteria, access provisioning instructions, approval matrices, reconciliation standards, evidence requirements).

Deliverable: Control inventory with owners and operators (even if imperfect).

Step 2: Build a Control-to-Communication Map (CCM)

For each key control, capture:

Field	What “good” looks like
Control name / ID	Matches your controls library
Control owner	One accountable role (not a committee)
Control operators	Named team/role(s) who perform it
Required info	Policies, procedures, thresholds, systems, forms
Communication trigger	What causes comms (new control, change, exception trend, system change)
Channel	Policy portal, GRC workflow, ticketing, email distribution list, chat announcement with retention
Acknowledgment need	None / attestation / training completion / workflow approval
Escalation route	Who gets notified when exceptions occur; time expectations can be qualitative
Evidence produced	What artifact proves the communication happened and supported operation

This becomes your core Principle 14 artifact. Daydream is useful here because it can keep the map tied to control ownership, workflow, and evidence requests so it stays current as org charts and controls change.

Step 3: Standardize internal communication “control packets”

Create a reusable template for any control-impacting communication:

• What changed (policy/procedure/control design)
• Why it changed (business/process/system change)
• Who is affected (roles and teams)
• What the recipient must do (steps, effective date, evidence requirements)
• Where to find the procedure and the evidence template
• How to escalate questions/exceptions

Keep it short. Make the action required unmissable.

Step 4: Implement escalation paths that connect to issue management

Principle 14 is not satisfied by broadcasting information if exceptions disappear into inboxes. Tie internal communication to your issue workflow:

• Define what qualifies as a control exception vs. a process question.
• Require that control exceptions enter a tracked system (GRC issue, ticket, audit issue log).
• Ensure the control owner receives exceptions and documents disposition (accept, remediate, redesign control, or train operators).

Evidence: issue tickets, root cause notes, approvals, closure evidence.

Step 5: Add “communication checks” to your control testing

When you test a control’s operating effectiveness, add explicit checks that internal communication worked:

• Operator had the current procedure at the time of execution.
• Operator knew the threshold/criteria and followed it.
• Exceptions were escalated through the defined channel.
• Evidence requirements were understood and met.

This closes the loop: Principle 14 becomes part of control operation, not a separate program.

Step 6: Define recordkeeping rules (what must be retained)

Create a retention standard for internal control communications:

• Where communications are stored (system of record)
• Who can publish changes (ownership and approvals)
• What must be retained for audit: version history, distribution list, acknowledgments, training logs, and any related decisions

Avoid scattered evidence across email, chat, and shared drives without retention controls.

Required evidence and artifacts to retain

Keep artifacts that let an auditor replay the story from control design to operator action:

1. Control-to-Communication Map (CCM) mapped to your key controls.
2. RACI for controls and communications (owner, operator, approver, informed).
3. Current policies and procedures with version history and approval records.
4. Distribution evidence: announcement posts, email distributions, workflow notifications, or ticket broadcasts.
5. Acknowledgments where needed: attestations, training completion logs, policy read-receipts (if used).
6. Meeting minutes and decision logs for control changes, including attendees and outcomes.
7. Issue and escalation records tied to specific controls, with triage and closure evidence.
8. Testing workpapers showing communication checks during control testing.

In practice, Daydream helps by centralizing the CCM, attaching artifacts to the relevant control, and generating audit-ready evidence packets without re-creating the trail.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how control owners communicate changes to operators.”
• “How do you know operators are using the current procedure?”
• “What is your escalation path for exceptions, and show examples.”
• “How do you communicate responsibilities during org changes?”
• “Where is evidence stored, and how do you ensure completeness?”

Hangups that slow exams:

• Evidence exists but is fragmented across tools with no index.
• Policies are current, but operator instructions (job aids, SOPs) lag behind.
• Communications are verbal and leave no trail.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating Principle 14 as “send an annual policy email.”
   Fix: tie communications to control triggers and control execution artifacts.

2. Mistake: no single accountable owner for communication content.
   Fix: assign control owners as accountable for control-impacting communications; compliance supports with templates and review.

3. Mistake: relying on chat posts with weak retention.
   Fix: designate a system of record (policy portal, ticketing, GRC workflow) and treat chat as a pointer, not the record.

4. Mistake: documenting channels but not escalation outcomes.
   Fix: require exceptions to be logged and dispositioned; test the workflow periodically.

5. Mistake: evidence is created only during audits.
   Fix: embed evidence capture into workflows (publishing, attestations, tickets, control execution checklists).

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources, so this page does not list specific enforcement actions.

Operationally, Principle 14 gaps tend to surface as:

• Control failures caused by outdated procedures or inconsistent interpretation across teams.
• Delayed detection of issues because exceptions were not escalated.
• Audit findings for lack of evidence that controls were communicated and understood.

For a CCO/GRC lead, the practical risk is auditability: you may have controls, but you cannot prove the organization was enabled to operate them consistently.

A practical 30/60/90-day execution plan

First 30 days: establish the minimum viable system

• Identify the controls that matter most (financial reporting, ITGC, and high-risk operational controls).
• Assign clear control owners and operator groups for that set.
• Create the first version of the Control-to-Communication Map for those controls.
• Standardize a “control communication packet” template and require it for any control change.

Days 31–60: make communications testable and repeatable

• Implement an escalation workflow for control exceptions with tracked disposition.
• Choose your system of record for communications and evidence; document retention expectations.
• Add communication checks to control testing workpapers.
• Run one tabletop exercise: simulate a control change and validate communications and escalation end-to-end.

Days 61–90: scale and harden

• Expand the CCM to remaining key controls.
• Require acknowledgments where the risk justifies it (high-impact changes, new control owners/operators).
• Build an “audit packet” structure by control (procedure, last change notice, acknowledgments, exceptions, testing results).
• Use Daydream (or your GRC system) to keep ownership, workflows, and evidence linked so the map stays current through personnel and process changes.

Frequently Asked Questions

Do we need employee attestations for every control-related communication?

No. Use attestations selectively for high-risk changes, new controls, or roles with material control responsibilities. For routine updates, a retained distribution record plus accessible procedures is often more workable.

What counts as “internal communication” under Principle 14?

Any internal information flow that enables control execution or escalation, including policy updates, SOPs, approval matrix changes, training, workflow notifications, and issue escalation records. The key is that it supports operation of controls and leaves evidence.

How do we prove people actually received and understood the information?

Match the proof method to the risk. For some communications, a system-of-record publication and access logs may be sufficient; for others, require training completion, workflow approvals, or role-based attestations tied to the change.

We have great policies, but teams still do things differently. Is that a Principle 14 problem?

Often, yes. Inconsistent execution commonly indicates gaps in how procedures are communicated, how exceptions are escalated, or how updates are rolled out and confirmed with operators.

How do we handle communications during reorganizations or turnover?

Treat role changes as a trigger in your CCM. When a control owner/operator changes, require a handoff package: current procedure, evidence examples, open exceptions, and a record that the new owner accepted responsibility.

Can we rely on email alone?

Email can be a channel, but it is rarely a good system of record by itself. Auditors usually want durable version history, consistent distribution logic, and easy retrieval by control; a policy portal or GRC workflow makes that simpler.

Footnotes

1. COSO Internal Control guidance page

2. COSO Internal Control guidance page; Weaver summary of COSO 17 principles