Incident Response Steps Explained for Security Beginners

What is incident response?

Incident response is the organised process used to identify, contain and recover from a cybersecurity incident. It helps a team limit damage, preserve evidence, restore services safely and reduce the chance of the same incident happening again.

A security alert is not automatically an incident. An alert is a signal that needs investigation, while an incident is a confirmed or reasonably suspected event that affects confidentiality, integrity or availability.

Examples include:

• A compromised employee account
• Malware running on a server
• Unauthorised access to cloud resources
• Data being copied outside the organisation
• A ransomware infection
• A denial-of-service attack affecting a business service

For beginners, the incident response steps can be remembered as:

Prepare → Identify → Contain → Eradicate → Recover → Review

Diagram in words: imagine six connected boxes arranged from left to right. The final Review box has an arrow returning to Prepare because every incident should improve future readiness.

What are the six incident response steps?

The six-step model provides a practical workflow for handling incidents from preparation through improvement. Different frameworks may combine or rename phases, but the underlying activities remain similar.

The traditional six-step model is useful for learning and operational runbooks. Newer frameworks may present incident response as activities connected to broader risk management, detection, response and recovery functions.

Step 1: How should an organisation prepare for incidents?

Preparation means deciding how incidents will be handled before an emergency occurs. A prepared team knows who can make decisions, where evidence will be stored and how critical services can be restored.

A basic preparation checklist should include:

• An incident response policy and contact list
• Defined roles for security, IT, management, legal and communications teams
• Asset inventories and system owners
• Centralised logs with synchronised timestamps
• Endpoint detection, antivirus and network monitoring
• Tested backups protected from normal user accounts
• Secure administrator accounts and multi-factor authentication
• Evidence storage with restricted access
• Communication methods that do not depend on a compromised system
• Tabletop exercises using realistic scenarios

Define severity levels

Severity should reflect business impact, not just technical complexity. A malware alert on an isolated test computer may be less urgent than suspicious access to a production database.

Teams should also understand how logs support investigations. Beginners can review log analysis basics for SOC analysts before practising incident triage.

Step 2: How is a security incident identified?

Identification determines whether an alert represents a real incident, which systems are involved and how serious the situation is. Analysts validate evidence, establish a timeline and avoid making assumptions from a single indicator.

Possible detection sources include:

• SIEM correlation alerts
• Endpoint detection alerts
• Firewall or proxy logs
• Cloud audit logs
• User reports
• Authentication failures
• Unexpected processes or network connections
• Changes to files, accounts or scheduled tasks

A SIEM can bring events from multiple systems into one investigation view. See how security teams detect threats from logs for the relationship between log collection, correlation and alerting.

Ask the first triage questions

1. What generated the alert?
2. When did the activity begin?
3. Which user, device or application is involved?
4. Is the activity still happening?
5. What evidence confirms or contradicts the alert?
6. Could other systems be affected?
7. Is sensitive data or a critical service at risk?

Collect volatile information carefully

On a suspected Linux server, an authorised responder might collect the current time, logged-in users, processes and network connections:

date -u
hostnamectl
who -a
w
sudo ss -plant
sudo ps auxf
sudo lsof -nP

date -u records the current UTC time for timeline correlation. ss -plant displays listening sockets and active TCP connections with associated processes where permissions allow. ps auxf shows a process tree, while lsof -nP can associate files and network sockets with processes.

Collecting information changes a live system slightly, so every command should be documented. If legal, regulatory or law-enforcement action is possible, follow the organisation's evidence procedure rather than improvising.

Examine relevant Linux logs

On a system using systemd, responders can review a defined time window:

sudo journalctl --since '2026-11-03 08:00:00' \
  --until '2026-11-03 10:00:00' --utc

sudo journalctl -u ssh --since '2026-11-03 08:00:00' --utc
sudo last -Fai

Some distributions use sshd rather than ssh as the service unit. Check the correct unit with:

systemctl list-units --type=service | grep -E 'ssh|sshd'

Do not search only for one expected message. Compare authentication events, process activity, file changes, DNS queries and outbound connections to build a reliable timeline.

How does a practical investigation begin?

Consider an Ubuntu web server that generates an alert for an unusual outbound connection. The objective is to confirm whether the connection is expected, identify how it started and determine whether the server is compromised.

The analyst finds the following sequence:

1. An SSH public-key login for the deploy account came from 198.51.100.24.
2. A process started from /tmp/.cache-update shortly afterwards.
3. The process connected repeatedly to 203.0.113.77.
4. The deployment system does not normally use either address.

These documentation IP ranges are used only for the example. An unusual address is an indicator for investigation, not proof of malicious activity.

The responder can inspect the file without executing it:

sudo stat /tmp/.cache-update
sudo file /tmp/.cache-update
sudo sha256sum /tmp/.cache-update

Example output:

/tmp/.cache-update: ELF 64-bit LSB pie executable, x86-64
8f4d...c921  /tmp/.cache-update

file identifies the file format, while sha256sum creates a repeatable hash for evidence tracking and authorised threat-intelligence checks. The hash does not explain what the program does, and a clean reputation result does not prove that the file is safe.

Step 3: How should an incident be contained?

Containment limits further damage while preserving enough evidence to understand the incident. The safest action depends on business impact, attacker activity and the importance of the affected system.

Containment may include:

• Moving an endpoint into an isolated network
• Applying a quarantine security group in a cloud environment
• Blocking confirmed malicious domains or IP addresses
• Disabling a compromised identity
• Revoking active sessions, tokens and exposed keys
• Temporarily removing a server from a load balancer
• Increasing logging around related accounts and systems

Diagram in words: place the compromised server in the centre. Disconnect its paths to users, databases and the internet, but retain a controlled path to the evidence collection system if policy permits.

Do not immediately power off every suspected device. Memory, active connections and running processes may be lost. However, rapid shutdown may still be necessary if destructive malware is actively encrypting systems and isolation is not possible.

For the example server, the team removes it from the load balancer, isolates its network access and revokes the deploy account's active credentials. A clean replacement server maintains the customer-facing service.

Short-term and long-term containment

Short-term containment stops immediate harm. Long-term containment keeps the business operating while a trusted replacement or permanent fix is prepared.

For example, blocking one destination address is short-term containment. Rebuilding the server, rotating deployment credentials and restricting administrative access form part of a more durable response.

Step 4: How is the threat eradicated?

Eradication removes malware, persistence mechanisms, vulnerable components and compromised credentials. The team must address the entry point as well as visible symptoms.

Typical eradication work includes:

• Rebuilding a host from a trusted image
• Removing unauthorised accounts, keys and scheduled tasks
• Patching the exploited vulnerability
• Rotating passwords, API keys, certificates and tokens
• Correcting firewall, IAM or application configuration
• Scanning related systems for the same indicators
• Validating software and configuration integrity

On Linux, persistence checks may include systemd services, cron jobs and SSH keys:

sudo systemctl list-unit-files --state=enabled
sudo crontab -l
sudo find /etc/cron.d /etc/cron.daily /var/spool/cron -type f -ls
sudo find /home /root -path '*/.ssh/authorized_keys' -type f -ls

These commands list possible persistence locations; they do not prove that an entry is malicious. Compare results with approved configurations and change records.

If an attacker obtained root privileges, manually deleting one executable is rarely sufficient. Rebuilding from a trusted image is usually safer because hidden changes may remain. Credentials should be rotated from a known-clean administrative device, not from the compromised host.

Step 5: How should systems be recovered safely?

Recovery restores services in a controlled manner and verifies that the threat has not returned. Systems should be monitored closely before the incident is considered closed.

A recovery plan may include:

1. Restore or deploy a clean system.
2. Apply current security updates.
3. Restore validated data from a known-good backup.
4. Confirm account, network and application configurations.
5. Run security and functional tests.
6. Reconnect the system in stages.
7. Monitor relevant indicators and logs.
8. Obtain approval from the service owner.

For the web server example, the replacement instance is first connected only to its required database and management networks. After health checks and log validation, a small portion of traffic is sent to it through the load balancer. Full traffic is restored only after the team confirms normal behaviour.

Recovery is not complete simply because the application responds to a request. Authentication, logging, backup, monitoring and business functions must also work correctly.

Step 6: What happens during the lessons-learned review?

The lessons-learned review identifies what worked, what failed and which controls should change. It should focus on improving the system rather than blaming individuals.

A useful review answers:

• What was the root cause?
• How did the organisation detect the incident?
• Which alerts were useful or missing?
• How long did validation and containment take?
• Was the scope initially understood correctly?
• Were evidence and decisions documented?
• Did backups and recovery procedures work?
• Which actions have owners and deadlines?

The final timeline might show that an old deployment key remained active after a tooling change. Corrective actions could include expiring unused keys, enforcing central identity controls, restricting SSH source networks and alerting on unexpected deployment-account logins.

How should evidence and incident notes be handled?

Evidence should be collected consistently, stored securely and linked to a clear timeline. Responders must distinguish observed facts from assumptions and record who handled each item.

A simple evidence record can contain:

Hash collected files and verify the copied evidence:

sha256sum suspicious-file > suspicious-file.sha256
sha256sum -c suspicious-file.sha256

A matching hash confirms that the checked file has the same content as when the hash was generated. It does not prove who created the file or whether it is malicious.

What common incident response problems should beginners troubleshoot?

Common problems include missing logs, incorrect timestamps, premature containment and incomplete scoping. Troubleshooting should protect evidence while testing each assumption against more than one data source.

Logs are missing

Check whether the service was logging, whether logs were rotated and whether central copies exist. Review SIEM, firewall, cloud audit and endpoint records rather than relying only on the affected host.

Timestamps do not match

Convert events to UTC and record each source's time zone and clock offset. Do not manually edit original logs; normalise time in the investigation notes or analysis platform.

The suspicious connection cannot be reproduced

The process may have stopped, changed its destination or used short-lived connections. Check historical DNS, proxy, firewall and flow logs, then compare related hosts for the same indicator.

Isolation breaks a critical service

Use staged containment where risk permits. Remove one node from a cluster, restrict only unnecessary paths or replace the affected host before full isolation. Document who accepted any temporary risk.

An alert appears to be a false positive

Record why it is benign, including the process owner, approved change and supporting logs. Closing an alert without evidence makes repeated alerts harder to evaluate.

What should beginners remember about incident response steps?

Incident response is a controlled cycle of preparation, identification, containment, eradication, recovery and improvement. Good responders preserve evidence, document decisions, verify scope and balance security actions with business needs.

Do not rush directly from an alert to deleting files. First establish a timeline, confirm the affected assets and select a containment action that matches the risk.

To practise investigation workflows, Linux evidence collection, SIEM triage and containment in guided labs, explore the Cybersecurity and SOC course. Contact Network Rhinos for current batch details and course enquiries.

*Reviewed by Network Rhinos cybersecurity trainers.*