TSC-CC2.2 Guidance

TSC-CC2.2 (“COSO Principle 14”) is where many SOC 2 programs feel deceptively “soft” and then fail in testing. The requirement is simple: your organization must internally communicate information necessary to support internal control. ¹ The operational challenge is harder: deciding what information matters, who needs it, when they need it, and how you will prove it happened consistently across the audit period.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn CC2.2 into a small, enforceable communications control set: (1) a written policy defining control-relevant internal communications; (2) a communications matrix mapping topics to owners, audiences, channels, and timeframes; (3) a ticketed workflow that shows communications were issued and acknowledged; and (4) periodic review to keep the program current as your org, systems, and risks change. ¹

This page focuses on execution: what to build, how to run it weekly, and what evidence to retain so your auditor can test CC2.2 without guesswork.

Regulatory text

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

Operator meaning: You must establish reliable internal pathways for control-related information so people can perform control responsibilities. That includes routine communications (policy updates, role expectations, control procedure changes) and event-driven communications (incidents, control failures, material system changes, emerging risks) that affect how controls operate. ¹

What an auditor will test: Whether you (a) defined what must be communicated, (b) communicated it to the right roles through the audit period, and (c) can produce evidence that communications occurred and were integrated into operations (for example, procedures were updated, access was changed, incidents were triaged, or exceptions were tracked). ¹

Plain-English interpretation (tsc-cc2.2 guidance requirement)

If internal controls depend on people doing the right things, those people need timely, accurate information about what to do and what changed. TSC-CC2.2 expects you to run internal communications as part of your control environment: clear messages, assigned owners, defined audiences, and proof of execution. ¹

A practical interpretation you can implement:

• Control-relevant information exists (policies, procedures, risk decisions, incident learnings, control exceptions).
• It has an owner accountable to publish/communicate.
• It reaches specific internal audiences (engineering, IT, HR, support, security, finance, leadership) with a defined channel.
• It is traceable: you can show what was communicated, when, to whom, and what follow-up happened. ¹

Who it applies to

Entity scope: Any organization undergoing a SOC 2 audit that includes the AICPA Trust Services Criteria Common Criteria. ¹

Operational context where CC2.2 shows up:

• SaaS companies where engineers operate key controls (deployments, access, change management).
• Cloud/IT operations teams handling logging, monitoring, backup/restore, vulnerability remediation.
• Customer support or Trust/Security teams communicating incident processes and escalation paths.
• HR/People Ops communicating acceptable use, onboarding/offboarding responsibilities.
• Third-party risk processes where business owners must follow intake, due diligence, and renewal steps (even though CC2.2 is “internal,” it supports how you manage third parties operationally). ¹

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

Step 1: Define “control-relevant internal communications”

Create a short standard that answers: “What types of information must be communicated to support internal controls?” Examples you can explicitly include:

• Policy approvals and updates (security policy, access control policy, change management procedure).
• Control procedure changes (new review steps, new tooling, revised evidence requirements).
• Identified control failures and required remediation steps.
• Incident response expectations and lessons learned that change procedures.
• Material system changes that affect controls (new cloud account, new CI/CD pipeline, new IAM provider). ¹

Deliverable: Internal Control Communications Policy/Standard (1–3 pages).

Step 2: Build a communications matrix (the “who needs what” map)

Create a matrix with these minimum columns:

• Topic / trigger (policy change, incident, control exception, tooling change)
• Owner (function accountable to publish)
• Audience (roles, not names)
• Channel (email, Slack/Teams channel, all-hands, ticketing system, intranet page)
• Required timing (e.g., “before effective date,” “within X business days,” “next CAB meeting”)
• Evidence produced (meeting minutes, ticket, screenshot, acknowledgement record) ¹

This matrix becomes your CC2.2 control procedure. Keep it small enough to run.

Step 3: Implement a repeatable publishing and acknowledgement mechanism

Pick mechanisms that produce evidence without extra work:

• Policy management: a system that records version, approver, publish date, and readership/attestations (or a documented manual method with exported logs).
• Operational changes: a change ticket template that includes a required “internal communications completed” field and link to the message.
• Incidents: incident postmortem template with “internal distribution list” and a link to where it was shared. ¹

Practical tip: Avoid relying on “tribal knowledge” channels alone. If you use chat, standardize where messages go (named channel) and how you export/retain transcripts for the audit period.

Step 4: Create monitoring and review

Auditors will ask how you ensure the process doesn’t decay. Implement:

• A periodic review of the communications matrix (ownership, channels, and triggers still correct).
• Sampling checks: pick recent policy changes/incidents and confirm communications and follow-ups exist.
• Exception handling: if a required communication was missed, log it, document the remediation, and prevent recurrence. ¹

Step 5: Test control effectiveness (before the auditor does)

Run an internal “mini-audit”:

• Select a few events (policy update, incident, system change).
• Trace end-to-end: trigger → message → audience → acknowledgement (if required) → operational follow-up.
• Document gaps and corrective actions. ¹

Where Daydream fits (naturally)

If you manage evidence across many tools (ticketing, chat, policy platform, incident tooling), Daydream can serve as the control hub where you map CC2.2 requirements to your communications matrix, assign owners, and track evidence requests so audits don’t turn into screenshot hunts.

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

Design evidence (what you intended to do)

• Internal Control Communications Policy/Standard. ¹
• Communications matrix with owners, audiences, channels, timing, and evidence types. ¹
• Documented procedures/templates (change ticket template, incident template, policy update workflow). ¹

Operating evidence (what actually happened)

• Policy version history and approval records; publication logs; attestations/read receipts where applicable.
• Examples of internal announcements for control-impacting changes (sanitized if needed).
• CAB meeting minutes or change review notes that reference communicated changes.
• Incident communications: timeline entries, internal notifications, postmortem distribution proof.
• Exception log for missed communications and remediation actions.
• Periodic review records (agenda, checklist, sign-off). ¹

Evidence hygiene rules you should enforce:

• Store evidence in a system of record with retention aligned to your audit period.
• Name files consistently (date_topic_owner).
• Preserve access so auditors can verify authenticity (read-only exports or system logs).

Common exam/audit questions and hangups

Auditors tend to probe these areas for CC2.2: ¹

1. “How do you decide what must be communicated internally?” They want your definition and triggers.
2. “Who receives which messages?” Expect scrutiny on role-based audiences for engineering, IT, security, and executives.
3. “Show me evidence this happened throughout the period.” One-off examples rarely satisfy; you need repeatability.
4. “How do you know people read/acted on it?” For high-impact topics (policy acknowledgements, incident procedures), attestations or follow-up tickets help.
5. “What happens when you miss a communication?” A documented exception and remediation workflow prevents a control failure from becoming a systemic finding.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating CC2.2 as “security awareness training.”
   Fix: Training can be part of it, but CC2.2 is broader: policy updates, control changes, incidents, and exceptions must be communicated and evidenced. ¹

2. Mistake: No ownership for communications.
   Fix: Assign a named function owner per topic (Security, IT, HR, Engineering Ops) and require backups for coverage.

3. Mistake: Chat-only communications with no retention plan.
   Fix: Standardize an auditable channel and export/retain artifacts, or mirror critical communications in a ticket or email archive.

4. Mistake: Evidence that proves “sent,” not “received.”
   Fix: For critical items, require attestations, meeting minutes with attendance, or follow-up tasks assigned and completed.

5. Mistake: No periodic review, so the matrix drifts.
   Fix: Put the review on a governance calendar and record outcomes. ¹

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so “enforcement cases” are not the right lens for CC2.2 based on the provided sources. ¹ The practical risk is an audit finding: if internal control information is inconsistently communicated, controls can fail silently. That drives downstream risks: security incidents handled inconsistently, unauthorized access persisting, and untracked changes making evidence unreliable.

Practical 30/60/90-day execution plan

Days 0–30: Stand up the minimum viable CC2.2 control

• Draft and approve the Internal Control Communications Policy/Standard. ¹
• Build the communications matrix for the controls in scope for your SOC 2 boundary. ¹
• Choose primary channels (policy system + ticketing + one chat channel) and document the “system of record.”
• Create templates: policy update notice, incident internal notification, change ticket “communications complete” checkbox.

Deliverable: a CC2.2 control description your auditor can read in one pass.

Days 31–60: Operationalize and start collecting evidence

• Run the process for real: publish at least one control-relevant communication per category that applies to your org (policy, change, incident/tabletop, exception).
• Implement acknowledgement where appropriate (policy attestations, required read receipts, meeting attendance).
• Set up an evidence repository structure and naming standard.
• Begin an exceptions log (missed comms, late notifications, unclear ownership). ¹

Deliverable: operating evidence across multiple events, not a single example.

Days 61–90: Monitor, test, and harden

• Conduct a periodic assessment of CC2.2 operations (sample recent communications and trace follow-through). ¹
• Close gaps: missing audiences, unclear triggers, weak evidence, inconsistent retention.
• Train control owners on “what evidence to produce by default.”
• Prepare an auditor-ready packet: policy, matrix, samples, review records, exception log, and remediation notes.

Deliverable: an audit-ready narrative that links communications to control operation.

Frequently Asked Questions

Does CC2.2 require employee attestations for every policy?

No. CC2.2 requires internal communication that supports internal control; attestations are one way to prove receipt for high-impact topics. Use attestations selectively where lack of awareness would cause control failure. ¹

Can Slack/Teams messages count as evidence?

Yes, if you can show the content, date, channel, and intended audience, and you retain it in an auditable way for the period. For critical communications, pair chat with a ticket, meeting record, or formal announcement archive. ¹

How do we scope “internal communication” for a small company?

Keep the matrix small: define a few triggers (policy changes, incidents, material system changes, control exceptions), set a consistent channel, and ensure leadership and control operators receive messages. Your auditor needs consistency and evidence more than volume. ¹

What counts as “information necessary to support internal control”?

Information that changes how a control is performed, who performs it, or what “good” looks like, plus information about failures or risks that require control adjustments. If a reasonable control owner would need it to do their job, include it. ¹

Our controls are run by Engineering. How do we satisfy CC2.2 without spamming them?

Route communications through existing engineering mechanisms: change tickets, CAB notes, release processes, and a single owned channel for control announcements. Make “communications complete” part of the workflow instead of separate broadcasts. ¹

What’s the fastest way to fail CC2.2 in a SOC 2 audit?

Having a policy that claims you communicate control updates, but no consistent artifacts showing it happened across the period, or having evidence that only one person knew about control changes. Auditors treat that as a control design or operating failure. ¹

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