What the communication plan must actually address

The plan must make it possible to share a reliable situation update while information, tools and responsibilities are still unstable. It is not a pre-written press release, but a decision-making mechanism that works during an outage, Microsoft 365 compromise, ransomware attack, data breach or unavailability of a critical supplier.

Technical incident, cyber incident and data breach

The plan must survive an outage

If the Microsoft 365 tenant, network, IP telephony and password manager all depend on the same environment, the team may simultaneously lose its messages, contacts and procedures. A protected offline copy, a limited crisis directory, verified telephones and an alternative channel then become operational components, not administrative appendices.

The GVISION page dedicated to protection and response to cybersecurity threats presents the technical controls that reduce risk. This guide addresses the human side: maintaining consistent communication when the organisation only has partial facts available.

Organising communication during the first hour

The first hour is about establishing a source of truth, protecting communications and announcing a next update; it is not about definitively explaining the incident. The timeline below is an internal model to be adapted to the severity, working hours and structure of the organisation. These are not legal deadlines.

0 to 15 minutes: open the log and contact decision-makers

Record the detection time, reporter, affected services, actions already taken and uncertainties. Provisionally appoint an incident manager and a communications lead. Activate a backup channel if the integrity of email or Teams is in doubt. Avoid forwarding sensitive screenshots to improvised groups.

15 to 30 minutes: assess the communicable impact

Describe unavailable services, affected groups and required actions. For example: do not restart, do not reconnect to the VPN, do not use an application or keep a device switched on. Have these instructions validated by the technical lead; an incorrect instruction could destroy evidence or extend the incident.

30 to 60 minutes: publish the first useful message

The initial message states what has been observed, the concrete impact, the expected action, the support channel and the time of the next update. It must not attribute the incident, minimise the risk or announce a guaranteed restoration. If no new information is available by the promised time, publish a status update anyway.

Assign roles and decision-making authority

Credible communication requires an owner for each message and a clearly designated approver. A large crisis team without decision-making authority creates delays; a single person combining technical, legal and communications responsibilities creates blind spots.

Incident Manager

They maintain the timeline, arbitrate priorities and confirm the operational version of the facts. They do not necessarily have to be the most experienced technician: their role is to coordinate, protect decision-making capacity and escalate.

Technical owner

They confirm the impact, containment measures, dependencies and restoration scenarios. They provide facts, not public wording. They explicitly state what remains unknown and what cannot be disclosed without compromising the investigation.

Communications, management, legal and DPO

Communications adapts the level of language and maintains consistency across channels. Management decides on commitments with commercial or institutional impact. Legal checks contractual obligations and disclosure risks. The DPO assesses the personal data dimension and advises the data controller; they do not replace the controller's decision.

Deputies and thresholds

Each critical role must have a deputy and an independent means of contact. The plan can provide for three levels: a local incident managed by IT, a major incident requiring management and business teams, and a crisis requiring external communication, legal advice and engagement with authorities. Thresholds should be based on impact, probable duration, data sensitivity and scope, not emotional intensity.

Provide channels that remain available and secure

The primary crisis channel must not depend exclusively on the potentially compromised system. An “emergency” email mailbox in the same tenant is not a genuine backup channel if identity, DNS or Microsoft 365 are affected.

Three spaces, three purposes

• Technical channel: evidence, indicators, containment actions and detailed log.
• Decision-making channel: business impact, decisions, notifications, resources and message approval.
• Information channel: approved messages intended for employees, customers or partners.

This separation limits leaks, prevents a technical hypothesis from being repeated as fact and allows each group to receive the appropriate level of detail. Nevertheless, maintain a shared timeline with the author, time, decision and next action.

Writing useful messages without speculation

Each message must address five points: known situation, impact, expected action, temporary solution and next update. The reader should not have to decode jargon or guess whether they can continue working.

State what is confirmed

Prefer “access to the portal has been unavailable since 09:20” to “we are probably experiencing a sophisticated ransomware attack”. If the confidentiality of the data has not yet been assessed, say so. Distinguish between detection time, estimated start time and time of regulatory awareness.

Give an observable instruction

An instruction such as “stay vigilant” is too vague. Specify the action: do not open a link, use a backup number, work offline, keep the computer switched on or suspend data entry. Specify who is affected and when the instruction will be reassessed.

Avoid absolute promises

Do not say “no data has been stolen” until the analysis establishes this. Do not promise a return to normal by midday if the team does not control all dependencies. A timeframe for the next communication is generally more reliable than a resolution time.

Distinguishing crisis communication, GDPR and NIS2

Operational messages never replace regulatory notification, and not all cyberattacks trigger the same obligations. The organisation must separately assess service availability, any personal data breach, whether an incident is significant under NIS2 and the applicable contractual clauses.

Personal data breach

The Belgian Data Protection Authority states that a breach must be notified to the competent authority without undue delay and, where possible, within 72 hours after becoming aware of it, unless it is unlikely to result in a risk to the rights and freedoms of individuals. The decision, known facts and assessment must be documented. Communication to affected individuals is subject to a separate threshold and content; it must not be improvised by the IT team.

Significant NIS2 incident

For affected Belgian entities, the CCB describes a phased notification process: an early warning no later than 24 hours after becoming aware of the significant incident, a full notification within 72 hours — with a specific rule for trust service providers — followed by a final report no later than one month after the notification. These deadlines do not turn every outage into a NIS2 incident: the entity's scope and the significance of the incident must be verified.

Several clocks may start

The same event may involve the DPA, CCB, a sector regulator, the police, an insurer and contractually bound customers. The clocks, thresholds and content differ. Maintain a decision log recording the competent authority, legal basis, time of awareness, responsible person, deadline and status. Seek legal advice when the scope is uncertain.

The IT disaster recovery and business continuity plan describes how to prioritise restorations. GVISION recommends linking this technical sequence to the communication plan: each service restoration should trigger a verified message, without announcing that a system is safe before the necessary checks have been completed.

Building a recipient matrix

The same incident requires multiple messages because employees, management, customers and authorities do not have the same decisions to make or the same need for detail.

Three ready-to-adapt message templates

Pre-approved templates speed up the first communication, but the fields must only be completed with confirmed facts. Keep them offline and specify who can approve them.

1. Initial internal alert

Since [time], [service] has been [unavailable/disrupted]. The team is investigating the situation. Until further notice, [specific instruction]. Do not use [channel or application] and report [symptom] via [backup channel]. Next update at [time], even if the investigation is ongoing.

2. Customer or partner information

We have been experiencing an incident affecting [service/scope] since [time]. Our teams have activated the planned response measures. At this stage, the confirmed impact is [fact]. You can [temporary solution or action]. We will publish a further update at [time] via [channel].

3. Restoration message

The [name] service has been restored since [time] and is subject to enhanced monitoring. [Potential user action]. Analysis of the causes and impact is ongoing; we will communicate relevant additional information via [channel]. If you experience [symptom], contact [point of contact].

These formulations avoid announcing a cause, data theft or definitive resolution before validation. Add sector-specific contractual obligations and have the relevant functions review the templates before an incident occurs.

Adapting the plan to the realities of Belgian organisations

The communicable severity depends on the service provided, not just the number of affected machines. The same technical outage can have very different consequences depending on the sector.

School or non-profit organisation

If email is compromised, the priority is to provide staff with a reliable channel, prevent fraudulent messages from being followed and explain to families how to identify official communications. The plan must specify who can contact parents, in which languages and via which independent platform.

Medical practice or healthcare organisation

The unavailability of an appointment system or patient record immediately affects patient reception. The first internal message should describe the degraded operating mode, temporary record-keeping and the channel for emergencies. Public information should remain minimal to protect data and security, while the DPO assesses any potential breach.

Multi-site company

Each site may experience a different impact. Use local representatives who confirm receipt and execution of instructions. A central table separates “unverified”, “confirmed” and “resolved”. Sales teams receive approved wording so they can respond without creating multiple versions of the incident.

Public administration or organisation

The plan must incorporate institutional stakeholders, transparency obligations, emergency procurement procedures and channels accessible to the public. It must also allow publication in the required languages without divergence in substance. A single source version and controlled translations reduce this risk.

Preparing and testing the framework in ten steps

A plan is only operational if contacts, channels, templates and decision-making authority are tested under the conditions of a real outage.

1. Define the scenarios. Ransomware, identity compromise, cloud unavailability, data breach and supplier outage.
2. Classify severity levels. Link each level to a communication trigger and a decision-maker.
3. Name primary and backup role holders. Management, incident manager, IT, DPO, legal, HR, communications and business teams.
4. Create the crisis directory. Professional and backup contact details, retained proportionately and securely.
5. Separate the channels. Technical, decision-making and information channels, with an option independent of the primary environment.
6. Prepare the templates. Alert, status update, instruction, customer, partner, authority and resolution.
7. Map the obligations. NIS2, GDPR, sector-specific requirements, police, insurance and contracts, with responsible persons and procedures.
8. Link communication and recovery. Each technical step must have a message criterion and an approver.
9. Simulate a real outage. Deliberately disable access to the usual tools during the exercise.
10. Correct and date. Record discrepancies, update contacts and schedule the next test.

Mistakes that make a crisis worse

The most common problems stem less from writing style than from untested dependencies and unassigned decisions.

• Keep everything in Microsoft 365: procedures, passwords and contacts become unavailable simultaneously.
• Create a large informal group: assumptions circulate, decisions are no longer traceable and access remains in place.
• Wait for complete certainty: users invent their own explanations and actions.
• Announce an attack too early: an outage may be misclassified and the communication becomes difficult to correct.
• Promise a timeframe: restoration may depend on a supplier, evidence or security checks.
• Copy the same text everywhere: an employee, customer and authority do not have the same needs.
• Forget the languages: an improvised translation can alter an instruction or risk assessment.
• Stop communicating once services are restored: you need to confirm follow-up, user actions and lessons learned.