What NIS2 Article 23(4)(c) to (e) requires after the first notification
Once an entity has sent its early warning and incident notification, the clock does not stop. Article 23 keeps the CSIRT or competent authority informed through three follow-up duties: an intermediate report on relevant status updates when the authority asks for one, a progress report if the incident is still ongoing when the final report falls due, and a final report no later than one month after the incident notification. The final report must describe the incident in detail, covering severity and impact, the likely threat type or root cause, the mitigation measures applied and still under way, and any cross-border effect. Recital 101 explains the logic: staged reporting lets authorities act quickly to limit spread and offer help, while the in-depth report draws lessons from the incident.
The hardest part is usually the final report, because it asks for a root cause that many teams have not yet established. Under Implementing Regulation (EU) 2024/2690, a post-incident review must identify the root cause where possible and produce documented lessons learned. Start that review while containment is still underway, and record evidence as you go: timestamps, affected assets, indicators of compromise and each decision taken. Confirm with your national authority which format and portal it expects for intermediate and progress reports, and whether it has set a response window for information requests, since these details come from national transposition law rather than the Directive alone.
Gaps in the incident record are the most common reason a final report is weak. If the timeline is reconstructed from memory, or the root cause is still listed as unknown without an explanation of what was tested, a supervisor may ask follow-up questions that the team cannot answer quickly. Decide before an incident who owns the report, who approves it, and where the working record lives, so that a progress report can be produced from the same source as the final report. Where the root cause remains uncertain at the one-month point, the final report should say so, state what has been ruled out and describe the next steps, rather than guess.
Which incidents and entities trigger the follow-up reports
The follow-up reports under Article 23(4)(c) to (e) apply only after a significant incident has been notified, so the first question is whether the entity and the incident fall in scope. The cards below cover the decisions that change how much reporting work follows, from entity classification to open incidents and cross-border effects.
Essential and important entities
Essential and important entities owe the same Article 23 reporting duties, so the follow-up reports apply whichever classification the entity holds. The classification changes supervision, with essential entities supervised ex ante and important entities ex post, not the content or timing of the reports. Confirm your classification with your national competent authority, because it sets who may request an intermediate report and when.
Incidents still open at notification
An incident that is still ongoing when the final report falls due triggers a progress report at that point, followed by a final report within one month of handling the incident. Teams often miss this because the notification clock appears to end the work. Check whether containment, recovery and forensic analysis will run past the one-month mark, and plan the progress report before that date arrives.
Cross-border impact to describe
The final report must state any cross-border impact of the incident. Entities operating in several Member States, or serving users there, should decide early which affected jurisdictions and CSIRTs the report must reach. Map where affected services, data and customers sit so the description in the final report is accurate and complete.
Digital entity type and IR 2024/2690
Entities of the digital types covered by Implementing Regulation 2024/2690, such as DNS, cloud, data center, CDN, managed service and online platform providers, must apply its technical and methodological rules and significant incident thresholds. Confirm whether your entity type falls under that regulation, because it can set stricter criteria for what the final report must document, including post-incident reviews with root cause analysis and lessons learned.
Sector rules and national channels
Sector-specific laws may displace NIS2 for some entities, and national transposition laws may set the exact channel, portal and format for each report. Ask your national competent authority or CSIRT which reporting channel applies, which templates they require, and whether any sector regulator also expects notice. A report sent through the wrong channel may not count as filed.
Records that support each report
Each follow-up report depends on a case record that holds timestamps, affected assets, indicators, actions taken and evidence handling. If that record is kept in scattered tickets and chat threads, the final report will be slow and hard to verify. Decide before an incident which system will hold the case record and who owns updating it, so the intermediate and final reports can draw from one source.
How an assessor or supervisor tests the follow-up reports
This table sets out how a supervisor or assessor tests each follow-up duty under Article 23(4)(c) to (e), what evidence they ask for, and where entities commonly fall short. Read each row as a test the entity must be able to pass with records, not memory. The main takeaway is that timing and content are tested separately, so an on-time final report with no root cause statement still fails.
| Duty tested | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Intermediate status updates | Updates were sent when the CSIRT or competent authority requested them, with relevant status changes | Request log with dates, the requester, and copies of each update sent | Requests received by phone or email but never logged or answered in writing |
| Progress report for ongoing incidents | A progress report was filed when the final report was due and the incident was still open | Incident timeline showing the due date, the filing time, and the content submitted | Progress report filed late or not at all because the team assumed the final report would cover it |
| Final report timing | The final report was submitted no later than one month after the incident notification | Notification timestamp, final report timestamp, and the submission receipt | Clock started from the date of resolution instead of the notification date |
| Severity and impact content | The report describes the incident in detail, including severity and impact | Impact assessment with affected services, users, and duration, signed off by the incident lead | Generic severity labels with no link to the actual service or user impact |
| Threat type or root cause | The report states the likely threat type or root cause, or explains why it is not yet known | Root cause analysis record and the reasoning behind any stated uncertainty | Root cause field left blank or repeated from the early warning without analysis |
| Mitigation and cross-border impact | Applied and ongoing mitigations are listed, and any cross-border impact is stated | Change records for mitigations, plus the cross-border assessment for affected Member States | Ongoing mitigations omitted, or cross-border impact not assessed at all |
| Post-incident review | A documented review identifies the root cause where possible and records lessons learned | Post-incident review report, action items with owners, and dates for closure | Review held but no written lessons learned or no tracked follow-up actions |
How to build the follow-up reporting workflow step by step
This sequence turns the Article 23(4)(c) to (e) follow-up duties into a repeatable workflow, so the intermediate, progress and final reports are drafted from one case record and sent on time with the evidence to back them.
Define report templates and owners
Start by writing one template for each follow-up report: the intermediate status update, the progress report for an ongoing incident and the final report. Each template should carry the fields the Directive asks for, including severity and impact, the type of threat or likely root cause, applied and ongoing mitigation measures, and any cross-border impact. Name an owner for each report and a deputy, and record who approves a report before it leaves the organization. Confirm the exact content and format each CSIRT or competent authority expects, since national practice may add requirements. The output is a signed-off template set and a RACI table that the incident response team can find without searching.
Set reporting clocks from the notification timestamp
Record the exact time the early warning and the incident notification were sent, because the follow-up clocks run from the notification. Create a reporting calendar that shows when the final report falls due, which is no later than one month after the incident notification, and add an internal checkpoint before that date. Configure the case tool or ticketing system so that the notification timestamp drives the reminders, and confirm with the competent authority whether any intermediate update is expected in the meantime. The output is a dated reporting calendar tied to a single timestamp field in the case record.
Link the case record to timeline and evidence
Open one case record for the incident and attach affected assets, indicators of compromise, tasks and evidence items to it. Build the investigation timeline from alerts and analyst actions so that every statement in a report can be traced to a logged event. Store evidence with hash verification and a chain of custody record, and confirm that changes to the case are captured in an audit trail. DFIR-IRIS is one open-source option for this case-centred approach, and a wiki with version history can hold the report drafts and approvals. The output is a case that can answer who did what, when, and on which evidence.
Schedule progress report checkpoints
If containment or recovery is still running when a report is due, the Directive requires a progress report at that point. Set recurring checkpoints during the incident so the incident lead reviews status, open actions and new impact, and decides whether a progress report or an intermediate update is needed. Keep a short log of each checkpoint decision, including the reason for not reporting, so the reasoning is available to an authority later. The output is a checkpoint log and a progress report that states current severity, impact, and the mitigation still in progress.
Respond to authority requests for intermediate updates
An intermediate report is submitted when the CSIRT or competent authority asks for it, so the workflow needs a single intake point for those requests. Route each request to the report owner, pull the latest state from the case record, and confirm the update is consistent with what was previously reported. Log the request, the response and the time sent. The output is a request register and a set of intermediate updates that match the case timeline.
Run the post-incident review and produce the final report
Once the incident is handled, hold a post-incident review that establishes the root cause where it can be determined and records lessons learned, as the implementing regulation requires for significant incidents. Use the case timeline to check severity, impact, threat type, mitigation and cross-border effects, then draft the final report from the template. Have the approver confirm each statement against the evidence, and send the report before the final deadline. The output is a final report with a documented root cause or a stated reason it could not be determined, plus a lessons-learned record and an improvement list with owners.
Test the process in an exercise
Run a tabletop or simulated incident that moves through the early warning, notification, progress and final report steps, using the same templates, calendar and case record. Time each step against the reporting clocks, check that the owners and approvers respond, and confirm that the evidence chain holds up when the report is traced back. Record gaps, assign fixes and retest the changed steps. The output is an exercise report with dated actions and a revised workflow that the organization can show to its supervisor as proof that the process works.
Why staged reporting depends on a single incident record
Staged reporting only works if every report the team sends says the same thing about the same incident. The early warning, the incident notification, any intermediate update and the final report are separate documents sent at different times, but they describe one event. The organization needs one authoritative case record that holds the timeline, affected assets, indicators of compromise, decisions taken and the reasoning behind them. Each report is then an extract of that record at a fixed point in time, not a fresh account written from memory.
A supervisor or CSIRT reads the reports in sequence and compares them. A later report that changes the severity, the affected services, the apparent cause or the cross-border impact is expected to explain why the earlier view was different. An unexplained change, or a timeline that places an event after the time the earlier report said it was detected, is the kind of inconsistency that becomes a finding. Version control matters here because the team must be able to show what the record said at the time each report was filed. A change history that records what changed, when and by whom lets the team reconstruct that position without relying on recollection.
Before the first incident, confirm three things with your own tooling: who owns the case record, whether the platform keeps an audit trail of edits to case data and report drafts, and whether reports are generated from the record or typed separately. The DFIR-IRIS documentation describes how cases, timelines and evidence are organized and how reports are generated from case data, so check the current release against your reporting template. Where the record is a wiki or document store, confirm that prior versions can be compared and restored, and agree in advance who may approve a version that goes to the authority.
Evidence that satisfies the follow-up reporting duties
Follow-up reports under Article 23(4)(c) to (e) are judged on whether the entity can show what it told the CSIRT or competent authority, when, and how the incident was understood and closed out. The cards below cover the records that prove those statements, and they should be kept current between incidents and exercises, not assembled after the fact.
Dated copies of every status update
Keep a dated, unaltered copy of each intermediate status update, progress report and final report as it was sent, with the named recipient, channel and time of transmission. Article 23(4)(c) ties intermediate updates to requests from the CSIRT or competent authority, so the log should show which request each update answered. Check that the copy in the record matches the version actually submitted, not a later draft.
Final report with severity and impact
The final report must describe the incident in detail, including severity, impact, the likely threat type or root cause, and any cross-border effect. Keep the severity and impact assessment with the data that supports it, such as affected services, users and duration, so an assessor can trace each figure back to its source. Confirm the final report went out no later than one month after the notification.
Root cause and mitigation record
Record the root cause where it can be established, or the likely cause where it cannot, and separate mitigations already applied from those still ongoing. Each mitigation should name an owner, a date and the change it produced, such as a patch, a configuration change or a revoked credential. Supervisors compare these statements against later findings, so unsupported claims about cause are a common weak point.
Incident timeline and case record
Maintain one consolidated timeline that links detection, triage, containment, notifications and each report to the underlying alerts and actions. A case management tool such as DFIR-IRIS can hold assets, indicators, tasks and evidence in one record with an audit trail. Check that timestamps are consistent across the SIEM, ticketing system and the case record before a report relies on them.
Post-incident review and lessons learned
Implementing Regulation 2024/2690 requires a post-incident review that identifies the root cause where possible and produces documented lessons learned. Record the review date, attendees, findings, owners of each corrective action and the date each action was verified closed. Where the review changes a control or procedure, link the change back to the incident so the evidence shows a cycle, not a single report.
Version history of report drafts
Keep drafts of each follow-up report under version control, showing what changed, when and by whom, and who approved each release. Version history shows whether statements about impact or cause were revised as facts emerged, which is what a reviewer will ask about. Store the approved final version separately and make it read-only so later edits cannot alter the submitted record.
What meeting the follow-up reporting duties costs in money and effort
The tooling cost for follow-up reporting is mostly about where the case record lives and how it is kept. Open-source platforms such as DFIR-IRIS (LGPL-3.0-or-later) carry no license fee, so the money goes to hosting, storage, backup, patching and integration with the alert sources the organization already runs. Those costs are paid to the organization's own cloud or data center provider and to whoever operates the platform, which may be internal staff or an implementation partner such as DeployOpen.
- Hosting and storage: Case records, evidence and audit trails grow with incident volume and retention periods, and they must stay available for the length of any regulator inquiry.
- Integration work: Connecting SIEM, EDR and REST sources to the case platform is usually a one-time build, followed by maintenance whenever a source changes.
- Backup and recovery: Recurring backup jobs and periodic restore tests are needed so that a final report can still be written if a system is lost during an incident.
- Commercial add-ons: Any paid support subscription or commercial module is a recurring license cost that must be listed separately.
- Access control: Identity integration and role design are mostly one-time work, with recurring reviews.
Ask the provider to itemize one-time build work, recurring hosting and licenses, and the support hours included. Confirm the retention period assumed in the quote.
The largest variable cost is the time people spend on an incident and on the reports that follow it. Article 23(4)(c) to (e) require an intermediate report when the CSIRT or competent authority asks for one, a final report no later than one month after the incident notification, and a progress report if the incident is still ongoing when the final report falls due. Each of those documents needs analysts to collect facts, confirm severity and impact, and describe the likely root cause and mitigation. Effort depends heavily on how complex the incident is and on how many authorities receive the reports.
- Analyst and engineer time: Forensic work, log review and root cause analysis are paid as staff hours, either internal or contracted.
- Management and legal review: Reports that describe cross-border impact or may overlap with GDPR notifications need time from management and counsel.
- Repeat reporting: Progress and intermediate reports add effort at each update, so an incident that runs for weeks costs more than one closed in a day.
- Staffing coverage: Organizations need a plan for who writes reports when key staff are unavailable.
- Surge capacity: Some organizations contract emergency responders for large incidents, which is an incident-driven, unscheduled cost.
Ask the provider how it estimates effort per report type and what it assumes about incident volume. Confirm whether surge work is billed separately.
Documentation and exercises are the recurring costs that keep the reporting process ready between incidents. A final report is only credible if the reporting templates, post-incident review records and lessons learned are kept current and versioned. Implementing Regulation 2024/2690 requires post-incident reviews that identify the root cause where possible and produce documented lessons learned. Exercises test whether staff can meet the reporting timeline under pressure, and they produce findings that feed back into the documents.
- Document upkeep: Procedures, contact lists and report templates need reviews, usually on a set schedule, and each change should be traceable. Wiki tools such as XWiki (LGPL-2.1-or-later) keep version history, and BookStack (MIT) can set permissions per role at shelf, book, chapter or page level.
- Tabletop and simulation exercises: These are recurring costs in staff time and, if external facilitators are used, in fees.
- Post-incident review time: Each real incident adds review hours that are often overlooked in budgets.
- Training refreshers: Staff who write reports need periodic training on the reporting structure.
- Evidence collection for supervisors: Gathering records for an inspection or information request is a recurring task.
Ask the provider how many exercises and review cycles are included, and whether facilitation and reporting of exercise results are priced separately.
Some organizations buy outside help for the final report, and others retain a managed security operations centre (SOC) to watch systems and start the reporting clock sooner. Neither is required by NIS2 itself. Management remains responsible for the reports, and an independent review or managed provider only changes who does the work. An independent auditor or assessor does not issue reports for NIS2 because the directive creates no certificate of compliance, so any external review is a quality check, not a regulatory approval.
- External review of the final report: A consultant or counsel may review drafts, typically for a fixed scope, and this is a per-engagement cost.
- Managed SOC retainer: Monitoring, triage and alerting are usually billed as a recurring retainer, with extra charges for hours beyond the agreed scope.
- Hand-off arrangements: Defining how the managed SOC notifies the organization in time for the 24-hour and 72-hour steps is part of the contract, not an extra fee, but it needs clear terms.
- Retainer scope: Confirm whether the retainer covers writing reports or only detecting and escalating incidents.
- Contract exit costs: Moving case data to a new provider may carry one-time migration effort.
Ask for a written scope listing which report tasks are included, the response times committed, and what is billed when an incident exceeds the agreed hours.
Which self-hosted tools keep the follow-up report trail
This table compares three self-hosted open-source tools that can hold the records behind an intermediate, progress or final report, with each tool's license and the role it plays. Read each row as a question to test against your own environment, since a tool supports the trail but does not decide whether a report satisfies Article 23(4)(c) to (e). The main takeaway is that case management, document history and access control are separate needs, and most teams will want a tool for each.
| Capability | DFIR-IRIS | XWiki and BookStack |
|---|---|---|
| Primary role in the report trail | Holds the incident case, timeline, evidence and generated report drafts | XWiki keeps version-controlled report and review pages; BookStack holds templates and runbooks with role-based access |
| License | LGPL-3.0-or-later | XWiki: LGPL-2.1-or-later. BookStack: MIT |
| Incident case record and timeline | One case record covering assets, IOCs, tasks and evidence, with a consolidated investigation timeline | Not designed for case records; use for narrative drafts, reviews and cross-references to the case |
| Evidence handling | Logs evidence with SHA-256 verification and chain of custody | Stores documents, but does not provide evidence hashing or chain of custody; keep original evidence in the case tool |
| Audit trail of changes | Full audit trail on the case record | XWiki records what changed, when and by whom, and allows comparing and rolling back versions; BookStack relies on its own page history |
| Report generation | Generates reports from case data, which supports building the one-month final report and progress updates | Hosts the written narrative, review sign-off and lessons learned pages |
| Access control | Confirm per-case permissions match your need-to-know rules for incident data | BookStack permissions come from assigned roles and can be overridden per shelf, book, chapter or page |
| Points to confirm before adoption | Data residency, retention periods, and whether the report format meets what your CSIRT or competent authority expects | Whether version history and role settings meet your retention and supervisor evidence expectations, and whether the tools fit your data handling rules |
Who writes, reviews and assesses the follow-up reports
The entity owns every follow-up report and every submission to the CSIRT or competent authority. Day to day, an incident owner holds the case, keeps the facts current and drafts each report. The management body does not write the report, but it must be able to show it approved the incident handling approach and oversaw the outcome. Legal counsel and the data protection officer review any report where the incident may also be a personal data breach, so that statements to the authority and to the GDPR supervisory authority stay consistent.
- Incident owner: keeps the timeline, drafts the intermediate, progress and final reports, and records who changed what.
- Management body approval: a named approver signs off each submission before it leaves the entity, and the approval is kept on file.
- Legal and DPO review: checks overlap with GDPR breach notification and wording on personal data impact.
- Technical contributors: supply root cause findings, containment actions and the status of ongoing mitigation.
- Submission record: the entity stores the exact version sent, the time sent and the channel used.
Confirm with your national competent authority which submission channel, format and recipients apply in your Member State before the first incident.
An implementation partner such as DeployOpen prepares the systems the entity uses to produce follow-up reports. This covers setting up a self-hosted case management platform, building report templates that match the content the Directive asks for, configuring timers and reminders around the one-month final report deadline, and running tabletop exercises so staff have practised the workflow. The partner does not decide whether an incident is significant, does not approve reports, and does not sign or submit them on the entity's behalf.
- Case system setup: deploys the platform inside the entity's own infrastructure and configures roles so only authorized staff can edit or approve.
- Templates: drafts intermediate, progress and final report templates with fields for severity, impact, root cause, mitigation and cross-border impact.
- Timers and records: configures deadline tracking and an audit trail so the entity can show when each step happened.
- Exercises: runs scenario-based drills that test whether the entity can produce a final report within the required period.
- Documentation: writes the procedure that describes who does what, kept under version control.
Ask the partner in writing which deliverables are included, who holds administrator access after handover and what happens to the platform when the engagement ends.
The competent authority or CSIRT receives the reports and can request an intermediate report on relevant status updates. Supervisors oversee compliance through inspections, security audits, security scans and information requests, so the records an entity keeps must stand up to inspection. An independent assessor, when an entity engages one, tests the reporting records and reports against the entity's own procedure and the timing rules. An assessor's work is an opinion on the evidence, not a NIS2 certificate, because the Directive does not create one.
- Information requests: the authority may ask for intermediate status updates at any point while an incident is open.
- Record testing: an assessor samples incidents and checks that each report was produced, approved and sent within the required periods.
- Content testing: checks that the final report covers severity, impact, likely root cause, mitigation and cross-border impact.
- Traceability: confirms that the version submitted matches the version approved and that changes are logged.
- No certificate: an assessor's findings are shared with the entity and do not constitute a NIS2 compliance certificate.
Before engaging an assessor, confirm the scope, the period under review and whether the assessor is qualified for your sector and national rules.
Where follow-up reporting usually fails and how to close each gap
Follow-up reports under Article 23(4)(c) to (e) are where many entities lose track of their own deadlines and content. The gaps below tend to appear together, because they share one root cause: the incident record is not kept as a single, dated source that every report is drawn from.
No clock tied to notification
The one-month window for the final report runs from the incident notification, so a team that starts the clock from the day it found the problem may report late. Record the exact timestamp of the notification in the case record when it is sent, and calculate the final report date from that entry. Check that every responder sees the same deadline. Illustrative example: a notification sent late on a Friday still fixes the due date from that Friday, not from the following Monday's review meeting.
Final report missing root cause
The final report must describe the likely root cause or threat type, not only what happened. Teams often list symptoms and timelines but leave out the cause because analysis was still open when the report was drafted. Keep a running hypothesis field in the case, update it as evidence arrives, and state clearly in the report which causes are confirmed and which remain under investigation.
Cross-border impact left out
The final report must say whether the incident has cross-border impact, which is easy to overlook when the affected systems look domestic. Check which Member States host affected services, which users or recipients sit in other countries, and which subsidiaries or suppliers operate across borders. Record the answer, even when it is none, so the assessor can see the question was asked.
Progress report skipped on long incidents
When an incident is still ongoing at the time the final report is due, Article 23(4)(e) requires a progress report at that point, with the final report following within one month of handling the incident. Long incidents are the ones most likely to be skipped, because the team is focused on containment. Set a recurring review in the case workflow that asks whether the incident is still open on the due date, and draft the progress report from the case timeline.
Post-incident reviews never written
Implementing Regulation 2024/2690 requires post-incident reviews that identify the root cause where possible and produce documented lessons learned for digital entities in scope. Many teams close the incident, file the report and move on, leaving no review. Schedule the review before the incident is closed, assign an owner, and store the lessons learned with named actions and dates so the next report can show they were followed up.
Report versions not kept
Intermediate, progress and final reports are often edited in shared documents, so a supervisor who asks what was told on which date may receive an answer that does not match the earlier submission. Keep each submitted version as a fixed record, with the date, author and what changed. Compare versions before any new submission so the later report explains any correction to the earlier one.
Questions buyers ask about NIS2 follow-up reports
How much does it cost to prepare NIS2 follow-up reports?
No supplied fact gives a price for follow-up reporting, and DeployOpen does not publish one. The cost is driven by what already exists: a documented incident process, a case record for each incident, and evidence collected while the incident is handled. Most of the spend falls into one-time work (designing report templates, building the case workflow, training responders) and recurring work (keeping the timeline current, running post-incident reviews, updating the process after each exercise). Ask any provider for a written quote that separates these two groups and states which items the organization keeps in-house.
How long does it take to get follow-up reporting ready?
The time depends mostly on how far your incident process already goes. If you have a tested playbook, a single system of record for incidents and a template for post-incident reviews, the work is mostly adaptation. If incidents are tracked in email and chat, expect the preparation to start with building that record. No duration is supplied here, so ask a provider to estimate effort against your current process and to show what is included in a fixed-scope plan before work starts.
Can our own security team write NIS2 follow-up reports in-house?
Yes, many organizations do, provided the team can keep a complete timeline, record severity and impact, and document root cause and mitigation within the deadlines. The Article 23(4)(d) final report must cover severity, impact, threat type or likely root cause, applied and ongoing mitigations, and any cross-border effect, so the people writing it need access to forensic and business facts. Internal teams often struggle with the root cause analysis and the post-incident review that Implementing Regulation 2024/2690 expects. Decide early which parts you will write yourselves and which you will bring in external help for.
What does management need to provide for follow-up reports?
Management must approve the reporting process, name who signs and submits each report, and make sure the business owners of affected services answer impact questions quickly. Under Article 20, the management body approves and oversees the Article 21 measures, so it should see the final report and the lessons learned. Expect to allocate budget for tooling and for the time of engineers and legal staff during an incident. Without these decisions in place, intermediate updates tend to be late or inconsistent.
How do NIS2 follow-up reports relate to GDPR breach notifications?
A single incident can trigger both a NIS2 report to the CSIRT or competent authority and a GDPR personal data breach notification to the supervisory authority, and the two clocks run separately. The facts you record for NIS2, such as timeline, impact and mitigation, should be the same facts you use for GDPR, so the two sets of reports do not contradict each other. Keep one incident record that tags which reports apply and when each is due. Confirm with your legal and data protection teams how your national authorities expect the two to be coordinated.
What can an implementation partner sign, and what can it not?
A partner such as DeployOpen can prepare the systems, the report templates, the case records and the evidence trail, and can help write the timeline and post-incident review drafts. It cannot submit reports on your behalf as your legal representative, and it cannot issue an audit report, attestation or certificate. The organization owns the decisions, the content it certifies to its authority, and the submission. Only independent auditors, assessors or certification bodies issue reports or certificates. NIS2 itself creates no certificate of compliance, so ask your supervisor which evidence it expects.
How do we keep the progress and final reports consistent over time?
Keep one case record per incident and version every update, so each report draws from the same facts and the changes between versions are visible. Record what changed, when and by whom, and keep the original text of each submission. Tools such as DFIR-IRIS keep an audit trail of case activity, and version control in a wiki such as XWiki or a permissions-managed space such as BookStack can hold the report drafts and approvals. Confirm that each tool meets your retention and access requirements before you rely on it.
What should we check before we rely on an external partner for reporting?
Check that the written scope names each report, the evidence it draws on, the roles of your staff and the partner, and the retention period for records. Ask how the partner handles access to sensitive incident data and where that data is stored, given that the systems run in your own infrastructure. Confirm who is the escalation contact at 2 a.m. and how the partner supports the post-incident review. Ask your national authority which format and portal it requires before the first incident occurs.
Where the legal text and implementing rules apply
The authoritative starting point for the intermediate, final and progress reports is the text of Article 23 of Directive (EU) 2022/2555, which sets out the staged reporting sequence and the deadlines that govern it. Read paragraph 4 in full, including points (c), (d) and (e), because the follow-up reports are triggered by conditions in those points, such as a request from the CSIRT or competent authority or an incident that is still ongoing when the final report falls due. Read it alongside the NIS2 text on EUR-Lex so that your reporting procedure quotes the exact conditions rather than a summary.
For the content of the final report, the operative rules sit in Commission Implementing Regulation (EU) 2024/2690. Point 3.6.1 of its Annex requires post-incident reviews that identify the root cause where possible and produce documented lessons learned. This is the requirement that gives the final report its substance: if your review process cannot establish a root cause, your report must say so and explain what was done to establish it. The regulation binds only the digital entity types it lists, so confirm with counsel whether it applies to your entity directly or whether you should treat its requirements as the benchmark your supervisor will expect.
Member States transposed NIS2 into national law, and national measures may add formats, submission channels, portals or additional content requirements for these reports. Confirm these details with your national competent authority or CSIRT before you finalize templates, because a report that meets the EU text can still be rejected for missing a national field or using the wrong channel. Record the answers in your incident response plan, with the date you checked and the name of the official who confirmed them, so you can show the process was verified.
