First actions after detecting a security incident

Incident response begins before the incident

NIST SP 800-61 Revision 3 connects incident response with the wider risk-management process. Preparation includes Govern, Identify, and Protect; the incident cycle includes Detect, Respond, and Recover; and lessons learned should feed continuous improvement.

This changes the perspective: a team should not wait for an outage to decide who may disconnect a system, where logs are stored, how to contact a supplier, or which services are critical.

The first minutes — order of action

1. Name the symptom, not the cause

Record what is actually visible: an EDR alert, unusual sign-in, encrypted file, unavailable service, unknown process, or user report. “We have ransomware” remains a hypothesis until evidence confirms it.

2. Record time and context

The time, device, account, screen, message, and actions performed before detection make later correlation possible. Preserve alert identifiers, message headers, filenames, and available logs according to procedure.

3. Contain proportionately

Isolating a workstation may be appropriate when active malware is suspected, but disconnecting an entire business service without assessment may cause greater damage. The decision should consider criticality, potential lateral movement, evidence availability, and continuity plans.

4. Escalate through the correct channel

Do not discuss an incident through an account or messenger that may be compromised. Activate the established emergency channel and provide a concise status: symptom, time, scope known so far, actions taken, and the decision required.

5. Separate containment from recovery

Deleting one file does not close an incident. First understand the vector, scope, and persistence mechanism; only then restore the system from a state considered trustworthy.

What not to do blindly

• do not clear logs, history, or temporary files without approval from the incident lead;
• do not perform repeated trial restarts;
• do not contact the attacker or respond to demands independently;
• do not send samples or data through private, unapproved channels;
• do not announce a cause or scope before it is confirmed;
• do not reconnect a system merely because the symptom disappeared.

Three common scenarios

Suspicious account sign-in

Review authentication events, location, device, and active sessions. If compromise is confirmed, revoke sessions and tokens, secure recovery methods, require a password change, and analyze mailbox activity, OAuth applications, and actions performed through the account.

Execution of a suspicious file

Record its name, source, and time. Do not delete the message that carried it. According to procedure, limit the device's connectivity, preserve telemetry, and determine whether the same artifact appeared on other endpoints.

Public service outage

Separate failure from attack. Collect load metrics, errors, traffic information, and deployment changes. If DoS or DDoS is suspected, engage the connectivity or mitigation provider, preserve traffic samples, and maintain communication with affected users.

What must be prepared in advance

• a list of system owners and emergency contacts;
• an alternative communication channel;
• log retention and time synchronization;
• authority to isolate accounts, devices, and services;
• backups tested through an actual restore;
• criteria for legal, regulatory, and business escalation;
• ready-to-use short situation-report templates;
• exercises focused on decisions, not only technical commands.

After the incident, do not stop at “who clicked” or “which server failed.” Determine why the defensive system did not interrupt the chain earlier. Lessons learned should produce technical, procedural, and organizational changes.