CC2.3 SOC 2

SOC 2 CC2.3: COSO Principle 15: Externally Communicates Information

What This Control Requires

The entity communicates with external parties regarding matters affecting the functioning of internal controls. The entity communicates information to external parties to enable them to understand and act on matters affecting the entity's system of internal control.

In Plain Language

Your customers, regulators, and vendors all need to understand how your security posture affects them. When an incident hits or a compliance obligation triggers, the speed and clarity of your external communication directly impacts trust - and in many jurisdictions, it's a legal requirement.

In practice, this includes providing customers with information about your security practices and any incidents that affect them, communicating with regulators about compliance status and reportable events, sharing security expectations with vendors and partners, and maintaining public-facing security documentation like trust pages and status pages.

Auditors evaluate whether you've established channels for external security communication, whether you meet notification obligations to customers and regulators when incidents or changes occur, and whether external parties receive enough information to understand how your controls affect them. For service organisations whose customers depend on their security posture, this is especially scrutinised.

How to Implement

Write a formal external communication policy defining what security information you share with external parties, through what channels, and under what circumstances. Cover routine communications (security documentation, compliance certifications), event-driven communications (incident notifications), and regulatory communications (breach notifications).

Create and maintain public-facing security documentation: a trust centre or security page on your website, security whitepapers or FAQs, compliance certifications and attestation reports (like SOC 2 reports), and a data processing agreement or security addendum for customer contracts. Keep it current and easy to find.

Build an incident notification process for external parties. Define the criteria triggering customer and external notifications, the timeline, the content and format, and who's authorised to send them. Make sure the process complies with applicable breach notification laws and contractual obligations.

Set up a process for communicating security requirements to vendors and third parties. Include security questionnaires or assessments during vendor onboarding, contractual security requirements, and ongoing communication about shared security responsibilities.

Maintain a system status page showing real-time availability and any active incidents. This demonstrates transparency and helps customers manage their own risk when your services are affected.

Create a process for handling inbound external security inquiries - customer security questionnaires, due diligence requests, vulnerability reports. Designate responsible individuals, set response time targets, and keep records of all external security communications.

Evidence Your Auditor Will Request

External communication policy defining information sharing with customers, regulators, and vendors
Public-facing security documentation (trust center, security page, compliance certificates)
Incident notification procedures and records of notifications sent to affected external parties
Vendor security communication records including requirements and assessment results
System status page and records of external security inquiry responses

Common Mistakes

No formal process for notifying customers of security incidents that may affect them
Security documentation shared with customers is outdated and does not reflect current practices
Breach notification timelines are not defined or do not comply with applicable regulatory requirements
No mechanism for external parties to report security concerns or vulnerabilities to the organization
Vendor communications lack clear security requirements and expectations

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.5	Related
ISO 27001	A.5.6	Partial overlap
nist-csf	GV.OC-05	Related

Frequently Asked Questions

How quickly must we notify customers of a security incident?

It depends on your contracts and applicable regulations. GDPR requires notification within 72 hours; other regulations vary. Best practice is to notify affected parties as soon as reasonably possible once you understand the scope and impact. Define specific timelines in your incident response plan and customer agreements - don't leave it ambiguous.

Should we share our SOC 2 report with anyone who requests it?

SOC 2 reports are typically shared under NDA with current and prospective customers who need to evaluate your security posture. They shouldn't be made public. Set up a process for managing report requests: verify the requester's identity and get a mutual NDA in place before sharing the full report.

Do we need a public vulnerability disclosure program?

SOC 2 doesn't strictly require one, but having a vulnerability disclosure programme (or at least a security.txt file) shows maturity and transparency. It gives external researchers and users a way to report security concerns to you, which aligns well with the principle of receiving and acting on external security information.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment