🖊️ By Harry V.M. van der Plas (Management-Projects.nl)
Peer-reviewed by Danny Zeegers (Qfirst)
đź“… Published: 22 May 2025
“The Breach at DigiVerge: A Lesson in Unpreparedness”
DigiVerge-x Benelux was a mid-sized cloud service provider operating across the Benelux region. With a lean team and a growing client base, their priority was uptime, not paperwork. Despite warnings from advisors, they hadn’t implemented a formal incident response plan. “We’ll handle things when they come,” the CEO had said.
Day 1 – The Breach
On a quiet Monday morning, a junior engineer noticed strange outbound traffic from one of DigiVerge-x’s core servers. It was a ransomware attack—ongoing and spreading fast. Panicked, he emailed his manager, who was on vacation. The rest of the team scrambled. There was no hotline. No form. No protocol.
By midday, client data was encrypted. Three key customers were offline, including a hospital system relying on DigiVerge-x’s cloud API for patient records.
Day 2 – The Confusion
There was still no formal internal report. The CISO (newly appointed) wasn’t even aware of the full scale. Legal and HR weren’t looped in. Marketing, hearing rumors from a customer, prematurely issued a vague press release.
Meanwhile, the national CSIRT had not been notified within the required 24-hour window. The company had no XML template, no contact details, no trained staff for regulatory communications.
Day 3 – The Fallout
Regulators heard about the breach from the press. They launched an immediate investigation. DigiVerge had missed the 72-hour reporting deadline. Worse, clients began terminating contracts, citing breach of SLAs.
The media pounced: “Cloud Provider Covers Up Hospital Data Breach.”
Internally, the board was furious. But the damage was done.
Week 3 – The Audit
During a compliance audit, it became clear DigiVerge-x had no documented incident classifications, no role-based escalation paths, no impact matrix, and no audit logs for how the event was handled. They failed to meet NIS2 obligations under Article 23 and multiple ISO 27001 clauses.
They were fined €120,000 for delayed notification and inadequate governance.
The Lesson
Had DigiVerge used a structured incident response framework, they could have:
- Logged the breach centrally within minutes.
- Escalated to the right people within hours.
- Notified CSIRT and affected clients in time.
- Contained reputational damage with accurate messaging.
- Avoided financial penalties and contract loss.
Moral: In the age of NIS2, preparedness isn’t optional—it’s strategic survival.
Introduction – Help from expert Harry V.M. van der Plas
As the European NIS2 Directive (EU 2022/2555) comes into force, it reshapes the way organizations—especially SMEs—must handle cybersecurity incident reporting. The directive mandates structured, multi-tiered communication for significant security incidents, shifting incident response from a purely technical task to a board-level governance issue. This article, grounded in a comprehensive study by Management-Projects.nl and reviewed by Qfirst, outlines a practical and compliant framework to align with both NIS2 and, where applicable, the DORA Regulation (EU 2022/2554).
Key Objectives
The study aims to help small and medium-sized enterprises (SMEs) operationalize NIS2-compliant incident communication through:
- Defined timelines and structured reporting (24h early warning, 72h formal notice, 1-month final report).
- Integration into existing management systems, such as ISO/IEC 27001:2022 and the Harmonized Structure Management System (HSMS).
- Templates and escalation procedures for reporting to CSIRTs, regulators, and customers.
- Clear governance and role distribution across executive, security, communication, and IT teams.
Governance and Legal Implications
NIS2 puts the ultimate responsibility for cybersecurity, including incident communication, squarely on the organization’s top management. Article 20 mandates board-level accountability for ensuring timely and structured reporting.
Legal obligations now include:
- Proof of a working incident response structure.
- Documented procedures embedded in the HSMS (section H7.4).
- Readiness for regulatory audits, including evidence of timelines and content quality.
- Escalation and customer communication protocols for public or cross-border incidents.
Reporting Structure Under NIS2 (Article 23)
| Report Type | Deadline | Purpose & Audience |
|---|---|---|
| Early Warning | Within 24h | Preliminary assessment to CSIRT/regulator |
| Incident Notification | Within 72h | Severity, indicators, impact |
| Final Report | Within 1 month | RCA, mitigation steps, cross-border effects |
| Notification to Users | Without delay | If users are affected or at risk |
| Interim Updates | On request | CSIRT or regulator-specific follow-ups |
Defining a “Significant Incident”
An incident is considered significant if it results in:
- ≥4h service downtime
- Personal or sensitive data leak
- Integrity compromise of data or services
- Cross-border impact
- Expected damage > €50,000
- Media/reputational damage
If any of these criteria apply, formal notification is mandatory.
Incident Communication Lifecycle (ISO/IEC 27001 Integration)
The framework is based on ISO/IEC 27001:2022 controls:
- A.6.8: Initial detection and internal reporting
- A.5.24–A.5.28: Full incident lifecycle—classification, analysis, escalation, learning
Each step must be logged, auditable, and aligned with the broader HSMS structure. Automation via SIEM, Power Automate, and incident logging dashboards is recommended.
Roles and Responsibilities
| Role | Duties |
|---|---|
| Security Officer | First responder, impact triage, CSIRT liaison |
| CISO / MT | Escalation decisions, final report delivery |
| Communications Team | Stakeholder messaging, media handling |
| Legal / Privacy | Compliance checks, liability review |
| Board of Directors | Final Go/No-Go on disclosure, strategic oversight |
Supply Chain and Customer Communications
NIS2 expands accountability to supply chain incidents. SMEs must ensure:
- SLA clauses with suppliers include reporting duties.
- Clear downstream communication to customers if service is disrupted.
When customers are affected, they must be informed about:
- What happened
- Potential consequences
- Actions they can take
- Steps the organization has taken
A standard customer message template and internal Go/No-Go checklist are included in the document.
Integration with DORA Requirements
For financial entities, the study also maps DORA’s reporting structure:
| DORA Report Type | Deadline | Channel |
|---|---|---|
| Initial Notification | ≤4h after classification | ESMA/NBB portal |
| Intermediate Report | ≤72h after initial | Same |
| Final Report | ≤1 month | Same, includes RCA & mitigation |
An XML reporting template for DORA notifications is also provided.
Final Thoughts
This study delivers a full-spectrum model for NIS2/DORA-aligned incident communication tailored to SME needs. It balances legal compliance, operational feasibility, and reputational risk management, offering templates, procedures, and escalation paths in a practical, structured format.
The collaboration between Management-Projects.nl and Qfirst (via peer review by Danny Zeegers) ensures that the proposed model is both regulatory-proof and implementation-ready.
