Security incident management: process, roles and tools

Security incident management is the process for detecting, containing, investigating and recovering from events that threaten the confidentiality, integrity or availability of your systems and data. It follows the same lifecycle as other incident response, with three additions: restricted access to incident details, evidence preservation, and decisions about legal and regulatory notification deadlines.

NIST SP 800-61 incident response phases

NIST’s incident handling guide is the most widely referenced framework for security incident response. SP 800-61 Rev. 2 (2012) defined four phases. SP 800-61 Rev. 3, published in April 2025, supersedes it and organizes the same work around the NIST Cybersecurity Framework 2.0 functions. The table maps one onto the other.

Rev. 2 phase	What the team does	CSF 2.0 functions in Rev. 3
Preparation	Set policy, roles and on-call; build playbooks; deploy logging and detection; agree on who can authorize containment and notification.	Govern, Identify, Protect
Detection and analysis	Triage alerts and reports, confirm whether an incident happened, judge scope and severity, start the timeline.	Detect
Containment, eradication and recovery	Isolate affected systems, revoke compromised credentials, remove the attacker’s access and tooling, restore from known-good state, monitor for return.	Respond, Recover
Post-incident activity	Hold a retrospective, record lessons learned, update controls and playbooks, keep evidence as your retention policy requires.	Identify (improvement)

Rev. 3 treats incident response as part of ongoing cybersecurity risk management, which is why preparation and improvement map to several functions.

How security incidents differ from reliability incidents

Most of the mechanics carry over: an incident commander, a timeline, severity levels and a retrospective. The differences are in who can see the incident and what clocks are running.

	Reliability incident	Security incident
Main concern	Availability and performance	Confidentiality, integrity and availability
Default visibility	Open channel, anyone can join	Restricted channel, need-to-know access
Evidence	Logs and metrics for diagnosis	Logs, snapshots and artifacts preserved for investigation, and possibly for regulators or law enforcement
Containment	Roll back, fail over, scale	Isolate hosts, revoke credentials, block indicators, sometimes watch the attacker before acting
Who joins	Engineering, support, communications	Security, engineering, legal, privacy, communications, executives
External deadlines	Customer SLAs	Legal and regulatory notification deadlines, contractual breach clauses
Public communication	Status page updates on a cadence	Reviewed by legal before release; timing may depend on notification rules

Confidentiality and private channels

Details of an active security incident can help an attacker, expose personal data or move a stock price. Open the incident in a private channel, add people by role, and review the member list as the incident goes on. Keep sensitive details out of broadcast channels and status pages until legal and communications agree on the wording.

Legal and regulatory clocks

Several laws set notification deadlines for security incidents. The summary below describes what each source says; it isn’t legal advice, and which rules apply depends on your organization, data and jurisdictions.

Requirement	Who it applies to	Deadline as written in the source
GDPR Article 33	Controllers processing personal data of people in the EU	Notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. Article 34 covers notifying affected people when the risk is high.
SEC Form 8-K Item 1.05	Public companies registered with the US SEC	Disclose a material cybersecurity incident generally within four business days after determining it is material. Disclosure may be delayed if the US Attorney General determines it poses a substantial risk to national security or public safety.
NIS2 Directive Article 23	Essential and important entities in EU member states	Early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month.
HIPAA Breach Notification Rule	US covered entities and business associates	Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured protected health information.

Two practical points follow. First, the clocks start at different moments: GDPR and NIS2 at awareness, the SEC rule at the materiality determination. Record both times in the incident timeline. Second, contracts with customers often carry their own notification terms, so legal needs to be in the incident early.

Security incident roles

Role	Responsibilities
Incident commander	Runs the response, sets priorities, decides when to escalate, keeps the incident moving. Usually from security for confirmed security incidents.
Security lead	Directs investigation and containment, interprets detection data, decides what evidence to preserve.
Engineering lead	Makes changes to affected systems: isolation, credential rotation, patching, restore.
Scribe	Keeps the timeline: what was found, what was changed, who decided what, and when.
Legal counsel	Assesses notification obligations and contractual terms, advises on privilege and communication.
Privacy lead or DPO	Assesses whether personal data is involved and what risk it poses to the people affected.
Communications lead	Drafts internal, customer and public statements with legal review.
Executive sponsor	Approves major decisions such as public disclosure, customer notification or taking systems offline.

Smaller teams combine roles. The incident response roles guide covers how to staff each one.

Security incident response checklist

Detect and declare

• Incident declared as private, with access limited to the response team.
• Severity set and incident commander assigned.
• Time of first detection and time of confirmation recorded.
• Legal and privacy notified if personal data, customer data or a public-company disclosure might be involved.

Contain and preserve

• Evidence preserved before changes: disk or instance snapshots, relevant logs, alert data.
• Affected systems isolated and compromised credentials, keys and tokens revoked.
• Indicators of compromise recorded and blocked.
• Every containment action logged in the timeline with who did it and when.

Eradicate and recover

• Attacker access and tooling removed; root entry point identified.
• Systems restored from known-good state and monitored for return.
• Notification decisions made and documented, with timestamps, by legal.
• Customer and public communication reviewed by legal and communications before release.

After the incident

• Retrospective held with security, engineering and legal.
• Follow-up items have owners and due dates.
• Evidence retained according to policy.
• Playbooks and detection rules updated.

How teams do this in Rootly

Rootly runs the coordination side of a security incident: who is involved, what happened when, and what follow-up work remains. Your detection and SIEM tools keep finding threats; Rootly coordinates the people who respond. Each feature below is documented on docs.rootly.com.

• Private incidents. A private incident adds incident-level access on top of role-based access control. Users see it only if their role grants private-incident read access or if a responder adds them. You can mark an incident private when you declare it in Slack.
• Access management during the incident. Add or remove people with /rootly access or the Manage Access dialog in Slack or on the web. Rootly attempts to invite added users to the incident channel, and its “remove unauthenticated users” option removes anyone without private-incident permission.
• Security incident types. Incident types such as “Security Event” can drive workflow conditions, so a security incident notifies the security team, attaches the right playbook and starts its own retrospective process.
• Security alerts in. Splunk is an alert source, and any detection tool that can send an HTTP request can use the generic webhook alert source. Expel is listed on Rootly integrations for managed detection and response alerts.
• Roles. Define security-specific incident roles such as security lead or legal counsel, and assign them from Slack or the web.
• A defensible timeline. The incident timeline records events, decisions and status changes. If you declare after detection, update the incident timestamps so the record matches when you became aware.
• Follow-up work. Create remediation action items in Jira so they stay visible after the incident closes.

For audit evidence, see audit-ready incident records for SOC 2. Security incidents in cloud infrastructure often start as cloud incidents, so link both processes in your playbooks.