Incident Triage & First-Hour Assessment Procedure
Guides the first responder from initial report to a classification decision within the first hour, including evidence preservation.
Available soon
- Format
- Word
- Size
- 72 KB
- Length
- 23 pages
- Version
- 1.2
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- Triage
- Declaration
- The first hour
- Evidence to preserve in the first hour
- Outputs and records
- Timing targets
- Escalation when someone cannot be reached
- Worked example — ransomware, out of hours
- Worked example — a mailbox takeover, declared high and lowered
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 1.2
RD-10 now states DORA's rule for an incident classified as major only after 24 hours: the initial notification is due within 4 hours of that classification (Delegated Regulation (EU) 2025/301, Article 5(2)).
- 1.1
Step F4 contains with the least disruptive action and brings in the service owner and specialists before stopping a service people depend on for safety or essential operations.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure takes a reported security event from the first report to the end of the first hour after it is declared an incident. It is the working routine behind the Security Incident Management Policy: the policy states the rules (IM-01 to IM-12); this procedure says who does what, in which order and by when, for the part of the response where speed and good records matter most.
It answers four questions quickly and in writing: is this an incident, how bad is it, who must know now, and what must we stop, keep or report. Everything after the first hour follows the Incident Response Plan and the playbook for the category.
Scope
This procedure applies to:
- every security event reported to [[Organisation Name]], by anyone, through any route, at any time of day;
- the triage of that event, and the decision to close it, log it as a near miss, or declare an incident;
- the first hour after declaration, whatever the category and severity;
- everyone in the roles below, including suppliers who triage or respond for us.
It does not cover containment, eradication and recovery beyond the first hour (the Incident Response Plan and the playbooks), how reports to authorities are written (the Incident Communications Template Set), or the review after closure (the Post-Incident Review Template). It hands over to each at the step named.
Roles
Role | What they do in this procedure |
|---|---|
Reporter anyone: staff, contractors, suppliers or customers | Reports at once through a route below (IM-01), answers the triage questions, and does not try to fix, delete or investigate. |
IT service desk [[internal service desk, or the managed IT provider's]] | Acknowledges every report, asks the triage questions, rules out known issues and false alarms, and calls the incident manager for anything that might be an incident. Handles Severity 4 incidents. |
Incident manager [[e.g. Information Security Manager, with a named deputy]] | Decides whether to declare; opens the case; sets severity and category; escalates; decides to contain or preserve; starts the reporting screen; sends the first update. Leads the response until closure (IM-03). |
Executive incident lead [[e.g. Chief Operating Officer, with a named deputy]] | Is told of every Severity 1 and 2 incident (IM-05); decides on stopping a customer-facing service and on reports to authorities; tells the board chair of a Severity 1 incident. |
Data Protection Officer [[or the privacy lead where no DPO is appointed]] | Answers the GDPR question of the reporting screen whenever personal data may be involved, and advises on whether a notification is needed. |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Is told of Severity 3 incidents the same working day and of Severity 4 in the weekly summary; acts as incident manager when neither the incident manager nor the deputy can be reached. |
Technical responders [[IT operations, the managed IT provider and the security monitoring provider]] | Isolate, collect and preserve evidence on the incident manager's instruction; the security monitoring provider supplies alerts, logs and analysis. |
Guidance — delete before approval
Name a deputy for the incident manager and the executive incident lead, and put both on the contact list in the Incident Response Plan. An incident at 02:00 on a Sunday is still triaged within 60 minutes, so someone must be reachable, and the service desk must know who.
In a small organisation the IT service desk and the incident manager may be one person, or the managed IT provider. That is acceptable, but the decision to declare, and the severity, must still be recorded with the name of whoever took it.
Triggers and inputs
How events reach triage
Every route ends at the IT service desk, except where the table says otherwise. Whoever receives a report passes it on at once, without investigating first.
From | How | Lands with | Note |
|---|---|---|---|
Staff and contractors | [[Service desk phone number, email address and portal form]] | IT service desk | Everyone must report at once (IM-01). A report made in good faith is never blamed. |
The security monitoring provider | Alert under its contract, by [[ticket and phone call]] | IT service desk; out of hours, the on-call incident manager direct | The provider's out-of-hours analysts call the incident manager direct for any alert they rate [[high or critical]]. |
Suppliers | Notice under the incident notice clause of their contract, within the [[24]] hours it sets | IT service desk, copied to the supplier's business owner | A supplier incident that affects our data or services is category IC-10. |
Customers and the public | [[Customer service, account managers, a security contact address]] | IT service desk, passed on by whoever received it | Thank the reporter; say nothing about whether there is an incident (IM-09). |
The authority, the police or another organisation | [[CSIRT warning, law enforcement contact, a partner's notice]] | Incident manager direct | Treat it as a report: triage it on the same clock. |
Inputs
Input | Where it comes from | Used at |
|---|---|---|
Severity levels, categories and escalation times | Incident Classification, Severity & Escalation Matrix | Steps 5, F2, F3 |
Contact list, with deputies, and decision rights | Incident Response Plan | Steps 4, F3, F4 |
Known issues and planned changes | [[Service desk known-error list; the change calendar]] | Step 3 |
The case log | Incident Case & Action Log | Steps 6, F1 and every record after |
The message templates | Incident Communications Template Set | Step F6 |
The playbooks | Ransomware Response Playbook; Business Email Compromise Response Playbook; Personal Data Breach Response Playbook | Step F2, once the category is set |
Triage
Triage of every reported event must start within 30 minutes of the report in working hours and 60 minutes outside them, and must end within [[30]] minutes of starting with the event closed with a recorded reason or declared an incident (IM-02). Working hours are [[08:00–18:00, Monday to Friday]]; every other time, including [[public holidays]], is out of hours.
Step | What to do | Who | When | Output |
|---|---|---|---|---|
1 | Acknowledge the report. Log a ticket with the time it was reported and the route. Tell the reporter not to switch anything off, delete anything or reply to anyone, and to stay available. | IT service desk | Triage starts within 30 minutes (working hours) or 60 minutes (out of hours) of the report | Ticket, with the time reported |
2 | Collect the facts: ask the six questions below, in order, and write down the answers in the reporter's words. If the answer to the last question is yes, go straight to step 4 while you finish. | IT service desk | At once | Answers in the ticket |
3 | Check it is not a known issue, a planned change, a test, or a false alarm the monitoring provider has already explained. A false alarm is confirmed, not assumed: name who confirmed it. | IT service desk | Within the triage time | Known issue or false alarm confirmed, or ruled out |
4 | Call the incident manager for anything that is not closed at step 3. Out of hours, call the on-call incident manager by phone; a message alone is not enough. If there is no answer, see Escalation when someone cannot be reached. | IT service desk | As soon as step 3 does not close it | Call made, time recorded |
5 | Decide, using the decision table below: close with a reason, log as a near miss, or declare an incident. When in doubt about whether it is an incident, declare: an incident can be closed early; a late declaration cannot be undone. | Incident manager; the IT service desk may close a confirmed false alarm or known issue | Within [[30]] minutes of triage starting | Decision, with the reason |
6 | Record the decision in the ticket and, for a near miss or an incident, in the Incident Case & Action Log. Tell the reporter what happens next, and thank them. | IT service desk; Incident manager | With step 5 | Ticket closed, near miss logged, or case opened |
The six triage questions
Question | What to get |
|---|---|
1. What was seen? | The symptom in the reporter's words: a message, a pop-up, an alert name, a request that looked wrong. |
2. When? | When it was first seen, and when it was reported. The earlier time matters for the reporting clocks. |
3. Where? | Which device, account, system, site or supplier. Get the device name or the user name. |
4. Who? | Who reported it, who else has seen it, and whose account or device is involved. |
5. What data or service? | What the device, account or system holds or runs: customer or personal data, payments, a core service. |
6. Is it still happening? | Still spreading, still sending, still encrypting, still being used by someone else. A yes goes straight to the incident manager. |
Decision point — close, near miss or declare
Ask the questions in order; stop at the first that settles it.
Question | Yes | No |
|---|---|---|
Is it confirmed as a known issue, a planned change, a test or a false alarm? | Close with the reason and who confirmed it. | Next question. |
Could it have compromised our data or services, but was prevented or did not happen, and does it need nothing beyond logging? (A phishing email reported and not opened.) | Log as a near miss in the case log. Logged, never declared. Near misses are reviewed with the Severity 3 and 4 incidents each quarter. | Next question. |
Has it compromised, or does it threaten to compromise, our data or services, and does it need a managed response? | Declare an incident. An attack that was stopped but still needs response work, such as warning a supplier, confirming a patch or watching for a repeat, is declared, usually at Severity 4. Go to Declaration. | Close with the reason. |
Not sure? | Treat as yes: declare, and set severity by the worst it could be. | — |
Guidance — delete before approval
A near miss is still worth logging: NIS2 Article 6(5) defines it, and a pattern of them is how a weak control shows before it fails. Log near misses in the Incident Case & Action Log with category and a one-line reason, and review them with the quarterly batch.
Declaring is not the same as reporting to an authority. The reporting screen (step F5) decides whether anything is reported; declaring only starts the clock and the response.
Declaration
Every declared incident must have one named incident manager, a case number, a category and a severity, recorded at declaration (IM-03). Awareness is the moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. Record these fields in the Incident Case & Action Log as the case is opened.
Field | What to record |
|---|---|
Case number | INC-YYYY-nnn, the next number in the case log |
Time declared | Date and time, to the minute. This is awareness: every reporting clock starts here |
Time reported and time triage started | From the service desk ticket |
Reporter and route | Who reported it, and how it reached us |
Incident manager | The one named person leading the response, and their deputy |
Category | IC-01 to IC-10 from the matrix; it chooses the playbook |
Severity, with the reason | 1 to 4, and the impact area that sets it |
What we know | The answers to the six triage questions, in two or three sentences |
Still happening? | Yes or no, and what is being done about it |
Next update | The time the team reconvenes |
The first hour
The first hour runs from declaration. Take the steps in this order; where two can run together (containment and escalation usually can), do both. Each step's owner is the incident manager unless the table says otherwise.
Step | What to do | Who | When | Output |
|---|---|---|---|---|
F1 | Open the case. Give it a case number, record the time of declaration (the start of every reporting clock) and the reporter. | Incident manager | At declaration | Case log entry with the declaration record |
F2 | Set severity and category. Use the matrix. When in doubt, choose the higher severity. | Incident manager | Within [[10]] minutes of declaration | Severity with its reason; category and playbook |
F3 | Escalate. Tell the people the severity requires, within its time. | Incident manager; for Severity 1 the executive incident lead tells the board chair | Within the severity's times | Times each person was told, in the case log |
F4 | Contain what is spreading. Isolate before investigating when harm is spreading, with the least disruptive containment that stops it; otherwise preserve evidence first. | Incident manager, with the technical responders | As soon as spread is seen; otherwise after evidence is preserved | Contain-or-preserve decision and what was done, with times |
F5 | Start the reporting screen. Ask the three legal questions (NIS2, GDPR, DORA where it applies) and the contract and insurance questions. The screen is complete within 4 hours (IM-06). | Incident manager, with the Data Protection Officer | Started within the first hour | Screen started, with a named owner for each question |
F6 | Set the next update. Agree when the team reconvenes, and send the first internal update. | Incident manager | Before the first hour ends | CT-01 alert sent; next update time in the case log |
Step F2 — setting severity and category
Severity is the highest level any impact area reaches, judged on what the incident has done or is capable of doing. When in doubt, choose the higher level. Severity is reviewed at every update and can be raised by anyone on the response team; it is lowered only by the incident manager, with the reason recorded in the case log (IM-04).
Judge each impact area on what the incident has done or is capable of doing, then take the highest level any area reaches. The matrix, in the Incident Classification, Severity & Escalation Matrix:
Impact area | Severity 1 Critical | Severity 2 High | Severity 3 Medium | Severity 4 Low |
|---|---|---|---|---|
Service | A core customer service stopped, or likely to stop, for more than [[4 hours]] | A core customer service degraded, or an internal critical service stopped | One system or group of users affected; no customer effect | No service affected |
Data | Personal or customer data at scale taken or exposed, or likely to be | Personal data of individuals exposed, lost or altered, in limited numbers | Internal non-personal data, or personal data that was protected (for example encrypted) or recovered before it could be misused | No data affected |
Spread | Malware or an attacker spreading, or administrator-level access to core systems | One system or account compromised with elevated rights, and contained | One user account or device compromised; attacker stopped before harm | Attack stopped by an existing control, with response work still needed |
Financial | Loss likely above [[€1,000,000]] | Loss likely between [[€250,000]] and [[€1,000,000]] | Loss likely between [[€50,000]] and [[€250,000]] | Loss likely below [[€50,000]] |
Legal and regulatory | Likely a significant incident (NIS2), a major ICT-related incident (DORA), or a breach that individuals must be told of | Possibly notifiable to a supervisory authority or under a contract | Not notifiable | Not notifiable |
Reputation | National press, or loss of a major customer, likely | Customers or local press aware | Not noticed outside the organisation | None |
The category chooses the playbook; severity is set separately.
Category | For example | Playbook |
|---|---|---|
IC-01 Ransomware or destructive malware | Files encrypted; ransom note; systems wiped | Ransomware Response Playbook |
IC-02 Other malware | Malware found and blocked or removed, no encryption | The general response in the Incident Response Plan |
IC-03 Business email compromise and payment fraud | A mailbox taken over; a request to change bank details; a fake invoice | Business Email Compromise Response Playbook |
IC-04 Account compromise | A user or administrator account used by someone else | The general response in the Incident Response Plan |
IC-05 Personal data breach | Personal data sent to the wrong person, lost, stolen, altered or made unavailable | Personal Data Breach Response Playbook |
IC-06 Exploited vulnerability | A weakness in an internet-facing system used to get in | The general response in the Incident Response Plan |
IC-07 Denial of service | A service made unavailable by traffic or requests | The general response in the Incident Response Plan |
IC-08 Insider misuse | An employee or contractor misusing access | The general response in the Incident Response Plan |
IC-09 Lost or stolen device | A laptop, phone or removable drive | Personal Data Breach Response Playbook |
IC-10 Supplier incident | An incident at a supplier that affects our data or services | The general response in the Incident Response Plan |
Guidance — delete before approval
Set severity on what you know now and what the incident could do next, not on what it has done so far. Ransomware on one PC is Severity 1 if it can spread; a mailbox rule forwarding mail outside is Severity 2 if personal data may already have gone.
Step F3 — escalation by severity
Severity 1 and 2 incidents must be escalated to the executive incident lead, and Severity 1 incidents to the board chair or equivalent, within the times the matrix sets (IM-05). Times run from declaration.
Severity | Who is told, and when | Led by | Updates | Hours |
|---|---|---|---|---|
Severity 1 Critical | Incident manager at once; executive incident lead within 30 minutes; crisis team convened within 1 hour; board chair, or equivalent, within 4 hours | Incident manager, with the executive incident lead deciding | Every 2 hours | Round the clock until contained |
Severity 2 High | Incident manager at once; executive incident lead within 2 hours | Incident manager | Every 4 hours | Extended hours as needed |
Severity 3 Medium | Incident manager at once; Head of Information Security the same working day | Incident manager, or the IT service desk under their direction | Every 24 hours | Working hours |
Severity 4 Low | IT service desk logs and handles it; Head of Information Security in the weekly summary | IT service desk | At closure | Working hours; closed within [[5]] working days |
Step F4 — contain or preserve
Evidence must be preserved before systems are wiped or rebuilt, unless waiting would let the harm spread; who handled it, and when, must be recorded (IM-07). The first decision is which comes first: stopping the harm, or keeping the evidence.
Question | Yes | No |
|---|---|---|
Is harm spreading now? (Malware moving between machines, files being encrypted, data leaving, an attacker active in an account, a payment about to be made.) | Contain first. Isolate the machine, account, site or connection now; preserve what you can while you do. Isolate a system, site or account: incident manager, without waiting for an executive. Use the least disruptive containment that stops the harm, and bring in the service owner and specialists before any action that would stop a service people depend on for safety or essential operations. Tell the executive incident lead at the next update. | Preserve first, then contain: see Evidence to preserve. |
Would containment stop a customer-facing service? | Stop a customer-facing service: executive incident lead. The incident manager may do it first where waiting would let the harm spread, and reports it at once. Where people depend on the service for safety or essential operations, its service owner and specialists are brought in first. | The incident manager decides. |
Would it stop a service people depend on for safety or essential operations? | Bring in its service owner and specialists before that action, and keep containing around it with the least disruptive steps meanwhile (IM-08). | — |
Is a machine encrypting files? | Disconnect it from the network (cable out, wireless off). Do not power it off until the technical responders advise. | — |
Is there a ransom or extortion demand? | Do not reply. Pay a ransom or extortion demand: only the board or its equivalent. Never before legal advice (including sanctions checks), the insurer's view and a report to law enforcement. The plan assumes we do not pay. | — |
Guidance — delete before approval
"Waiting for the executive is never a reason to let harm spread" (IM-08). Nor is speed a reason to stop a service people depend on for safety or essential operations without its owner and specialists: cut off the account, device or segment first, and take the service down only once they are in. Write the isolation step for each site and each critical system into the contact list and the Ransomware Response Playbook, so the person on call does not have to work it out at night.
Step F5 — the reporting screen
Every incident must be screened against every reporting duty (NIS2, GDPR, DORA where it applies, contracts and insurance) within 4 hours of declaration, and the decision and its reasons recorded whether or not a report is made (IM-06). Start the screen in the first hour and complete it within 4 hours of declaration. Name an owner for each question; the Data Protection Officer answers the GDPR question. Report to an authority: executive incident lead, on the incident manager's reporting screen. The Data Protection Officer advises on GDPR reports. A report is never held back to avoid a deadline.
Law | The question | If yes |
|---|---|---|
NIS2 | Are we an essential or important entity, and has this incident caused, or could it cause, severe operational disruption or financial loss to us, or considerable damage to others? | Duties RD-01 to RD-05 |
GDPR | Is personal data affected (confidentiality, integrity or availability)? If so, is the breach unlikely to result in a risk to individuals, a risk, or a high risk? | Duties RD-06 to RD-09 |
DORA | Are we a financial entity, and does the incident affect critical services and meet the thresholds of Delegated Regulation (EU) 2024/1772 Articles 8 and 9? | Duties RD-10 to RD-13 |
Then the duties outside the law:
Duty | When it applies | Deadline |
|---|---|---|
RD-14 Notice to customers under contract | Where a contract requires it | [[as each contract requires]] |
RD-15 Notice to the cyber insurer | Where a cyber policy is held | [[as the policy requires, often within 48 hours]] |
RD-16 Crime report | Suspected criminal acts, including ransomware and fraud | [[as soon as practical for suspected crime]] |
The clocks that start at declaration, earliest first. Record the decision and its reasons whether or not a report is made.
Duty | Report | Deadline |
|---|---|---|
RD-01 | NIS2 early warning | Within 24 hours of awareness |
RD-10 | DORA initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after awareness; where it is classified as major only after those 24 hours, within 4 hours of that classification |
RD-02 | NIS2 incident notification | Within 72 hours of awareness |
RD-06 | GDPR notification to the supervisory authority | Without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay |
Step F6 — the first update
Send CT-01, incident alert to the response team, from the Incident Communications Template Set at declaration: incident manager, responders, executive incident lead. It says what happened, the severity, who leads, what is being done now and when the team reconvenes. For Severity 1 and 2, CT-02, executive and board briefing, follows at each update (executive incident lead, crisis team, board chair). Agree the next update time before anyone leaves the call, and put it in the case log.
If staff will notice the effects (machines disconnected, a system down), the executive incident lead approves CT-03, staff holding message. Nothing is said outside the organisation except by the communications lead, from the approved templates (IM-09).
Evidence to preserve in the first hour
Most volatile first. Evidence lost in the first hour is lost for good; evidence kept can be discarded later.
What | How |
|---|---|
What is on the screen | Photograph or screenshot it: ransom notes, error messages, pop-ups, the alert. Note the time on the device clock and the real time. |
A running machine's memory and connections | Leave it on. Disconnect it from the network (unplug the cable, turn off wireless) rather than powering it off. Do not power off a machine that is encrypting until the technical responders advise: memory may hold the key and the attacker's tools. |
Accounts in use | Record which accounts are signed in and from where before resetting them; export the sign-in log for the account. |
Logs | Ask the security monitoring provider and the managed IT provider to preserve logs for the affected systems and accounts from [[at least 30]] days before the first sign, and to extend retention so nothing rolls over. |
Keep the suspicious message. Forward it as an attachment, with its full headers, to [[the security mailbox]]; do not delete it from the mailbox. | |
Mailbox and account rules | Record any forwarding or deletion rules, and new sign-in methods, before removing them: screenshot or export. |
Devices | Label any device taken out of use with the case number, who took it and when; keep it somewhere locked. Do not wipe or rebuild it until the incident manager agrees (IM-07). |
Who handled what, when | Every item goes on the handling record below, from the moment it is taken. |
Handling record
One line for every item taken or passed on, kept with the case in the Incident Case & Action Log. It shows who had each item, and when, from the moment it was taken (IM-07).
Item | Taken from | By | When | Stored at | Passed to (who, when) |
|---|---|---|---|---|---|
[[e.g. Laptop WH2-PC07]] | [[Warehouse 2 office]] | [[Name]] | [[YYYY-MM-DD HH:MM]] | [[Locked cabinet, IT room]] | [[Name, YYYY-MM-DD HH:MM]] |
[[e.g. Sign-in log export]] | [[Email service admin console]] | [[Name]] | [[YYYY-MM-DD HH:MM]] | [[Case folder, read-only]] | [[—]] |
Guidance — delete before approval
If the incident might end in court, in a claim against a supplier or with the police, ask your outside responders to take disk and memory images: they will know how to keep them admissible. Your job in the first hour is to not destroy anything and to write down who touched what.
Outputs and records
Output | Produced at step | Held in |
|---|---|---|
Ticket with the time reported and the triage answers | 1, 2 | [[Service desk tool]] |
Triage decision and reason: closed, near miss or declared | 5, 6 | Ticket; Incident Case & Action Log for near misses and incidents |
Declaration record | F1 | Incident Case & Action Log |
Severity with its reason, and category | F2 | Incident Case & Action Log |
Times each person was told | F3 | Incident Case & Action Log |
Contain-or-preserve decision and actions | F4 | Incident Case & Action Log |
Reporting screen, with decisions and reasons | F5 | Incident Case & Action Log |
CT-01 sent; next update time | F6 | Incident Case & Action Log; message copies with the case |
Handling record for evidence | F4 onwards | Incident Case & Action Log |
Timing targets
Activity | Target | Basis |
|---|---|---|
Triage starts, in working hours | Within 30 minutes of the report | IM-02 |
Triage starts, out of hours | Within 60 minutes of the report | IM-02 |
Triage decision | Within [[30]] minutes of triage starting | IM-02 |
Declaration record complete | At declaration | IM-03 |
Severity and category set | Within [[10]] minutes of declaration | IM-04 |
Severity 1: executive incident lead told | Within 30 minutes of declaration | IM-05 |
Severity 2: executive incident lead told | Within 2 hours of declaration | IM-05 |
Severity 1: crisis team convened | Within 1 hour of declaration | IM-05 |
Severity 1: board chair told | Within 4 hours of declaration | IM-05 |
Severity 3: Head of Information Security told | The same working day | Matrix |
Reporting screen complete | Within 4 hours of declaration | IM-06 |
CT-01 sent | At declaration | Incident Communications Template Set |
Severity 1: updates | Every 2 hours | Matrix |
Severity 2: updates | Every 4 hours | Matrix |
Severity 3: updates | Every 24 hours | Matrix |
Escalation when someone cannot be reached
A role that does not answer is not a reason to wait. Try the named person, then the deputy, then the next role up, and record every attempt with its time in the case log.
Cannot reach | After | Go to | Then, after a further |
|---|---|---|---|
Incident manager | [[15]] minutes | The named deputy incident manager | [[15]] minutes: the Head of Information Security, who acts as incident manager until one is reached |
Executive incident lead | [[15]] minutes | The named deputy | [[15]] minutes: [[the Chief Executive]]. Meanwhile the incident manager contains without waiting (IM-08) |
Data Protection Officer | [[15]] minutes | [[The DPO's deputy or external privacy adviser]] | The screen continues; the GDPR answer is recorded as provisional and confirmed when the DPO is reached, within the 72-hour clock |
The security monitoring provider or the managed IT provider | [[15]] minutes | The provider's escalation contact under the contract | The executive incident lead, who raises it with the provider's account executive |
Guidance — delete before approval
Two calls and a message count as an attempt. Set these minutes to fit your on-call arrangement, but keep the sum short enough that the executive incident lead is still told within 30 minutes for a Severity 1 incident.
Worked example — ransomware, out of hours
EXAMPLE, not part of the procedure. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State. INC-2026-014: ransomware on 14 office PCs at Warehouse 2. The security monitoring provider alerted on encryption activity on one office PC at Warehouse 2. It had spread to 14 office PCs on that site's office network before the site was cut off. Ordering and dispatch were not affected. Replace every time and name with your own.
The first four hours
Wednesday 12 Aug 2026. Times are local; comparisons are with the limits in this procedure.
Time | What happened | Who | Against the procedure |
|---|---|---|---|
07:50 | Monitoring alert: encryption activity on one office PC at Warehouse 2 | Security monitoring provider (SUP-006) | |
08:05 | Triage starts (out of hours: within 60 minutes) | IT service desk | 15 minutes after the alert; reported at 07:50, before working hours start, so the limit is 60 minutes |
08:25 | Declared Severity 1, category IC-01; reporting clocks start | Incident manager | 20 minutes after triage started (limit 30); 35 minutes after the alert. Awareness is 08:25 |
08:40 | Executive incident lead told | Incident manager | 15 minutes after declaration (Severity 1: within 30) |
08:55 | Decision: cut Warehouse 2's office network off from all other networks (the incident manager's decision; the executive incident lead agreed, as it stopped office work at the site) | Incident manager | 30 minutes after declaration, within the incident manager's own decision rights (isolate a system, site or account: incident manager) |
09:10 | Warehouse 2 office network isolated | Managed IT provider (SUP-001) | 45 minutes after declaration: spread stopped at the site boundary |
09:20 | Crisis team convened | Executive incident lead | 55 minutes after declaration (within 1 hour) |
11:30 | Reporting screen complete: NIS2 significant; GDPR breach to assess; DORA not applicable | Incident manager, Data Protection Officer | 3 hours 5 minutes after declaration (IM-06: within 4 hours) |
11:45 | Cyber insurer told | Executive incident lead | 3 hours 20 minutes after declaration; within the policy's notice period (RD-15) |
12:20 | Board chair told | Executive incident lead | 3 hours 55 minutes after declaration (within 4 hours) |
The severity choice
At 08:25 the incident manager judged each area on what the incident could do next. “Spread” and “Legal and regulatory” reached Severity 1, so the incident is Severity 1, whatever the other areas show. (EXAMPLE)
Impact area | Level | Why | The matrix's words for that level |
|---|---|---|---|
Service | Severity 2 | Office work at Warehouse 2 stopped: an internal critical service; ordering and dispatch still running | A core customer service degraded, or an internal critical service stopped |
Data | Severity 2 | Shipping records with customer names and addresses held on the PCs may be lost | Personal data of individuals exposed, lost or altered, in limited numbers |
Spread | Severity 1 | Encryption spreading across the site's office network | Malware or an attacker spreading, or administrator-level access to core systems |
Financial | Severity 3 | Rebuilding one site's office PCs and a day or two of lost office work | Loss likely between [[€50,000]] and [[€250,000]] |
Legal and regulatory | Severity 1 | Capable of severe operational disruption if it reaches the warehouse systems: likely significant under NIS2 | Likely a significant incident (NIS2), a major ICT-related incident (DORA), or a breach that individuals must be told of |
Reputation | Severity 3 | Not noticed outside the organisation | Not noticed outside the organisation |
Checks against the limits
Check | Limit | Actual | Met | Basis |
|---|---|---|---|---|
Triage started, from the report | 60 minutes (out of hours) | 15 minutes | Yes | IM-02 |
Triage decision, from triage starting | 30 minutes | 20 minutes | Yes | IM-02 |
Executive incident lead told, from declaration | 30 minutes | 15 minutes | Yes | IM-05; Severity 1 |
Crisis team convened, from declaration | 1 hour | 55 minutes | Yes | IM-05; Severity 1 |
Reporting screen complete, from declaration | 4 hours | 3 hours 5 minutes | Yes | IM-06 |
Board chair told, from declaration | 4 hours | 3 hours 55 minutes | Yes | IM-05; Severity 1 |
Category IC-01, ransomware or destructive malware, chose the Ransomware Response Playbook. The screen found the incident capable of severe operational disruption, so significant under NIS2: the early warning was due by 13 Aug 2026, 08:25, 24 hours after awareness, and was made on 12 Aug 2026 at 15:40, 7 hours 15 minutes after awareness. The organisation is not a financial entity, so DORA's reporting duties do not apply. The incident was contained at 13:50, 6 hours after the alert. (EXAMPLE)
Guidance — delete before approval
What this example teaches: the incident manager declared 35 minutes after the alert and set severity on what the malware could do, not on the one PC it started on. The incident manager decided to cut the site off 30 minutes after declaration, within their own decision rights, without waiting for the crisis team. The steps to isolate the site were worked out on the call; the review of this incident raised PIA-04: add site isolation steps for each warehouse to the Ransomware Response Playbook.
Worked example — a mailbox takeover, declared high and lowered
EXAMPLE. INC-2026-017: staff mailbox taken over after a phishing email, declared at Severity 2 and lowered to Severity 3 once the facts were known. The security monitoring provider alerted on a sign-in to a sales administrator's mailbox from another country and a new rule forwarding mail outside. Sessions were revoked and the password reset within 40 minutes. The audit log showed no mail had yet been forwarded. Tuesday 22 Sep 2026, in working hours.
Time | What happened | Who |
|---|---|---|
14:10 | Monitoring alert: sign-in to a sales administrator's mailbox from another country, and a new rule forwarding mail outside | Security monitoring provider (SUP-006) |
14:18 | Triage starts: 8 minutes after the alert (working hours: within 30) | IT service desk |
14:25 | Declared Severity 2, category IC-04 account compromise, 7 minutes after triage started: personal data may already have gone, and when in doubt the higher level is chosen. CT-01 sent; the executive incident lead is due to be told within 2 hours. First task: check the mailbox audit log | Incident manager |
14:50 | Contained: sessions revoked, password reset, the forwarding rule recorded and removed, 40 minutes after the alert | Technical responders |
15:00 | Head of Information Security told | Incident manager |
15:20 | Audit log checked. Lowered to Severity 3 by the incident manager, reason recorded in the case log: the mailbox audit log showed no mail had been forwarded or read by the attacker, so no personal data had gone. The executive incident lead no longer needs to be called | Incident manager |
15:30 | User back in the mailbox with a new password and a new second factor | IT service desk |
16:05 | Reporting screen complete, 1 hour 40 minutes after declaration. NIS2: not significant. GDPR: no personal data disclosed (audit log checked); recorded as assessed, not a breach. DORA: not applicable | Incident manager; Data Protection Officer |
Severity area by area, at declaration and after the audit log was checked at 15:20. At declaration “Data” and “Legal and regulatory” reached Severity 2, so the incident was declared Severity 2. The audit log settled the doubt, and the incident manager lowered it to Severity 3 with the reason recorded (IM-04). (EXAMPLE)
Impact area | At declaration, 14:25 | Why | After the audit log, 15:20 |
|---|---|---|---|
Service | Severity 4 | One mailbox; no service affected | Unchanged |
Data | Severity 2 | A rule forwarding mail outside: customers' personal data in the mailbox may already have gone | Severity 4: no mail forwarded or read by the attacker, as the audit log shows |
Spread | Severity 3 | One user account compromised; sessions can be revoked at once | Unchanged |
Financial | Severity 4 | No loss expected | Unchanged |
Legal and regulatory | Severity 2 | Possibly notifiable to the supervisory authority, if personal data went | Severity 4: no personal data went, so not notifiable |
Reputation | Severity 4 | None | Unchanged |
Check | Limit | Actual | Met | Basis |
|---|---|---|---|---|
Triage started, from the report | 30 minutes (working hours) | 8 minutes | Yes | IM-02 |
Triage decision, from triage starting | 30 minutes | 7 minutes | Yes | IM-02 |
Lowered before the Severity 2 executive deadline | 2 hours | 55 minutes | Yes | IM-05; Severity 2 |
Reporting screen complete, from declaration | 4 hours | 1 hour 40 minutes | Yes | IM-06 |
Lowered 55 minutes after declaration, before the Severity 2 deadline for telling the executive incident lead, so from then on Severity 3 applies: incident manager at once; Head of Information Security the same working day. Had the audit log shown mail had gone, the incident would have stayed at Severity 2, the executive incident lead would have been told, and the Data Protection Officer would have assessed a GDPR notification. The case was closed on 24 Sep 2026, with the root cause recorded: a convincing phishing page captured the password; the account's second factor was a text message that the attacker also phished. As a Severity 3 incident it has no review of its own. Severity 3 and 4 incidents are reviewed together once a quarter, and this one goes into that review. (EXAMPLE)
Related documents
Document | Relationship |
|---|---|
Security Incident Management Policy | The rules this procedure runs: IM-01 to IM-07 in the first hour |
Incident Response Plan | Everything after the first hour; the contact list, deputies and decision rights |
Incident Classification, Severity & Escalation Matrix | Severity levels, categories, escalation times and the reporting clocks (steps F2, F3, F5) |
Ransomware Response Playbook; Business Email Compromise Response Playbook; Personal Data Breach Response Playbook | The response for the category, once it is set (step F2) |
Incident Case & Action Log | Where the declaration record, decisions, times and handling record are kept |
Incident Communications Template Set | The first update (CT-01), briefings (CT-02) and every report to an authority |
Post-Incident Review Template | The review after closure, which checks the times in this procedure were met |
Incident Response Readiness Checklist | Tests whether the routes, contact list and deputies in this procedure are ready |
Adapting this template
Guidance — delete before approval
Small organisation: the IT service desk may be one person or your managed IT provider, and the incident manager may be the IT manager. Keep the six questions, the decision table, the 4-hour screen and the declaration record; they are what an auditor or regulator asks for. Out of hours, a phone number that rings a named person is enough, as long as it is answered within the 60-minute triage time.
Regulated entity (NIS2, GDPR, DORA): NIS2's 24-hour early warning (RD-01) and GDPR's 72 hours (RD-06) both run from awareness. This pack defines awareness as the moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. The legal clocks run from when you really became aware: if the case log shows you had reasonable certainty before declaring, count from then, and never delay declaring to delay a clock. A DORA financial entity must classify each incident against Delegated Regulation (EU) 2024/1772 (the DORA screen question), then make the initial notification within 4 hours of classifying the incident as major, and no later than 24 hours after awareness; where it is classified as major only after those 24 hours, within 4 hours of that classification (RD-10), with the intermediate and final reports to follow (RD-11, RD-12; the final report comes once the root cause analysis is complete). Add the classification criteria of Article 18(1) to step F2 and record the classification time in the declaration record.
IT run by a service provider: your managed IT provider and security monitoring provider may do steps 1 to 4 for you. Put the triage times, the six questions and the call to your incident manager into their contract or service description, and test them. The decision to declare, the severity and the reporting screen stay with your organisation.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2022/2554 (DORA), Delegated Regulations (EU) 2024/1772 and 2025/301, Implementing Regulation (EU) 2025/302.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 6.8 — Information security event reporting | Reporting routes; step 1 |
ISO/IEC 27001:2022 | Annex A 5.25 — Assessment and decision on information security events | Triage steps 2 to 6: each event assessed and decided |
ISO/IEC 27001:2022 | Annex A 5.26 — Response to information security incidents | The first hour: containment, escalation and first update |
ISO/IEC 27001:2022 | Annex A 5.28 — Collection of evidence | Evidence to preserve; the handling record |
NIST CSF 2.0 | DE.AE-02 — “Potentially adverse events are analyzed to better understand associated activities” | Steps 2 and 3: the event analysed |
NIST CSF 2.0 | DE.AE-04 — “The estimated impact and scope of adverse events are understood” | Step F2: impact and scope judged area by area |
NIST CSF 2.0 | DE.AE-08 — “Incidents are declared when adverse events meet the defined incident criteria” | Step 5: declaration against the defined criteria |
NIST CSF 2.0 | RS.MA-02 — “Incident reports are triaged and validated” | Triage: reports triaged and validated |
NIST CSF 2.0 | RS.MA-03 — “Incidents are categorized and prioritized” | Step F2: severity and category |
NIST CSF 2.0 | RS.MA-04 — “Incidents are escalated or elevated as needed” | Step F3 and escalation when someone cannot be reached |
NIST CSF 2.0 | RS.AN-07 — “Incident data and metadata are collected, and their integrity and provenance are preserved” | Evidence to preserve and the handling record |
NIST CSF 2.0 | RS.MI-01 — “Incidents are contained” | Step F4: contain first when harm is spreading |
NIS2 — Directive (EU) 2022/2555 | Article 6(5) — “near miss” means an event that could have compromised the availability, authenticity, integrity or confidentiality of data or services, but that was successfully prevented from materialising or did not materialise | The near miss outcome of triage |
NIS2 — Directive (EU) 2022/2555 | Article 6(6) — “incident” means “an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems” | The declaration test in the decision table |
NIS2 — Directive (EU) 2022/2555 | Article 23(4) — an early warning within 24 hours of becoming aware of a significant incident; an incident notification within 72 hours; an intermediate report on request; a final report not later than one month after the incident notification (or a progress report, then a final report within one month of handling, if still ongoing) | Step F5: the 24-hour early warning clock starts at declaration |
GDPR — Regulation (EU) 2016/679 | Article 33(1) — notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay | Step F5: the 72-hour clock runs from awareness |
DORA — Regulation (EU) 2022/2554 | Article 17(3) — early warning indicators; procedures to log, categorise and classify incidents; roles for each incident type; communication plans; reporting major incidents to senior management and the management body; response procedures | Logging, classifying and escalating; regulated-entity tailoring |
DORA — Regulation (EU) 2022/2554 | Article 18(1) — classify ICT-related incidents by clients and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of services affected and economic impact | Regulated-entity tailoring: the classification criteria added to step F2 |
DORA — Delegated Regulation (EU) 2024/1772 | Article 8 — an incident is major where it affects critical services and either meets the data-loss threshold in Article 9(5)(b) or meets two or more of the other materiality thresholds | The DORA screen question and regulated-entity tailoring |
DORA — Delegated Regulation (EU) 2025/301 | Article 5 — initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it; intermediate report within 72 hours of the initial notification; final report no later than one month after the latest intermediate report | Regulated-entity tailoring: the 4-hour and 24-hour initial notification |
Definitions
Term | Meaning in this procedure |
|---|---|
Awareness | The moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. |
Category | The kind of incident, IC-01 to IC-10 in the matrix. It chooses the playbook. |
Containment | The incident can no longer spread or cause new harm, even though systems may not yet be restored. |
Declaration | The incident manager's decision that an event is an incident, recorded with its time. It starts every reporting clock. |
Event | Something observed or reported that might affect the security of our information or services. Most events are not incidents. |
Incident | An event, declared by the incident manager, that has compromised, or threatens to compromise, the availability, authenticity, integrity or confidentiality of our data or services, and needs a managed response. |
Major ICT-related incident | DORA's term, for financial entities only: an ICT-related incident with a high adverse impact on systems that support critical or important functions, as tested by Delegated Regulation (EU) 2024/1772. |
Near miss | An event that could have compromised our data or services but was prevented or did not happen, and needs nothing beyond logging. Logged, never declared. An attack that was stopped but still needs response work, such as warning a supplier, confirming a patch or watching for a repeat, is declared, usually at Severity 4. |
Out of hours | Any time outside working hours, [[08:00–18:00, Monday to Friday]]. |
Personal data breach | GDPR's term: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. |
Reporting screen | The recorded check of every reporting duty against the incident, complete within 4 hours of declaration (IM-06). |
Severity | How fast and how high we respond, 1 (Critical) to 4 (Low), set on the worst impact area. It is not any of the legal tests. |
Significant incident | NIS2's term: an incident that has caused or could cause severe operational disruption or financial loss to us, or considerable damage to others. Reported to the authority on NIS2's clock. |
Triage | The first look at a reported event: the questions, the checks and the decision to close, log or declare. |