Incident Response Plan: Logging, Detection and Recovery

The most expensive phrase in incident response is "we don't know". We don't know when they got in. We don't know what they accessed. We don't know if they're still here. Every one of those unknowns costs money — in investigation hours, in regulatory exposure, in the reputational damage of being unable to tell customers what happened — and every one of them is avoidable with logs that were kept and someone who looked at them. An incident response plan is the difference between those unknowns and a clear answer.

IBM's Cost of a Data Breach study has for years found that the time to identify and contain a breach runs to months on average — 258 days in the 2024 edition — and that organisations which detect faster pay dramatically less. Attackers know this. Their playbooks assume they'll have weeks of quiet inside your environment. Your job is to take those weeks away.

This is the foundation of visibility: logging so you can know, detection so you do know, and incident response so that knowing turns into action.

Part 9 of 10 · Foundations of Infosec. Previous: Social Engineering. Next: Cybersecurity Frameworks.

Key takeaways

Breaches take months to detect on average (258 days, IBM 2024); detection speed drives cost.
Log authentication, privilege changes, admin actions, sensitive data access and config changes — off-box.
Ten well-tuned alerts that page a human beat a thousand rules nobody reads.
An incident response plan is a few pages, rehearsed yearly: who leads, who to call, first steps, how to restore.

Logging: the raw material

A log is a record of something that happened: a login, a file access, a firewall decision, a database query, a configuration change. Individually they're noise. Collectively they are the only way to reconstruct what happened after the fact, and the only way to detect what's happening now.

What to log. The events that matter for security are consistent across environments:

Authentication — successes and failures, from where, with what method, and MFA outcome.
Authorisation — privilege changes, group membership changes, role assumptions.
Administrative actions — anything done with elevated rights, especially on identity systems and cloud control planes.
Access to sensitive data — reads and exports of the datasets you classified as important.
Configuration changes — firewall rules, security settings, new users, disabled logging.
Network — connections allowed and denied at boundaries, DNS queries, VPN sessions.
Endpoint — process execution, script execution, new services, security tool status.
Application — errors, input validation failures, unusual request patterns.

The cloud providers give you most of the control-plane events for free (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs); the identity providers give you sign-in logs; the operating systems give you event logs. The main task is turning them on where they're off by default and collecting them somewhere central.

What not to log. Passwords, session tokens, full card numbers, and personal data you have no reason to keep. Logs get copied, shared with vendors and retained for years; anything sensitive in them is a second breach waiting to happen. Mask or exclude it at the source.

Where to keep them. Off the box that generated them. This is the rule most often broken and most consequential: an attacker who compromises a server will clear its logs, and a ransomware operator will encrypt them. Ship logs to a central system — a SIEM, a cloud logging service, even a hardened log server — with write-only access from sources and no delete rights for ordinary administrators. Retain them long enough to investigate an incident discovered late: a year is a common baseline, and some regulations require more.

Time. Synchronise clocks. An investigation across systems with drifting clocks is an exercise in frustration. NTP everywhere, timestamps in UTC.

Detection: turning logs into alarms

Logs answer questions after the fact. Detection is asking the questions continuously. The spectrum runs from simple to sophisticated, and the simple end delivers most of the value.

Start with a handful of high-signal alerts. You don't need a thousand rules. You need the ten that would have caught the last ten incidents you've read about:

An administrator account logging in from a new country or device.
MFA disabled or reset on any account.
A new user added to an admin group.
Security tooling (EDR, logging agents) stopped or uninstalled.
Cloud audit logging turned off, or a storage bucket made public.
Mass file modification or deletion on a file server — the signature of ransomware beginning.
A large outbound data transfer to an unfamiliar destination.
Logins outside working hours for accounts that never work outside hours.
Many failed logins followed by a success.
Mail forwarding rules created to external addresses — a classic BEC persistence trick.

Each of these can be a saved query in whatever log tool you have. Each should page a human.

Use the frameworks. MITRE ATT&CK maps the techniques attackers actually use; the open-source Sigma project provides detection rules mapped to them that translate to most log platforms. You don't have to invent detection from scratch.

Tune relentlessly. An alert that fires constantly is an alert that gets ignored, and ignored alerts are how breaches sit undetected for months. When Target was breached in 2013, its security tooling did raise alerts; they were among many and nobody acted. Every false positive is a cost; every unactioned alert is a failure. Better five alerts a week that someone investigates than five hundred that nobody reads.

Someone must be watching. Detection without a person is decoration. In a small organisation that might be one named individual who checks a dashboard each morning and gets paged for the critical rules. If nobody can do that, a managed detection and response (MDR) provider — an outsourced team watching your EDR and logs around the clock — is, in my experience, the single highest-value security spend for a business without its own security staff.

The incident response plan: what happens when the alarm rings

NIST's SP 800-61, the standard reference, describes incident handling as a cycle: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Most of the value is in the first phase, because it's the only one you can do calmly.

Preparation

Write the plan. A short one. The plans that work in a crisis fit on a few pages and answer: Who is in charge? Who do we call — internally, legal, insurer, forensic help, regulator, police? How do we communicate if email is compromised? What are the first steps for the three or four scenarios we most expect (ransomware, compromised account, lost device, data exposure)? Where are the backups and how do we restore them?

Know your obligations. Data protection laws impose notification deadlines — 72 hours to the regulator under GDPR, and Qatar's Personal Data Privacy Protection Law and the NCSA's frameworks impose their own requirements on organisations here. Your cyber insurance policy almost certainly requires notification within a set period and may require you to use their approved responders. Find these out before the incident, not during.

Prepare the tools. Can you isolate a machine from the network remotely? Can you reset every session for a compromised user? Can you snapshot a cloud instance for forensics before rebuilding it? Can you restore from backup, and have you timed it? Every one of these is an afternoon to set up in advance and a disaster to discover you can't do under pressure.

Rehearse. A tabletop exercise — the team in a room, walking through a scenario for two hours — finds gaps in the plan that reading never would. "The plan says call the IT manager. He's on a plane. Now what?" Do one a year at minimum.

Detection and analysis

When something fires, the first job is to establish what you're dealing with, without destroying the evidence. Resist the urge to immediately wipe the affected machine; you'll lose the ability to learn how the attacker got in, which means you'll rebuild with the same hole. Preserve first: snapshot, image, copy the logs. Then analyse: what's the scope? One account or the domain? One server or the network? Is data leaving?

Triage honestly. Most alerts are not incidents. But when one is, declare it early — over-declaring costs a few hours; under-declaring costs weeks.

Containment, eradication, recovery

Contain to stop the spread: isolate hosts, disable accounts, block the attacker's infrastructure, revoke sessions and rotate credentials. Short-term containment buys time; then plan longer-term containment that lets the business keep operating.

Eradicate the attacker's foothold: remove malware, close the vulnerability, delete the persistence mechanisms (new accounts, scheduled tasks, mail rules, OAuth grants). This is where incident responders earn their fee; a partial eradication means the attacker returns, and in ransomware cases they frequently do.

Recover from known-good state: rebuild rather than clean where you can, restore data from backups taken before the compromise, and monitor closely as systems come back — the attacker may still be trying.

Post-incident

The step everyone skips, and the one that makes the next incident smaller. Within a couple of weeks, while memories are fresh, hold a blameless review: what happened, in order; what worked; what didn't; what will change. The output is a list of concrete actions with owners and dates, feeding back into the threat model, the risk register and the detection rules. An incident that doesn't change anything was a cost with no return.

A small-organisation version

You do not need a security operations centre. Here is a minimal, real visibility capability for a company without a security team:

Turn on audit logging in your identity provider, your cloud accounts and your email platform. Ship them to one place — the cloud provider's logging service is fine.
Deploy EDR on every endpoint and either watch its console daily or pay an MDR provider to.
Create the ten alerts above. Route them to a phone.
Name an incident lead and a deputy. Write the one-page plan with the phone numbers. Put a printed copy somewhere.
Test a backup restore. Time it. Write the time in the plan.
Run one tabletop exercise this year.
After anything that goes wrong — even a near-miss — spend thirty minutes on what you'd change.

That's a weekend of setup and an hour a week of attention. It's the difference between a breach you find on day one and a breach you find when a journalist calls.

The mindset

Prevention is where most security budgets go, and prevention is necessary. But every experienced practitioner will tell you the same thing: you will be breached in some form, at some point, and what determines the outcome is not whether your walls held but how fast you noticed they didn't and how well you'd prepared for that moment.

Visibility is the foundation that makes every other foundation accountable. Without it, your controls are assumptions. With it, they're facts you can check — and mistakes you can catch while they're still small.

Further reading

NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management (2025)
NIST SP 800-92 — Guide to Computer Security Log Management
IBM Security, Cost of a Data Breach Report 2024
MITRE ATT&CK; Sigma detection rules — github.com/SigmaHQ/sigma
NCSC (UK), Logging and protective monitoring guidance
Qatar National Cyber Security Agency (NCSA) — national information assurance and incident reporting requirements

This series