NIS2 Incident Reporting Within 24 and 72 Hours: Procedure, Accountability and Readiness Testing

A procedure for reporting incidents within 24 and 72 hours cannot begin with a form or end with assigning responsibility to IT. Its effectiveness depends on when the organisation considers itself aware of an incident, who assesses its impact, who makes the reporting decision, and whether a notification can still be prepared and submitted with incomplete information, key personnel unavailable or core systems offline. Readiness must therefore be designed as a cross-functional process and validated through a time-pressured exercise.

Why the clock may start earlier than management expects

The reporting period should not be treated as starting only after full technical confirmation or once the matter reaches the person authorised to submit the notification. The organisation must distinguish between an event—an observed anomaly or warning—and a security incident affecting the confidentiality, integrity, availability or authenticity of assets and services. A further threshold is reached when an incident meets the statutory reporting criteria. Not every alert therefore activates the 24- and 72-hour process, but every signal should be assessed against defined criteria.

The greatest risk of delay arises when the procedure does not define when the organisation is considered to have become aware of an incident. The first information may reach a service desk, production-line operator, system administrator, service provider or customer service team. If the clock is treated as starting only when a board member or security coordinator is notified, an artificial gap is created between the organisation’s actual recognition of the disruption and its formal response. The procedure should therefore identify internal and external reporting sources, escalation criteria and the role responsible for deciding whether a disruption has crossed the threshold of an ordinary failure.

If a provider maintaining a production system informs the service desk about a loss of availability and suspected external activity, the cause, full scope and expected recovery time may still be unknown. This does not justify waiting for the final technical report. Escalation can be based on the time the signal was identified, the affected services and locations, the observed impact, potential consequences and mitigating actions already taken. Using this information, an authorised person should perform a preliminary assessment and document the decision to activate—or not activate—the regulatory reporting route.

The 24- and 72-hour stages should be treated as the progressive development of knowledge about the same incident. An early warning is first submitted on the basis of the information available, followed by a more detailed assessment as further facts are established. These are not two unrelated administrative obligations. The applicable deadlines, qualification thresholds and reporting channels must always be confirmed against current national legislation implementing NIS2 and the requirements of the competent authority, rather than relying solely on the Directive. The effectiveness of the adopted arrangements can be evaluated through the NIS2 audit in a manufacturing company—how to assess whether the organisation is ready for the new obligations.

Where organisations lose the first critical hours

The first hours are often lost not to technical analysis, but to waiting. A ticket remains in the service system, the out-of-hours contact route does not work, a supplier is preparing its opinion, departments dispute the scale of the impact, or the person authorised to make the decision is unavailable. Manual consolidation of information from multiple sources creates further delay. The problem typically arises at the interfaces between IT, operational technology, production, quality, legal, communications, data protection, procurement and senior management, because each function holds only part of the evidence.

In a manufacturing business, loss of access to a planning system combined with instability affecting some equipment does not immediately provide a complete picture. It may indicate failure across interdependent systems, disruption to operational technology or an incident with a wider scope. The organisation should protect operations and production continuity while simultaneously identifying affected assets and locations and progressing the escalation. Technical containment must not wait for a formal reporting decision, but the reporting decision should not be postponed until the cause has been established or the disruption fully resolved.

Bottlenecks are best exposed through a scenario-based exercise that includes an overnight incident and the unavailability of a key person. The organisation should measure the time from the initial signal to escalation, assessment, contact with the decision-maker and collection of the minimum information set. Contracts with ICT service providers should also be tested. A supplier may support the preparation of information, but submitting a notification on the organisation’s behalf requires a clear basis, appropriate authority and alignment with the approved procedure. Maintaining the system does not, by itself, transfer accountability.

Readiness assessment should cover the whole organisation, not only IT: roles, information flows, suppliers, operational technology and crisis management. Evidence that these arrangements operate effectively should be consistent with the scope described in NIS2 and KSC documentation before an inspection: which policies, registers and evidence are actually required.

From the initial signal to a submitted notification

The procedure should take the organisation from the first signal to documented submission without making the decision dependent on completion of the technical investigation. The workflow should cover receipt of the signal, recording its time and source, preliminary assessment, preservation of evidence and evaluation of the impact on the service. Escalation is then initiated, a decision is made, the communication is prepared and submitted through the correct channel, and proof of submission is retained. Every stage requires an owner, a deputy, an internal deadline and a defined record. Internal deadlines must leave sufficient time for approval and resolution of submission problems rather than coinciding with the statutory limit.

At the first stage, within 24 hours, the organisation needs a minimum set of verified information: identification of the entity, time of detection, affected service, observed effects, known scope and actions taken. Uncertain information should be clearly marked as preliminary, with its source and intended method of verification recorded. Lack of knowledge about the cause, full scope or end time should neither lead to a misleading appearance of completeness nor automatically prevent submission. The procedure must define who approves the notification, who acts as deputy and how previously submitted information is updated.

If a site loses access to the system controlling order fulfilment, the coordinator records the alert, detection time and user reports while the technical team secures event logs and contains the effects. The service owner evaluates the impact on production, logistics and customers, while the designated decision-maker determines the reporting obligation from the available evidence. If the incident is ongoing, the recording system is unavailable or the supplier is the source of the event, the prepared fallback channel should be used without waiting for a final report. In a group comprising several companies, the affected services, entity-specific jurisdiction and authority to act for each entity must be established separately.

By the 72-hour stage, the organisation supplements its assessment of the nature and severity of the incident, its impact, available indicators of compromise and mitigation measures—to the extent required by the currently applicable legislation and reporting forms. If later findings change the scale, cause or classification of the event, the earlier information should be corrected through a controlled process rather than overwritten without an audit trail. Before implementing the procedure, the organisation should therefore confirm the authority or incident response team applicable to its entity category, the reporting channel, the rules for calculating deadlines, and the requirements for updates and subsequent reporting. The entities in scope are discussed in more detail in NIS2 for manufacturing companies: who is covered, what obligations apply and how to prepare the organisation without treating NIS2 as an IT-only issue.

A single incident record should provide the basis for information management. It should contain the timeline, successive versions of findings, data sources, decisions and their rationale, the content of communications and proof of submission. Email and messaging tools may be used for alerts, but they should not create parallel versions of the incident narrative. Process readiness should be measured through the elapsed time from signal to registration, escalation, decision and submission, the proportion of entries with identified sources, and the ability to reconstruct who changed the incident assessment, when and on what basis.

Roles, deputies and decision thresholds

The reporting process requires clear separation of tasks, accountability and authority. The person detecting the event records it and initiates escalation. The incident coordinator maintains the timeline and manages information flow, while the technical specialist evaluates the nature of the event and preserves relevant data. The service or process owner determines the operational impact, a person with appropriate legal competence assesses the notification obligation, the approver makes the reporting decision, and an authorised employee submits the notification and retains evidence of submission. One person may perform several roles, provided this does not obscure decision authority or create a single point of dependency.

A responsibility matrix becomes useful only when it identifies more than job titles. It should specify the task, required response time, decision-making authority, deputy and expected evidence of completion. It should also establish who may decide on the basis of incomplete information and how conflicts between production continuity, security and reporting obligations are resolved. Senior management approves the response model, escalation thresholds and available resources. It cannot transfer the entire decision risk to a systems administrator or quality representative, who will not usually have the mandate to determine business and legal consequences.

Not every notification must be approved by a board member if the organisation’s authority model provides an appropriate delegation or authorisation consistent with the requirements applicable to the entity and reporting channel. Deputy arrangements require the next person in the sequence to be named, 24/7 contact details to be available and a rule defining when responsibility transfers after an unsuccessful contact attempt. The deputy must have genuine access to the incident record, reporting form, mailbox, required electronic signatures and fallback channel. A statement in the procedure does not ensure continuity if the corresponding permissions have not been granted.

If an incident occurs overnight, the coordinator should not wait indefinitely for the designated approver. Once the internal contact limit expires, the coordinator contacts the deputy and then the person authorised to make an emergency decision. Internal deadlines should be materially shorter than the external deadlines, preserving contingency for data checks, legal assessment, approval, technical difficulties and documentation of submission. The times from detection to escalation, decision and submission should be measured during exercises.

This model requires funding for on-call arrangements, access rights, training and tools. It should therefore be reflected in the planning discussed in How much NIS2 and uKSC implementation costs—building a budget for audits, documentation, training and safeguards without costly mistakes. Relying on a single decision-maker or a single holder of the necessary permissions is a false economy: during an incident, organisational unavailability becomes the direct cause of formal delay.

An exercise that reveals actual readiness

Readiness to report an incident is not demonstrated by familiarity with the procedure. It is demonstrated by the ability to execute it under time pressure and with incomplete information. The exercise scenario should release information progressively. The initial signal may be ambiguous, some systems and documents may be unavailable, the supplier may respond late, and the operational impact may increase with each new inject. This design shows whether the organisation can begin escalation without waiting for a complete technical analysis.

The exercise should follow a realistic timeline, recording when the signal is received and logged, passed to the coordinator, reviewed by the assembled team, initially classified, converted into draft notification content, approved and tested for submission. The test should not result in a real notification unless a safe test environment and data-labelling method have been agreed in advance. Involvement of external parties requires a separate decision. A supplier should be included where its information, access or action is essential to classifying the incident. Senior management should participate at least in a scenario requiring a business decision, acceptance of risk or activation of deputy arrangements.

A sample scenario might begin with a report of production-system slowdown. The facilitator then reveals that access to event logs has been lost, the approver is unavailable, data on the number of affected processes is inconsistent and the supplier is not responding. Observers should not prompt the team; they should record actual times and evidence. They assess how quickly the signal reaches the coordinator, whether deputies are available, how many responsibilities remain unclear, whether the timeline is complete, where sources conflict and whether the fallback channel can be used. They should also record roles without deputies, missing permissions and outdated contact details.

The evaluation should not be limited to whether a draft notification was completed before the internal deadline. It should verify whether participants:

• distinguished verified facts from assumptions,
• identified information sources,
• documented the basis for classification,
• marked information requiring later completion,
• activated deputies in line with the approved rules,
• could use the fallback reporting channel.

The team’s performance under uncertainty is also an important outcome. Participants should neither classify every disruption automatically as a reportable incident nor delay escalation until the full technical investigation has been completed.

The exercise should conclude with a corrective action plan, not merely a report. Every gap requires an owner, a completion date, a measurable effectiveness criterion and identification of the element to be retested. The organisation should monitor the proportion of actions closed and effectively verified within its agreed timeframe. The frequency of future exercises and changes to the scenario should be based on risk, previous results and organisational change. New roles, suppliers, systems or reporting channels—and any significant weakness—provide particular grounds for an additional test. These arrangements should be aligned with the schedule described in NIS2 implementation after entry in the KSC register—action plan to 3 April 2027.

Minimum standard for management readiness

Senior management should consider the incident reporting process operational only after approving its complete organisational framework. This includes the procedure, escalation criteria, an up-to-date contact list, assigned roles and deputies, access to primary and fallback reporting channels, communication templates, a single incident record, rules for preserving and retaining evidence, and a completed exercise. The absence of any of these elements should be treated as an operational risk, not as an editorial gap in the documentation.

The evidence of readiness is not the number of approved documents, but a coherent audit trail from event detection through assessment and decision-making to preparation and submission of the notification. It should identify times, information sources, decision-makers, the basis for classification and the content communicated to the relevant body. The organisation must also demonstrate that it can operate when key personnel are unavailable, primary systems have failed and access to data is restricted.

The exercise should be followed by a management review that converts findings into decisions before an audit or inspection. Within the limits of their authority, the process owner may improve the instruction, incident record or contact list. Senior management should decide on gaps requiring acceptance of residual risk, funding, additional resources or revised accountability. Every action requires an owner, a deadline and a scheduled date for verifying effectiveness.

Incident reporting should be integrated into the wider implementation plan, with current deadlines and requirements verified in each case. The maturity assessment should also consider NIS2 and ISO 27001: what certification provides and what may still be missing for KSC compliance. An organisation is ready only when it can make, execute and evidence the appropriate decision within a limited timeframe and on the basis of incomplete information.