How do we…
How do we decide whether something is an incident or just an event?
Add to board memoOpen the memo
The short answer
- Recommendation
- Treat every report as an event and triage it within the time limit. Close only a confirmed known issue, change, test or false alarm; log a prevented event that needs nothing more as a near miss; declare anything that harms or threatens your data or services and needs a response. When in doubt, declare.
- Reasoning
- Most events are not incidents, but the reporting clocks usually start when an incident is declared, so a slow or wrong call costs time you cannot get back. The questions run in order and stop at the first that settles it. A stopped attack that still needs work, such as warning a supplier or confirming a patch, is an incident, usually at the lowest severity. An incident can be closed early; a late declaration cannot be undone.
- Considerations
- The triage times are the pack's defaults: triage starts within 30 minutes of a report in working hours and 60 minutes outside them, and ends in a decision within 30 minutes. Your own policy may set others.
- A false alarm counts only once someone has confirmed it, and that person is named. If nobody can confirm it, it goes to the incident manager.
- Declaring is not reporting to an authority. A separate reporting screen decides whether anything is reported.
- Nobody is blamed for a report made in good faith. That is what keeps people reporting.
The decision, step by step
Select any step for the reasoning behind it and where the pack covers it.
- Start
- Step
- Decision
- Outcome
Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.
Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.
Read as text
The same flow written out: each step, its reasoning and where the pack covers it. 11 steps.
Start
Something odd has been reported or alerted
An event is anything observed or reported that might affect the security of your information or services. Most events are not incidents. An alert from a monitoring provider, a supplier's notice or a warning from an authority counts as a report and starts the same clock.
In the pack
- P09-A02 Security Incident Management PolicyDefinitions
- P09-A05 Incident Triage & First-Hour Assessment ProcedureHow events reach triage
Step
Log it and start triage within the time limit
Log a ticket with the time it was reported and the route. The pack's default is that triage starts within 30 minutes of the report in working hours and 60 minutes outside them. Tell the reporter not to switch anything off, delete anything or reply to anyone, and to stay available. Nobody is blamed for a report made in good faith.
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureTriage
- P09-A02 Security Incident Management PolicyReporting and triage (rules IM-01, IM-02)
Step
Ask the six triage questions
What was seen, when, where, who is involved, what data or service is affected, and is it still happening. Write the answers down in the reporter's words. When it was first seen matters, because the earlier time can matter for the reporting clocks. If it is still spreading, sending, encrypting or being used by someone else, call the incident manager at once while you finish.
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureThe six triage questions
Decision
Is it a confirmed known issue, change, test or false alarm?
Check the known-error list, the change calendar and any test that was planned. A false alarm is confirmed, not assumed: name who confirmed it. The service desk may close a confirmed false alarm or known issue itself. If you cannot confirm it, it is not closed here.
- Yes, confirmed: Close it with the reason and who confirmed it
- No, or not confirmed: Call the incident manager
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureTriage
- P09-A05 Incident Triage & First-Hour Assessment ProcedureDecision point — close, near miss or declare
Outcome
Close it with the reason and who confirmed it
Record the reason and the name of the person who confirmed it in the ticket, and tell the reporter what was found. The pack's yearly audit sample includes at least one event closed without declaration, so the reason must stand on its own.
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureOutputs and records
- P09-A02 Security Incident Management PolicyCompliance and consequences
Step
Call the incident manager
Anything not closed as a confirmed known issue goes to the incident manager, who decides. Out of hours, call by phone; a message alone is not enough. In the pack's defaults, with no answer after 15 minutes you call the deputy, and 15 minutes after that the Head of Information Security acts as incident manager.
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureTriage
- P09-A05 Incident Triage & First-Hour Assessment ProcedureEscalation when someone cannot be reached
Decision
Was harm prevented, with nothing needed beyond logging?
A near miss could have compromised your data or services but was prevented or did not happen, and needs no further work. A phishing email reported and not opened is the pack's example. If the attack was stopped but still needs work, such as warning a supplier, confirming a patch or watching for a repeat, it is not a near miss. If you are not sure, answer no.
- Yes: Log it as a near miss; do not declare it
- No, or not sure: Does it harm or threaten data or services, needing a response?
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureDecision point — close, near miss or declare
- P09-A04 Incident Classification, Severity & Escalation MatrixDefinitions
Outcome
Log it as a near miss; do not declare it
Log it in your case log with its category and a one-line reason. It is logged, never declared. Near misses are reviewed each quarter with the Severity 3 and 4 incidents: a pattern of them is how a weak control shows before it fails.
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureDecision point — close, near miss or declare
- P09-A03 Incident Response PlanYearly calendar
Decision
Does it harm or threaten data or services, needing a response?
The test is whether it has compromised, or threatens to compromise, the availability, authenticity, integrity or confidentiality of your data or services, and needs a managed response. It does not have to be proven. A stopped attack that still needs response work passes. If you are not sure, answer yes.
- Yes, or not sure: Declare an incident and open the case
- No: Close it with a recorded reason
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureDecision point — close, near miss or declare
- P09-A02 Security Incident Management PolicyDefinitions
Outcome
Close it with a recorded reason
It is an event that caused no harm, threatened none and needs no response. Record the reason in the ticket, and tell and thank the reporter. The policy expects a reason for every event closed without declaration, and the triage decision to be made within the time limit, 30 minutes from the start of triage in the pack's defaults.
In the pack
- P09-A02 Security Incident Management PolicyReporting and triage (rule IM-02)
- P09-A05 Incident Triage & First-Hour Assessment ProcedureTriage
Outcome
Declare an incident and open the case
The incident manager declares, gives it a case number and records the time. That time is usually when the reporting clocks start, unless you had reasonable certainty earlier. Never delay declaring to delay a clock. A stopped attack that still needs work is usually declared at the lowest severity. Declaring is not reporting to an authority: a separate screen decides that.
In the pack
- P09-A05 Incident Triage & First-Hour Assessment ProcedureDeclaration
- P09-A05 Incident Triage & First-Hour Assessment ProcedureAdapting this template
- P09-A02 Security Incident Management PolicyClassification and escalation (rule IM-03)
Practical checklist
- Log a ticket with the time and route of the report, and start triage within the time limit.
- Tell the reporter not to switch anything off, delete anything or reply to anyone, and to stay available.
- Ask the six triage questions: what, when, where, who, what data or service, and is it still happening.
- Check the known-error list, the change calendar and planned tests, and name whoever confirms a false alarm.
- Call the incident manager for anything not closed, by phone out of hours, and the deputy if there is no answer.
- Decide within the time limit: close with a reason, log a near miss, or declare an incident.
- Tell the reporter what happens next, and thank them.
Evidence to have ready
- The ticket with the time reported, the time triage started and the time of the decision.
- The answers to the six triage questions, in the reporter's words.
- For every event closed without declaration, the reason and who confirmed it.
- Each near miss in your case log, with its category and a one-line reason.
- For a declared incident, the declaration time, case number, incident manager, category and severity.
Assumptions
- You have a reporting route that everyone knows, and a named incident manager with a deputy who can be reached at any hour.
- The triage times shown are the defaults in the CISO Times incident pack. Your own policy may set different ones, as long as they leave room for the legal reporting clocks.
Not covered here
- How severe a declared incident is. That is “How do we decide an incident's severity when the facts are still unclear?”.
- Whether an incident must be reported to a regulator. That is “When do we have to notify a regulator, and under which regime?”.
- Who may take a system offline once an incident is declared. That is “Who has the authority to take a production system offline?”.