control
incident management
A written way to spot an incident, call it, contain it, report it and learn from it, with named roles. The rules ask for the process and set clocks for reporting. The tool is a place to keep the record.
- what it protects
- the first hours of trouble, when decisions are made on incomplete facts
- who owns it
- head of IT, with a named deputy
- start with
- name who may declare an incident at any hour, and keep the contact sheet off the affected network
what it is
Incident management is the way a company notices that something has gone wrong, decides that it counts, contains it, tells the people who must be told and learns from it. It starts as a written procedure with named people. A tool helps by keeping the record, the timeline and the reporting clocks in one place.
NIS2 lists incident handling as one of its measures and sets the reporting clocks. DORA describes the process in more detail for financial entities. GDPR adds a record for every personal data breach. Each rule starts a clock from a different moment and goes to a different authority, so the process has to cover all of them at once.
The hardest part is the decision to call it an incident, before the facts are complete. Give a named person the authority, and put the reports into the same record as the response.
basis NIS2 Art. 21(2)(b), 23(4); DORA Art. 17(1), 19(1); GDPR Art. 33(5). The roles and the tools are practice.
from noticing a problem to learning from it
- 1noticesomeone sees something odd and knows who to tell
- 2declarea named person, or a deputy, decides that it counts
- 3containstop the spread, keep the timeline in one record
- 4reporteach clock starts at its own moment, each report has an owner
- 5learnroot cause written down before the record is closed
a tabletop at planned intervals tests the same path
basis NIS2 Art. 21(2)(b), 23(4); DORA Art. 17(1), 17(2). The roles and the order are practice.
an example
Picture a company of 200 people whose file server stops answering at night.
The administrator who sees it has no authority to call it an incident, and the manager who has it is on a plane. The procedure sits on the same server. By morning nobody knows when the clock started, and the record is a chat thread.
A named person and a deputy can declare at any hour. The contact sheet exists on paper and on a phone. One record holds the timeline, the decisions and each report with its time stamp. A short tabletop each year shows what nobody could answer.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2)(b) | Incident handling as one of the cybersecurity risk-management measures. | Write the process: who can declare an incident, what happens next and who is told. |
| NIS2 | NIS2 Art. 23(4) | Early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month of the notification. | Build the three reports into the process, with an owner and a deputy for each. |
| IR 2024/2690 | IR 2024/2690 Annex 3.1 | Listed digital providers: an incident handling policy that sets roles, responsibilities and procedures for detecting, analysing, containing, recovering from, documenting and reporting incidents, tested and reviewed. | Use the same list of stages as a checklist for your own process. |
| DORA | DORA Art. 17(1) | Financial entities define, establish and implement an ICT-related incident management process to detect, manage and notify incidents. | Cover the whole path from detection to notification in one process. |
| DORA | DORA Art. 17(2) | Record all ICT-related incidents and significant cyber threats, and follow up so that root causes are identified, documented and addressed. | Keep one record of every incident and write the root cause down before closing it. |
| DORA | DORA Art. 19(1) | Report major ICT-related incidents to the competent authority. | Add the major-incident test and the three report stages to the process. The time limits are in the incident reporting work page. |
| GDPR | GDPR Art. 33(5) | Document every personal data breach, with facts, effects and action taken, so the authority can verify compliance. | Log breaches you decide not to report as well, with the reason. |
basis NIS2 Art. 21(2)(b), 23(4); IR 2024/2690 Annex 3.1 as a reference; DORA Art. 17(1), 17(2), 19(1); GDPR Art. 33(5). What the control has to do is practice.
what to look for when you choose
- Does it keep one record per incident, with a timeline, an owner, a severity and the decisions taken?
- Does it start the reporting clocks from the moment the incident is declared, and show who has filed what?
- Does it hold templates for each authority and customer notice, and a contact sheet that people can reach out of hours?
- Can it call the on-call person by phone or message at any hour, and escalate when nobody answers?
- Can it work when your own systems are down, for example on a separate account or on paper?
- Does it keep the record apart from the systems it describes, with its own access limits?
- Can it link an incident to the affected assets, suppliers and personal data?
- Can you export the full record for an authority or a lawyer?
- What does it cost per user per month, and who counts as a user once the on-call and legal contacts are added?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
Write the process on one page: who may declare, who is told, who files each report. Keep a copy off the affected network.
- solid
Keep one record per incident, add a deputy for every role, store templates for each authority and review the process after every incident.
- strong
Practise a tabletop at planned intervals, link incidents to assets and suppliers and test that your suppliers know how to reach you.
basis working practice. No legal text sets this.
where it goes wrong
nobody may call it an incident
The person who sees the problem has no authority to declare it, and the person who has authority is away. Name who may declare, with a deputy, at any hour.
the plan sits on the system that is down
A procedure stored only on the affected network is unreachable when you need it. Keep a copy and the contact list somewhere that does not depend on it.
closing it when it is fixed
The record has to say what happened, what was decided and why. Add the root cause and the lessons before closing, and review whether the process changed.
never tested
A process that has not been practised fails at the first real use. Run a short tabletop at planned intervals and write down what nobody could answer.
the supplier's incident arrives late
Your clock can start from their notice, which only comes if the contract asks for it. Check that your suppliers are told how to reach you.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| incident procedure with named roles, deputies and contact sheet | head of IT | yearly and after any incident |
| incident record: timeline, decisions, severity, root cause | head of IT | each incident |
| breach log, including events judged not reportable and why | head of IT and DPO | each event |
| filed notifications with timestamps | head of IT and lawyer | each report |
| tabletop record: date, scenario, attendees, gaps found | head of IT | yearly |
basis GDPR Art. 33(5) for the breach log. The rest is practice, and the rhythms are your choice.
check it yourself
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
- Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
- Regulation (EU) 2022/2554 (DORA) (EUR-Lex)
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
your next step
Write down the person who may declare an incident at 03:00 and their deputy, then check both are reachable.