Controls27 April 2026 6 min read

CC2: Communication and Information Controls for SOC 2

SOC 2 CC2 requires internal and external communication of security policies. Learn what auditors check and what evidence to prepare.

Key Takeaways

CC2 covers how the organization communicates security responsibilities internally and externally.
CC2.2 requires a communication channel for employees to report concerns — a whistleblower mechanism satisfies this.
CC2.3 requires external communication: your privacy policy, terms of service, and customer-facing security documentation.
Policy acknowledgment records are the primary CC2.1 evidence artifact.
Vendor and customer security communication (sub-processors list, security page) directly addresses CC2.3.

In this guide

What Is CC2?
CC2.1: Internal Communication
CC2.2: Reporting Channels
CC2.3: External Communication
CC2 Evidence Checklist
Building a Security Page for CC2.3

What Is CC2?

CC2 is the Communication and Information component of the COSO framework as applied to SOC 2. It has three sub-criteria: CC2.1 (internal information), CC2.2 (internal communication of roles), and CC2.3 (external communication with third parties).

The core question CC2 asks is: does the organization communicate security and compliance requirements clearly, both to employees and to external parties like customers and vendors? Controls can exist on paper, but if employees don't know what they're supposed to do, or customers can't find your security policies, the control environment is incomplete.

CC2.1: Internal Communication of Information

CC2.1 requires the entity to obtain and use relevant quality information to support the functioning of internal control. In practice, this means security policies must be documented, versioned, and accessible to employees who need them.

Evidence for CC2.1 includes a policy library (Notion, Confluence, or a GRC tool like AuditPath), version history showing policies are reviewed and updated, and access logs or distribution records showing employees can access them. If policies are stored in a locked folder that only the IT team can reach, they don't satisfy this criterion.

Auditors will ask to see your information security policy, access control policy, and incident response policy as baseline CC2.1 evidence. They will also check that these policies are linked or referenced in employee onboarding.

CC2.2: Reporting Channels for Control Concerns

CC2.2 requires internal communication channels that allow employees to report control deficiencies, concerns about unethical behavior, or security incidents. This sub-criterion overlaps with CC1.1 (code of conduct) and CC7 (incident response).

A whistleblower policy with a named reporting channel — an email address like security@yourcompany.com, an anonymous form, or a dedicated Slack channel — satisfies the mechanism requirement. The policy should document who receives reports, how they are investigated, and non-retaliation protections.

Auditors will check that the reporting channel is communicated to employees (mention in the code of conduct or annual training) and that at least one test or real report has been processed during the audit period.

CC2.3: External Communication with Customers and Vendors

CC2.3 requires the entity to communicate relevant information to external parties, including customers, regulators, and vendors. For a SaaS company, this primarily means: a public privacy policy, terms of service, a security page or trust center, and sub-processor documentation.

The security page (often at yourcompany.com/security) should document your security program, certifications, penetration testing cadence, and how to report vulnerabilities. It does not need to be exhaustive, but it must exist and be accessible without authentication.

For vendor communication, your vendor contracts should include security requirements (data processing agreements, right-to-audit clauses). Auditors will sample 2-3 vendor contracts to verify these provisions exist.

CC2 Evidence Checklist

Internal (CC2.1): policy library with version history, employee acknowledgment records, links in onboarding checklist.

Reporting channel (CC2.2): whistleblower policy, documentation of the reporting mechanism, evidence it was communicated (training records or handbook reference).

External (CC2.3): URL and screenshot of public privacy policy, security page, and terms of service. DPA template used with customers. Sub-processor list or documentation. Sample vendor contracts with security provisions.

Building a Security Page for CC2.3

A minimal security page for CC2 compliance should include: your SOC 2 report availability (even if under NDA), encryption standards (TLS 1.2+ in transit, AES-256 at rest), infrastructure provider (AWS, GCP), backup and recovery policy, penetration testing cadence, and a security contact or vulnerability disclosure email.

Trust center platforms like Vanta Trust, Secureframe Trust, or a simple static page on your website all satisfy CC2.3. The key is that external parties can find your security posture without having to email your sales team.

Frequently Asked Questions

Does CC2 require us to share our SOC 2 report publicly?

No. CC2.3 requires you to communicate relevant security information externally, but your SOC 2 report itself is confidential and is typically shared under NDA with customers who request it. Your security page or trust center satisfies the external communication requirement.

What if we use Slack for internal security communication — does that count?

Slack can satisfy the communication channel requirement for CC2.2 if the channel is documented as the official reporting mechanism in your security policy. You would need to show that employees know about it and that reports are tracked and followed up.

Is a DPA (Data Processing Agreement) required for CC2.3?

A DPA is required if you process personal data on behalf of customers — which most SaaS companies do. For SOC 2, CC2.3 looks for evidence of appropriate external communication about security and data handling. A standard DPA template you use with customers directly satisfies this for the data processing context.

How often do we need to review and update policies for CC2.1?

At least annually. Most SOC 2 auditors look for evidence that each policy was reviewed within the last 12 months. The review doesn't have to result in changes — a documented "reviewed, no changes required" with a date and approver signature is sufficient.

Can a Notion page serve as a policy repository for CC2.1?

Yes, as long as it is accessible to all relevant employees and has a version history or last-reviewed date. Notion's page history feature and the ability to share pages with your workspace satisfy both the accessibility and versioning requirements.