A Cyber Incident Response Plan That Works at 2 a.m.

The phone rings at 2 a.m. The night-shift supervisor says every screen is showing a ransom note. Your first questions: who has the firewall admin password? Where is the backup provider's number? Who has the authority to shut everything down?

If the answers are on the server that was just encrypted, you don't have a plan. This guide is about writing one short enough to actually use.

Four phases

The long-standing NIST SP 800-61 model has four phases. Revision 3 (2025) reorganizes incident response around NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), but the practical work is the same:

What the plan must contain

1. What counts as an incident, and how serious it is

2. Who does what. Incident lead (coordinates; doesn't need to be the strongest technician), technical lead, an executive with authority to shut systems down or approve emergency spending, someone handling communication with customers and staff, the organization's contract and risk adviser, and outside providers. Every role has a backup person.

3. Contact list. Printed, on the team's phones, and stored outside company systems. Include personal numbers, the ISP, firewall and backup suppliers, the bank, and the insurer if you have one.

4. A backup communication channel. If the attacker is inside your Microsoft 365, they can read email and Teams. Set up a WhatsApp or LINE group in advance.

5. External notifications. Who you will tell, and when: the bank when a payment went wrong, customers when their data may be exposed, the insurer, and anyone else management agrees in advance. Note who approves each message before it goes out.

6. Playbooks for common incidents: ransomware, hijacked mailbox, lost laptop, payment fraud.

7. Evidence. Don't delete logs, don't reimage before collecting evidence, take screenshots, and timestamp every action.

Example playbook: hijacked mailbox

This is the incident we see most, and it often leads to payment fraud.

1. Reset the password and revoke all sessions (including refresh tokens).
2. Find and remove inbox rules that forward mail externally or move it to folders nobody checks. Attackers use these to hide replies from suppliers.
3. Review newly registered MFA methods and consented OAuth apps. Remove anything unknown.
4. Review mail sent from the account during the compromise. If payment requests or bank-detail changes went out, phone those partners immediately.
5. Find the original phishing email and purge it from every mailbox.
6. Check sign-in logs for other accounts accessed from the same IPs.

Example playbook: ransomware, the first hour

1. Disconnect affected machines from the network (unplug the cable, turn off Wi-Fi), but don't power them off yet. Memory and running processes can show how the attacker got in.
2. Cut remote access: disable VPN and remote-desktop accounts that aren't essential, and block outbound traffic from servers that don't need it.
3. Check the backups before touching anything else. Are the offline or immutable copies intact? If the backup console is reachable from the infected network, take it off the network now.
4. From a clean device, reset domain admin, backup and firewall admin passwords. Assume every password typed on an infected machine is known to the attacker.
5. Find the first infected machine and the time it happened. The restore point must be from before that time, not just before the ransom note appeared.
6. Decide on outside help and external notifications at management level, using the contact list, not by improvising on the night.

Our ransomware protection checklist covers what to put in place beforehand.

Worked example: how long will the restore take?

A company's file server holds 2 TB. Its only backup is in the cloud, and the office has a 100 Mbps line. 2 TB is about 16,000,000 megabits; at 100 Mbps that's 160,000 seconds, roughly 44 hours, before any overhead, and only if nothing else uses the line. The same restore from a local NAS over a 1 Gbps network takes about 4.5 hours in theory. That's why we recommend a local copy as well as an off-site one, as in the 3-2-1 backup rule, and a timed test restore at least once a year. The number you measure is the number to put in the plan.

Rehearse it

Plans that have never been rehearsed fail in unexpected places: changed phone numbers, people who left, backups nobody knows the password for.

Run a tabletop exercise once or twice a year. Two hours around one table with management, IT, finance and HR. The facilitator reveals the scenario step by step:

• "Friday 18:30. An accountant reports that files on the shared drive won't open."
• "19:15. Three more PCs show a ransom note."
• "21:00. An email arrives from the attackers saying they have copied customer data."

At each step ask: who does what? Who decides? Where is the information we need? Write down every point where people hesitate. That's what the plan needs to fix.

Have these ready before anything happens

1. The plan and contact list printed, and stored outside company systems.
2. A backup communication group set up and tested.
3. Logs from the firewall, email and endpoints kept for at least 90 days, somewhere an attacker can't erase.
4. At least one backup copy that is offline or immutable, with a timed test restore on record.
5. MFA on email, VPN and every admin account (see our password and MFA guide).
6. A break-glass admin account, with its password sealed and kept by management.
7. A named executive who can authorize shutting systems down.
8. A tabletop exercise in the last 12 months, with its gaps fixed.

What makes incidents worse

• The plan only exists on the file server that got encrypted.
• Machines reimaged immediately, so nobody learns how the attacker got in, and they come back the same way.
• Restoring from a backup taken after the attacker was already inside.
• Coordinating over company email the attacker is reading.
• Nobody has authority to shut systems down, so everyone waits for a director who is travelling.

Talking to staff and customers

Name one spokesperson. Everyone else says "we're looking into it, and we'll update you" and nothing more. Prepare a short holding statement in advance: what happened in one sentence, what customers should do (for example, ignore emails asking to change bank details), and when the next update will come. Don't guess at numbers of records or causes in the first hours; early figures are usually wrong and are hard to take back. Tell staff before customers hear it elsewhere.

Incident log template

Keep it short, in your team's language

A 5–10 page plan everyone has read beats an 80-page plan nobody opens. Write it in Lao or Thai, whichever your team works in, and keep technical terms in English. For provincial branches, name one local coordinator who knows how to unplug the branch network and call it in. If you have no in-house security team, agree terms with a provider in advance; searching for help on the night itself burns the hours that matter most.

Start with one tabletop

If you have no plan yet, a single exercise will show you what to write. We can run a two-hour tabletop in Lao or Thai using a scenario that matches your systems, then send you a draft plan and the list of gaps within a week.