Preparing NIS2 72-Hour Incident Notifications for MSSPs #
Preparing a NIS2 incident notification means reconciling facts from the SOC’s investigation, the customer’s business-impact assessment, and the earlier warning sent to the authority—all while those facts keep changing. Manual copying is slow and error-prone.
BlackStork reads the incident record, calculates deadlines and durations, shows what changed, and produces a consistent draft for review. This post walks through a downloadable template that an MSSP can use to prepare a customer’s NIS2 72-hour incident notification.
Here is an excerpt rendered from the template’s fictional incident:
NorthRiver Logistics BV reports an incident affecting Warehouse Management Service.
SOC severity: High.
Incident status: Contained; recovery complete; investigation ongoing.
Service interruption: 258 minutes.
Affected countries: BE, NL.
Financial loss estimate: EUR 310000 (Initial estimate; finance validation in progress).
External customers affected: under assessment.
Data-access assessment: Possible unauthorized access to customer shipment data; not confirmed.
Initial-access assessment: Compromised privileged credentials; acquisition method remains under investigation.
The same render makes unresolved work visible:
| Check | Result | Meaning |
|---|---|---|
| National requirements and reporting route | REVIEW | Customer confirmation required. The template does not verify current law, authority designation, or portal compatibility. |
The fixture leaves the authority and portal unset and both confirmations false. Before submission, the team must identify the current authority and route, review the national requirements, update the customer profile, and approve a new render. BlackStork exposes that work; it does not make the legal conclusion or declare the document ready to submit.
What a NIS2 72-Hour Incident Notification Requires #
Under NIS2 Article 23(4)(b), the incident notification updates the early warning where applicable and provides:
- an initial assessment of the significant incident, including its severity and impact;
- indicators of compromise, where available.
At 72 hours, root cause, total loss, and full customer impact may still be under investigation. State what is known, distinguish estimates from confirmed findings, and name unresolved questions. “Under assessment” is better than an unsupported zero or certainty the evidence does not support.
These are Union-level content requirements. National law and the receiving authority may require additional fields or a particular form. The twelve sections in our template are a practical reporting structure, not a prescribed EU form.
When the NIS2 72-Hour Reporting Clock Starts #
The general sequence in Article 23 is:
| Stage | Time limit | Purpose |
|---|---|---|
| Early warning | Without undue delay, within 24 hours of awareness | Flag the significant incident; indicate suspected unlawful or malicious acts and possible cross-border implications where applicable |
| Incident notification | Without undue delay, within 72 hours of awareness | Update the warning; provide initial severity, impact, and available indicators |
| Intermediate report | On request from the CSIRT or competent authority | Provide relevant status updates |
| Final report | No later than one month after the incident notification | Give the detailed assessment, likely threat or root cause, mitigation, and applicable cross-border impact |
If the incident is still ongoing when the final report is due, provide a progress report, then a final report within one month of handling the incident. Significant incidents affecting trust services have a 24-hour incident-notification exception; the downloadable example covers the general 72-hour case and rejects that exception.
The 72 hours run from awareness, not from submitting the early warning. They are an outer limit, not a reason to postpone reporting.
For the digital providers it covers, recital 31 of Implementing Regulation 2024/2690 describes awareness as having reasonable certainty, after a timely initial assessment, that a significant incident has occurred. Record the factual time and the evidence supporting it. A later approval records the assessment; it does not start or reset the clock.
In our example, the first alert occurs at 07:42 UTC on 14 September. By 08:35, the team has linked an anomalous privileged sign-in to remote execution and file encryption on critical warehouse servers. For this scenario, the customer treats that confirmed compromise and credible risk of service loss as capable of causing severe operational disruption. That evidence supports the awareness time even though the service interruption is not recorded until 09:10.
In a production record, put that reasoning in the awareness basis and retain links to the supporting evidence; a timestamp on its own is not enough.
BlackStork therefore calculates the 72-hour deadline as 17 September at 08:35 UTC. It does not substitute the first-alert time, the later outage time, or the time at which a reviewer approves the report.
MSSP and Customer Responsibilities Under NIS2 #
The SOC can describe affected devices, observed activity, and containment actions. The customer must supply the business context: the affected service, disruption, customer consequences, and its significance assessment. Article 23(3) covers severe operational disruption or financial loss to the entity, and considerable material or non-material damage to other persons, whether caused or capable of being caused.
An MSSP can prepare the report and, where authorized and permitted by the reporting route, deliver it for the customer. The reporting entity remains accountable for its obligation. Preparing, approving, and delivering the report are distinct steps.
When the MSSP’s Own Service is Affected #
Preparing a customer’s notification and assessing the MSSP’s own obligations are separate tasks. If the same event also affects the MSSP’s service, run that second assessment independently; do not apply the provider-specific thresholds to every customer incident.
Implementing Regulation 2024/2690 specifies significance criteria for the digital providers it covers. Article 10 includes, for MSPs and MSSPs:
- complete service unavailability for more than 30 minutes;
- limited availability affecting more than 5% of EU service users or one million, whichever is smaller, for more than one hour;
- compromise of the integrity, confidentiality, or authenticity of service-related data resulting from a suspected malicious action;
- such data compromise affecting more than 5% of EU service users or one million, whichever is smaller.
Read these alongside the horizontal criteria in Article 3 and recurring-incident rules in Article 4. For example, the direct-financial-loss threshold is a loss caused or capable of being caused exceeding EUR 500,000 or 5% of the previous financial year’s turnover, whichever is lower.
The template records the MSSP’s assessment as a separate, provider-supplied fact. It does not decide whether the MSSP must notify or merge that decision into the customer’s significance assessment.
A Practical Incident Walkthrough #
The sample follows fictional NorthRiver Logistics BV and its MSSP, ExampleShield MDR. For this exercise, assume the entity and affected service are in scope. This is not a claim that warehouse operators generally fall under NIS2.
A privileged-account compromise disrupts the warehouse-management service at three facilities in the Netherlands and Belgium. The service stops at 09:10 UTC and is restored at 13:28 UTC: 258 minutes, or 4 hours 18 minutes. The initial financial loss estimate is EUR 310,000. External-customer impact and possible shipment-data access remain under investigation.
The rendered excerpt above keeps the SOC’s High severity separate from the customer’s significance assessment. Two affected countries do not, by themselves, establish significance, and the provisional loss estimate does not become a legal conclusion merely because it appears in the report.
Connect Native Sources, Then Normalize Once #
The template’s inline fixtures mirror the response shapes of BlackStork’s native connectors. A shared JQ layer normalizes both fixture and live responses into the report model; Go templates handle presentation. Adopters do not need to build HTTP adapters merely to reshape Jira, Microsoft, or MISP data.
| Source group | Facts it supplies | BlackStork source |
|---|---|---|
| Customer compliance registry | Entity, service, contacts, scope, and reporting route | postgresql |
| Microsoft Sentinel | Incident identity, severity, timing, and analyst description | microsoft_sentinel_incidents |
| Microsoft Defender XDR | Alerts, devices, identities, evidence, and remediation status | microsoft_graph |
| MSSP incident case | Awareness basis, timeline, decisions, and owners | jira_issues |
| Customer impact intake | Interruption, facilities, business consequences, and estimates | file or a customer workflow |
| Threat-intelligence platform | Indicators and their confidence | misp_events |
| Previous early warning | Submitted facts, reference, receipt status, and comparison snapshot | file or an archived-record source |
The default render reads provider-shaped fixtures from vars.sample_sources and
human-owned or file-shaped values from vars.sample, so it needs no APIs,
credentials, or input files. The production config and data blocks remain
commented until an adopter enables them.
For production, configure the relevant BlackStork data sources and change
the corresponding selector in vars.raw_sources from the fixture to the live
.data value. The included vars.normalized_sources mapping then produces the same
canonical model. Jira custom-field IDs and the customer registry schema remain
deployment-specific; fictional values must never serve as fallbacks for missing
live data.
From that normalized record, the template:
- calculates the 24-hour and 72-hour deadlines from awareness;
- calculates interruption duration from start and restoration, or elapsed time for an ongoing interruption;
- sorts the timeline and derives affected-country and device counts;
- keeps missing values distinct from zero;
- compares five current fields with the early-warning snapshot;
- checks selected required fields, awareness and deadline evidence, source linkage and freshness, and review records for the current revision;
- builds the source appendix from supplied metadata.
The configurable freshness threshold is review policy, not a statutory limit. The checks expose gaps such as the unconfirmed route shown above; they do not validate every statement or settle contradictions between systems. Retain authentic source snapshots, submitted reports, and receipts in the surrounding evidence workflow.
Standardize the Output Structure #
The template renders twelve sections: notification details, factual summary, significance, impact, technical description, timeline, indicators, response, cross-border impact, outstanding questions, changes since the early warning, and approval/submission. Review checks and source records follow as internal appendices. Adapt the authority-facing copy to the required form and exclude internal material where appropriate.
Required information stays visible even when incomplete. With no indicators, for example, the report states that none were supplied at the snapshot time. It does not omit the section or imply that no compromise occurred.
Track Changes from the Early Warning #
The template compares the earlier and current records to generate a change table. Here is the sample output:
| Field | Early warning | Current notification | Change |
|---|---|---|---|
| Affected devices | Under assessment | 3 | Added |
| Affected facilities | Rotterdam distribution centre (NL) | Antwerp distribution centre (BE); Eindhoven fulfilment centre (NL); Rotterdam distribution centre (NL) | Updated — review |
| Financial loss estimate (EUR) | Under assessment | 310000 | Added |
| Service interruption (minutes) | Under assessment | 258 | Added |
| Shipment-data access | Unknown | Possible unauthorized access to customer shipment data; not confirmed | Updated — review |
The comparison covers those five fields. Reviewers still need to explain material corrections and check changes elsewhere in the report. Keep the actual submitted warning and its receipt in the evidence store; the template does not make an incident record immutable.
Generate Summaries with LLMs #
The optional llm_text block turns a selected set of reviewed fields into a short
summary. It receives service impact, severity, status, and unresolved assessments;
it does not receive the full source record, contacts, or raw indicators.
The prompt tells the model to preserve uncertainty and numbers and avoid new conclusions about cause, significance, compliance, or approval. Enabling it requires a named summary reviewer for the current revision, and the output is visibly marked as generated. Deadlines, calculations, comparison tables, and checks remain reproducible template logic.
Prepare, Approve, and Deliver #
BlackStork is useful in either delivery workflow:
| Workflow | What needs to happen |
|---|---|
| Prepare the report for manual submission | Render the draft, resolve review findings, adapt it to the authority’s form, approve the final artifact, and have an authorized person submit it |
| Prepare and deliver through an implemented publisher | Add the authority-specific field mapping and output format, then a publisher supporting the permitted interface and authentication; run it only after approval and capture the submission result and receipt |
The template renders Markdown and HTML. It includes no national submission publisher. Its review-record checks are not an enforceable release gate, and a successful render is not a submission receipt. A production workflow must bind approval to the exact artifact being delivered, including any generated summary, and handle delivery failures and duplicate attempts.
Consult the receiving authority’s current requirements before implementing that mapping. ENISA’s NIS2 Technical Implementation Guidance is non-binding guidance for specified digital providers; it does not replace national reporting instructions.
Try the NIS2 Incident Notification Template #
Download the NIS2 72-hour incident notification template on GitHub. It includes provider-shaped fixtures, native-source configuration examples, the normalization layer, and the complete report definition.
Full HTML report can be seen in BlackStork SaaS.
Save the raw template as
nis2-72h-incident-notification.document.blackstork.hcl in its own directory.
With the BlackStork CLI installed, run this from that directory:
blackstork-cli render document.nis2_72h_incident_notification \
--source-dir . \
--input as_of=2026-09-17T08:00:00Z > report.md
The explicit snapshot time reproduces the historical example. Omit as_of to use
the current time. Edit vars.sample_sources and vars.sample to try another
scenario. To render HTML, add --format document.format.html.review_copy and
redirect the output to report.html. The default run makes no LLM call; configure
the model in the llm_text block before enabling --input use_llm=true.
BlackStork removes repeated evidence collation, calculations, and document assembly from this workflow, leaving reviewers a consistent report and explicit gaps to resolve. To apply it to your process, bring one incident-notification workflow, its source systems, and the authority’s reporting requirements. We can work through the data mappings, review steps, and delivery requirements with you.