Incident Response Basics

Why Incident Response Matters

Every organization will face a security incident. The difference between a minor disruption and a catastrophic breach often comes down to how quickly and effectively the IT team responds. Incident response (IR) is the structured approach to detecting, containing, and recovering from security events.

As IT support staff, you are frequently the first point of contact when something goes wrong. Whether a user reports a suspicious email, a server starts behaving erratically, or an alert fires in your monitoring dashboard, your initial actions set the tone for the entire response. Acting correctly in the first minutes can mean the difference between containing a threat to one workstation and watching it spread across the network.

The Incident Response Lifecycle

The NIST Computer Security Incident Handling Guide (SP 800-61) defines four phases of incident response. These phases are not strictly sequential — you will often cycle between them as new information emerges.

Phase 1: Preparation

Preparation happens before an incident occurs. This includes:

• Developing IR plans and playbooks — Documented procedures for common incident types
• Building an IR team — Defining roles, responsibilities, and escalation contacts
• Deploying tools — SIEM, EDR, log aggregation, forensic imaging tools
• Training and exercises — Tabletop exercises, simulated incidents, skills development
• Maintaining contact lists — Who to call at 2 AM, vendor support numbers, law enforcement contacts

You cannot improvise an effective response during a crisis. Preparation is the phase that makes everything else work.

Phase 2: Detection & Analysis

This is where most IT support staff first engage with the IR process. Detection comes from multiple sources:

• Automated alerts — SIEM rules, antivirus detections, IDS/IPS alerts, EDR notifications
• User reports — "My computer is acting weird," "I got a strange email," "I can't access my files"
• External notification — A vendor, partner, or law enforcement informs you of a compromise
• Proactive hunting — Security analysts searching logs for indicators of compromise (IOCs)

Analysis is the hard part. You need to determine: Is this a real incident or a false positive? How severe is it? What is affected? What happened?

Phase 3: Containment, Eradication & Recovery

Once you've confirmed an incident:

• Containment — Stop the bleeding. Isolate affected systems, block malicious IPs, disable compromised accounts. Short-term containment buys you time.
• Eradication — Remove the threat. Clean malware, patch vulnerabilities, eliminate attacker access.
• Recovery — Restore systems to normal operation. Rebuild from clean images, restore from backups, verify integrity.

Phase 4: Post-Incident Activity

After the incident is resolved:

• Lessons learned meeting — What happened? What worked? What didn't? What do we change?
• Documentation — Complete the incident report with timeline, actions taken, and recommendations
• Improvement — Update playbooks, add new detection rules, address gaps

Triage: The First Five Minutes

When an alert or report comes in, you need to triage it quickly. Triage determines priority and guides your next actions.

Containment vs. Investigation: The Balancing Act

One of the hardest decisions in incident response is when to contain (and potentially alert the attacker that you've detected them) versus when to observe (and gather more intelligence about what they're doing).

Escalation Procedures

Not every IT support person needs to handle every incident. Escalation ensures the right people engage at the right time.

When to Escalate Immediately

• Any confirmed compromise of a production system or user account
• Ransomware or evidence of encryption activity
• Data exfiltration — sensitive data leaving the network
• Compromise of privileged accounts — domain admin, service accounts, root
• Attacks on critical infrastructure — domain controllers, email servers, backup systems
• Legal or regulatory implications — incidents involving PII, financial data, or healthcare records

How to Escalate Effectively

A good escalation includes:

1. What you observed — The specific alert, user report, or anomaly
2. When it started — Timestamp of the first indicator
3. What is affected — Systems, users, data, services
4. What you've done so far — Any containment or investigation steps you've taken
5. Your assessment — What you think is happening and how severe it is

Avoid: "Something weird is happening with a server." Prefer: "At 14:32 UTC, EDR detected PowerShell execution on DC01 running AD enumeration commands. The script has been running for 20 minutes. I've isolated DC01 from the network and notified the on-call security analyst. I believe this is an active compromise of our primary domain controller."

Documentation During an Incident

Documentation feels like a low priority when systems are on fire, but it is essential. Poor documentation leads to repeated mistakes, legal exposure, and inability to learn from incidents.

What to Document

• Timeline — Every action, observation, and decision with timestamps. Use UTC.
• Actions taken — Who did what, and why. Include both successful and unsuccessful actions.
• Evidence collected — Screenshots, log excerpts, memory dumps, disk images. Note the chain of custody.
• Decisions and rationale — Why did you choose to contain vs. investigate? Who approved the decision?
• Communications — Who was notified, when, and what was communicated

Documentation Tips

• Write as you go — Don't rely on memory after a 12-hour incident
• Use shared documents — Everyone on the IR team should contribute to the same timeline
• Be precise — "Around lunchtime" is useless. "12:37 UTC" is actionable.
• Don't editorialize — "The user did something stupid" helps nobody. "User reported clicking a link in a phishing email at 09:15 UTC" is useful.
• Preserve evidence — Screenshots, exports, and copies before you make changes. Once you remediate, the original evidence may be gone.

Key Takeaways

• Preparation is the most important phase — You cannot improvise an effective response during a crisis
• Triage quickly, escalate early — Spend minutes on initial assessment, not hours. Escalate with context, not just "something is wrong"
• Containment before investigation for critical systems — When crown jewels are at risk, isolate first and ask questions later
• Document everything with timestamps — Your future self (and your legal team) will thank you
• Every incident is a learning opportunity — Post-incident reviews prevent the same incident from happening twice
• Never power off a compromised system unless instructed — Preserve volatile evidence by isolating from the network instead