SOC 2 CC2: communication and information
CC2 is three criteria about whether security expectations actually reach people, inside the company and outside it.
CC2 has three criteria. CC2.1 asks that you obtain and use quality information to support internal control, CC2.2 that you communicate security objectives and responsibilities internally, and CC2.3 that you communicate with external parties about matters affecting internal control. In a first audit, CC2.2 is satisfied almost entirely by policy acknowledgement records and onboarding materials, CC2.3 by your contracts, status page and security page, and CC2.1 by whatever dashboards and reports your team already looks at.
It is the family people underestimate, because none of it sounds like security. A company with good habits and no paperwork loses marks here: you do communicate this stuff, in Slack, verbally, in a founder's head. None of that samples.
Who has to be told what?
| Audience | What they must be told | Evidence | Criterion |
|---|---|---|---|
| Every employee and contractor | The policy set, their security responsibilities, how to report an incident | Timestamped acknowledgement per person, onboarding checklist | CC2.2 |
| Engineers specifically | Secure development expectations, secrets handling, review requirements | Role-based training records, the development policy itself | CC2.2 |
| Management and oversight | Control performance, incidents, risk register changes | Dated review notes, deficiency log | CC2.1 |
| Customers | Security commitments, subprocessors, incident notification terms | Signed agreements, DPA, public subprocessor list, status page history | CC2.3 |
| Vendors and subprocessors | Your security requirements of them | Contract clauses, security schedules, review records | CC2.3 |
| Anyone reporting a problem | How to reach you about a vulnerability or concern | A published security contact address and the ticket trail behind it | CC2.3 |
What counts as quality information under CC2.1?
CC2.1 is the vaguest criterion in the family and the one auditors interpret most differently. It asks that the information used to run internal control is relevant and of sufficient quality. An auditor is looking for evidence that the people making security decisions had something in front of them: a vulnerability report, a log of alerts, an access list export, a metrics dashboard. If every security decision at your company was made from memory, CC2.1 has no artifact.
The cheapest way to satisfy it is to make one existing artifact into a recurring input. If your team already reviews a dependency scan every Monday, retain the report and the note that says who looked at it. That single habit gives you CC2.1 evidence, feeds CC4 monitoring, and doubles as part of the evidence set for CC7.
What does CC2.3 mean for a Canadian company selling into the US?
External communication is where Canadian privacy law and your US customer's security review meet, and they ask for the same things in different words. PIPEDA's openness and accountability requirements expect you to be able to tell an individual what you do with their personal information and who you have given it to. Your US enterprise customer's vendor security review asks for a subprocessor list, a breach notification commitment and a named security contact. One published page and one contract schedule satisfy both.
If you hold personal information about people in Quebec, Law 25 adds a named privacy officer whose contact details are published, and confidentiality settings that default to the most private option. Both of those are external communications in the CC2.3 sense as well as statutory obligations, so write them once and cite them in both places. The Law 25 overview on GetAudited covers the statute itself; what matters here is that the published privacy officer is the same person your system description names.
Slack is not a communication control
A message in a channel is not evidence that a person received and understood a policy, because you cannot produce a per-person record and you cannot show the message was still there in month six. Auditors sample people, not channels. Anything you need to evidence under CC2.2 has to produce a row per person with a date.
Build CC2 in an afternoon
- Pick one acknowledgement mechanism for the whole policy set, so a new hire signs once and produces one dated record.
- Write the incident reporting instruction into the onboarding checklist, in the words a non-engineer would use.
- Publish a security page with a contact address, a subprocessor list and your notification commitment.
- Add a security schedule to your customer agreement template, if the contracts do not already carry one.
- Nominate the recurring report that becomes your CC2.1 input, and start retaining it with a reviewer name on it.
0 of 5 done ·
Most of what CC2.2 needs is produced as a by-product of the policy work, so if you are running the two families together the policy checklist tool will tell you which documents you need before you build the acknowledgement flow around them.
Get CC2 documented once, properly
CC2 is mostly writing things down that already happen. A readiness firm gets it done in days rather than quarters. Send your scope and compare who is available.
Get matchedCommon questions
How many criteria are in CC2?
Three: CC2.1 on information quality, CC2.2 on internal communication and CC2.3 on external communication. They map to COSO principles 13 through 15.
Do we need a public trust or security page for SOC 2?
Not strictly. CC2.3 requires that you communicate relevant security matters to external parties, and contract terms plus a subprocessor list sent on request will satisfy it. A public page is simply the cheapest way to do it once instead of forty times, and it answers part of a US buyer's security questionnaire before they send it. What a US buyer asks for besides the report lists the rest.
Does a status page count as CC2.3 evidence?
Yes, particularly if you have taken the availability category, where incident and outage communication is directly relevant. Keep the history rather than only the current state, because the auditor will want to see what you told customers during the observation window.
Our policies are acknowledged in an HR tool. Is that enough?
Usually yes, provided the export shows the person, the document version and the timestamp. The failure is an HR tool that records the acknowledgement but not which version of the policy was acknowledged, which leaves you unable to show that people saw the version in force during the window.
Who is the audience for CC2 if we are fully remote with no managers?
Everyone with access to the system in scope. Flat companies still have to show that responsibilities were communicated and acknowledged; the absence of a management layer changes who sends the message, not whether a record exists.