CMMC Level 2 Lost Device Response Plan With Intune

Lose a laptop that handled CUI, and the clock starts before anyone finds the charger. When I build a CMMC lost device response plan, I focus on the first hour, because that’s where risk, evidence, and downtime all collide.

Intune gives me the device controls, but a compliant response needs more than a remote wipe. I need clear triage, identity actions, user communication, ticketing, and records that stand up during a CMMC Level 2 assessment.

What CMMC Level 2 expects when a device disappears

CMMC Level 2 does not have one practice named “lost device response.” I treat a missing laptop or phone as a cross-control event. It touches incident response, access control, media protection, and physical protection under NIST SP 800-171.

That matters because a lost endpoint is more than an asset problem. It might still hold CUI, cached mail, browser sessions, or synced files. If the device can still reach Microsoft 365, SharePoint, OneDrive, or line-of-business apps, the identity side matters as much as the hardware side.

If a missing device could access CUI, I treat it as a security incident until the facts say otherwise.

For CMMC Level 2, assessors want to see that I can detect, report, respond, track, and document the event. The incident response family in NIST 800-171, especially 3.6.1 through 3.6.3, is a good anchor. A plain-language summary appears in this incident response guidance for NIST 800-171 and CMMC 2.0.

I also tie the device workflow to identity controls. Microsoft’s CMMC Level 2 identity guidance points to compliant-device policies, Conditional Access, and device management as part of the control picture. In practice, that means my lost-device runbook must answer four questions fast:

1. What device is missing?
2. What data and accounts could it reach?
3. What actions did I take, and when?
4. What evidence can I retain for later review?

If I can’t answer those cleanly, the Intune action buttons alone won’t save me.

Build the Intune playbook before the incident

A good response starts long before a laptop goes missing. First, I want a clean Intune inventory. Every managed device should have a clear owner, serial number, platform, enrollment type, device name, and group membership. If the device list is messy, lost-device triage slows down right when time matters most.

Next, I set policy around encryption, compliance, and access. For corporate devices that may handle CUI, I want full-disk encryption enforced, endpoint protection in place, and compliance policies tied to Conditional Access. If a device falls out of compliance, access to protected apps should narrow or stop. That reduces the blast radius if someone reports a loss late.

I also define the decision points before the incident. Remote lock, retire, and wipe are not the same:

• I use remote lock when recovery looks possible and I want to block immediate local access.
• I use retire mainly for personal or lightly managed devices where I need to remove company data and management.
• I use wipe for corporate-owned devices when the risk is high or recovery is unlikely.

Platform support varies, so I write those limits into the procedure. I don’t want the help desk learning that nuance under pressure.

Communication needs structure too. The user should know exactly where to report the loss, what details to provide, and how fast to escalate. The security team should know when to open an incident record. Management should know when a missing device becomes a potential CUI exposure.

This is also where tabletop tests pay off. I run the scenario, capture gaps, and update the playbook. That work doesn’t guarantee certification, but it produces the operating evidence assessors like to see.

The first hour of a lost device response in Intune

When the alert comes in, I open a ticket first. Then I record the who, what, when, and last known location. I also ask whether the device held CUI, whether the user was signed into Microsoft 365, and whether the loss looks accidental or suspicious.

Inside Intune, I go straight to the device record. I check the primary user, last check-in time, compliance state, encryption status, ownership, and recent device actions. On supported platforms, I can use Locate device in Microsoft Intune to review the current or last known location. That won’t solve every case, but it can narrow the window fast.

Then I decide on containment. If recovery is likely, I may start with remote lock and a user callback. If the device held CUI and the risk is higher, I move faster to wipe. For BYOD, I usually retire rather than wipe, unless policy and consent allow stronger action.

At the same time, I coordinate with Microsoft Entra. If the device might expose active sessions, I revoke tokens, force re-authentication, and consider a password reset. If I suspect account compromise, I can block sign-in while I investigate. Conditional Access should already require compliant devices, which helps keep a lost endpoint from being a back door.

This is the timeline I use as a working model:

Time window	Core action	Evidence to capture
0 to 15 minutes	Open ticket, validate user report, record last known possession and possible CUI exposure	Ticket creation time, user statement, asset ID
15 to 30 minutes	Look up the device in Intune, review compliance, encryption, owner, and last check-in	Device overview screenshot, compliance state, last sync
30 to 60 minutes	Trigger locate, remote lock, retire, or wipe; coordinate Entra session controls	Action status screenshots, admin audit logs, sign-in logs
1 to 4 hours	Classify the incident, notify internal stakeholders, review contractual reporting needs	Incident record, notification timestamps, decision notes
By 24 hours	Close initial investigation, preserve evidence, plan recovery or re-provisioning	Final timeline, retained exports, management approval

The takeaway is simple: move the device and identity actions in parallel. If I wait to handle Entra until after the Intune task finishes, I waste time I may not have.

What evidence to keep for a CMMC assessment

Assessors don’t need a dramatic story. They need objective evidence that my process works. That means I keep records that show the event, the actions, the timing, and the outcome.

For a lost-device case, I usually retain:

• The original help desk or SOC ticket, with timestamps and the reporting path.
• A screenshot or export of the Intune device overview page.
• Proof of device compliance and encryption status at the time of review.
• Device action records for locate, remote lock, retire, or wipe.
• Microsoft Entra sign-in and audit logs tied to the user and device.
• Copies of user and management communications, including escalation notices.
• The final incident summary, with the CUI exposure decision and closure notes.

I prefer screenshots plus native exports where possible. Screenshots help a reviewer read the event quickly. Exports help prove timestamps and log integrity. I store that evidence in a controlled repository, not in someone’s mailbox or chat thread.

If the device comes back, I document that too. I record who recovered it, where it was found, whether tampering was suspected, and what I did before it returned to service. For CUI endpoints, I usually re-image and re-enroll rather than trust a device with an uncertain chain of custody.

Good evidence does two jobs. It supports the assessment, and it helps me learn from the incident without guessing later.

Turn the workflow into policy, training, and repeatable operations

A usable plan needs both policy and procedure. My policy states who reports a loss, who can approve a wipe, when security takes over, and when legal or contract staff must be notified. My procedure gives the exact admin steps in Intune and Entra, plus the evidence checklist and communication templates.

That distinction matters for small teams. A two-page policy gives direction. A step-by-step procedure lets the help desk act at 8:00 a.m. or 10:00 p.m. with the same result.

For Small Business IT teams, this work fits much bigger programs. The same controls that protect a lost laptop also support Cloud Infrastructure, Office 365 Migration, and older Data Center Technology environments. If your MSP handles mixed clients, the lesson carries over to Restaurant POS Support and Kitchen Technology Solutions too. A missing tablet can stop operations anywhere.

I fold that into broader Cybersecurity Services because lost-device response is part of Endpoint Security and Device Hardening. It also belongs inside Cloud Management, Secure Cloud Architecture, and Business Continuity & Security. The best Innovative IT Solutions are simple enough to use under stress. Good Tailored Technology Services account for different enrollment models, app access paths, and contract duties.

From a service standpoint, this is where a Business Technology Partner earns trust. Solid Technology Consulting, Infrastructure Optimization, and a grounded IT Strategy for SMBs turn policy into daily operations. That is real Digital Transformation for defense contractors and for Managed IT for Small Business teams that need proof, not promises.

Conclusion

When I write a lost-device plan for CMMC Level 2, I don’t start with the wipe button. I start with reporting, identity control, evidence, and a clean Intune workflow.

A repeatable response protects CUI, shortens downtime, and gives assessors something concrete to review. If the first hour is clear and well-documented, the rest of the incident gets easier to manage.