Triage a suspected security incident
Separate observations from assumptions, record uncertainty and choose the next evidence, escalation and containment decisions in a worked incident log.
Triage establishes enough understanding to choose the next action and the right people to involve. It rarely begins with a complete explanation. The aim is a proportionate, recorded decision while the team continues to learn.
Use the organisation's authorised response process. If you are the person who noticed something suspicious, preserve the details you already have and report through that route; do not start unapproved investigation across systems or accounts.
Capture the first observation precisely
Record what happened, when it was noticed, where the information came from and who is reporting it. Include the original event time if available, its timezone and any uncertainty about the clock. Keep a pointer to the original record rather than relying solely on a copied screenshot.
Useful first questions are:
- Which account, device, application or service is implicated?
- What behaviour was actually observed?
- Is the behaviour continuing, and what impact is currently visible?
- What access and data could be involved, without assuming that they were used?
- What information is missing or likely to disappear soon?
- Who owns the service and who is authorised to investigate it?
NIST SP 800-61r3's incident-management guidance bases triage and escalation on risk factors such as service criticality, functional and data impact, and recoverability. It does not prescribe handling every alert in arrival order. See the full publication, particularly RS.MA.
A worked observation and decision log
Fictional scenario: a customer-support employee reports an unexpected account-setting change in a cloud service. The log uses an illustrative incident day; all displayed times are UTC. No real person or service is implicated.
| Time | Observation or evidence | Assessment and uncertainty | Decision and owner |
|---|---|---|---|
| 09:10 | Employee reports a notification of a new forwarding rule they do not recognise | A notification is reported; the rule and its origin are not yet confirmed | Service desk opens an incident record and contacts the authorised responder |
| 09:16 | Authorised responder confirms the rule in the service's administration record | Unexpected configuration exists; account compromise is a hypothesis | Incident lead requests preservation of relevant audit data and identity review |
| 09:23 | Identity log shows a sign-in unfamiliar to the employee | Location or unfamiliarity alone does not establish who signed in; device and session context need checking | Technical lead compares authorised access records and asks the service owner about impact |
| 09:30 | Service owner confirms the account can access customer correspondence | Potential data impact increases; actual access or forwarding is still being assessed | Incident lead engages the data owner and agrees proportionate containment with the authorised team |
| 09:45 | The team has applied the approved account/session containment and recorded the changes | The immediate route is restricted; investigation of prior activity remains open | Technical lead verifies the restriction; lead schedules the next update and assigns unanswered questions |
The example deliberately avoids a leap from an alert to a confirmed large-scale breach. It also avoids treating uncertainty as a reason to do nothing. The team preserves evidence, obtains authority and updates its response as impact becomes clearer.
Keep competing explanations visible
For the forwarding rule, possible explanations might include an unauthorised change, a forgotten legitimate configuration or an administrative migration. Record what would support or weaken each explanation. Ask for evidence that could disprove the current favourite theory.
The question “what else could explain this?” is particularly useful when information comes from one tool. A detection alert, an employee report and an administration log may describe different parts of the same event. Reconcile their timestamps and scope before assuming they agree.
Decide containment with the right owner
Containment can reduce further harm while affecting service availability or investigation opportunities. The authorised team should evaluate the actual system and business consequences, then record the choice, approver, time and expected result.
Avoid applying a universal instruction such as always powering off or always leaving a device connected. The correct action depends on safety, ongoing harm, volatile evidence, dependencies and the organisation's capability. Obtain suitable specialist help where the incident exceeds that capability.
The NCSC's incident-process guidance describes correlating findings and reprioritising analysis, containment and recovery actions as circumstances develop. Treat triage as a continuing activity rather than a box ticked once.
Give the next responder a usable handover
Use a short record containing: incident reference; confirmed observations; important uncertainties; affected or potentially affected services; actions already taken and by whom; evidence locations; decisions requiring approval; and the next update time.
For the fictional account case, “unexpected rule confirmed, potential customer correspondence exposure, prior activity under investigation” is more useful than either “false alarm” or “all customer data stolen” without evidence.
Record the reason if an incident is downgraded or closed. A benign explanation should be supported by evidence and an authorised decision. If a technical weakness remains, link it to the remediation backlog so closing the alert does not lose the improvement work.
Keep collected records traceable with the evidence-handling guide, then use the post-incident review to examine what made the response easier or harder.
Sources and further reading
- NIST SP 800-61r3: full publication — checked 2 November 2026
- NCSC: Plan your cyber incident response processes — checked 2 November 2026