Resources · 21

Triage a cyber incident and preserve early evidence

Turn a confusing signal into a timeline, hypotheses, decisions and proportionate escalation.

Updated 28 October 2026 · 9 min

What this guide helps achieve

Receive a useful signal
Preserve context
Assess impact
Organise decisions

Quick check

Who saw what, where and when?
Which sources or traces may disappear?
Which services, accounts and data could be affected?
Who authorises immediate measures?
When will the assessment be revisited?

Step-by-step method

01
Open one case record
Record the initial signal, time, observer, affected systems and reporting channel. Assign a case owner and deputy.
Deliverable: timestamped incident record.
02
Separate fact from hypothesis
List verifiable observations, sources and confidence. State possible scenarios without assuming origin or scope.
Deliverable: factual timeline and testable hypotheses.
03
Preserve volatile material
Identify useful logs, alerts, messages and system states; retain copies under internal procedures and record access. Avoid changes that destroy traces.
Deliverable: initial evidence inventory and handling record.
04
Assess scope and impact
Map potentially affected assets, accounts, data and business journeys. Record what is confirmed, ruled out or unknown and the cost of waiting.
Deliverable: scope map and provisional impact level.
05
Decide and escalate
Choose proportionate protective steps, specialists and stakeholders to inform under applicable requirements. Log the decision maker and rationale.
Deliverable: decision log and communication plan.
06
Reassess and learn
Set the next situation update, add new evidence and connect causes and gaps to corrective work after closure.
Deliverable: dated updates and lessons learned.

Understand · try · decide

False positives: count the cases before judging an alert

Fictional example: 100 positive cases among 10,000 observations. Reference labels are known; each observation produces one binary decision here: alert or no alert.

The set contains 90 true positives, 99 false positives, 10 false negatives and 9,801 true negatives. Recall uses positive cases; precision uses alerts. These results do not establish a probability for a real alert.

One set, distinct denominators

Measure	Calculation	Interpretation
Reference positive cases	100 / 10,000 · 1 %	Frequency imposed in this set.
Detected positive cases	90 / 100 · 90 %	Recall: positive-case denominator.
Alerts on negative cases	99 / 9,900 · 1 %	False-positive rate: negative-case denominator.
Positive cases among alerts	90 / 189 · 47.62 %	Precision: alert denominator.
Negative cases with no alert	9,801 / 9,900 · 99 %	Specificity: negative-case denominator.

Change an assumption

What changes the conclusion

Change one condition, then state which conclusion remains supported.

Define the scope
Fix the unit, period, labels and rule version.
Count all four outcomes
Keep both alerts and non-alerts in the reference set.
Qualify the signals
Seek evidence about the real case and document the decision.

Fictional exercise: no real alert is handled.

What if positive cases rise to 10%?

New evidence: The second set has 1,000 positives among 10,000, assuming unchanged recall and false-positive rate.
What changes the decision: Of 990 alerts, 900 are positive: precision reaches 90.91%. The population changes the result; holding these rates constant is a teaching assumption.

What if only alerts were reviewed?

New evidence: Cases with no alert have no reference label.
What changes the decision: False negatives are unknown: do not claim measured recall. Document label coverage and check an appropriate scope.

What if tuning reduces the alert count?

New evidence: The new rule produces fewer notifications.
What changes the decision: That alone does not show improvement. Replay the same labelled cases and also compare missed positives, delays and investigation workload.

Management indicators

Indicator	What it measures	First action
Time to triage	Time from signal to first documented scope	Clarify escalation
Decision trace	Decisions with time, owner and rationale	Complete the log
Evidence coverage	Critical sources identified and preserved	Fix collection gaps
Reassessment	Hypotheses revisited at agreed checkpoints	Update scope

Common pitfalls

Erasing traces through premature action
Announcing a cause before validation
Keeping contradictory timelines
Failing to date a decision or revisit an assumption

Frequently asked questions

Is every alert an incident?

No. Triage determines whether the observations warrant a formal response and can change as evidence develops.

Must protection wait until everything is known?

No. Proportionate measures can limit harm while investigation continues, provided their effects on evidence and service are recorded.

What can be communicated initially?

Confirmed facts, known effects, current actions and the next update. Cause and scope remain provisional until established.

Incident, vulnerability or data breach: find the right contact

A CSIRT serves a defined constituency: an organisation, sector or community. Its country and FIRST membership do not establish your eligibility, its availability or the services it offers. Check all three on its official website.

Establish the facts
Check the constituency
Confirm the official channel

Incident on your system

Contact the internal team or provider named in your response plan. Look for a CSIRT covering your organisation when external coordination is needed.

Check who it serves, reporting procedures and operating hours; a public form does not guarantee an immediate response.

Find a CSIRT

Flaw in a third-party product

Check the supplier’s disclosure policy or product security incident response team (PSIRT). The /.well-known/security.txt file may specify a contact, policy and encryption details.

Check the domain, Expires field and policy scope. security.txt does not authorise testing; agree on a channel before sending sensitive evidence.

Understand disclosure

Personal data involved

Involve the data controller and data protection officer, if appointed, alongside the technical response team.

Technical assistance and any regulatory notification are separate processes. Have the applicable authority, conditions and deadlines determined for your situation.

Explore data governance

Prepare a useful first contactTimeline with time zone, affected service and observed facts, kept separate from hypotheses.Known scope and impact, actions already taken and a person authorised to communicate.Redacted summary and agreed sharing channel; no passwords, tokens or complete logs in a public form.

This checklist prepares a conversation; it measures neither incident severity nor resolution. Selections stay on this page and are not sent.

References: FIRST, RFC 9116 and CNIL (French framework). FIRST · CSIRT Services Framework 2.1 RFC 9116 · security.txt CNIL · Violations de données personnelles

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
NIST · SP 800-61 Rev. 3 Prepare incident response within cybersecurity risk management.	Revision 3 was published in April 2025 and supersedes Revision 2. It is a CSF 2.0 Community Profile.	Rehearse containment decisions, evidence preservation, communication and recovery. Compare planned actions with evidence produced during the exercise. Explore the method →	Reading the guide does not validate a local plan. Contacts, emergency access and dependencies need local testing.

Cyber incidents: recovery decisions and evidence

From alert to recovery: make decisions verifiable

Qualifying a signal, preserving investigative material and restoring a service answer different questions. CSF 2.0 distinguishes recovery initiation, integrity of restoration assets, validation of restored assets and the end of recovery. These are outcomes to document, not certification or one mandatory procedure.

The twelve entries below are a selected, paraphrased part of CSF 2.0. Evidence columns, timelines and injects are original teaching proposals. They do not replace a local plan and imply no universal timing, severity level or authority. SP 800-61 Revision 3 has been final since April 2025 and supersedes Revision 2.

Fictional empty recovery laboratory with an isolated rack and storage cases under amber light. — Generated conceptual illustration: an empty isolated recovery-validation laboratory. It depicts no real system, authentic backup or security result.

Four separate decisions during recovery

RS.MA-05: apply initiation criteria. RC.RP-03: verify restoration assets before use. RC.RP-05: check restored assets and service operation. RC.RP-06: declare completion against criteria and finish documentation. These are decision points, not a mandatory sequence; investigation and monitoring may continue.

Twelve NIST outcomes and useful local evidence

Twelve NIST outcomes and useful local evidence
Reference and paraphrased meaning	Useful local record	Conclusion to avoid
`RS.MA-02` Triage and validate incident reports.	Received signal, verified source, timestamps and reason for the provisional assessment.	An alert is not automatically a confirmed incident.
`RS.MA-03` Categorise and prioritise incidents.	Suspected or confirmed type, affected service, impact, urgency and review date.	Alert volume alone does not establish business severity.
`RS.MA-04` Escalate or elevate as needed.	Resource need, contacted role, required authority and next reassessment.	Adding responders does not mean a decision has been obtained.
`RS.MA-05` Apply criteria for initiating recovery.	Local criteria, known facts and assumptions, action risks, decision maker and authorised scope.	A backup’s existence alone is insufficient to initiate restoration.
`RS.AN-06` Record investigative actions while preserving record integrity and provenance.	Action, actor, time, reason, observed effect and protected access to the log.	A rewritten account without history does not establish decision order.
`RS.AN-07` Collect incident data and metadata while preserving integrity and provenance.	Origin, collection, timestamps, custodian and retention rules; access limited to authorised staff.	A hash alone does not establish full origin or all collection circumstances.
`RC.RP-01` Execute recovery procedures when initiated from incident response.	Plan and version, authorisations, assigned people and operation start.	Recovery can run during or after response rather than always being a wholly separate phase.
`RC.RP-02` Select, scope, prioritise and perform recovery actions.	Target services and dependencies, order, resources, assumptions and scope changes.	Restoring everything in one fixed order may not reflect priorities.
`RC.RP-03` Verify backups and other restoration assets before using them.	Planned checks for corruption, compromise indicators, consistency and origin of the selected candidate.	A successful backup job does not by itself validate the copy.
`RC.RP-04` Consider critical mission functions and cyber risk when establishing post-incident operating norms.	Accepted normal or degraded operation, limitations, business owner and appropriate monitoring.	Degraded operation should not be described as complete recovery without qualification.
`RC.RP-05` Verify restored assets, restore services and confirm operation.	Integrity checks, root causes addressed within scope, tested business journey and owner validation.	Copied files or a reachable screen do not demonstrate journey recovery.
`RC.RP-06` Declare recovery completion against criteria and finish incident documentation.	Closure decision, criteria met, residual risks, review and assigned actions.	Service return does not automatically close every investigation or corrective action.

A fictional timeline that preserves uncertainty

Teaching case: a request-processing application shows unusual service-account activity. T+0 is 08:00 UTC for this exercise; these durations are not NIST targets. No affected-record count or data disclosure is assumed without evidence.

A fictional timeline that preserves uncertainty
Exercise time	Observation or decision	Evidence and limit
T+0 · 08:00 UTC	An alert reports an unusual export.	Retain the event and its source; the alert alone does not prove exfiltration.
T+7 · 08:07 UTC	The alert source is validated; the overnight backup is marked completed.	Two different facts: job status does not establish backup integrity.
T+12 · 08:12 UTC	The lead declares an incident under the plan and has a sensitive journey paused.	Record authority, known scope and business effects; extent remains provisional.
T+25 · 08:25 UTC	Targeted access restrictions are authorised and recorded.	Trace what actually changed; this does not prove absence of other access or persistence.
T+40 · 08:40 UTC	A restoration-candidate check reveals corruption.	Do not use that candidate; document rejection and evaluate another recovery point.
T+60 · 09:00 UTC	Another candidate passes the defined checks; isolated restoration is authorised.	Keep results and check scope. Passing is not a guarantee of absence of compromise.
T+90 · 09:30 UTC	Files are restored but a dependency causes the business journey to fail.	Service validation has not passed; the case stays open.
T+120 · 10:00 UTC	The critical journey is tested in a business-approved degraded mode.	Record limits and monitoring. Closure still awaits the planned criteria and decision.

Six fields for each important decision

Observed fact: Source, event time, collection time and time zone.
Assumption: What is assumed, why and how it will be checked.
Chosen action: Exact scope, decision maker and assigned executor.
Observed effect: Actual result, deviation and remaining unknowns.
Retained evidence: Protected reference, provenance, integrity and authorised access.
Next review: Condition or date, owner and blocking dependency.

Use the six exercise cards →

Primary references and limits

Identifiers and outcome meanings come from CSF 2.0; SP 800-61r3 adds incident response and recovery recommendations. Evidence tables, times and scenarios are educational, with no client results, certification or actual notification.

NIST · SP 800-61 Rev. 3 · Final · 2025-04-03
Community Profile CSF 2.0 ; remplace / supersedes Rev. 2
NIST · SP 800-61r3 — recommandations détaillées / detailed recommendations · April 2025
Pages imprimées / printed pages 27–29, 34–35 : RS.MA, RS.AN, RC.RP, RC.CO
NIST · Cybersecurity Framework 2.0 · 2024-02-26 · NIST CSWP 29
Appendix A, printed pages 22–23 : official outcome identifiers
NIST · SP 800-184 — Guide for Cybersecurity Event Recovery · Final · 2016-12-22
Recovery planning, playbooks, testing and improvement

References reviewed 2026-10-22

STIX indicators and TLP sharing

Connect the indicator to observations and retirement

An indicator match opens an analytical lead. To assess its significance, preserve observed events, technical context, sensor coverage and alternative hypotheses.

Distinguish Indicator, Observed Data and Sighting; an intelligence assertion does not replace observed data.
Do not equate a DNS resolution with execution or a Sighting count=0 with worldwide threat absence.
Assign an owner and a mechanism for retiring derived rules after expiry or revocation.

Read the STIX, observations and TLP sharing reference →

Sources checked on 2026-10-22 · OASIS · STIX 2.1

OSINT: evidence preservation

Preserve context before confusing a copy with proof

Incident response must connect retained traces to their source, scope and handling actions. A digest protects a content comparison; it does not reconstruct undocumented custody.

Use distinct identifiers for the preserved reference and working copies.
Record handovers, receipts and clock uncertainty.
Preserve an observed discrepancy and its reference before investigating cause.

See copy lineage and the eight preservation cases →

Sources reviewed on 2026-10-22 · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard

Syslog codes and collection evidence

A syslog code cannot qualify an incident alone

During triage, preserve the raw value, source and normalisation rule. Informational severity may document a sign-in or action relevant to an investigation; Emergency remains a sender declaration.

Connect the message to a known asset and exposure context.
Compare the raw event with the value displayed in the SIEM.
Connect alerts to decisions and state collection gaps.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.