CMMC Level 2 Incident Response Plan Template for Small Contractors (Microsoft 365 + endpoints, with a 30-day test schedule)

If you handle CUI, an incident isn’t just “an IT problem.” It’s a contract risk, a trust risk, and a timeline risk. The good news is a CMMC incident response plan doesn’t have to be a 60-page binder to work. For small contractors, I’d rather see a tight plan that your team can execute at 2:00 a.m. than a perfect plan nobody reads.

Below is a template + guidance hybrid I use for Microsoft 365 + endpoints (Intune-managed Windows devices, plus whatever else you’ve got in the field). It’s written for small teams (1 to 20 IT/security staff), and it focuses on minimum viable documentation that still holds up in an assessment. This is not legal advice.

What CMMC Level 2 expects from incident response (in plain terms)

CMMC Level 2 aligns closely with NIST SP 800-171’s Incident Response family. At a practical level, your assessor wants proof that you can (1) respond, (2) document and report, and (3) test. A clean summary of the core requirements is laid out in Lake Ridge’s breakdown of NIST SP 800-171 incident response requirements.

In real life, that means I need to show:

• A defined process: preparation, detection, analysis, containment, recovery, and user actions.
• A record trail: incident tickets, timestamps, who approved what, and what you changed.
• Testing evidence: tabletops and small drills, plus fixes after the fact.

If you’re running Microsoft 365, use it as your backbone. Microsoft even publishes a practical reference for security incident management in Microsoft 365 Business Premium, which lines up well with how small teams actually operate.

One more reality check: many small contractors also support mixed environments. I often see the same IT team handling Small Business IT, Cloud Infrastructure, Office 365 Migration, and even on-site work like Restaurant POS Support and Kitchen Technology Solutions. Your IR plan should fit that world, while still protecting CUI boundaries.

CMMC Level 2 Incident Response Plan Template (with Microsoft 365 + endpoint notes)

1) Plan header, scope, and system boundaries (fill-in template)

Company Name: [COMPANY NAME]
Plan Owner: [NAME, TITLE]
Effective Date: [DATE]
Review Cycle: Quarterly, plus after any major incident

CUI System Boundary (describe plainly):
[LIST TENANTS, SUBSCRIPTIONS, DEVICES, NETWORKS, APPS THAT STORE/PROCESS/TRANSMIT CUI]
Examples: Microsoft 365 tenant, SharePoint sites, Exchange Online mailboxes, specific device groups in Intune, file shares, VPN, line-of-business apps.

Incident Definition:
An event that jeopardizes confidentiality, integrity, or availability of CUI or systems in-scope.

Implementation notes (Microsoft 365 + endpoints): I document the tenant name, primary domains, Entra ID tenant ID, Intune device groups for CUI users, and which endpoints are allowed to access CUI. This also supports Secure Cloud Architecture and Cloud Management decisions later.

2) Roles, contacts, and escalation paths

Internal IR Roles:

• IR Lead: [NAME, PHONE, EMAIL]
• M365 Admin: [NAME]
• Endpoint/Intune Admin: [NAME]
• Contracts/Program Lead: [NAME]
• Legal/HR (as needed): [NAME]
• Business Technology Partner / Technology Consulting support (if outsourced): [VENDOR, MSA DETAILS]

External Contacts:

• C3PAO / Assessor Contact: [NAME]
• Cyber insurance hotline: [POLICY #, PHONE]
• Law enforcement (if directed): [DETAILS]
• Microsoft support (if applicable): [CASE PROCESS]

Implementation notes (Microsoft 365 + endpoints): I pre-create two “break-glass” global admin accounts, protect them with strong MFA, store access in a controlled vault, and test sign-in monthly. This supports Business Continuity & Security when Conditional Access gets locked down.

3) Detection and triage (sources + common scenarios)

Detection sources (use what you already have): Microsoft Defender for Endpoint (MDE), Defender for Office 365, Microsoft Defender XDR incidents, Entra ID sign-in logs, Purview Audit (Unified Audit Log), Intune device compliance and configuration reports, Windows Event Logs (Sysmon optional).

Triage workflow (minimum viable): confirm scope, confirm CUI exposure, stop spread, preserve evidence, open an incident ticket, notify required roles.

Scenario playbooks (quick steps):

1. Suspected account compromise: check Entra ID risky sign-ins, confirm MFA prompts, review recent consent and mailbox activity.
2. Phishing with credential theft: quarantine message, hunt for similar, identify clickers, reset credentials, check token replay.
3. Ransomware on endpoint: isolate device, capture volatile details if feasible, assess lateral movement, validate backups.
4. Lost/stolen device with potential CUI: confirm encryption and last check-in, remote wipe, review recent file access.
5. Malicious OAuth app/consent: revoke app consent, remove enterprise app, review sign-in and mailbox access.
6. Suspicious mailbox rules: remove rules/forwarding, review sent items, check for additional persistence.

For incident handling inside Microsoft’s tooling, I follow Microsoft’s guidance to prioritize and respond to incidents in Microsoft Defender XDR.

Implementation notes (Microsoft 365 + endpoints): I standardize one ticket template: “What happened, when in UTC, who detected, what data, what systems, what actions taken.” That consistency is part of Infrastructure Optimization and IT Strategy for SMBs, because it keeps the team calm and fast.

4) Containment, eradication, recovery, and communications

Containment actions (choose what fits the case):

• Endpoint: isolate device in MDE, block execution via Defender policies, remove from network VLAN if needed.
• Identity: disable user, force password reset, revoke sessions, require re-register MFA, block sign-in in Entra ID.
• Email: remove malicious inbox rules, disable forwarding, purge messages, quarantine senders/domains.
• Emergency lockdown: tighten Conditional Access (block legacy auth, require compliant device, require phishing-resistant MFA where available).

For compromised mailboxes, Microsoft’s step-by-step on responding to a compromised email account maps cleanly to what I document in the incident timeline.

Recovery: restore from known-good backups, validate device hardening baselines, re-enable access in stages, and monitor for re-compromise.

Implementation notes (Microsoft 365 + endpoints): I treat Device Hardening and Endpoint Security as “recovery gates.” If the device isn’t compliant in Intune, it doesn’t get access back to CUI.

5) Evidence handling, retention, and after-action review

Evidence rules: preserve originals, work from copies, record handlers, and keep timestamps in UTC. Store evidence in a restricted location inside the CUI boundary.

Artifacts to collect (when applicable): email headers, message IDs, Safe Links/Safe Attachments results, MDE alert details, Entra ID sign-in logs, Purview audit exports, Intune device actions, screenshots of admin actions, and ticket notes. Disk or memory capture is “when feasible,” especially for ransomware, but I don’t block response if a small team can’t do full forensics.

Reporting: notify internal officials listed above, then follow contract and customer reporting terms. Track who was notified, when, and what was shared.

After-action (within 5 business days): root cause, what worked, what failed, control updates, and training needs.

Implementation notes (Microsoft 365 + endpoints): I keep retention simple: incident tickets and after-action reports for [RETENTION PERIOD], plus exported audit logs attached to the ticket. This supports Cybersecurity Services maturity without buying extra tools.

30-day incident response test schedule (small-team friendly)

The fastest way to “make the plan real” is to run short drills weekly, then one fuller test by Day 30.

Day	Test type	Objective	Participants	Steps (high-level)	Expected artifacts	Pass/Fail criteria
5	Mini-drill	Validate detection sources and ticketing	IR Lead, M365 Admin	Trigger test alert, open ticket, record UTC timeline	Ticket, screenshot/log export note	Ticket created, source verified, timestamps in UTC
12	Mini-drill	Account compromise response speed	IR Lead, M365 Admin	Simulate risky sign-in, disable user, revoke sessions, document	Ticket, Entra ID action evidence	Containment in under 30 minutes, actions recorded
19	Mini-drill	Mailbox rule persistence removal	M365 Admin	Create suspicious rule in test mailbox, detect, remove, verify	Ticket, rule before/after	Rule removed, forwarding checked, user comms drafted
26	Mini-drill	Endpoint ransomware containment	Endpoint Admin	Simulate MDE alert, isolate device, collect key details	Ticket, MDE isolation evidence	Device isolated, scope assessed, no missed steps
30	Tabletop or technical test	End-to-end IR readiness	Full IR team, contracts lead	Run a full scenario with reporting and after-action	Full incident package, AAR	All artifacts produced, gaps logged with owners/dates

This is also where I tie incident response into Digital Transformation work. If your incident process is solid, other projects (Office 365 Migration, Cloud Infrastructure changes, even Data Center Technology refreshes) stop feeling risky.

Assessment evidence checklist mapped to NIST 800-171 3.6

Here’s what I keep ready for a CMMC Level 2 assessor, mapped to the 3.6 controls.

Control	What the assessor looks for	Strong evidence examples
3.6.1	Operational incident-handling capability	IRP document, defined roles, Microsoft 365 + endpoint procedures, incident categories
3.6.2	Track, document, and report incidents	Tickets, notification records, exported audit/log snippets, incident timeline, escalation matrix
3.6.3	Test the incident response capability	30-day test records, tabletop notes, pass/fail results, after-action reports, assigned remediations

I also keep training records for users and admins. Small organizations don’t need perfection, they need consistency. That’s the heart of Tailored Technology Services and Managed IT for Small Business.

Conclusion

If you want a CMMC incident response plan that stands up in Level 2, write it like you’ll use it under stress, because you will. Keep the scope tight, make Microsoft 365 and endpoints your source of truth, and prove the process with testing that produces real artifacts. If your current plan feels too big to run, it’s too big to pass.