Building an Incident Response Plan You Can Actually Follow at 2 AM
A cyber incident rarely chooses a convenient time.
The first warning could be:
“Someone approved an MFA request they didn’t recognise.”
“Files on the server are suddenly encrypted.”
“The finance mailbox is forwarding email somewhere unexpected.”
“Our systems have gone offline.”
And it may happen at two o’clock in the morning when:
senior managers are asleep
the normal IT team is unavailable
nobody is certain how serious the incident is
every minute feels important
That is when an incident response plan either proves its value—or proves that it was written for the wrong audience.
A good plan should not require somebody under pressure to read 60 pages before discovering who to call.
It should answer five questions immediately:
What do I do first?
Who is in charge?
Who do I contact?
What am I allowed to disconnect or disable?
Where do we record what happens?
The NCSC recommends simple checklists, key contacts, escalation criteria and incident-specific playbooks precisely because the first few hours can be the most time-critical part of an incident.
The First Page Matters More Than the Next Fifty
The front page of your incident plan should contain the things somebody may genuinely need at 2 a.m.
I would include:
incident-response provider
internal technical lead
senior decision-maker
cyber insurer
legal adviser
communications/PR contact
key suppliers
emergency conference-call details
location of recovery credentials
location of the full incident playbooks
The NCSC recommends having multiple contacts and more than one way of reaching important people because your primary contact may be unavailable during an emergency.
Do not assume the contact list stored inside Microsoft Teams will be useful if Microsoft 365 itself is the system that has been compromised.
Keep an appropriately protected offline or independent copy of the critical contact information.
Step 1: Decide Whether This Is Actually an Incident
Not every security alert needs the full crisis process.
You need simple severity criteria.
For example:
Low
suspicious phishing email reported but not interacted with
antivirus blocks a file before execution
one unsuccessful suspicious login
Medium
user entered credentials into a phishing site
unexpected MFA approval
malware detected on one device
suspicious mailbox rule
High
confirmed unauthorised account access
administrator compromise
multiple infected devices
significant customer-data exposure
Critical
ransomware
widespread outage caused by attack
privileged-domain or cloud compromise
major data exfiltration
critical business systems unavailable
The exact categories matter less than having an agreed answer to:
When do we wake senior management and invoke the full response plan?
Step 2: Establish Incident Command
One of the strongest additions from the NCSC’s July 2026 recovery guidance is the need to establish a clear incident command structure immediately.
Someone must have authority to coordinate:
technical response
business operations
legal/regulatory decisions
communications
recovery priorities
The NCSC recommends clear governance with defined authority for containment, recovery and communications decisions, potentially using structures such as Gold/Silver/Bronze where appropriate.
For an SME, this does not need to become bureaucratic.
It might simply be:
Incident Lead
Makes overall decisions.
Technical Lead
Investigates, contains and coordinates IT/security response.
Business Lead
Identifies which services must be maintained or restored first.
Communications Lead
Controls internal/customer/supplier communications.
The crucial rule is:
one person owns each decision.
At 2 a.m., “we thought someone else was dealing with it” is not an acceptable incident-management model.
Step 3: Start One Incident Log Immediately
Create a central incident record.
Record:
time
person
observation
action
decision
result
For example:
02:14 — Defender alert reports ransomware behaviour on PC-042.
02:17 — PC-042 isolated from network.
02:21 — user account disabled.
02:25 — suspicious authentication discovered against administrator account.
The NCSC’s latest disruptive-attack guidance explicitly recommends establishing a central record so responders maintain shared situational awareness.
This record becomes invaluable for:
technical investigation
insurance
regulatory reporting
legal review
post-incident analysis
Do not rely on memory.
During a serious incident, nobody remembers the timeline as accurately as they think they do.
Step 4: Contain — But Don't Destroy Evidence Blindly
This is one of the trickiest incident-response decisions.
Suppose ransomware is spreading.
Possible actions include:
isolate affected endpoint
disable compromised account
block malicious IP/domain
disconnect network segment
stop remote access
But there is an important distinction between:
disconnecting
and:
shutting down.
The NCSC’s 2026 guidance says disconnecting systems can stop further attacker commands and limit spread while preserving useful evidence. Completely shutting a system down may halt activity faster but can also destroy volatile evidence needed for the investigation.
That does not mean:
never switch anything off.
It means the incident plan should define who has authority to make that decision and when specialist advice should be sought.
For example:
Pre-authorised actions
IT may immediately:
isolate an endpoint through EDR
disable a compromised user
revoke active sessions
block malicious email rules
Escalation required
Management/incident lead approval before:
shutting down a critical server
disconnecting an entire office
disabling all external access
turning off major production systems
Pre-authorisation prevents a dangerous delay caused by somebody trying to locate a director at 2:07 a.m.
Step 5: Get Specialist Incident Response Help Early
Do not assume the normal IT support team should investigate a serious breach entirely on its own.
For highly disruptive incidents, the NCSC recommends engaging an appropriately assured cyber-incident response provider early so the organisation can understand:
initial entry point
attacker movement
actions taken
persistence
whether the attacker is still present.
That information directly affects safe recovery.
It also means your incident plan should already contain:
Who will we call?
not:
Who should we Google for after ransomware encrypts the servers?
Check your:
MSP
cyber insurer
incident-response retainer
specialist CIR provider
before you need them.
Step 6: Work Out What Still Works
During a serious incident, responders often focus entirely on what has failed.
You also need to establish the current operational state.
Ask:
Can employees still communicate?
Is Microsoft 365 available?
Does identity still work?
Are backups accessible?
Is internet connectivity available?
Which servers are down?
Which systems are unaffected?
Can customers still contact us?
The NCSC’s July 2026 guidance explicitly recommends assessing critical business functions, affected systems, dependencies, backups and attacker status during the first hours.
This determines your next objective.
Step 7: Define Minimum Viable Operations
This is another concept I would add prominently.
During a major attack, the immediate objective may not be:
Restore everything.
It may be:
Restore enough to operate safely.
The NCSC calls this Minimum Viable Operations (MVO): the lowest level of capability at which the organisation can continue operating safely while meeting key legal, regulatory and customer obligations.
For example:
A business might need first:
1. phones
2. customer communications
3. email
4. accounting
5. critical line-of-business system
while:
archive servers
old project data
secondary applications
can wait.
Your incident plan should identify these priorities before the incident.
Otherwise the recovery order gets determined by whichever employee complains most loudly.
Step 8: Protect the Backups
As soon as ransomware or destructive activity is suspected, somebody should confirm:
Are backups still available?
Are they still running?
Can attackers reach them?
Should additional backup jobs temporarily stop?
Are immutable/offline recovery points available?
What is the oldest potentially clean recovery point?
Do not automatically attach offline backup storage to a potentially compromised environment.
And do not automatically restore the newest backup.
If the attacker was present for three weeks before triggering ransomware, yesterday’s backup may contain compromised configuration.
Step 9: Don't Rush Into Recovery
This is probably the most important lesson from the NCSC’s new guidance.
Restoring systems quickly feels productive.
It can also restart the incident.
The NCSC explicitly warns that if you are not confident the attacker has been evicted, beginning recovery creates a risk that the organisation will simply be compromised again.
So the sequence should be:
contain
↓
investigate
↓
remove attacker access/persistence
↓
rebuild trusted systems
↓
validate recovery data
↓
restore
not:
files encrypted → restore yesterday’s backup immediately
Recovery speed matters.
Safe recovery matters more.
Step 10: Secure Identities Early
Attackers often target accounts as aggressively as computers.
Your plan should include procedures for:
disabling compromised accounts
revoking sessions
resetting passwords
reviewing MFA registrations
checking administrator roles
identifying suspicious OAuth applications
checking mailbox forwarding/rules
securing service accounts
If an administrator account is compromised, changing only the employee's laptop achieves very little.
Identity should have its own incident-response playbook.
Step 11: Have Separate Playbooks for Common Incidents
One enormous generic plan becomes difficult to follow.
The NCSC recommends developing playbooks for your highest-risk and most likely incident types, with particular emphasis on the actions required during the first few hours.
For many SMEs I would start with:
Microsoft 365 account compromise
disable/restrict account
revoke sessions
inspect MFA
check sign-in logs
inspect mailbox rules/forwarding
investigate OAuth applications
Ransomware
isolate systems
protect backup infrastructure
establish incident command
engage incident-response specialist
determine attacker status
identify safe recovery points
Business email compromise/payment fraud
secure mailbox
contact bank/payment provider
identify fraudulent messages
contact affected suppliers/customers
preserve evidence
Lost or stolen device
assess encryption
remote lock/wipe where appropriate
revoke sessions
disable credentials if necessary
record potential data exposure
Malware on one endpoint
isolate endpoint
capture alert information
identify user/account exposure
determine whether movement occurred elsewhere
Each playbook should ideally fit onto a few pages.
Step 12: Plan Communications Before You Need Them
A cyber incident quickly becomes a communications problem.
You may need to communicate with:
employees
customers
suppliers
insurers
regulators
law enforcement
media
But communication must be coordinated.
Avoid employees posting speculative explanations such as:
“We have been ransomwared and all our customer data is stolen.”
before anybody has established what actually happened.
The NCSC’s latest guidance explicitly includes communications with key stakeholders among the first-hours activities.
Prepare templates in advance for:
internal service outage
investigation underway
customer update
supplier notification
recovery update
Templates reduce improvisation while still allowing facts to be inserted carefully.
Step 13: Know Your Reporting Obligations
Your plan should identify possible obligations involving:
ICO
cyber insurer
contractual customers
sector regulator
NCSC
police/action fraud channels where appropriate
Do not hard-code every legal deadline into a technical checklist and assume it applies universally.
Instead specify:
Who determines whether reporting is required?
Usually that will involve:
senior leadership
legal advisers
data-protection lead
insurer
The NCSC recommends including basic regulatory/legal guidance and escalation routes inside the response plan.
Step 14: Keep Emergency Access Separate
A serious cyber incident may make normal systems unavailable.
You should know how to access:
Microsoft 365 emergency accounts
backup consoles
firewall management
domain recovery
critical SaaS portals
encryption keys
vendor support
without relying entirely on the potentially compromised environment.
For example, the document containing your emergency administrator password should probably not exist solely in:
the SharePoint tenant you can no longer access.
Keep recovery information appropriately protected and independently accessible.
Step 15: Test the Plan
The first test should not be the real attack.
Run tabletop exercises.
Give the team a scenario such as:
> It is 02:15. Defender reports ransomware on three endpoints. A domain administrator has logged in from an unfamiliar location. The backup console is unreachable. What do you do?
Then see what happens.
Do people know:
who is in charge?
which systems may be isolated?
who calls the insurer?
where the contact details are?
who communicates with staff?
how to access emergency credentials?
The NCSC recommends exercising and maintaining the response capability rather than treating the plan as a document written once and forgotten.
The One-Page 2 A.M. Checklist
For the front of the plan, I would use something close to this:
1. Start the incident log.
2. Confirm what triggered the alert.
3. Classify the severity.
4. Contact the incident lead and technical lead.
5. Isolate obviously compromised devices/accounts where pre-authorised.
6. Preserve evidence—do not indiscriminately wipe or power everything off.
7. Contact the incident-response provider/insurer when thresholds are met.
8. Determine which critical business services still work.
9. Protect backups and recovery systems.
10. Establish a secure incident communications channel.
11. Do not begin large-scale restoration until attacker status is understood.
12. Record every significant action and decision.
Everything else can live in the relevant playbook.
What Should Not Be in the Core Plan?
Avoid filling the emergency plan with:
lengthy cyber-security theory
screenshots that will age rapidly
dozens of vendor-specific troubleshooting commands
policies written mainly for certification
information nobody needs during the incident
Put detailed technical procedures in separate playbooks.
The core document should be something somebody can realistically navigate while tired and under pressure.
Keep It Available When Your Normal IT Is Down
Store copies somewhere that does not depend entirely on:
Active Directory
Microsoft 365
the file server
one employee's laptop
Suitable protection might include:
controlled offline copy
secure independent cloud repository
incident-response provider
printed emergency contact sheet
Make sure it remains protected from unauthorised access.
An incident plan itself may contain sensitive:
administrator information
supplier contacts
architecture details
recovery procedures
Availability matters.
So does confidentiality.
Review It After Every Incident and Exercise
Every real incident should improve the plan.
Ask:
What confused people?
Which phone numbers were wrong?
Which decision took too long?
Which access did we not have?
Which technical procedure failed?
Which supplier was difficult to reach?
What information did management need but not have?
Update the playbook.
An incident-response plan should evolve as:
systems change
suppliers change
employees change
threats change
How Hamilton Group Can Help
Hamilton Group can help businesses build an incident response capability that is practical enough to use under real pressure.
We can assist with:
incident-response planning
Microsoft 365 compromise playbooks
ransomware response
business email compromise
identity-security procedures
emergency access
backup and recovery planning
cyber-security monitoring
tabletop exercises
post-incident reviews
The objective is not to produce the longest incident-response policy.
It is to make sure that if something serious happens at 2 a.m., the person responding knows:
who is in charge, what they can safely do immediately, who they need to call and what must not be destroyed in the rush to recover.
Visit hgmssp.com or call 0330 043 0069 to discuss incident-response planning and cyber security.
SEO Meta Description
SEO Keywords
Drupal-ready blog summary
I would replace the current article with this version. The original is already good and was only published on 3 August 2026, but the newer structure makes the NCSC’s 28 July 2026 highly disruptive attack guidance much more visible. In particular, it strengthens four areas that should sit at the heart of a 2 a.m. plan: clear incident command, one authoritative incident record, minimum viable operations, and no rushed recovery while attacker access may still exist.