Building an Incident Response Plan You Can Follow at 2 A.M.

A cybersecurity incident rarely waits for a convenient time.

It may begin with a compromised mailbox, a ransomware alert, a lost laptop or an employee reporting that they approved an unexpected multifactor authentication request. The first warning could arrive during a busy working day—or at two o’clock in the morning when the usual decision-makers are asleep.

That is when an incident response plan proves its value.

A good plan is not a 60-page document written for auditors. It is a practical set of instructions that tells the person on call what to do first, who to contact and how to prevent the situation from becoming worse.

At 2 a.m., nobody wants to search through policy folders or debate who has authority to disable an account. The plan must be clear enough to follow under pressure.

What Is an Incident Response Plan?

An incident response plan explains how your organisation will prepare for, identify, contain, investigate and recover from a cybersecurity incident.

It should cover common events such as:

• Microsoft 365 account compromise
• Phishing and business email compromise
• Malware or ransomware
• Lost or stolen devices
• Unauthorised data sharing
• Suspicious administrator activity
• Website or cloud-service compromise
• Accidental deletion or data exposure

The document should answer four immediate questions:

1. What has happened?
2. What should we do right now?
3. Who needs to know?
4. What evidence must we preserve?

The best incident response plans reduce hesitation. They give employees permission to take necessary containment steps without waiting for a lengthy meeting.

Why Most Incident Plans Fail

Many businesses technically have an incident response policy, but it is not usable during a real emergency.

Common problems include:

• The plan is too long.
• Contact information is outdated.
• Responsibilities are vague.
• Nobody knows where the document is stored.
• The plan assumes every system is available.
• Technical instructions are incomplete.
• No one has tested the process.
• Senior approval is required for every action.
• The company has no clean administrator account or device ready.

A plan that exists only inside the compromised Microsoft 365 tenant may be inaccessible when you need it most.

Keep an offline or independently stored copy containing essential contacts, recovery procedures and emergency credentials.

Start With Clear Incident Priorities

The first response should follow a simple order.

1. Protect People

Some incidents affect more than computers.

For example, fraudsters may be pressuring employees to make payments, threatening individuals or impersonating senior staff. Physical safety, safeguarding and urgent financial controls come before technical investigation.

2. Contain the Threat

Stop the attacker from continuing.

This might mean:

• Blocking a Microsoft 365 account
• Revoking active sessions
• Isolating a laptop
• Disabling a malicious application
• Blocking a domain or IP address
• Stopping an unauthorised payment
• Removing a public sharing link

Containment should happen quickly, but destructive actions should be considered carefully when evidence may be required.

3. Preserve Evidence

Record what you saw before deleting it.

Capture:

• Screenshots
• Alert details
• Email headers
• Sign-in logs
• Malicious rules
• IP addresses
• File names
• Times and dates
• User statements
• Actions taken

Use a consistent time zone throughout the incident record.

4. Restore Safe Operations

Recovery should begin only after the immediate cause has been addressed.

Restoring a compromised user’s access before removing malicious forwarding rules, OAuth consent or authentication methods may simply return control to the attacker.

Define Incident Severity Levels

Not every security event requires the same response.

A useful model might include four levels.

Severity 1: Critical

Examples:

• Active ransomware across several systems
• Confirmed administrator compromise
• Large-scale customer data exposure
• Ongoing financial fraud
• Major operational outage caused by an attack

This level should trigger immediate leadership, legal and specialist security involvement.

Severity 2: High

Examples:

• Confirmed mailbox compromise
• Sensitive documents shared externally
• Malware on a privileged device
• Suspicious application with broad Microsoft 365 access
• Compromised finance or payroll account

Urgent containment and investigation are required.

Severity 3: Medium

Examples:

• Successful phishing with limited impact
• Lost managed device
• Suspicious sign-in requiring review
• Unapproved application use
• Incorrect external sharing without evidence of access

These incidents should be investigated promptly but may not require the full crisis team.

Severity 4: Low

Examples:

• Blocked phishing attempt
• Routine malware detection contained automatically
• Policy violation with no confirmed exposure
• Unsuccessful password-spray attempts

These events still need recording and review, but they may follow the normal service-desk process.

Severity definitions prevent every alert from becoming a crisis while ensuring serious incidents are escalated quickly.

Assign Roles Before an Incident

Do not wait until an attack to decide who is responsible.

A small business may not have a dedicated security team, but it still needs named roles.

Incident Lead

Coordinates the response, records decisions and keeps the team focused.

Technical Lead

Handles containment, investigation and recovery across Microsoft 365, devices, networks and applications.

Management Contact

Approves significant business decisions and keeps company leadership informed.

Communications Contact

Manages messages to employees, customers, suppliers and the public.

Legal or Data Protection Contact

Assesses contractual, regulatory and personal-data obligations.

Business Owner

Explains the affected process and helps judge operational impact.

One person may perform several roles in a small organisation. What matters is that the responsibilities are assigned in advance.

Include deputies. Your primary incident lead may be unavailable, on holiday or directly involved in the compromise.

Build an Emergency Contact Sheet

The first page of your plan should contain the information needed immediately.

Include:

• Internal incident lead
• Backup incident lead
• IT support provider
• Microsoft 365 administrator
• Cyber-insurance contact
• Legal adviser
• Data protection contact
• Bank fraud team
• Key software providers
• Internet and telecoms suppliers
• Police or relevant reporting channels
• Senior management contacts

For each entry, include:

• Name
• Role
• Telephone number
• Alternative number
• Email address
• When they should be contacted

Do not rely entirely on company email. A compromised mailbox or tenant outage may make it unsafe or unavailable.

Create Short Playbooks for Likely Incidents

The main plan should describe the overall process. Separate one- or two-page playbooks should cover the incidents your organisation is most likely to experience.

Microsoft 365 Account Compromise Playbook

Immediate actions might include:

1. Block the user’s sign-in.
2. Revoke active sessions.
3. Reset the password from a clean device.
4. Review and remove unknown authentication methods.
5. Inspect inbox rules and forwarding.
6. Review OAuth consent and enterprise applications.
7. Check Entra sign-in logs.
8. Search Microsoft Purview Audit.
9. Identify messages sent or files accessed.
10. Warn affected contacts where necessary.

Do not simply change the password and assume the incident is finished.

Ransomware Playbook

Immediate actions might include:

1. Disconnect affected devices from the network.
2. Isolate endpoints using the security platform where available.
3. Stop users from connecting removable storage.
4. Notify the incident lead and technical responders.
5. Preserve affected systems for investigation.
6. Identify the first affected device and user.
7. Review identity and administrative activity.
8. Protect backups from deletion or encryption.
9. Determine whether data was stolen before encryption.
10. Begin recovery only from known-clean sources.

Do not start wiping systems until evidence and recovery options have been assessed.

Business Email Compromise Playbook

Immediate actions might include:

1. Contact the bank using a verified number.
2. Stop or recall payments where possible.
3. Secure the compromised mailbox.
4. Preserve the fraudulent conversation.
5. Contact suppliers or customers using a separate channel.
6. Review bank-detail changes and payment instructions.
7. Search for similar messages across the tenant.
8. Investigate whether another account was compromised.
9. Report the fraud through the appropriate channels.
10. Review payment-verification procedures.

Speed matters. A bank may have only a short window to intercept a fraudulent transfer.

Lost or Stolen Device Playbook

Immediate actions might include:

1. Confirm the device and assigned user.
2. Determine whether it is company-owned or personal.
3. Check whether it is encrypted and managed.
4. Disable or retire it through Intune where appropriate.
5. Revoke the user’s active sessions if risk is significant.
6. Review recent sign-ins.
7. Change exposed credentials.
8. Record what data may have been stored locally.
9. Notify insurance or data protection contacts if required.
10. Replace the device through a controlled process.

The response should differ depending on whether the laptop was encrypted, compliant and protected by strong authentication.

Decide Which Actions Can Happen Without Approval

At 2 a.m., waiting for a director to approve every containment step can allow the attacker to continue.

Pre-authorise actions such as:

• Blocking a suspected compromised account
• Revoking sessions
• Isolating a device
• Disabling a malicious forwarding rule
• Blocking a confirmed malicious domain
• Suspending a suspicious application
• Stopping external sharing of exposed files

Define which decisions still require senior approval, such as:

• Shutting down a major business system
• Paying a ransom
• Notifying the public
• Contacting regulators
• Engaging expensive external responders
• Restoring systems where evidence may be overwritten

The plan should favour rapid containment while maintaining clear accountability.

Keep a Simple Incident Log

Create a standard incident record with fields for:

• Incident number
• Date and time discovered
• Person reporting it
• Systems and accounts affected
• Initial symptoms
• Severity
• Actions taken
• Person responsible for each action
• Evidence collected
• Decisions and approvals
• Notifications made
• Recovery status
• Follow-up actions

Record events as they happen.

During a long incident, people forget exactly when an account was blocked, which laptop was isolated or who contacted the bank. A reliable timeline is essential for investigation, insurance and regulatory review.

Prepare Clean Recovery Access

Your incident plan should not assume the affected administrator account, laptop or Microsoft 365 tenant can be trusted.

Prepare:

• Emergency access accounts
• Securely stored credentials
• A clean administrative laptop
• Independent password-manager access
• Offline contact details
• Backup internet connectivity where justified
• Recovery codes and supplier account details
• Access to backup and security portals

Emergency accounts should be monitored, tested and used only during genuine recovery situations.

Include Communications Templates

Writing messages during a crisis wastes time and increases the chance of saying the wrong thing.

Prepare short templates for:

• Employee security warning
• Customer phishing notification
• Supplier payment-fraud warning
• Service outage notice
• Lost-device notification
• Regulatory or insurance escalation
• Internal leadership update

A useful status update should explain:

• What is known
• What is not yet known
• What has been contained
• What users should do
• When the next update will arrive

Avoid speculation. Early incident information is often incomplete.

Test the Plan With Tabletop Exercises

A plan that has never been tested is mostly a theory.

Run a tabletop exercise at least annually. Present a realistic scenario and ask the response team to explain what they would do.

For example:

At 2:05 a.m., the finance director reports that a supplier received fraudulent bank details from their genuine mailbox. Entra shows a successful overseas sign-in, and the bank transfer was sent 30 minutes ago.

Work through:

• Who takes control?
• Who contacts the bank?
• Which account is blocked?
• How are sessions revoked?
• Where are the logs?
• Who informs the supplier?
• Does cyber insurance need to be contacted?
• What evidence is preserved?
• When is the account restored?

The exercise should expose gaps without blaming individuals.

Update the plan after every test and real incident.

Common Incident Response Mistakes

Creating a Plan That Is Too Long

Responders need checklists and decisions, not pages of background theory.

Storing the Only Copy in Microsoft 365

A tenant compromise or outage may make it unavailable.

Using Outdated Contact Details

Test every emergency contact at least twice a year.

Restoring Access Too Quickly

Containment is not complete until persistence mechanisms and affected devices have been reviewed.

Failing to Record Actions

A missing timeline makes investigation and insurance claims much harder.

Ignoring Business Processes

Technical recovery alone will not stop invoice fraud or customer misinformation.

Never Practising

An untested team will improvise under pressure.

Final Thoughts

A strong incident response plan is not measured by its length.

It is measured by whether somebody can open it at 2 a.m. and know exactly what to do next.

Keep the core plan short. Put emergency contacts and immediate priorities first. Create separate playbooks for mailbox compromise, ransomware, payment fraud and lost devices. Pre-authorise urgent containment actions, prepare clean recovery access and keep a clear incident log.

Then test the plan.

The first time your team works through a serious cyber incident should not be during the real one.

Need Help Building a Practical Incident Response Plan?

Hamilton Group can help your organisation create and test an incident response process built around the systems and risks you actually face.

Our experts can help you:

• Identify likely cyber incident scenarios
• Build clear response roles and escalation routes
• Create Microsoft 365 compromise playbooks
• Plan ransomware containment and recovery
• Prepare business email compromise procedures
• Configure emergency access accounts
• Review audit logging and evidence retention
• Develop communications templates
• Run realistic tabletop exercises
• Improve the plan after testing

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to build an incident response plan your team can follow—even at two o’clock in the morning.