Security automation for NIS2 incident reporting deadlines starts with the 24-hour clock
NIS2 asks essential and important entities to prove they can move through a fixed reporting sequence after a significant incident, and automation can help a great deal with the first step. Under Article 23(4), an entity must submit an early warning without undue delay and within 24 hours of becoming aware of a significant incident. That early warning should say whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. Within 72 hours, the entity must submit an incident notification that updates the early warning and gives an initial assessment of severity, impact and, where available, indicators of compromise. A final report follows no later than one month after the notification. An intermediate report is due only when the CSIRT or competent authority asks for it. Trust service providers face a stricter variant: they must notify significant incidents affecting their trust services within 24 hours instead of 72.
The clock starts when the entity becomes aware of the incident, so the detection and triage path is where the deadline is won or lost. A Shuffle playbook can be triggered from alerts in your SIEM or EDR, enrich the event with asset ownership and threat intelligence, check whether the affected systems fall in scope, and page the people who must decide on significance, all within minutes. Recital 102 asks that the early warning contain only what is needed to make authorities aware and let you seek help, so the automated draft should be short and fill in fields such as the suspected cause and cross-border indicators from data you already hold. Decide now who approves the early warning, which mailbox or portal it goes to, and how the timestamp of awareness is recorded, because that timestamp is what you will be asked to defend.
NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34, and essential entities face ex ante supervision while important entities face ex post supervision. Your evidence is therefore the record of how each report was produced, not a badge. Ask your national transposition law and competent authority what format and channel they expect, because implementing detail varies by Member State. The Commission's 20 January 2026 proposal, COM(2026) 13, would amend NIS2, including a new small mid-cap category, but it still needs approval by the European Parliament and the Council, so confirm its status before you design around it.
Mapping Article 23 and Implementing Regulation 2024/2690 to Shuffle playbook steps
This table maps each NIS2 Article 23 reporting step, the trust service variant and the significant incident criteria in Implementing Regulation 2024/2690 to what the function must produce and how to build it in Shuffle with Wazuh or Security Onion inputs. Read each row as a design requirement: the clock starts at awareness, so the workflow must timestamp that moment and stage the outputs. Main takeaway: the 24-hour early warning should be a short, automated draft that a human confirms, while the 72-hour notification and one-month final report depend on evidence the playbook collects as the incident unfolds.
| Requirement | What the function must do | How to configure Shuffle and alert inputs |
|---|---|---|
| Article 23(4)(a): early warning within 24 hours | Record the time of awareness, state whether malicious or unlawful acts are suspected and whether cross-border impact is possible, using minimal information | Trigger from a Wazuh alert or Security Onion Suricata alert with a high-severity rule; start a timer step at awareness; a template step fills the suspicion and cross-border fields for analyst approval |
| Article 23(4)(b): notification within 72 hours | Update the early warning, give an initial assessment of severity and impact, and list indicators of compromise where available | Enrichment actions pull affected hosts, users and IOCs from the SIEM; a timer step at 72 hours from awareness raises an escalation if no approved notification exists; the IOC list exports from the case record |
| Article 23(4)(c): intermediate report on request | Provide status updates when the CSIRT or competent authority asks, from the same case record | Use a manual trigger or approval-gated workflow that exports the current case timeline and status without re-running containment actions |
| Article 23(4)(d): final report within one month | Describe severity, impact, threat type or likely root cause, mitigations applied and ongoing, and any cross-border impact | Scheduled reminder at the one-month mark from the notification; a report template step pulls the action log, approvals and enrichment results from the case record |
| Article 23 trust service variant: 24-hour notification | Trust service providers notify within 24 hours of awareness instead of 72 hours, so the notification timer must be set differently for that entity type | Use a per-tenant or per-workflow variable that sets the notification timer to 24 hours; confirm the classification with counsel and the national authority before deploying |
| Implementing Regulation 2024/2690: significant incident criteria | Decide whether an event meets the significant incident criteria for the entity's service type, which the regulation sets for DNS, cloud, data center, managed and other providers | Classification step scores alerts against documented criteria and routes only matching events to the reporting path; an analyst approval gate records the decision and its rationale |
| Approval gates and evidence trail | Show who approved each report, when it was sent and what automated actions ran, since an assessor will sample this record | Require human approval before any external submission; log each Shuffle workflow execution and output; confirm retention with the case management and log platform before go-live |
Which Shuffle deployment fits a reporting team
A single server running Shuffle under Docker Compose is the simplest option to stand up and the easiest to reason about. Everything, including the frontend, the backend API, the OpenSearch document database and the Orborus runtime, sits on one host. That simplicity is also its main weakness for reporting: if the host sits inside the same network or identity domain an attacker has reached, the tool that files the report may be affected by the incident it is reporting.
- Continuity: One host means one failure point. A compromised hypervisor, disk or admin account takes out detection, enrichment and reporting together.
- Inbound firewall needs: Analysts reach the backend on port 5001 and the frontend through your proxy, so inbound rules must be scoped to the reporting network.
- High availability: The configuration docs recommend an OpenSearch cluster, several backends and more than one Orborus node. A single server cannot meet that guidance.
- Credential safety: Saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, so back up that secret separately from the host.
- Best fit: Pilots and non-critical playbooks, not the sole route for a 24-hour early warning.
Confirm with your own architecture team whether the host can sit outside the production identity domain and how restoration is tested before you rely on it for regulatory deadlines.
Docker Swarm spreads the Shuffle services across several servers, which gives you more than one place to run backends and workers. The architecture documents describe it as a distributed option, and the configuration docs' high-availability advice (shared cache, shared files and several backends) applies most directly here. For a reporting team, the main design question is which nodes sit in which network zone.
- Continuity: Several nodes allow the backend and frontend to be scaled across servers, so one node failing does not stop every workflow.
- Inbound firewall needs: Swarm manager and worker traffic must be restricted to the cluster network, and only the user-facing ports should be reachable from analyst networks.
- High availability: Plan an OpenSearch cluster rather than a single document store, and run more than one Orborus node so executions continue if one fails.
- Shared state: The docs mention NFS for shared files when several backends run, which adds a dependency you must also keep available during an incident.
- Placement: Spread nodes across failure domains, and keep at least one worker outside the segment most likely to be affected.
Confirm how your team will rebuild the Swarm if managers are compromised, since a clustered control plane can spread a compromise as easily as it spreads load.
The hybrid model keeps a local Orborus worker in your environment while the management plane runs in Shuffle Cloud. The architecture docs state that the local Orborus needs no inbound firewall ports because it polls the backend for jobs. For reporting, this can separate the place where the report is authored from the environment that may be under attack, but it also means a dependency on an external service you do not operate.
- Continuity: The cloud control plane can keep the workflow definitions and case flow reachable while your internal network is isolated, provided the local worker can still reach it.
- Inbound firewall needs: None for the local Orborus, since it makes outbound polling connections. This is the strongest argument for this model in segmented networks.
- Data residency: Confirm where execution data, logs and saved credentials are stored before sending any incident detail to a cloud tenant, given NIS2 and any national rules on processing.
- High availability: Run more than one local Orborus node so workflows keep executing if one fails.
- Dependency: Cloud availability and terms become part of your reporting chain, so confirm the service commitments in writing.
Confirm with the vendor which data leaves your environment, how SSO is enforced for the tenant, and what happens to queued executions during a cloud outage.
Shuffle documents Kubernetes deployment with Helm charts. This suits organizations that already run a hardened cluster with policy, secrets and monitoring in place, and that want the reporting workflow to follow the same change and recovery processes as other platforms. The cluster itself becomes part of the security boundary, so its administration must be separated from the SOC's reporting path.
- Continuity: Replicas, health checks and rescheduling can restore backends and workers after a node loss, which fits the requirement for reporting to continue.
- Inbound firewall needs: Expose only the ingress path analysts require, and use network policies to limit pod-to-pod traffic to what the workflows need.
- High availability: Pair the backend and frontend replicas with an OpenSearch cluster and several Orborus workers, as the configuration docs recommend.
- Blast radius: A cluster-admin compromise affects every namespace. Keep a dedicated namespace and separate credentials for the reporting stack.
- Skills: Cluster operations need staff who can run and recover Kubernetes under pressure, which is a recurring cost to plan for.
Confirm the Helm chart version you will deploy, how you will rebuild the cluster from backups in a separate account, and who holds the encryption secret outside the cluster.
Open-source platforms that feed and run NIS2 reporting
NIS2 reporting depends on evidence collected while the incident is still moving: alerts, network traces, indicators and identity records. The platforms below cover that chain, from detection and network evidence through threat intelligence to the automation that assembles the early warning, notification and final report.
Shuffle for playbooks and reporting steps
Shuffle runs the workflows that gather alert context, enrich indicators and draft the 24-hour early warning, 72-hour notification and one-month final report. It is licensed under AGPL-3.0, so self-hosting and any modification you distribute carry source obligations to confirm with counsel. Check how app runs are counted for your expected alert volume, and who maintains the playbooks when a connected tool changes its API.
Wazuh for alerts and agent inventory
Wazuh provides the alert stream and the endpoint software inventory that show which systems were affected and when. Its core is licensed under GPL-2.0, and its dashboard includes prebuilt views for compliance frameworks such as HIPAA and NIST 800-53, which are not NIS2 views. Confirm that agent coverage reaches the systems in your NIS2 scope, including those in offline or segmented networks.
Security Onion with Suricata and Zeek
Security Onion bundles Suricata for network intrusion detection and Zeek for network analysis, producing the traffic records that show how an intrusion moved and whether cross-border systems were involved. Security Onion is licensed under the Elastic License 2.0, which has terms to review before commercial use. Sensor placement decides what the evidence can show, so confirm where taps or mirror ports can be installed in your network.
MISP and OpenCTI for indicators
MISP and OpenCTI hold the indicators of compromise that the notification must include where they are available, and they record what was shared with sector or national CSIRT communities. MISP is licensed under AGPL-3.0, while OpenCTI Community Edition is under Apache 2.0 and its Enterprise Edition is under a separate license. Decide which platform is the system of record for indicators so the figures in the report match what was sent.
Keycloak for SSO into Shuffle
Keycloak can provide OpenID Connect single sign-on to Shuffle, so analysts who draft and approve reports are identified and their actions are attributable in the audit trail. Keycloak is licensed under Apache-2.0. Check which Shuffle SSO method your version supports, confirm that SAML is being deprecated on Shuffle Cloud, and plan how reviewers and the emergency access account are managed.
Building the reporting playbook in phases
The sequence turns NIS2 reporting from a memo that someone remembers under pressure into a tested Shuffle workflow with named owners, evidence capture and approval gates. Each phase closes with an artifact the reader can show an assessor or a national authority.
Confirm significant incident criteria with counsel
Legal counsel, the CISO and the compliance lead agree which events count as significant under the national transposition law and Implementing Regulation (EU) 2024/2690, if your sector is covered by it. Record the criteria, the decision owner and the national competent authority or CSIRT you report to. The output is a signed criteria note that the playbook logic will reference, so every trigger has a documented basis.
Map alert sources and owners
List every source that can reveal an incident, including the SIEM, EDR, identity provider, cloud audit logs, network sensors and vendor notifications, and name the team that receives each one. Note which sources are reachable from Shuffle and which need a connector or a custom app built from an OpenAPI specification. The output is a source register that shows where the reporting clock can start, and who must be reached out of hours.
Build the clock and reminder workflow
Create a Shuffle workflow that records the time the entity became aware of a potential significant incident, then issues reminders against the 24-hour early warning and 72-hour notification deadlines in Article 23(4). The workflow should write its timestamps to the case record, not to a chat thread. Test it with a synthetic alert so the timestamps and reminders are confirmed before any live use. The output is a tested timer with a logged start time.
Draft the early warning template
Write the early warning template to carry only what Recital 102 expects: whether the incident is suspected of unlawful or malicious acts, and whether it could have a cross-border impact. Keep fields short so responders can complete them within the first hours without diverting effort from containment. The workflow pre-fills known facts from the alert and leaves the rest as marked fields. The output is an approved template stored with version control.
Add enrichment and evidence capture
Add Shuffle actions that enrich the alert with asset ownership, user context and threat intelligence, and that preserve the raw alert, query results and timestamps as evidence. Store each artifact with a hash and a link to the case so the later notification and final report can cite it. Confirm with the security lead which indicators of compromise can be shared, since the notification must include them where available. The output is an evidence bundle that fills the notification fields without manual copying.
Add approval gates before external submission
Insert a manual approval step before any message leaves the organization to the authority. The approver, typically the incident lead with counsel review, confirms the content, the severity assessment and the sender identity. Shuffle should log who approved, when and which version was sent. Confirm that submission credentials for reporting portals are stored under the platform's encryption controls and are limited to the people who need them. The output is a sent-message record tied to an approval.
Test the workflow with tabletop exercises
Run tabletop exercises that walk the team through a suspected significant incident from first alert to early warning, notification and approval, using the playbook as the script. Record which steps were slow, which fields were unclear and where a person had to improvise. Fix the workflow and template, then retest the changed steps. The output is an exercise report with dated findings and the changes they produced, which is evidence assessors commonly ask for.
Add the final report workflow
Extend the case so the final report, due no later than one month after the notification under Article 23(4)(d), draws on the timeline, evidence bundle and approval records already captured. Add fields for severity and impact, the likely root cause or threat type, applied and ongoing mitigations, and any cross-border impact. Ask the team to confirm whether an intermediate report has been requested by the CSIRT or authority. The output is a final report draft generated from the case, reviewed before submission.
Evidence auditors and authorities ask for and which component produces it
This table maps each evidence item a supervisor may ask for after a NIS2 significant incident to what it proves and the component that produces it. Read it as a checklist for designing the playbook, since evidence that is not written during the response is hard to reconstruct later. NIS2 issues no certificate of compliance, so this record supports inquiries from national competent authorities rather than a pass or fail result.
| Evidence item | What it proves | Producing component |
|---|---|---|
| First awareness timestamp | When the entity became aware of a significant incident, which starts the 24-hour and 72-hour clocks under Article 23 | Wazuh alert timestamp, plus the Shuffle trigger time and the case record opened by the playbook |
| Early warning copy and submission time | That the early warning went out within 24 hours and contained the required indicators, such as suspected unlawful or malicious acts and cross-border impact | Shuffle execution log of the submission step, with the sent message and API response stored in the case |
| Incident notification copy and submission time | That the 72-hour notification gave an initial assessment of severity, impact and available indicators of compromise | Shuffle execution log and the stored notification document, versioned in the case record |
| IOC lists and their source | Which indicators supported the assessment, where each came from and when it was enriched | Shuffle enrichment actions against MISP or OpenCTI, plus Wazuh alerts that triggered the lookups |
| Wazuh alert history | Raw detection evidence, rule IDs and affected agents across the incident window | Wazuh indexer, which stores alerts, and the Wazuh server rules that generated them |
| Shuffle execution logs | Which automated actions ran, in what order, with what inputs and outputs, and whether any failed | Shuffle workflow execution records in the OpenSearch backend, including the worker run for each execution |
| Approval records for containment actions | That a person authorized each disruptive or destructive response step before it ran | Shuffle approval steps and the recorded approver identity, reviewed alongside the identity provider log |
| Final report content | Detailed description of the incident, root cause or threat type, mitigation applied and ongoing measures, due within one month of notification | Case record assembled from the timeline, alert history and approvals, reviewed and signed by the entity's staff |
| Access and change records for the playbooks | Who could edit or run NIS2 playbooks and which version was live during the incident | Shuffle workflow version history and SSO audit logs, to be confirmed in the chosen deployment |
Questions buyers ask about NIS2 reporting automation
Can open source software meet NIS2 incident reporting obligations?
Yes, the software does not decide compliance, but open-source tools can cover the reporting workflow. NIS2 Article 23 sets the sequence: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than one month after the notification. A self-hosted SOAR platform such as Shuffle can time these steps, collect the indicators and logs, and assemble the evidence as the incident progresses. Whether a given tool satisfies your national authority is a question for your legal and compliance team, and the national transposition law in each member state applies. Confirm the specific reporting channel and template your competent authority expects before you design the playbook.
What drives the cost of a NIS2 reporting automation project?
The main cost drivers are the number of playbooks, the number and complexity of integrations, and the staffing model. Each playbook needs logic for early warning, notification and final report, plus branches for cross-border impact and malicious versus accidental causes. Each connected tool needs an app or OpenAPI definition, credentials handling and testing. Shuffle's licensing is based on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted, and users, apps and workflows are unlimited, according to Shuffle's pricing article. Higher alert volume therefore raises run-based cost. Ask for a fixed-scope quote that lists playbooks, integrations, environments and who maintains the work after go-live.
How long does implementation take?
The duration depends on the agreed scope, so there is no standard timeline to quote here. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The timeline usually depends on how many reporting paths you need, how many source systems must feed the playbooks, whether a test environment exists, and how quickly your legal and incident response teams can approve the templates. Ask the implementation partner to confirm the milestones, the testing period and the acceptance criteria in the written scope before you commit to a date.
What does the internal team need to provide?
The internal team provides decisions and access. Legal or compliance staff must confirm the significance criteria, the reporting contacts and the templates for each NIS2 stage. Security operations staff must name the alert sources, the escalation paths and the approval roles for any containment action. Platform engineers must provide hosts or cloud accounts, network paths to the tools, and secrets storage for connector credentials. Expect reviews at each stage, because a playbook that sends an early warning with the wrong content is worse than a delayed one. Put these responsibilities into the scope so both sides know who signs off each step.
Can our own team build and run these playbooks without a partner?
A capable security engineering team can build and run Shuffle playbooks, but the deciding factors are skills, time and ongoing capacity. Shuffle apps are built from OpenAPI specifications or written in Python with the Shuffle app SDK, and they run as versioned Docker containers, so someone must own that code. High availability also requires an OpenSearch cluster, more than one Orborus node and shared storage, as the Shuffle configuration docs describe. The team must also keep connectors working as vendor APIs change and test playbooks before each release. Compare the cost of these internal hours with a fixed-scope partner engagement and a retainer for upgrades and testing.
Does automation replace legal judgment on whether an incident is significant?
No. Automation can gather facts, timestamp events and draft the fields of each report, but deciding whether an incident is significant and whether it has cross-border impact is a legal and operational judgment. NIS2 Article 23 leaves that assessment to the entity, and the significance criteria are set out in Commission Implementing Regulation (EU) 2024/2690 for the sectors it covers. Design the playbook so that a named person approves each submission before it leaves your organization, and record that approval in the case file. Keep the human decision points visible in the workflow.
Which NIS2 requirements change the playbook design?
Three requirements shape the design. The early warning should contain only the information needed to make the CSIRT or authority aware, according to Recital 102, so the playbook should not force a full investigation into the first submission. The notification adds an initial assessment and indicators of compromise where available. The final report must describe root cause, mitigation and cross-border impact in detail. Trust service providers face a 24-hour notification instead of 72 hours. Confirm which entity type and sector apply to you before building the timer logic.
What tooling alone does not satisfy in NIS2 reporting
A SOAR playbook can collect evidence and draft the three NIS2 Article 23 reports on time, but several obligations still depend on people making decisions, interpreting national rules and keeping policies current. The cards below cover the parts of reporting that automation prepares but cannot finish on its own.
Significance decisions need a named person
Whether an incident is a significant incident is a judgment made against the criteria in Implementing Regulation (EU) 2024/2690 and the entity's own impact assessment. A playbook can score indicators and flag candidates, but the 24-hour clock starts when the entity becomes aware, so the approver, the escalation path and the time they were notified must be recorded. Check that the playbook has a documented approval step that pages a named role at any hour.
National transposition changes the rules
NIS2 is a directive, so the reporting channel, the authority, the form and some timing details come from each Member State's transposition law. A playbook hard-coded to one country's portal or template can fail in another market where the entity operates. Ask counsel to confirm which national authority and CSIRT receive each report and keep those endpoints in configuration, not in workflow logic.
Pending amendments to the obligations
On 20 January 2026 the Commission proposed targeted amendments to NIS2 in COM(2026) 13, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so the scope and simplification measures that apply to an entity may change. Assign an owner to track the proposal and build playbook templates so that thresholds and entity categories live in reviewable settings.
Final reports need analyst judgment
The final report due no later than one month after notification must describe severity, impact, the likely root cause, applied and ongoing mitigations and any cross-border impact. Automation can gather timelines, affected hosts and indicators, but explaining root cause and judging cross-border effects requires an analyst who reviews the evidence. Confirm that the case record separates machine-collected facts from analyst conclusions, with a reviewer sign-off before submission.
Out-of-hours staffing gaps
Early warnings can fall due at night, on weekends or during public holidays, when the 24-hour clock keeps running. Playbooks can send notifications and create tasks, but someone still has to approve and submit, and to answer follow-up requests from the authority. Check the on-call rota, the backup approver for each role and whether the team can reach the reporting channel from outside the corporate network.
Documented policies under Article 21
Article 21 risk-management measures and the reporting obligations in Article 23 are assessed through the entity's documented policies, procedures and records, not through a tool's configuration alone. Incident response roles, escalation criteria, playbook change control and review dates need written owners and approval history. Ask the implementation partner how playbook versions map to policy versions, and who signs off each change before it runs in production.
How DeployOpen scopes and delivers NIS2 reporting automation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For NIS2 reporting automation, that means a written scope that maps each reporting stage to a Shuffle playbook, built and tested in your environment, then handed over with documentation your team can run and maintain.
How we scope
- Confirm which entity classification applies and which national transposition law sets your reporting contacts and channels
- Map each Article 23 stage to the alert sources, enrichment steps and evidence fields it depends on
- Agree in writing the playbooks, integrations, deliverables and timeline, as engagements are fixed-scope
How we build
- Deploy Shuffle in your chosen architecture, such as Docker Compose, Docker Swarm, hybrid or Kubernetes with Helm charts
- Build playbooks that collect timestamps, affected systems and indicators for the 24-hour, 72-hour and one-month outputs
- Store app credentials with the encryption secret handled under your own key management and tested before production
How we hand over
- Test each workflow against agreed sample incidents and record the results for your review
- Document playbook logic, approval gates, run limits and the steps a reporting owner takes at each deadline
- Train your incident response and compliance staff to run, modify and review the playbooks
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Keep connectors and app versions current as upstream tools and Shuffle releases change
- Review playbooks when national transposition rules or the Commission's NIS2 amendments take effect
Sources and further reading
- NIS2 Article 23 Reporting obligations, EUR-Lex ↗
- Commission Implementing Regulation (EU) 2024/2690, EUR-Lex ↗
- NIS2 Technical Implementation Guidance (June 2025), ENISA ↗
- Proposal for a Directive as regards simplification measures and alignment with the Cybersecurity Act, COM(2026) 13 ↗
- Shuffle architecture docs ↗
- Shuffle configuration docs ↗
