AD7.4 Writing the Incident Response Plan

The complete Incident Response Plan template

INCIDENT RESPONSE PLAN
[Organization Name]
Version 1.0 | Effective: [Date] | Approved by: [Name, Title]
Review date: [12 months from effective date]

1. PURPOSE
This plan establishes [Organization Name]'s approach to detecting,
responding to, and recovering from information security incidents
affecting the Microsoft 365 environment and related systems.

2. SCOPE
This plan covers security incidents affecting [Organization Name]'s
M365 environment including: credential compromise, phishing attacks,
business email compromise, data breaches, and malware. Physical
security incidents and non-IT incidents are outside this plan's scope.

3. INCIDENT DEFINITION
A security incident is any event that compromises the
confidentiality, integrity, or availability of [Organization Name]'s
information systems or data. Examples include: unauthorized access
to user accounts, successful phishing attacks, malware execution,
unauthorized data disclosure, and suspicious system behavior.

4. SEVERITY LEVELS
4.1 CRITICAL: Active ransomware, confirmed data exfiltration,
    executive account compromise with evidence of fraud.
    Response: Immediate. Escalate to management and external IR.
4.2 HIGH: Confirmed credential compromise with post-compromise
    activity (inbox rules, email reading, file access).
    Response: Within 1 hour during business hours.
4.3 MEDIUM: Suspicious activity requiring investigation (unfamiliar
    sign-in, unusual inbox rule, phishing click reaching page).
    Response: Within 24 hours.
4.4 LOW: Contained threats (phishing blocked by Safe Links,
    sign-in blocked by conditional access).
    Response: Next Monday review.

5. ROLES AND RESPONSIBILITIES
5.1 IT Administrator: Primary responder. Executes detection (AD5
    monitoring), containment (AD6 procedures), evidence preservation,
    and initial investigation. Reports to IT Manager.
5.2 IT Manager / Line Manager: Authorizes response actions that
    affect business operations. Coordinates stakeholder communication.
    Makes escalation decisions for Critical severity.
5.3 Managed SOC [if applicable]: Provides 24/7 monitoring, deep
    investigation, and after-hours containment. Escalation contact:
    [email/phone].
5.4 Legal / DPO: Assesses GDPR notification obligations. Makes
    regulatory notification decisions. Contact: [name/email].
5.5 External IR Provider [if contracted]: Engaged for Critical
    incidents beyond internal capability. Contact: [name/phone].

6. RESPONSE PROCEDURES
6.1 Compromised Account: See Appendix A (AD6.2 procedure)
6.2 Phishing Click: See Appendix B (AD6.3 procedure)
6.3 Business Email Compromise: See Appendix C (AD6.4 procedure)
6.4 Evidence Preservation: See Appendix D (AD6.5 procedure)

7. ESCALATION
7.1 The escalation decision matrix (AD5.10) defines when to
    escalate to management, managed SOC, legal, and external IR.
7.2 After-hours incidents follow the after-hours decision matrix
    (AD6.7): contain immediately, escalate to SOC, or triage in
    the morning based on active attacker access.

8. COMMUNICATION
8.1 Internal: IT Administrator notifies IT Manager immediately for
    High and Critical severity. IT Manager notifies senior management
    for Critical severity.
8.2 Affected users: Notified after containment with guidance on
    password reset, MFA re-enrollment, and what to watch for.
8.3 External (regulatory): Legal/DPO determines GDPR notification
    obligations within 72 hours of incident awareness.
8.4 External (law enforcement): IT Manager decision for Critical
    incidents involving financial fraud or criminal activity.

9. POST-INCIDENT REVIEW
9.1 A post-incident review is conducted within 7 days of every
    High and Critical incident (AD6.10 process).
9.2 Review output: improvement actions with timelines and owners.
9.3 Improvement actions are tracked in the quarterly security report.

10. PLAN MAINTENANCE
10.1 This plan is reviewed annually and updated as needed.
10.2 Response procedures (appendices) are tested quarterly on
     a test account to verify PowerShell commands work.
10.3 Escalation contacts are verified quarterly.
10.4 Post-incident review findings trigger plan updates as needed.

APPENDICES
A. Compromised Account Response Procedure (AD6.2)
B. Phishing Click Response Procedure (AD6.3)
C. Business Email Compromise Response Procedure (AD6.4)
D. Evidence Preservation Procedure (AD6.5)
E. Escalation Contact Sheet (AD5.10)
F. Incident Report Template (AD6.9)
G. After-Hours Decision Matrix (AD6.7)

Making the IRP actionable

The IRP template above is 2 pages. The appendices (AD6 procedures) add another 8-10 pages. Total IRP package: 10-12 pages covering everything from incident definition to post-incident review.

The key to making the IRP actionable (not shelf-ware): the appendices ARE the AD6 procedures you've already built and tested. You're not writing new procedures — you're attaching existing, tested procedures to a governance document. When an incident occurs, you open Appendix A and follow the steps. The IRP provides the authorisation and context; the appendices provide the action.

Test the IRP quarterly: execute the compromised account procedure (Appendix A) against a test account. Verify every PowerShell command works. Update any commands that have changed due to PowerShell module updates. Record the test date in the plan. This quarterly test takes 15 minutes and proves the procedures are current — essential for audit readiness.

Running a tabletop exercise

Beyond testing PowerShell commands against a test account, run a tabletop exercise annually. This tests the decision-making, not just the technical steps:

Format (30 minutes, 2-3 participants): You (IT admin), your manager, and optionally the DPO or a colleague.

Scenario: "It's Tuesday at 14:30. You receive a high-severity alert: the finance director's account shows a sign-in from an unfamiliar IP in Eastern Europe at 01:00 last night. Two inbox rules have been created forwarding emails containing 'payment' and 'wire transfer' to an external address. The finance director is currently in a board meeting. Walk through your response."

Discussion points: Who acts first? (IT admin — contain immediately, don't wait for the board meeting to end.) What's the containment sequence? (Revoke sessions, reset password, disable inbox rules.) Who needs to be notified? (Manager, finance team, potentially legal.) Is this a GDPR-notifiable breach? (Depends on what was forwarded — assess after containment.) What evidence do you preserve? (Sign-in logs, inbox rules, mailbox audit log.)

Record the outcomes: What went well, what was confusing, what needs updating in the procedures. Update the IRP if the exercise revealed gaps.

The tabletop exercise is different from the technical test: the technical test verifies commands work, the tabletop tests decision-making and coordination. Both are needed — quarterly technical tests and annual tabletops provide comprehensive IRP validation.

Distributing the IRP

The IRP needs to be accessible to everyone named in the Roles section:

IT Administrator: Full IRP with all appendices. Printed copy at the desk. Digital copy in the governance library and on the local machine (C:\SecurityScripts\).

IT Manager / Line Manager: Sections 1-5 and 7-9 (no need for the technical appendices). They need to understand severity levels, their role in escalation, and the communication framework.

Legal / DPO: Sections 1-5 and 8 (communication section, particularly the GDPR notification timeline). They need to know when they'll be contacted, what information they'll receive, and what decisions they need to make.

Managed SOC: Section 5 (roles — understanding what you handle vs what they handle) and the escalation contact sheet. Most SOCs have their own procedures — your IRP tells them how YOU work, so they can coordinate effectively.

Don't distribute the full IRP (including technical procedures and escalation contacts) to all employees. General employees need only the AUP — it tells them to report suspicious activity and how to contact IT. The IRP is for the response team, not the general population.

IRP version control

Track IRP changes with the same version numbering as other policies:

VERSION HISTORY
v1.0 | [Date] | Initial version | Approved by [Name]
v1.1 | [Date] | Updated escalation contacts | [Name]
v1.2 | [Date] | Added BEC finance notification step from post-incident review | [Name]
v2.0 | [Date] | Annual review — updated all appendices, tested procedures | Approved by [Name]

Major versions (1.0 → 2.0) require management re-approval. Minor versions (1.0 → 1.1) are operational updates that don't change the governance framework — escalation contact changes, procedure refinements, and post-incident improvements. Document every change — the version history demonstrates active plan maintenance to auditors.

The IRP testing calendar

Schedule these recurring tests to keep the IRP current:

Monthly (5 minutes): Run one PowerShell command from each appendix against a test account to verify the modules are installed and the commands execute. This catches PowerShell module updates that change command syntax — which happens more often than you'd expect with the Microsoft.Graph module.

# Monthly IRP command verification
Connect-MgGraph -Scopes "User.ReadWrite.All" -NoWelcome
$testUser = "testuser@yourdomain.com"

# Test AD6.2 commands
Revoke-MgUserSignInSession -UserId $testUser -ErrorAction SilentlyContinue
Write-Host "Revoke sessions: OK" -ForegroundColor Green

Get-MgUserAuthenticationMethod -UserId $testUser -ErrorAction SilentlyContinue | Out-Null
Write-Host "Get MFA methods: OK" -ForegroundColor Green

Connect-ExchangeOnline -ShowBanner:$false
Get-InboxRule -Mailbox $testUser -ErrorAction SilentlyContinue | Out-Null
Write-Host "Get inbox rules: OK" -ForegroundColor Green

Write-Host "IRP command verification complete — $(Get-Date -Format 'dd MMM yyyy')"

Quarterly (30 minutes): Execute the full AD6.2 compromised account procedure on a test account. Time it. Verify every step produces the expected output. Record the test date and results in the IRP testing log.

Annually (60 minutes): Run the tabletop exercise with your manager and/or a colleague. Use a realistic scenario. Record the outcomes and update the IRP based on any gaps identified.

Log every test: "Monthly command check: [date] — all commands passed." "Quarterly procedure test: [date] — completed in 12 minutes, all steps successful." "Annual tabletop: [date] — scenario: BEC on finance director, outcome: identified need to add finance team notification to first 15 minutes." This testing log is audit gold — it proves the IRP is actively maintained and tested, not just a document that sits on a shelf.

Common IRP improvements from real incidents

After handling real incidents, the most common IRP improvements are:

Adding the finance team notification step. After the first BEC incident, teams realize the finance notification should happen within 30 minutes of confirmed compromise, not "at some point during the response." Update Appendix C (BEC procedure) to make it step 6 — immediately after securing the account.

Adding the evidence preservation step before containment. After the first incident where evidence was destroyed by the response (inbox rules deleted before being exported), teams add Appendix D (evidence preservation) as a mandatory step before Appendix A-C. Update the IRP main body to reference: "For all incident types, execute Appendix D (Evidence Preservation) before executing the incident-specific procedure."

Clarifying after-hours escalation. After the first after-hours incident where nobody was sure whether to call the SOC or wait until morning, update Section 7 to reference the after-hours decision matrix explicitly: "For incidents discovered outside business hours, follow the after-hours decision matrix (Appendix G) to determine immediate response vs morning triage."

Each of these improvements takes 5 minutes to document and prevents the same mistake from recurring. The IRP is a living document that gets better with every incident.