Microsoft documentation example of an automatic isolation action marked Skipped because policy excluded the device. Check the actual action status and reason before reporting containment; this is not an ALLMSP incident result.[2]
A Defender alert is the start of an investigation, not a recovery certificate. Identify the affected device and account, establish what actually ran, verify which actions completed, and confirm the service is safe before reconnecting it. A blocked file can still leave an unanswered question about credentials, another device or the original entry path.
This workflow is for authorized administrators and responders using the company’s licensed endpoint service. Agree who can interrupt a device, collect evidence, approve recovery and communicate with its business owner. An exercise on a designated test device is the place to discover missing permissions or a VPN-dependent containment path.
Open the alert in its incident context
In the Microsoft Defender portal, use Incidents & alerts > Alerts, then open the relevant alert and associated incident context. Review detection source, affected entities, timestamps and related evidence. Alerts describe individual signals; correlated incident information can connect them to a broader sequence.[1]
| Question | Evidence to inspect | Why it matters |
|---|---|---|
| Did the activity run or get blocked before execution? | Alert details, process sequence and reported action. | A blocked download and a running malicious process have different immediate implications. |
| Is the right device still reporting? | Device identity, last signal and timeline. | A stale record cannot prove a current response action reached the laptop. |
| Which account and other assets were involved? | User context, linked alerts, file identity and related devices where available. | Local cleanup alone may leave a compromised identity or another endpoint unaddressed. |
| What already changed automatically? | Completed and pending actions, with timestamps. | Do not confuse a recommendation or queued action with a completed containment step. |
| What business task will containment interrupt? | Device owner and dependent workflow. | The responder needs a safe alternate path and a clear recovery acceptance test. |
Assign an owner and write the working hypothesis in plain language. For example: “A payroll laptop launched an unexpected process after an attachment; we have not established whether the account was used elsewhere.” That statement defines the next evidence to collect more usefully than “high alert handled.”
Confirm containment completed, including on remote devices
From the affected device’s page, an authorized responder can choose an available action such as antivirus scan or device isolation. Availability depends on the product, platform, permissions and device state. Isolation is designed to restrict network access while retaining the Defender service path, but Microsoft warns that a full-tunnel VPN can prevent that service connectivity after isolation.[2]
Use isolation when the observed behavior and response plan call for it; do not isolate a production-critical system merely to rehearse a menu action. Confirm the exact asset, explain the reason in the action comment, and notify the responsible business contact. Keep a known support route that does not depend on the potentially compromised device.
After submitting an action, inspect its status and the device’s reporting. Pending is not completed. An offline device may not execute the requested action immediately, so escalate the unresolved exposure through the agreed physical or network containment process. Do not represent an accepted portal request as a successful isolation.
If isolation fails or reporting disappears, check platform support, response permissions, device-group access and the normal network route. Document the actual failure. Avoid broad isolation exclusions simply to make an exercise pass; any exception changes the containment design and needs its own reason and review.
Use the current investigation experience and Action Center
Microsoft’s current guidance says that from September 1, 2026, Automated Investigation and Response no longer runs as a separate investigation experience or supports manual triggering. Its detection and response capabilities remain in the default antivirus stack; Microsoft directs on-demand investigation to a full antivirus scan. Do not build a new playbook around an older “Initiate Automated Investigation” screenshot.[3]
Open Actions & submissions > Action Center to distinguish pending actions from completed history. Review an action’s scope and evidence before approval; confirm the completed result after it runs. A closed investigation label does not replace checking what was actually remediated.[4]
Keep collection proportional to the incident. Save the relevant alert/incident identifiers, timestamps, device timeline, file or process details, account context and response history through the approved evidence process. Use the investigation features actually licensed and available in that tenant. Advanced hunting and live response should not be assumed from a generic “Defender” product name.
Define recovery gates before releasing isolation
Decide whether the device can be trusted after remediation or should be rebuilt through the organization’s recovery process. That decision depends on what happened, the confidence of the evidence and the value of the affected system. A clean scan is one useful result, but it cannot by itself establish that stolen credentials, persistence or an unsafe entry path have been resolved.
- Endpoint: the identified malicious activity and persistence are addressed; the intended protection and sensor reporting are healthy.
- Identity: affected accounts, sessions and access paths are investigated and corrected through the identity response process when relevant.
- Entry path: the exploited weakness, unsafe attachment route or other confirmed cause has an assigned correction.
- Business data: required data and applications are available and their integrity is checked; any restoration has a known source and result.
- Return to work: the owner completes a defined application task, monitoring remains active, and someone is responsible for follow-up.
Release isolation only when the authorized responder accepts those gates. Check the device and action history after release, then confirm normal communication and the original business task. If sensor reporting is unreliable, use the Defender sensor-health troubleshooting guide before relying on that telemetry for closure.
Rehearse an alert-to-recovery path on a designated test device
Use Microsoft’s current detection-test guidance for the selected product and supported operating system. The official test is intended to exercise the reporting path on an onboarded device; it is not a reason to download live malware or weaken protection.[5] For Business client deployments, use the Windows client test in the Business onboarding instructions rather than assuming a server-specific applicability table covers that client.[6] Label the exercise and tell the responder what is in scope, while retaining a realistic test of notification and ownership.
- Prepare: select a noncritical managed device, an authorized responder, an exercise window, an alternate contact and an agreed rollback or release route.
- Generate the approved test: follow the current Microsoft procedure for that platform and retain the start time.
- Trace the response: find the resulting alert, identify the correct device, verify notification and assignment, and record the evidence used for the decision.
- Exercise containment if authorized: perform it only on the designated test asset, verify the action completed, and prove the support/Defender route still works.
- Recover: verify the release action, restore normal access, perform the agreed user task and confirm protection and fresh telemetry.
- Improve the playbook: turn each missed alert, permission problem or failed route into a named correction and a focused retest.
Example: a fictional sales team’s test laptop receives its alert, but the assigned responder can only read the device page. The exercise has found a permission/design defect, not a malware detection failure. Correct the supported role assignment and repeat the containment-and-release test. A second test under the usual remote VPN can expose a different connectivity limitation.
Measure verified response outcomes and connect the next work
Keep the exercise result compact: first signal, notification arrival, acknowledgment, confirmed containment, investigation conclusion, release approval and successful user task. Separate time waiting for a device to reconnect from time spent making a decision. These observations help improve the process; they are not service-level promises.
Use Defender plan and rollout choices if the exercise reveals an entitlement gap. For the broader operational design, read Endpoint Protection Operations for Safer Daily Work. Recovery planning belongs alongside ransomware protection priorities for identity, endpoints and backups, rather than inside an endpoint alert queue alone.
To review the response design with ALLMSP cybersecurity services, bring the affected-device scope, alert references, known business impact and existing response owner. Agree the responsibilities and exercise boundaries before planning any live containment test.
Frequently asked questions
Does a blocked Defender alert mean the incident is over?
No. Establish what was blocked, whether anything ran, which account was involved and whether related activity occurred elsewhere before closing the incident.
Should I investigate an alert or its associated incident?
Use both. The alert gives a specific signal; the associated incident context can connect related alerts and affected entities into a broader sequence.
[1]Does clicking Isolate device prove the endpoint is contained?
No. Verify the action completed and the intended device reached the expected state. A queued or pending action is not confirmation of containment.
Can an offline laptop execute a response action immediately?
Do not assume it can. Check the device and action state, and use the agreed alternate containment process when the device cannot receive the instruction.
Why can a remote laptop stop reporting after isolation?
Its normal VPN or network route may also block the remaining Defender service path. Microsoft specifically identifies full-tunnel VPN connectivity as a concern; test the actual route in advance.
[2]Where do I check pending and completed remediation actions?
In the Defender portal, open Actions & submissions > Action Center and review Pending and History as appropriate.
[4]Should a new playbook tell responders to trigger AIR manually?
No. Microsoft’s September 2026 change removes the separate manual AIR experience. Follow the current investigation flow; its guidance points to a full antivirus scan for on-demand investigation.
[3]Is a clean antivirus scan enough to reconnect a compromised device?
No. Also resolve the relevant persistence, identity, entry-path and data-integrity questions, verify healthy protection and telemetry, and obtain the authorized recovery decision.
How can we test the response path without using live malware?
Use Microsoft’s current documented detection test for the chosen platform on a designated device, with an authorized window and a controlled containment-and-recovery plan.
[5]What should a Defender response exercise produce?
A traceable alert, a correct device and owner, verified action results, a successful recovery task, and a short list of permission, connectivity or process defects with named follow-up.
Sources
- Microsoft Learn: Investigate alerts in Defender XDR ↩
- Microsoft Learn: Take response actions on a device ↩
- Microsoft Learn: Overview of automated investigations The dated Important notice supersedes older manual-trigger screenshots elsewhere in Microsoft documentation. ↩
- Microsoft Learn: Review remediation actions in Action Center ↩
- Microsoft Learn: Run a detection test on an onboarded device ↩
- Microsoft Learn: Defender for Business platform onboarding and detection tests ↩
