8 Security Operations and Incident Response

Purpose and response cycle

Incident response is coordinated work to recognize and manage security incidents, limit their effects, restore services, and use what was learned to improve security. It supports the confidentiality, integrity, and availability of information and systems.

NIST’s current guidance treats response as part of ongoing cybersecurity risk management. The cycle is to prepare broadly, detect, respond, and recover, then apply lessons through continuous improvement.

Recognizing and assessing incidents

A security event is an observed activity, such as an unusual login or malware alert. An incident is an event—or series of events—that meets the organization’s criteria for a security impact or policy violation. One alert alone may not prove compromise, so responders correlate evidence from endpoint, identity, network, cloud, and application logs.

Potential indicators include unexpected account activity, unauthorized changes, data transfers that do not fit normal patterns, unavailable services, or security tools being disabled. Responders record when and where an alert occurred, the affected accounts and assets, what is known, and what remains uncertain. A severity scheme and escalation path help route urgent threats to the appropriate technical, leadership, legal, privacy, and communications teams.

A single failed login may be routine. Repeated failures followed by a successful login from an unusual location and then access to sensitive files form a stronger pattern that warrants investigation.

Preserving evidence

Evidence helps establish what happened, how far an attacker reached, and whether recovery is safe. Follow organizational procedures and consult forensic specialists or legal counsel when appropriate. Preserve relevant logs and system data promptly because some records are short-lived or may be overwritten.

Record actions and times, protect collected material from unauthorized access or changes, and maintain a chain of custody: a record of who handled evidence, when, and why. Where feasible, make a forensic copy and analyze the copy rather than the original. Protect sensitive evidence with access controls and encryption, and keep reliable timestamps and collection notes.

Cryptographic hashes can help detect whether a file or image changed. Matching hashes support integrity, but a hash does not encrypt data or prove by itself that evidence is authentic. Do not delay urgent safety or containment actions merely to capture evidence; document the tradeoff and preserve what is practical.

Containing and removing threats

Containment limits ongoing harm while responders investigate. Possible measures include isolating a device from the network, disabling or restricting compromised accounts, revoking sessions or keys, blocking malicious traffic, or temporarily taking a service offline. Choose measures based on the threat, business impact, and safety needs. In operational technology or other safety-critical environments, isolation can itself create hazards, so coordinate with system owners.

Use least privilege and a zero-trust approach: do not assume an account or device is safe merely because it is inside the organization’s network. Verify identity and device context, restrict access to only what is needed, and re-check access as conditions change. These controls can limit an attacker’s ability to move from one compromised account or system to another.

After containing the threat, eradicate its causes and persistence where possible. This may include removing malicious tools, closing the exploited weakness, correcting unsafe configurations, and resetting compromised credentials. Keep a record of changes so the response remains understandable and reversible when necessary.

Restoring trustworthy services

Recovery restores trustworthy operations, not just availability. Restore from known-good backups or rebuild affected systems when warranted. Address the entry path and persistence before reconnecting systems; reset affected credentials and keys, apply needed updates, and test that systems and security controls work as expected.

Restore services in a controlled order, monitor for signs of renewed compromise, and communicate status to stakeholders. Recovery is part of the incident-response cycle.

Recovery decisions involve confidentiality, integrity, and availability. A fast return to service supports availability, but restoring compromised systems without verifying their integrity can repeat the incident. Protecting confidentiality may require limiting access or notifying affected parties. Balance these goals according to risk and organizational priorities.

Learning and improving

When immediate response ends, review the incident timeline, decisions, impact, and what worked or failed. Identify practical improvements, such as better log coverage, clearer escalation, stronger authentication, narrower permissions, tested backups, or updated response procedures.

Update detections and exercise revised procedures. Share useful threat information through approved channels while protecting sensitive information. Continuous improvement applies lessons across cybersecurity risk management rather than treating response as a one-time technical task.