The Conventional Wisdom
If you're managing SOC 2 or ISO/IEC 27001 compliance, you've likely heard it: incident response requires a communication plan. Auditors expect documented procedures for notifying customers, regulators, and stakeholders. Your framework maps probably link ISO/IEC 27001 Clause 5.3 (organizational roles and responsibilities) and Clause 16.1 (management of information security incidents) to communication protocols. You've got templates for breach notifications, escalation matrices, and stakeholder contact lists.
The assumption is straightforward: when something goes wrong, you need to tell people about it quickly and clearly. Manchester Airports Group's recent breach affecting 8.7 million customers seems to validate this view. They contacted affected customers, issued a public statement, notified authorities, and provided specific guidance about what data was compromised.
But here's the problem: most organizations are building communication strategies for incidents that haven't happened yet, based on assumptions about what customers and regulators actually need to hear.
Why a Decision Framework is Better
Your incident response plan doesn't need a communication strategy. It needs a decision framework.
The difference matters. A communication strategy assumes you know what you'll say before the incident occurs. You've drafted templates, defined timelines, and assigned spokespeople. When the breach hits, you fill in the blanks and send.
But consider what actually drives communication requirements:
The regulatory clock starts when you discover the breach, not when it occurs. GDPR Article 33 requires notification to supervisory authorities within 72 hours of becoming aware of a breach. ISO/IEC 27001 Clause 16.1.5 requires you to assess and respond to information security incidents but doesn't prescribe communication timelines. SOC 2 CC7.4 expects you to communicate security events to appropriate parties, but "appropriate" depends entirely on the incident's nature and impact.
The type of data compromised determines your obligations, not your templates. Manchester Airports Group emphasized that payment details weren't exposed. That's not just reputation management; it's a materiality assessment. If the breach had included payment card data, PCI DSS notification requirements would've kicked in. If it had exposed health information in a jurisdiction covered by HIPAA, different rules apply. Your communication strategy can't anticipate which regulatory framework will govern until you know what data you've lost.
Customers need actionable guidance, not just reassurance. MAG told customers to watch for suspicious communications and reminded them the company would never request payment details unexpectedly. That's useful. Contrast that with the boilerplate "we take security seriously" language that appears in most breach notifications. One helps customers protect themselves. The other protects your legal department.
The Evidence
Review your current incident response documentation. If it includes pre-written notification templates, ask yourself: can you actually use them?
ISO/IEC 27001 Clause 16.1.4 requires you to evaluate information security events and determine if they constitute incidents. That evaluation depends on your risk assessment (Clause 6.1.2) and your information security objectives (Clause 6.2). You can't template that analysis.
SOC 2 Trust Services Criteria CC7.3 requires you to identify, analyze, and respond to security events. The "analyze" step matters. It's where you determine scope, assess impact, and identify which controls failed. Only after that analysis can you know who needs to be notified and what they need to know.
Consider what Manchester Airports Group actually did: they contained the risk first, then brought in specialist advisors, then contacted affected customers. The sequence matters. They didn't blast out a notification the moment they detected the breach. They gathered facts, assessed scope, and determined what information would actually help customers.
What to Do Instead
Build an incident classification framework that drives communication decisions in real time.
Define materiality thresholds based on your risk register. Your ISO/IEC 27001 risk treatment plan (Clause 6.1.3) already identifies which information assets matter most and what level of impact would be unacceptable. Use those same criteria to determine when external notification is required. If you've assessed that exposure of contact information represents a low risk but exposure of authentication credentials represents a high risk, your communication obligations differ.
Map regulatory notification requirements to data types, not incident types. Don't create a generic "data breach notification procedure." Create a decision tree: if PII is exposed, check GDPR/CCPA requirements; if payment data is exposed, check PCI DSS; if the incident affects system availability for customers, check your SLA notification requirements. Each data type carries different obligations.
Document your assessment process, not your communication content. Your incident response procedure should specify how you'll determine scope, assess impact, identify affected parties, and evaluate regulatory obligations. ISO/IEC 27001 Clause 16.1.7 requires you to retain documented information about incidents. That documentation should show your decision process: how you classified the incident, which frameworks applied, why you chose specific notification channels, and what information you determined was relevant to affected parties.
Replace notification templates with information requirements checklists. What does a customer need to know to protect themselves? What does a regulator need to assess your response? What does your board need to evaluate business impact? List the questions each stakeholder will ask, then gather that information before you communicate anything.
When Communication Strategies Are Necessary
Communication strategies do matter in one specific scenario: managing expectations during an ongoing incident.
Manchester Airports Group took their Manage My Booking portal offline as a precaution. They told customers to call instead and warned that wait times would be longer than usual. That's not incident notification; it's operational communication. Your customers need to know when services are unavailable and what alternatives exist.
If your incident disrupts operations, you do need pre-planned communication channels. That might mean a status page, a dedicated customer service line, or social media monitoring. These aren't breach notification procedures; they're business continuity communications covered under ISO 22301 or your SOC 2 availability commitments.
The conventional wisdom also holds when you're dealing with major nonconformities during surveillance audits. If your auditor identifies gaps in your incident response process (ISO/IEC 27001 Clause 10.1), you'll need to demonstrate corrective action. Having documented communication procedures shows you've thought through stakeholder management. But those procedures should document your decision framework, not script your messages.
Your incident response plan should help you make better decisions under pressure, not give you something to hide behind when those decisions turn out to be wrong. Focus on building the judgment framework, not the press release template.
