COSO Principle 14: The entity internally communicates information necessary to support the functioning of internal control

COSO Principle 14 (SOC 2 TSC-CC2.2) requires you to establish reliable internal communication so people get the right control-related information, in time, to perform their responsibilities. Operationalize it by defining control communications (what/when/how/who), running them through owned channels, and retaining evidence that messages were issued, received, and acted on. ¹

Key takeaways:

• Build a control communication inventory mapped to your SOC 2 control set and operating cadence. ¹
• Prove operation with audit-ready artifacts: announcements, attendance, acknowledgements, tickets, and exception follow-up. ¹
• Treat “internal communication” as a control with owners, SLAs, escalation paths, and monitoring, not a soft practice. ¹

A SOC 2 program fails in quiet ways when internal control information doesn’t move: policy changes land in a doc repository but never reach engineers; incident learnings stay in a postmortem folder; access review exceptions don’t reach system owners; third-party risk decisions don’t reach procurement and get bypassed. COSO Principle 14 addresses that operational reality by requiring the entity to internally communicate information necessary to support the functioning of internal control. In SOC 2 terms, this is TSC-CC2.2. ¹

For a Compliance Officer, CCO, or GRC lead, the objective is straightforward: define the internal communications that your control environment depends on, ensure they happen on a predictable cadence through controlled channels, and retain evidence that they occurred and drove action. Auditors typically don’t accept “we tell people in Slack” unless you can show what was communicated, to whom, by whom, and what happened next.

This page gives requirement-level implementation guidance you can execute quickly, with practical artifacts, common audit hangups, and a 30/60/90 plan focused on building durable evidence for the coso principle 14: the entity internally communicates information necessary to support the functioning of internal control requirement. ¹

Regulatory text

Excerpt (SOC 2 / TSC-CC2.2): “COSO Principle 14: The entity internally communicates information necessary to support the functioning of internal control.” ¹

What this means for operators (what you must do):

• Identify the internal information that enables your internal controls to operate (policies, procedures, risk decisions, exceptions, incidents, role changes, system changes, and control performance issues). ¹
• Ensure that information is communicated to the right roles (control owners, operators, approvers, system owners, management) through channels people actually use and that you can evidence. ¹
• Communicate with sufficient frequency and timeliness so controls are executed as designed, especially when something changes (new system, new third party, major release, new risk acceptance). ¹
• Retain evidence of the communication and, where relevant, evidence that recipients understood and acted (acknowledgements, meeting minutes, ticket execution, exception remediation). ¹

Plain-English interpretation

Principle 14 is the “control nervous system” requirement. If people don’t receive control-relevant information, your controls become optional and inconsistent. This requirement expects structured internal communications that support:

• Awareness: people know what the rules are (policies/standards) and when they change.
• Execution: people know what to do (procedures, runbooks, checklists) and when to do it (cadence, triggers).
• Escalation: people know how to raise issues (control exceptions, incidents, risk acceptances) and who decides.
• Feedback loops: issues identified in monitoring, audits, or incidents get communicated back to owners for remediation. ¹

Who it applies to (entity and operational context)

This applies to service organizations seeking SOC 2 reporting under the AICPA Trust Services Criteria. ¹ In practice, it applies across:

• Control owners (security, IT, engineering, HR, legal, finance, privacy, procurement).
• Control operators (people running user access reviews, change management, incident response, onboarding/offboarding, vulnerability management).
• Management/oversight (executive leadership, risk committees).
• Shared responsibility teams (product teams whose systems are in scope for SOC 2).

Operational contexts where TSC-CC2.2 gets tested hard:

• High-growth orgs with frequent role changes and new hires.
• Distributed teams using multiple communication tools without governance.
• Environments with many systems and third parties where decisions and exceptions are easy to lose.
• Organizations with strong policies but weak execution evidence. ¹

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

Step 1: Define “control-relevant information” for your environment

Create a short list of communication topics tied to control operation. Start with:

• Policy and standard updates (security, access control, SDLC, incident response).
• Control schedule communications (quarterly access reviews, annual BCP tests, vendor reviews).
• Risk decisions (risk acceptances, compensating controls, exceptions).
• Security events and learnings (incidents, near-misses, postmortem actions).
• Material system/architecture changes affecting scope and controls. ¹

Deliverable: Internal Control Communications Taxonomy (one page).

Step 2: Map topics to audiences, owners, channels, and triggers

Build a Control Communications Matrix with columns:

• Topic
• Trigger (cadence or event-based)
• Sender/owner (role, not a person)
• Audience (roles/teams)
• Channel (ticketing system, email distro, HRIS workflow, GRC tool task, all-hands deck, security training platform)
• Required evidence (link type, screenshot type, export type)
• Escalation if not completed (who gets notified) ¹

Practical tip: Prefer channels that already produce logs (ticketing, HRIS tasks, training assignments) over informal chat threads.

Step 3: Standardize message formats so they’re auditable

Create templates:

• Policy change notice: what changed, effective date, required actions, who to contact.
• Control performance notice: control name, due date, assigned owner, completion criteria.
• Exception notice: what’s noncompliant, approved by whom, expiration date, tracking ticket.
• Incident learning notice: summary, required procedural changes, due dates for action items. ¹

Deliverable: a small template library stored in your controlled document repository.

Step 4: Implement acknowledgement where it matters

Not every message needs an acknowledgement. Use acknowledgements for:

• New/updated policies that require behavior change.
• Role-based procedures (on-call, deploy approvals, access provisioning).
• High-risk exceptions with expiration dates. ¹

Evidence options:

• Training platform completion/attestation export.
• HRIS “read and acknowledged” workflow.
• Ticket comment or checkbox acknowledgement tied to the assignee.

Step 5: Build communications into existing operational workflows

Avoid creating a parallel “compliance comms” process. Embed communications into:

• Change management: release approvals include linking the relevant standard/runbook.
• Joiner/mover/leaver: onboarding includes required security policy attestations.
• Incident response: post-incident action items include “communicate updated procedure” as a tracked task.
• Third-party onboarding: procurement workflow includes required internal approvals and risk decision distribution. ¹

Step 6: Monitor completion and chase exceptions

Principle 14 becomes real when you track whether communications happened:

• Weekly or biweekly check on overdue communications tasks (policy acknowledgement lag, overdue review notices, unassigned action items).
• Escalation path for repeated misses (manager notification, risk register entry). ¹

This is where tools like Daydream fit naturally: you can assign control communication tasks, collect acknowledgements and artifacts, and keep an auditor-ready trail without assembling evidence from five systems at the end of the period.

Required evidence and artifacts to retain

Auditors need evidence of both design (your process exists) and operation (it happened during the period). Retain:

• Control communications policy/procedure describing internal control communications approach, roles, and channels. ¹
• Control Communications Matrix (topic-to-audience mapping).
• Message artifacts: emails, memo PDFs, screenshots of announcements, intranet posts, Slack/Teams exports where feasible.
• Distribution proof: email logs, distro membership list, training assignment records.
• Acknowledgements: training completion exports, signed attestations, HRIS acknowledgements, ticket acknowledgements.
• Meeting evidence: agendas, minutes, attendance lists for governance meetings where control issues are discussed.
• Follow-through proof: tickets created from communications, closure evidence, exception remediation, updated runbooks. ¹

Storage rule: keep artifacts in a system with access control and retention that matches your audit period needs.

Common exam/audit questions and hangups

Expect these questions in SOC 2 walkthroughs and testing:

• “How do you ensure control owners know their responsibilities and deadlines?” ¹
• “Show me evidence that the updated security policy was communicated internally and acknowledged.” ¹
• “How are control exceptions communicated and tracked to closure?” ¹
• “Which channels are authoritative for control communications?” ¹
• “How do you communicate incidents and required control changes to affected teams?” ¹

Hangups that create findings:

• Communications exist but aren’t mapped to controls.
• Evidence is scattered and not reproducible.
• Messages are posted, but there is no proof anyone saw them.
• No escalation when required comms don’t happen. ¹

Frequent implementation mistakes and how to avoid them

1. Relying on informal chat as the system of record
   Fix: designate authoritative channels (ticketing + email + controlled wiki) and export evidence when chat is used. ¹

2. Over-communicating without tracking outcomes
   Fix: require “communication-to-action” linkage for high-impact items (ticket created, procedure updated, acknowledgement recorded). ¹

3. No ownership for communications
   Fix: assign a role owner per communication type and define backup coverage. ¹

4. Policies updated without an effective-date and training/attestation plan
   Fix: add a standard change notice template and an acknowledgement workflow for material changes. ¹

5. Evidence created only during audit season
   Fix: add lightweight monthly evidence capture (export logs, save PDFs/screenshots, store in a SOC 2 evidence folder or Daydream). ¹

Risk implications (why this fails in practice)

If internal control information doesn’t flow, you get:

• Control execution gaps (missed reviews, skipped approvals, incomplete onboarding/offboarding).
• Untracked exceptions that become permanent “shadow policy.”
• Inconsistent incident handling and repeat failures because learnings never reached operators.
• Audit scope disputes because teams don’t know what systems and processes are in scope. ¹

For SOC 2, the practical risk is a report with exceptions or a conclusion that controls were not operating effectively due to missing or insufficient evidence of communication and follow-up. ¹

A practical 30/60/90-day execution plan

Days 1–30: Define and standardize

• Inventory control-relevant communications tied to your SOC 2 control set (policy updates, control deadlines, exception notices, incident learnings). ¹
• Build the Control Communications Matrix and get sign-off from Security, IT, Engineering, HR, and Procurement leads.
• Publish templates (policy change notice, exception notice, control reminder).
• Decide your authoritative channels and where evidence will be stored. ¹

Days 31–60: Run the process and collect evidence

• Execute at least one full cycle: send control reminders, distribute a policy notice (if applicable), hold a governance meeting with documented minutes.
• Turn on acknowledgements for one high-impact policy or role-based procedure.
• Implement an escalation rule for overdue comms tasks (manager ping + ticket).
• Centralize evidence capture (folder structure or Daydream evidence tasks). ¹

Days 61–90: Prove operation and tighten weak points

• Perform an internal “mini-audit”: pick a sample of communications and verify you can show sender, audience, timing, and outcome.
• Fix the top two evidence gaps (commonly distro proof and acknowledgement logs).
• Add a recurring management review of control communications completion and exceptions.
• Update training/onboarding workflows so new hires receive required control communications automatically. ¹

Frequently Asked Questions

Do we need employee acknowledgements for every policy?

No. Focus acknowledgements on policies and procedures that drive required behavior for in-scope controls, or where you’ve had repeat findings. For other communications, retain distribution evidence and make the policy easily accessible. ¹

Will Slack or Teams messages count as evidence?

They can, but auditors often ask for completeness and retention. If you use chat, define it as a permitted channel, capture exports or screenshots with date/time and audience, and link messages to tickets or documented actions. ¹

How do we show “the right people” received the message?

Maintain controlled distribution lists or group membership records for each audience and retain those records with the message artifact. For role-based comms, route through ticket assignments or training enrollments tied to HR role data. ¹

What’s the fastest way to operationalize this for a SOC 2 audit already scheduled?

Start with the Control Communications Matrix, then implement evidence capture for recurring control reminders and exception communications. You can backfill limited prior-period evidence if it exists, but prioritize creating a repeatable process now. ¹

How does this connect to incident response and postmortems?

Treat “lessons learned” as control-relevant information. Require a tracked action item for any procedure change, and distribute the update to affected operators with evidence of the communication and closure. ¹

Where does Daydream fit without adding overhead?

Use Daydream to assign communication-related control tasks, collect message artifacts and acknowledgements, and keep evidence organized by control and period. The goal is fewer ad hoc evidence requests and less manual stitching across systems. ¹

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