A NIS2 and DORA incident register that knows what Directive (EU) 2022/2555 and Regulation (EU) 2022/2554 require: when severity is Critical, the incident becomes significant and the form cannot be saved without authority, early warning and notification. ICT third-party providers involved, root cause, evidence and a workflow that closes nothing without the security officer's approval. All in Dokuflex, the low-code BPM platform with AI: the module is free and the data is hosted in the EU.
A NIS2 incident register is the file in which an essential or important entity documents each significant incident: the Article 23 dates (early warning within 24 h, notification within 72 h and final report within one month), the authority notified, the root cause and who approved the closure. It is the evidence before the CSIRT, the supervisor or the auditor.
Article 23 of Directive (EU) 2022/2555 (NIS2) requires essential and important entities to notify the CSIRT or the competent authority of every significant incident: one that causes or is capable of causing severe operational disruption or financial loss, or considerable damage to third parties (Art. 23(3)). The calendar is fixed: early warning within 24 hours of becoming aware, notification within 72 hours with the initial assessment of severity and impact, and final report no later than one month afterwards, with root cause, measures applied and cross-border impact. The fines in Article 34 reach €10 million or 2% of worldwide turnover for essential entities and €7 million or 1.4% for important ones.
For financial entities, Regulation (EU) 2022/2554 (DORA), on the digital operational resilience of the financial sector, applicable since 17 January 2025, requires in its Article 19 that major ICT-related incidents be reported to the financial supervisor in three phases. Delegated Regulation (EU) 2025/301 sets the deadlines: initial notification within 4 hours of classification as major and never more than 24 hours after becoming aware, intermediate report at 72 hours and final report one month later.
In Spain, the draft Cybersecurity Coordination and Governance Act, which transposes NIS2, was approved by the Council of Ministers on 14 January 2025 and, as of the last regulatory review of this section (October 2026), has not been published in the BOE (the official gazette). The practical reference remains the National Guide to Cyber Incident Notification and Management (in Spanish): INCIBE-CERT for the private sector, CCN-CERT for the public sector and ESPDEF-CERT for defence. The context (who NIS2 applies to, governance, supply chain) is in NIS2: what it requires, deadlines, penalties and how to comply; the clock step by step, in NIS2 incident notification: what to send at 24 h, at 72 h and after one month (in Spanish).
Almost every organisation already has an incident register: a shared sheet, a chat and the emails to the provider. What they do not have is proof that the early warning went out before the 24 hours. When the CSIRT or the auditor asks for the file, the same gaps appear:
A useful register does the opposite: it forces the significance decision at detection, turns the deadlines into mandatory fields with evidence and separates who manages from who approves. Dokuflex does not notify for you and does not decide whether you comply: it gives the traceability and evidence with which your organisation proves it did so in time. If you are still on the spreadsheet, at least have it carry the three dates: the free Excel NIS2 incident register template calculates the 24-hour, 72-hour and one-month limits from the moment of awareness (the template is in Spanish).
The Cybersecurity incidents (NIS2/DORA) module is a complete Dokuflex process. What follows are the real fields and rules, as they come configured; everything can be changed with the low-code designer without coding.
Each incident receives an INC-{seq} number and a status (Detected, Under containment, Notified, Under recovery, Final report, Closed). Detection: title, severity (Low to Critical), date and time of detection, source (SIEM/EDR, user, provider, CSIRT/INCIBE, customer), type (ransomware, phishing, data leak, denial of service, exploited vulnerability, ICT provider failure…), affected systems, personal data and ICT provider involved. Impact and classification: significant incident (NIS2 Art. 23), applicable framework (NIS2, DORA, both, none), cross-border impact, users affected, hours of disruption, financial impact and essential services affected. Notifications (24 h / 72 h / 1 month): authority notified (INCIBE-CERT, CCN-CERT, ESPDEF-CERT, DORA financial supervisor, AEPD), reference assigned, communicated to those affected, the three dates and the receipt. Response and closure: security officer / CISO, containment, root cause, corrective measures, recovery, lessons learned and evidence.
Critical severity marks the incident as significant automatically, and a significant incident requires authority notified, early warning (24 h) and notification (72 h). An ICT provider involved requires its name. Under containment, containment measures are mandatory; under recovery, corrective measures are. Moving to Final report or Closed requires the final report date (1 month) and the root cause; Closed also requires the closure date. The form reminds you of the NIS2 and DORA deadlines and, if personal data is involved, the 72-hour breach notification to the AEPD, which is handled in the GDPR data subject rights and breaches module.
With Start management the incident enters the flow. The Approve incident closure step is decided by the security officer: if approved, it is closed and finalised; if rejected, it goes back to recovery with the reason in the history. Every transition is recorded with user and date and notified by email.
Four cards (Detected, Critical, NIS2 significant and Closed), a grid exportable to Excel with type, severity, framework, detection and notification (72 h) dates, flow status and officer, a kanban board by status and six charts: type, severity, status, detection source, incidents per month and applicable framework.
A security incident register template is only useful if it collects what the CSIRT, the financial supervisor or the auditor may later ask for. These are the five blocks of the module, as they come configured:
There is no need to build it in Excel: the DKF-P034 · Cybersecurity incidents (NIS2/DORA) template brings these fields already configured, with the 12 automatic rules and the closure workflow; it also covers DORA, ISO/IEC 27035 and Spain's ENS, and activates for free in your account.
As NIS2 incident notification software, the module does not replace submission through the CSIRT's official channels: what it does is prove that each submission went out on time. This is how a significant incident travels through the module, from detection to closure:
In a financial entity the journey is the same with the DORA deadlines: initial notification within 4 hours of classification as major, intermediate report at 72 hours and final report after one month. What to send at each milestone is explained in the step-by-step NIS2 guide to the notification clock (in Spanish).
It is activated from the module catalogue of your Dokuflex account, in the Regulatory compliance group, in under a minute. It is also in the template catalogue (DKF-P034).
Four panels, INC-{seq} numbering, six statuses and a built-in legal deadline reminder.
Significant by severity, mandatory authority and dates, root cause before closing.
Approved or rejected with history; rejection sends it back to recovery.
Detected, critical, significant and closed; exportable grid; board by status.
Type, severity, status, detection source, incidents per month and applicable framework.
Ransomware, phishing, provider outage, CVE in the VPN, lost laptop and brute force against the ERP, with tours of the form, the list and the dashboard.
The module is used the same way in an essential or important entity subject to NIS2, in a financial entity under DORA and in the ICT provider that both require to report immediately.
Essential entities in the NIS2 Annex I sectors. Significant incident with early warning to INCIBE-CERT within 24 hours, essential services affected and cross-border impact documented from the first record.
Financial entities subject to DORA: "DORA" or "Both" framework, "Financial supervisor" authority, 4 h / 24 h / 72 h / 1 month deadlines and ICT provider involved by name. See Dokuflex for banking and finance.
Notification to CCN-CERT and evidence aligned with incident management under Spain's ENS. Fits with the ENS Medium document management system to keep forensic reports and receipts.
Important entities in Annex II and third parties, including SMEs supplying essential entities, whose customers require them to report immediately. One incident per customer affected, with communication to those affected and the authority's reference, to answer the supply chain audit.
Many incidents do not start in-house: a provider outage, a vulnerability in a third party's software or unauthorised access from a managed service. NIS2 includes supplier security among its risk management measures and, under both NIS2 and DORA, you have to know which third party was involved in each incident.
In the module, the "ICT provider failure" type and the ICT provider involved field are part of the detection panel, and a rule requires the provider's name when one is involved. Each incident is thus linked to its third party, and the register gives NIS2 supplier management and the critical supplier audit the history of what failed, when and how it was closed. The module does not score or assess your providers: if you use a third-party risk management tool, the register supplies it with the evidence of what happened.
To document the notifications under Article 23 of NIS2 or Article 19 of DORA you do not always need a GRC suite: what is used day to day is a register that turns the deadlines into mandatory fields, keeps the receipt of each notification and records who approved the closure. That is what the free Dokuflex module does, with no card and no implementation project, on a platform with ISO 27001, aligned with Spain's ENS Medium level (certification in progress) and hosted exclusively in the European Union (Frankfurt, Madrid and Ireland).
If you also need a complete ISMS (ISO 27001 risk analysis and controls), business continuity or continuous supplier assessment, a GRC platform makes sense and you can combine it with Dokuflex: the list exports to Excel and Dokuflex connects to the rest of your stack through the low-code iPaaS with 200+ connectors and REST API.
The incident response plan says who does what: roles, escalation, communication channels, criteria for declaring a significant incident and playbooks by attack type. It is your document, and the module does not replace it. The register is the piece that plan needs to leave a trail: each incident with its detection, its classification, its notifications, its root cause and its approved closure. Under ISO/IEC 27001:2022 it is the evidence for controls 5.24 to 5.28 of Annex A (planning, assessment and decision, response, learning and evidence collection); under Spain's ENS, for the incident management measure (op.exp.7) and its register. The procedure and the forensic reports are kept as controlled documents in the ENS Medium document management system; the register references that procedure and proves it was followed.
The register sits alongside the other Dokuflex regulatory compliance modules (GDPR breaches and data subject rights, AI systems register (AI Act), ISO 9001 nonconformities and corrective actions register and KYC file and customer due diligence (Law 10/2010)) and with the ENS Medium document management system to keep forensic reports and receipts. If you want to bring other processes to Dokuflex, see the Dokuflex plans and pricing.
Article 23 of Directive (EU) 2022/2555 sets three milestones for significant incidents: early warning to the CSIRT or the competent authority within 24 hours of becoming aware of the incident, incident notification with an initial assessment of severity and impact within 72 hours, and a final report no later than one month after that notification. If the incident is still ongoing after one month, a progress report is submitted and the final report one month after it is handled.
Under Article 23(3) of the Directive, an incident is significant when it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or when it has affected or is capable of affecting other persons by causing considerable material or non-material damage. In the Dokuflex module, Critical severity marks the incident as significant automatically; for the rest, the officer decides in the form itself.
Article 19 of Regulation (EU) 2022/2554 requires major ICT-related incidents to be reported to the financial supervisor in three phases, and Delegated Regulation (EU) 2025/301 specifies the deadlines: initial notification within 4 hours of classifying the incident as major and at most 24 hours after becoming aware, intermediate report within 72 hours of the initial notification and final report one month after the intermediate report. The module lets you state the applicable framework (NIS2, DORA, both or none) and record the financial supervisor as the authority notified.
According to Spain's National Guide to Cyber Incident Notification and Management, INCIBE-CERT is the reference CSIRT for the private sector and citizens, CCN-CERT for the public sector and ESPDEF-CERT for defence. Financial entities also report to their supervisor (Bank of Spain, CNMV or DGSFP) under DORA, and if personal data is affected, the 72-hour notification to the AEPD is opened. The module's authority drop-down holds exactly these options.
No. The module records the incident, requires the authority and the early warning and notification dates to be filled in when the incident is significant, keeps the notification receipt and the reference assigned by the authority, and leaves a trace of who took each step and when. Submission is made through the official channels of each CSIRT or supervisor; the module is the register that proves it was done on time.
To prove the Article 23 deadlines it is worth collecting the date and time of detection, the decision on whether the incident is significant, the applicable framework (NIS2, DORA or both), the authority notified with reference and receipt, the dates of the early warning (24 h), notification (72 h) and final report (one month), the ICT provider, the root cause and who approved the closure. In Dokuflex all of them are fields of the form.
It is reported through the official channels of INCIBE-CERT (private sector) or CCN-CERT (public sector), according to Spain's National Guide to Cyber Incident Notification and Management. In the Dokuflex register remain the authority, the early warning and notification dates, the CSIRT's reference and the receipt. The module does not send the notification, but a significant incident cannot be saved without the authority and those two dates.
Yes, as a register: the applicable framework accepts DORA or both, the authority can be the financial supervisor (Bank of Spain, CNMV or DGSFP), the form reminds you of the Delegated Regulation (EU) 2025/301 deadlines (4 h, 24 h, 72 h and one month) and the ICT provider involved is recorded by name. Submission to the supervisor is made through its official channels; the module keeps the reference and the receipt.
Yes. The module does not replace your management system or your incident response procedure: it provides the register with evidence, dates and closure approval that you can present in an audit. The DKF-P034 template also covers DORA, ISO/IEC 27035 and Spain's ENS, and forensic reports and receipts can be kept in the Dokuflex ENS Medium document management system.
The module is free. It is activated from the module catalogue of any Dokuflex account, in the Regulatory compliance group, in under a minute: form, list with cards and grid, kanban board by status, dashboard with six charts, closure approval workflow, 12 automatic rules, six sample incidents and three guided tours. Everything can be modified with the low-code designer.
You choose the "ICT provider failure" type and state the ICT provider involved in the detection panel; when a provider is involved, the form requires its name. The incident follows the same NIS2 or DORA deadline and closure approval circuit, and is linked to that provider as evidence for the supplier audit.
Yes. The DKF-P034 template activates with the fields, the 12 automatic rules and the closure approval workflow already configured, and everything can be changed with the low-code designer without coding to adapt the fields to your procedure. It includes six sample incidents and three guided tours to try it before recording real cases.
The data is hosted exclusively in the European Union (Frankfurt, Madrid and Ireland), on a platform with ISO 27001 and aligned with Spain's ENS Medium level (certification in progress), and support is in Spanish. It matters because the register holds sensitive information: affected systems, root cause, evidence and receipts of the notifications to the CSIRT or the financial supervisor.
It depends on what is meant by mandatory. Directive (EU) 2022/2555 set 18 October 2024 as the date from which member states had to apply their transposition rules, but a directive does not impose obligations directly on companies: in Spain they depend on the transposition act (the Cybersecurity Coordination and Governance Act), whose draft was approved on 14 January 2025 and which, as of October 2026, has not been published in the BOE. In the meantime, Royal Decree-Law 12/2018 (NIS1) and the ENS for the public sector and its providers remain in force, and DORA, being a regulation, has applied directly to financial entities since 17 January 2025. The 24 h, 72 h and one-month deadlines will be those in the act, because they come from the Directive; having the register ready avoids starting from scratch when it is published.
Article 20 of the Directive requires the management bodies of essential and important entities to approve the cybersecurity risk management measures of Article 21, to oversee their implementation and to follow training on the subject, and provides that they can be held liable for infringements. Incident handling is one of those measures (Article 21(2)(b)), so management needs evidence that it exists and works: the closure of each incident approved by the security officer and the dashboard with incidents by type, severity and month are part of that evidence.
It provides evidence for controls 5.24 to 5.28 of Annex A of ISO/IEC 27001:2022: incident management planning and preparation (5.24), assessment and decision on security events (5.25, the decision on whether the incident is significant), response (5.26, containment, corrective measures and recovery), learning from incidents (5.27, lessons learned and root cause) and collection of evidence (5.28, attachments and receipts). The procedure and the response plan remain your documents; the register proves they were applied.
Guidance prepared by the Dokuflex Editorial Team. To determine whether your entity falls within the scope of NIS2 or DORA and which authority applies to you, consult your legal adviser or your reference CSIRT. More on how we protect data in the Trust and Security Centre.
Activate the module in your Dokuflex account, load the six sample incidents, take the tour and adapt the fields to your procedure. Free and with no card.