Incident Detection & Response in Cybersecurity — Complete Guide

Incident Detection & Response is the process of quickly finding cyberattacks or suspicious activity, confirming what happened, stopping the damage, removing the attacker, restoring systems, and improving security afterward.

Simple meaning:

Detection = Find the attack
Response  = Stop it, fix it, recover, and learn

NIST’s incident handling guide describes incident response as a structured process for analyzing incident data and deciding the correct response. The common lifecycle is preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

1. What is a cybersecurity incident?

A cybersecurity incident is an event that may harm the security of systems, data, users, or business operations.

Examples:

Malware infection
Ransomware attack
Stolen password
Unauthorized login
Data leak
Phishing attack
SQL injection
DDoS attack
Insider misuse
Suspicious admin activity
Cloud storage exposed publicly

Microsoft describes incident response as the actions an organization takes when it believes IT systems or data may have been breached, with goals such as eliminating the attack, recovering, notifying required parties, and reducing future risk.

2. Incident Detection

Incident detection means identifying signs that something suspicious or malicious is happening.

Detection can come from:

Source	What it detects
SIEM	Correlates logs and alerts
EDR/XDR	Malware, suspicious endpoint behavior
Firewall logs	Blocked traffic, scans, unusual connections
IDS/IPS	Network attack patterns
Cloud logs	Suspicious cloud access or configuration changes
Application logs	Failed login, API abuse, SQL errors
Email security	Phishing, malicious attachments
User reports	Suspicious email or abnormal system behavior
Vulnerability scanners	Weak systems attackers may exploit

Common signs of an incident

Many failed login attempts
Login from unusual country
Admin login at unusual time
New user account created unexpectedly
Large data export
Endpoint CPU suddenly high
Unknown process running
Files renamed or encrypted
SQL errors from web input
Antivirus alert
User reports phishing email
Unexpected firewall rule change
Unexpected cloud permission change

Example:

A user normally logs in from Norway.
Suddenly the same user logs in from another country at 03:00.
This may be suspicious.

3. Detection vs Response

Area	Meaning	Example
Detection	Find suspicious activity	SIEM alert: many failed logins
Analysis	Confirm real incident or false alarm	Check logs, user, IP, device
Response	Take action	Disable account, block IP, isolate host
Recovery	Restore normal operation	Restore backup, patch system
Lessons learned	Improve future security	Add MFA, tune alerts

4. Incident Response Lifecycle

A practical incident response lifecycle:

1. Preparation
2. Detection and analysis
3. Triage and classification
4. Containment
5. Eradication
6. Recovery
7. Lessons learned

SANS commonly presents this as PICERL: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned.

5. Stage 1 — Preparation

Preparation means getting ready before an incident happens.

You need:

Incident response policy
Incident response plan
Security tools
Logging enabled
Backup strategy
Contact list
Roles and responsibilities
Playbooks
Tabletop exercises
Legal/compliance process
Communication templates

CISA says an incident response plan should be a formally approved written document that helps the organization before, during, and after a cybersecurity incident.

Important preparation items

Item	Purpose
Incident response team	Know who handles incidents
Contact list	Know whom to call
Logging	Have evidence for investigation
Backups	Recover from ransomware or deletion
Playbooks	Step-by-step response guidance
Tools	Detect, investigate, and respond
Training	Make team ready
Legal process	Handle breach notification rules

Incident response team roles

Role	Responsibility
Incident Commander	Leads the response
Security Analyst	Investigates alerts
SOC Analyst	Monitors SIEM/EDR
System Admin	Fixes servers/endpoints
Network Engineer	Blocks IPs, checks firewall
Application Developer	Fixes application vulnerability
Database Admin	Checks database activity
Legal/Compliance	Handles regulatory obligations
Communications	Handles internal/external messages
Management	Makes business decisions

6. Stage 2 — Detection and Analysis

This is where the team finds and understands the incident.

Detection questions

What happened?
When did it start?
Which systems are affected?
Which users are involved?
What data may be exposed?
Is the attacker still active?
Is this a false positive?
What is the business impact?

Example detection sources

SIEM alert
EDR malware alert
Firewall logs
Windows Event Logs
Linux auth logs
Cloud audit logs
Database logs
Web server logs
Application logs
User report
Threat intelligence feed

Important logs to check

Windows

Security Event Log
PowerShell logs
Sysmon logs
Defender alerts
Login events
Process creation events

Linux

/var/log/auth.log
/var/log/syslog
/var/log/nginx/access.log
/var/log/nginx/error.log
bash history
running processes
cron jobs
SSH login logs

Cloud

Azure Activity Logs
Microsoft Entra ID sign-in logs
AWS CloudTrail
GCP Audit Logs
Storage access logs
Kubernetes audit logs

Web application

Login attempts
API request logs
HTTP 500 errors
SQL errors
JWT validation failures
Admin actions
File upload activity

7. Stage 3 — Triage and Classification

Triage means deciding how serious the incident is and what to do first.

Severity levels

Severity	Meaning	Example
Critical	Major business impact	Ransomware spreading
High	Serious risk	Admin account compromised
Medium	Limited impact	Malware blocked on one laptop
Low	Minor issue	Suspicious email reported, not clicked

How to classify incident type

Phishing
Malware
Ransomware
Credential theft
Data breach
DDoS
Web application attack
Insider threat
Cloud compromise
Supply chain compromise

Triage example

Alert:
Multiple failed login attempts on admin account.

Check:
Was login successful?
From which IP?
Was MFA passed?
Was account used after login?
Was any data accessed?

Decision:
If login failed only: monitor/block IP.
If login succeeded: treat as account compromise.

8. Stage 4 — Containment

Containment means stopping the incident from spreading.

Simple meaning:

Containment = Limit the damage

Short-term containment examples

Disable compromised account
Isolate infected laptop
Block malicious IP
Remove device from network
Disable suspicious API key
Revoke stolen JWT/session tokens
Stop affected service
Block malicious domain
Disable exposed storage bucket

Long-term containment examples

Apply temporary firewall rules
Force password reset
Enable MFA
Segment network
Move critical systems to isolated network
Disable vulnerable feature
Deploy temporary WAF rule

Example

If a laptop is infected with malware:

1. Disconnect laptop from network.
2. Preserve evidence.
3. Check EDR alerts.
4. Identify malware behavior.
5. Check if other systems are infected.

9. Stage 5 — Eradication

Eradication means removing the root cause and attacker presence.

Examples:

Remove malware
Delete malicious user account
Remove persistence mechanism
Patch vulnerable software
Fix SQL injection bug
Remove malicious scheduled task
Rotate compromised secrets
Close exposed port
Remove attacker SSH key
Rebuild compromised system

Important eradication rule

Do not only remove the visible symptom. Fix the root cause.

Bad:

Delete malware file only

Good:

Delete malware
Patch vulnerability
Remove persistence
Reset credentials
Check lateral movement
Harden system

10. Stage 6 — Recovery

Recovery means safely returning systems to normal operation.

Examples:

Restore from clean backup
Rebuild server
Patch system
Validate configuration
Monitor closely
Reconnect to network
Return service to users
Confirm business functions work

Recovery checklist

System is clean
Vulnerability fixed
Credentials rotated
Backups verified
Monitoring enabled
Logs reviewed
No attacker persistence found
Business owner approves restore

For ransomware, recovery often includes restoring from clean backups and verifying that the attacker is no longer active before reconnecting systems.

11. Stage 7 — Lessons Learned

After the incident, conduct a review.

Ask:

What happened?
How was it detected?
Why did it happen?
What worked well?
What failed?
How long did detection take?
How long did response take?
What controls should be improved?
Which policies need update?
Which alerts should be tuned?

Output of lessons learned

Incident report
Root cause analysis
Timeline
Evidence summary
Business impact
Actions taken
Preventive actions
Owner and deadline for improvements

12. Incident Response Metrics

Useful metrics:

Metric	Meaning
MTTD	Mean Time To Detect
MTTA	Mean Time To Acknowledge
MTTC	Mean Time To Contain
MTTR	Mean Time To Recover/Respond
False positive rate	How many alerts were not real
Number of incidents by type	Phishing, malware, web attack, etc.
Patch time	Time to fix vulnerability
Repeat incidents	Same issue happening again

Simple meaning:

Good incident response reduces detection time, containment time, and recovery time.

13. Common Incident Types and Response

A. Phishing incident

Detection:

User reports suspicious email
Email gateway alert
Multiple users receive same message

Response:

Collect email headers
Check links and attachments safely
Remove email from mailboxes
Block sender/domain
Check if user clicked
Reset password if credentials entered
Enable or verify MFA
Educate users

B. Malware incident

Detection:

EDR alert
Unknown process
High CPU usage
Suspicious file
Unexpected network traffic

Response:

Isolate machine
Preserve evidence
Identify malware
Kill malicious process if safe
Remove malware
Patch exploited vulnerability
Reset credentials
Reimage machine if needed
Monitor for reinfection

C. Ransomware incident

Detection:

Files encrypted
Ransom note
Many file rename events
EDR ransomware alert
User cannot open files

Response:

Disconnect affected systems
Stop spread
Disable compromised accounts
Preserve evidence
Identify ransomware family
Check backups
Do not immediately wipe evidence
Notify leadership/legal
Restore from clean backups
Monitor for reinfection

D. Compromised account

Detection:

Impossible travel login
MFA fatigue attempts
Login from unusual IP
Suspicious mailbox rules
Unexpected admin actions

Response:

Disable account temporarily
Revoke sessions/tokens
Reset password
Review MFA methods
Remove malicious mailbox rules
Check audit logs
Check data accessed
Re-enable account after cleanup

E. Web application attack

Examples:

SQL injection
Reflected XSS
Authentication bypass
API abuse
File upload attack

Response:

Check web server logs
Identify malicious payloads
Block attacker IP if useful
Deploy WAF rule
Fix code vulnerability
Patch dependencies
Rotate secrets if exposed
Review database access
Test before redeployment

F. Cloud compromise

Detection:

New admin account
Unexpected access key created
Public storage bucket
Unusual API calls
Large data download
Region not normally used

Response:

Disable suspicious keys
Revoke sessions
Remove unauthorized users
Check IAM permissions
Check audit logs
Lock down storage
Rotate secrets
Review network/security groups
Enable stronger monitoring

14. Incident Detection in Your .NET + React + SQL Server App

For your stack:

React UI
ASP.NET Core Web API
SQL Server
Entity Framework Core
JWT authentication
Docker
Linux server

What to monitor

React/frontend

XSS attempts
Unexpected script errors
Abnormal frontend requests
Suspicious redirect behavior

ASP.NET Core API

Failed logins
JWT validation failures
Unauthorized access attempts
HTTP 401/403 spikes
HTTP 500 errors
Input validation failures
Suspicious API payloads
Admin actions
Rate limit violations

SQL Server

Failed database logins
Large data export
Suspicious queries
Permission changes
New database users
DROP/ALTER attempts

Docker/Linux

Unknown containers
High CPU usage
Suspicious processes
New cron jobs
SSH login attempts
Open port changes
Image vulnerabilities

Example alerts to create

More than 10 failed logins from same IP in 5 minutes
Admin login from unusual country
More than 20 HTTP 500 errors in 10 minutes
SQL error pattern from API input
JWT validation failures spike
New container created unexpectedly
CPU above 90% for 15 minutes
Database backup/export outside normal time

15. Tools Used for Incident Detection & Response

Tool type	Examples
SIEM	Microsoft Sentinel, Splunk, Elastic SIEM
EDR/XDR	Microsoft Defender, CrowdStrike, SentinelOne
Vulnerability scanner	Nessus, Qualys, OpenVAS
Web app scanner	OWASP ZAP, Burp Suite
Cloud security	Defender for Cloud, AWS GuardDuty
Network monitoring	Zeek, Suricata, Wireshark
Log collection	Fluent Bit, Filebeat, Syslog
Container scanning	Trivy, Grype
Ticketing	Jira, ServiceNow
Case management	TheHive, Microsoft Sentinel incidents

16. Incident Response Playbook Template

Use this structure for each incident type.

Playbook name:
Example: Compromised user account

Trigger:
Suspicious login or impossible travel alert

Initial checks:
- User identity
- Source IP
- Device used
- MFA status
- Time of login
- Actions after login

Containment:
- Disable account
- Revoke sessions
- Block IP if needed

Eradication:
- Reset password
- Remove malicious MFA methods
- Remove mailbox rules
- Review permissions

Recovery:
- Re-enable account
- Monitor login activity
- Confirm user can work

Communication:
- Notify user
- Notify manager/security team
- Notify legal if data exposed

Lessons learned:
- Why did account get compromised?
- Was MFA enabled?
- Do alerts need improvement?

17. Incident Report Template

Incident Title:
Date/Time Detected:
Reported By:
Incident Type:
Severity:
Affected Systems:
Affected Users:
Data Involved:
Business Impact:

Summary:
Short explanation of what happened.

Timeline:
- Time detected
- Time confirmed
- Time contained
- Time eradicated
- Time recovered

Root Cause:
Why it happened.

Actions Taken:
What the team did.

Evidence:
Logs, alerts, screenshots, file hashes, IPs.

Impact:
Systems/data/business affected.

Recommendations:
Preventive actions.

Owner:
Person responsible for follow-up.

Status:
Open / Contained / Recovered / Closed

18. Best Practices

Prepare before incident happens
Enable centralized logging
Use MFA for all important accounts
Use least privilege
Patch systems quickly
Keep offline/immutable backups
Practice tabletop exercises
Create incident playbooks
Monitor privileged accounts
Use EDR on endpoints
Use SIEM for log correlation
Keep contact list updated
Preserve evidence
Document every action
Communicate clearly
Review and improve after every incident

19. Common Mistakes

No incident response plan
No proper logging
No tested backups
Everyone has admin access
Delayed communication
Deleting evidence too early
Only fixing symptoms, not root cause
No owner for follow-up actions
Ignoring low severity alerts that repeat
No tabletop exercises
No cloud audit logging

20. Simple Example: SQL Injection Incident

Detection

SIEM alert shows many SQL errors from same IP.
API logs show strange input:
' OR '1'='1

Analysis

Check affected endpoint
Check database logs
Check whether data was accessed
Check if attacker authenticated

Containment

Block attacker IP
Disable vulnerable endpoint temporarily
Add WAF rule

Eradication

Fix vulnerable code
Use parameterized queries
Add input validation
Patch dependencies

Recovery

Deploy fixed version
Test login/API
Monitor database logs
Re-enable endpoint

Lessons learned

Add security tests
Add alert for SQL error spikes
Review all similar queries
Train developers on secure coding

21. Final Simple Summary

Incident Detection & Response means:

1. Prepare before attacks happen.
2. Detect suspicious activity.
3. Analyze and confirm the incident.
4. Contain the damage.
5. Remove attacker and root cause.
6. Recover systems safely.
7. Learn and improve security.

Very simple memory trick:

Detect → Analyze → Contain → Eradicate → Recover → Learn