Checklist: 7 Things to Do and 7 Things Not to Do Immediately After a Cyber Incident

7 Things You Should Do Immediately After Discovering an Incident

1. Validate the Incident and Perform an Initial Severity Assessment

When an alert or abnormal behavior is detected, the first step is to verify whether it is a real incident or a false positive. This should be done by correlating information from multiple sources such as SIEM, EDR, Firewall, Authentication Logs, Email Gateway, Cloud Logs, and Network Traffic.

The initial assessment should identify:

• Which systems are affected
• Which users or accounts are involved
• Whether sensitive data has been accessed
• Whether the incident is still ongoing or has already stopped
• Whether there is a risk of lateral movement or spread to other systems

As a best practice, the initial validation and severity assessment should be completed as soon as possible, ideally within 15–30 minutes after detection for high-priority alerts. For critical incidents, escalation should not wait until the investigation is fully completed. If there is strong evidence of compromise or business impact, the incident should be escalated immediately according to the organization’s Incident Response process.

A preliminary severity rating helps the organization determine which teams should be involved and which level of Incident Response Process should be activated.

2. Open an Incident Ticket and Record the Timeline from the Beginning

Every incident should be documented systematically from the moment suspicious activity is detected. The record should include the time of detection, alert source, person responsible for the investigation, findings, actions taken, and the result of each action.

A well-maintained timeline is essential because it helps teams understand the sequence of events, supports Root Cause Analysis, and provides important information for the final Incident Report.

3. Notify and Escalate to Relevant Teams

Once an incident is confirmed, or if the risk level is considered high, the relevant teams should be notified immediately according to the Escalation Matrix. These teams may include SOC/CSOC, IT Operations, Network Team, System Owner, Management, Legal, Compliance, PR, or the Data Protection Officer.

For low- or medium-risk incidents, the details of the event, related evidence, and initial findings should be recorded and assigned to the responsible team for investigation and remediation according to the defined process.

However, if the incident shows signs of escalation, affects critical systems, or cannot be contained within the defined timeframe, it should be escalated immediately according to the Escalation Matrix.

Communication should use pre-defined channels. Teams should also be careful not to use communication channels that may already be compromised. For example, if the internal email system is suspected to be affected, a secure backup communication channel should be used instead.

4. Contain the Impact Without Destroying Evidence

If a compromised endpoint, account, or system is identified, appropriate containment actions should be taken. These may include isolating the endpoint from the network, disabling the account, blocking malicious IP addresses or domains, revoking tokens, resetting sessions, or applying temporary rules on Firewall, EDR, or WAF systems.

However, teams should avoid deleting files, shutting down systems, or making unnecessary changes before collecting evidence. Doing so may result in the loss of important information such as memory data, running processes, network connections, logs, or malware artifacts.

5. Collect Critical Evidence as Quickly as Possible

Some types of evidence are short-lived and may be overwritten or lost quickly. These include memory, process lists, network connections, temporary files, EDR telemetry, firewall logs, and cloud audit logs.

Security teams should collect relevant information in a structured manner, including logs, hashes, IP addresses, domains, usernames, hostnames, file paths, timestamps, screenshots, alert details, and indicators of compromise. This information will support further analysis and help guide the next response actions.

6. Identify the Scope of Impact

Teams should not focus only on the device or system that generated the initial alert. They should investigate whether other endpoints, accounts, or systems show similar behavior.

For example, teams should check whether the same IOC appears elsewhere, whether multiple logins came from the same suspicious IP address, whether similar abnormal processes are running on other devices, or whether multiple systems are connecting to the same C2 server.

Understanding the full scope of the incident allows containment to be more accurate, reduces the chance that the attacker remains inside the environment, and lowers the risk of reinfection or repeated attacks.

7. Communicate Formally and Control Information Sharing

For severe incidents, a clear communication owner should be assigned. This helps prevent inaccurate information, confusion, or inconsistent messaging both inside and outside the organization.

All communication should be based on verified facts, not assumptions. Messages should be reviewed by the relevant teams before being shared, especially when the incident involves customer data, personal data, legal matters, or regulatory requirements.

7 Things You Should Not Do Immediately After Discovering an Incident

1. Do Not Shut Down the Machine Immediately Without a Clear Reason

Shutting down a machine may cause valuable memory-based evidence to be lost, such as running processes, active network connections, active malware, or certain encryption keys.

In many cases, isolating the machine from the network may be more appropriate than shutting it down immediately.

However, if the incident is causing severe ongoing damage, such as ransomware actively encrypting large numbers of files, shutting down the machine may be necessary. This decision should follow the organization’s playbook, and the reason should be clearly documented.

2. Do Not Delete Malware or Artifacts Immediately

Although deleting a malicious file may seem like the right action, doing so too quickly can prevent the investigation team from analyzing the malware behavior, persistence mechanism, initial access method, or related indicators of compromise.

Before deleting or cleaning the system, teams should collect the file sample, hash value, file path, and metadata where possible.

3. Do Not Restore Systems Before Understanding the Root Cause

Restoring from backup or rebuilding a server too quickly may cause the system to become compromised again if the original vulnerability, persistence mechanism, or compromised credential has not been addressed.

Before recovery, the team should have a clear understanding of the cause of the incident, such as an exploited vulnerability, compromised account, misconfiguration, exposed service, or credential leakage.

4. Do Not Reset Passwords Without a Strategy

Password reset is often necessary during an incident. However, if it is done at the wrong time, it may alert the attacker and cause them to change tactics, hide deeper in the environment, delete evidence, or accelerate their attack.

Password reset should be considered together with session revocation, account disabling, key rotation, MFA review, token review, and investigation of possible persistence or backdoors within the identity system.

5. Do Not Communicate Through Potentially Compromised Channels

If email, chat systems, or internal accounts are suspected to be compromised, they should not be used to discuss incident details. The attacker may already be monitoring those communication channels.

Organizations should prepare out-of-band communication channels in advance, such as phone contacts, backup communication groups, or communication platforms that are separated from the main environment.

6. Do Not Conclude the Root Cause Too Quickly

During the early stage of an incident, information is often incomplete. Quickly concluding that the incident was caused by malware, user error, phishing, or a specific vulnerability without sufficient evidence may lead the team in the wrong direction.

The investigation should be evidence-driven, and hypotheses should be updated as new information becomes available.

7. Do Not Allow Multiple Teams to Make Changes Without Coordination

During a real incident, several teams may become involved, including SOC, IT, Network, Cloud, Application, and Management teams. Without an Incident Commander or central coordinator, teams may duplicate work, make conflicting changes, or unintentionally destroy evidence.

An organization should assign a main coordinator, establish a central communication channel, and record every action taken during the incident.

Quick Checklist: 7 Things to Do and Not to Do Immediately

Key Takeaways

Effective Cyber Incident Response requires the organization to respond correctly, rely on evidence, and reduce business impact without destroying information that is important for investigation.

During the early stage of an incident, organizations should focus on incident validation, impact containment, evidence collection, structured communication, and coordination between teams. These elements form the foundation for effective Containment, Eradication, Recovery, and Lessons Learned activities.

Having a clear playbook and regularly trained response team helps reduce confusion during a crisis, improve decision-making speed, and increase confidence when responding to cyber incidents.

What is a Cybersecurity Incident Response Playbook?

How BMSP Can Help

BMSP can support your organization in preparing for and responding to cyber incidents through experienced cybersecurity specialists and CSOC services that provide continuous security monitoring and response support.