Defender XDR Incident Readiness and Automated Response
IT Partner spends two weeks turning a Microsoft Defender XDR tenant you already own into one where incidents are seen, owned and — where you have agreed in writing that it is safe — contained without waiting for a human. We confirm which Defender workloads actually feed the portal (Endpoint, Office 365, Identity, Cloud Apps, Microsoft Entra ID Protection) and whether each one meets its own prerequisites; set the remediation level on every device group and enable automatic attack disruption with a written exclusion register for break-glass accounts, service accounts, critical servers and the IP ranges you cannot afford to have blocked; tune the alerts that generate noise, with the reason and the owner recorded for each rule; write custom detection rules for an agreed number of your own top scenarios — inbox-rule forwarding, consent to risky OAuth apps, impossible travel on an admin account; build the notification and ownership model so each severity reaches a named person; set Microsoft Defender unified role-based access control and the Action-center approval roles so the actions that wait for approval actually get approved; and hand over short response runbooks for the five most likely incident types, plus one incident walked end to end with your team. The fee is fixed at $3,500 for one tenant, agreed in writing before work begins, and you pay after you approve delivery. What we do not promise is that automation stops every attack: Microsoft's containment actions are scoped, reversible and driven by Microsoft's own models, and this engagement is about deciding — deliberately, and on paper — what is allowed to happen in your tenant without a human in the loop, and who reads the queue when something is not.
What this engagement is
Most tenants we open have the products and not the practice. Defender for Endpoint arrived with the Intune project, Defender for Office 365 came with the E5 upgrade, Defender for Identity was installed on the domain controllers by someone who has since left, and the result is a Microsoft Defender portal with a long incident queue, no owner, no notification rules that anyone trusts, and an Action center full of actions that have been pending since spring. Nothing is broken. Nothing is being used either. This engagement is the readiness pass between deployment and monitoring: two weeks that make the tenant's automation deliberate, so that the incidents that matter reach a named human, the ones that do not are suppressed on purpose rather than by exhaustion, and the containment Microsoft can perform on your behalf is switched on with the exceptions you actually need. Four decisions carry the engagement, and all four are yours to sign. The first is the automation level on each device group. In the Defender portal every device group has a remediation level, and the choice runs from 'Full - remediate threats automatically', which Microsoft recommends, through three semi-automatic levels (require approval for core folders, for non-temp folders, or for all folders) to 'No automated response'. That column is where most tenants quietly lose their automation: a group left at no automated response gets neither automated investigation and remediation nor automatic containment, and nobody notices until an incident that should have healed itself does not. We inventory the groups, propose a level per group with the reasoning written down — servers and OT-adjacent devices are usually where the argument is — and apply what you approve. The second decision is automatic attack disruption. This is Microsoft's built-in, incident-level containment: when its models correlate signals across endpoints, identities, email and SaaS into a high-confidence attack, Defender acts. Microsoft's documented actions include containing a device, containing the IP address of an undiscovered device, isolating a compromised workstation, disabling a user in Active Directory or Microsoft Entra ID, containing a user at the endpoint layer, revoking active sessions, suspending an Entra account and taking protective measures on a compromised OAuth application — with preview support for suspending Okta users and attaching a deny policy to an AWS IAM identity through Microsoft Sentinel connectors, and a newer set of predictive-shielding actions such as Safe Mode and Group Policy hardening. Microsoft states that all automatic actions can be undone by your security team. That is the sentence that usually ends the debate in the room, and the design records who is allowed to undo them. The third decision is exclusions, and it is the one that needs an adult in the room. Microsoft's own guidance is blunt: excluding assets from automated response is not recommended, because it reduces the effectiveness of the capability. But an emergency access account that gets disabled at 02:00, or a service account that runs your warehouse, is a real business risk too. So we build a short, argued exclusion register rather than a long, comfortable one: user exclusions for break-glass and named service identities, device-group automation levels where a group genuinely must not be contained, IP exclusions for infrastructure ranges, and — where the preview policy-application feature is available in your tenant — dynamic-tag rules that disable one specific disruption control for a tagged group instead of disabling everything. Every entry gets an owner, a reason and a review date, and one caution goes in bold in the handover: excluding a device group from automated responses also affects automated investigation and response for that group. The fourth decision is who is told, and who may approve. Defender's incident notification rules can filter by alert severity, by service or detection source and by device group, send one notification per incident, and include a tenant-specific portal link; a second rule set notifies on manual and automated response actions and their success or failure. We build the severity-to-owner map with you, create the rules, and prove them with test notifications rather than assuming the mail arrives. Where you want incidents in Microsoft Teams or in a ticket queue, we say plainly that Defender's own rules are email — the Teams card or the ticket is a Power Automate flow or Logic App we build on top, and one such route is included. Then we set the permissions: Microsoft Defender unified RBAC is now the default permissions model for new Defender for Endpoint and Defender for Identity tenants, and Microsoft extended that default to new Defender for Office 365 Plan 2 organizations from July 2026, so we assign least-privilege roles there rather than handing out Security Administrator, and we make sure the people named in the runbooks hold the specific permissions the Action center requires — including the Search and Purge role that email and content remediation needs. That last point deserves its own paragraph, because it is the most common misunderstanding about Defender automation. Microsoft's documentation is explicit that no remediation actions are taken automatically for email and email content: alerts and policies can trigger an automated investigation, but every email action waits for approval in the Action center. A tenant that has nobody rostered to approve those actions does not have automation — it has a to-do list. Part of what you buy here is that roster, the approval permissions behind it, and a runbook that says who approves what within what timeframe. Around those four decisions sits the work that makes the queue usable. We tune noise with Defender's alert tuning (what used to be called alert suppression), using its documented actions — hide the alert, resolve the alert, or convert matching signals to behaviours that stay available for hunting — with conditions scoped to the evidence that actually caused the noise, and with a written note on each rule saying what it hides and why. Microsoft's built-in tuning rules already suppress some common benign activity without breaking automated investigation or notifications, and reactivate a suppressed alert if the investigation finds something malicious; our rules are the ones on top of that. We then write an agreed number of custom detection rules — five by default — from advanced hunting queries against your real scenarios, each with the impacted-entity mapping done properly so alerts correlate into incidents, a frequency chosen deliberately (every 24, 12 or 3 hours, hourly, or Continuous near-real-time where the query qualifies), a device scope, and only the response actions you have approved. One honest constraint goes in the runbook: Microsoft states alert suppression is not compatible with custom detections, so a custom rule that turns noisy has to be fixed in the query, not muted. Finally we write the five runbooks — typically a compromised mailbox with an inbox rule, a malicious OAuth consent, a ransomware precursor on an endpoint, an admin-account anomaly and a data-exfiltration alert, but yours are chosen with you — and then walk one of them end to end with your team, on a real historical incident where one exists. That walk-through is where the gaps surface: the alert that goes to a distribution list nobody reads, the approver who is on holiday with no delegate, the device group that turned out to be excluded. Fixing those is the point. The boundaries are firm and we would rather state them here than in a change request. This is a one-time readiness pass on a tenant where the Defender products are already deployed. It is not monitoring — nobody at IT Partner watches your queue afterwards unless you buy Multi-Platform Managed Detection and Response. It is not incident response — if we find an active compromise during the engagement we stop, tell you immediately, and scope Security Managed Service: Incident Response or Business Email Compromise Investigation and Recovery separately. It is not a deployment project: if Defender for Endpoint, Defender for Office 365, Defender for Identity or Defender for Cloud Apps is licensed but not actually onboarded, that is the Defender for Endpoint deployment, Defender for Office 365 implementation, Defender for Identity implementation or Defender for Cloud Apps implementation engagement, and we will tell you which one you need instead of pretending a readiness pass can substitute. And it is not a SIEM: cross-source correlation, long retention, SOAR playbooks and non-Microsoft log sources are Microsoft Sentinel SIEM/SOAR implementation. Where you already run Sentinel in the Defender portal, we work with what is there. Where you want Security Copilot on top, that is the Microsoft Security Copilot deployment engagement and Microsoft's Security Compute Unit charges are billed to you, not to us.
Success criteria
What you receive
How the work unfolds
Read the tenant as it is: licences and their attack-disruption and AIR implications, which Defender workloads are onboarded and reporting, device groups and their remediation levels, the last 30-90 days of incidents and alerts by volume and disposition, existing tuning rules, custom detections, notification rules and permissions, and the prerequisites each workload needs — Defender for Endpoint sensor versions and device discovery mode, domain-controller auditing and Defender for Identity action accounts, mailbox audit logging, the Defender for Cloud Apps Microsoft 365 connector. We interview whoever handles alerts today and find out what actually happens when one arrives.
Produce the automation design: remediation level per device group, the attack-disruption configuration and the exclusion register, the alert tuning candidates with evidence from your own alert history, the five custom detection scenarios, the severity-to-owner map and notification rules, and the unified RBAC and Action-center approval model. You sign it. Nothing in the tenant changes before that signature, and anything we think is a bad idea is argued in the document rather than quietly implemented.
Apply the design: automation levels, attack disruption and its prerequisites, the exclusion register, tuning rules, notification rules for incidents and for response actions, the one agreed Teams or ticket route, and the RBAC and approval assignments. Each change is made in the order the design sets, with the portal state captured before and after so the handover pack shows what moved.
Build and observe the custom detection rules, correct the queries that produce false positives, send test notifications for each severity band and confirm they arrive with the named owners, verify the approvers can actually approve in the Action center, and write the five response runbooks against the tenant as it now is rather than as the design imagined it.
Walk one incident end to end with your team, capture the gaps it exposes as owned actions, deliver the handover pack, the registers and the maintenance calendar, and close with the honest statement of what is automated, what waits for a human and what nobody is watching — plus a recommendation, if the answer to the last one is uncomfortable, about what to do next.
Prerequisites
Who does what
IT Partner
- Review the tenant end to end and produce the coverage matrix, the automation design, the exclusion register and the notification and permissions model — with the reasoning written down and presented for your signature before anything changes.
- Verify and, where in scope, fix the per-workload prerequisites that attack disruption and automated investigation depend on, or name them clearly as gaps with an owner where fixing them is a separate project.
- Configure device-group remediation levels, attack disruption and exclusions, alert tuning rules, incident and response-action notification rules, one Teams or ticket route, and the unified RBAC and Action-center approval assignments.
- Build the agreed custom detection rules from advanced hunting queries, map their entities correctly, observe them for false positives and correct the queries before handover.
- Test what we built: notifications per severity to the named owners, an approver who can actually approve, and detections that fire on the scenario they were written for.
- Write the five response runbooks against the tenant as configured, and lead the end-to-end walk-through of one incident with your team.
- Say plainly where automation is the wrong answer — the scenario that needs a person, the exclusion that should not exist, the queue nobody is staffed to read — rather than leaving a tidy configuration on top of an unstaffed process.
- Stop and tell you immediately if the review surfaces evidence of an active or historical compromise, and scope the response separately rather than absorbing it.
Your team
- Provide the licence position, tenant access at the agreed privilege level, and the workload owners we need for prerequisites on endpoints, mail, identity and SaaS.
- Sign off the automation design: remediation levels, attack-disruption enablement, every exclusion, the tuning rules, the detection scenarios and the severity-to-owner map.
- Name the people — who receives which severity, who approves Action-center items (including email and content actions), who owns each runbook, and who covers them when they are away.
- Provide the change windows and change approvals for enabling automation, and the historical incident data the tuning proposals are based on.
- Own the Microsoft licensing decisions the review surfaces, and any Microsoft-metered consumption such as Security Copilot compute or Sentinel ingestion in your own subscription.
- Staff the queue after handover — your own team, or a separate managed detection and response arrangement. A configured tenant is not a monitored tenant.
- Maintain the registers after we leave: review exclusions and tuning rules on the cadence in the maintenance calendar, and revisit them after any Microsoft change to the disruption action set.
What's not included
Limitations & technical notes
Frequently asked questions
We already own Defender XDR. What does 'incident readiness' actually add?
Decisions, ownership and proof. Owning the products gives you a portal; readiness means every device group has a deliberate remediation level, automatic attack disruption is on with a short and argued exclusion list, the noise is suppressed on purpose, your top scenarios have custom detections, each severity reaches a named person who has been shown the mail arriving, the people in your runbooks hold the permissions the Action center needs, and there are five one-page runbooks plus a walk-through that has already exposed the gaps. Nothing here is exotic — it is the configuration and governance layer that tends to get skipped when products are bought one at a time.
Is this managed detection and response?
No, and the difference matters commercially. This is a one-time, fixed-price engagement that makes your tenant ready; nobody at IT Partner watches your incidents afterwards. If you want a team reading the queue around the clock, that is Multi-Platform Managed Detection and Response, and it is a separate recurring service. Many customers do this readiness pass first precisely so that whoever monitors afterwards — us, another provider, or their own team — inherits a tuned tenant rather than a noisy one.
We think we have an incident right now. Should we book this?
No. Live handling is Security Managed Service: Incident Response, and a compromised mailbox, forwarding rule or invoice-fraud case is Business Email Compromise Investigation and Recovery. Come back to this page afterwards — the readiness pass is a good use of the moment when the organisation has just been reminded why detection matters. If we find evidence of an active compromise during a readiness engagement, we tell you the same day and scope the response separately.
What licences do we need?
Microsoft lists a broad set of licences that grant Defender portal access, including Microsoft 365 E5 or A5, E3 with the Microsoft Defender Suite add-on, E3 with the EMS E5 add-on, A3 with the A5 Security add-on, Windows 10/11 Enterprise E5 or A5, EMS E5 or A5, Office 365 E5 or A5, Microsoft 365 Business Premium and the standalone Defender plans. The automation this engagement configures is narrower: Microsoft notes that automatic attack disruption requires Defender for Endpoint Plan 2, and the prerequisites for automated investigation and response name Microsoft 365 E5 or A5, E3 with the Defender Suite add-on, A3 with the A5 Security add-on, or Office 365 E5 with EMS E5 and Windows E5. We check your exact entitlements at scoping and tell you which parts of the scope apply before you commit.
Does this work on Microsoft 365 Business Premium?
Partly, and we will be specific rather than optimistic. Business Premium includes Defender for Business and appears on Microsoft's list of licences that grant Defender portal access, and Defender for Business appears in Microsoft's attack-disruption subscription list — but Microsoft's Defender XDR prerequisites page also states that automatic attack disruption requires Defender for Endpoint Plan 2, and the automated investigation and response prerequisites are enterprise-suite based. Because Microsoft's own documentation is not fully consistent here, we verify capability by capability in your tenant at scoping and scope the engagement to what is actually available. In a Business Premium tenant that usually means more emphasis on alert tuning, notifications, ownership and runbooks, and less on the full disruption and automated-remediation set.
What can automatic attack disruption actually do without asking us?
Microsoft's documented actions include containing a device, containing the IP address of an undiscovered device, isolating a compromised workstation, disabling a user account in Active Directory or Microsoft Entra ID, containing a user at the endpoint layer, revoking active sessions, suspending a user in Entra ID, and applying protective measures to a compromised OAuth application — with preview actions for Okta and AWS identities through Microsoft Sentinel connectors, and a set of predictive-shielding actions such as Safe Mode and Group Policy hardening. Each action requires its own product to be deployed: Defender for Endpoint to contain a device, Defender for Identity for on-premises account actions, Defender for Cloud Apps for OAuth app protection. Microsoft also states that every automatic action can be undone by your security team, and part of the design is recording who is allowed to undo what.
Can we stop it from touching our break-glass accounts and critical servers?
Yes, through exclusions — user exclusions for named accounts, device-group automation levels, IP exclusions for infrastructure ranges, and (where the preview capability is available) dynamic-tag policy rules that disable a single disruption control for a tagged group. Two honest caveats go in the register with them. Microsoft's own guidance says excluding assets is not recommended because it reduces the effectiveness of disruption, and excluding a device group from automated responses also suppresses automated investigation and response for that group. So we keep the list short, give every entry an owner, a reason and a review date, and argue against the ones we think will cost you more than they save.
What are the device-group remediation levels, and which do you recommend?
Defender offers 'Full — remediate threats automatically', three semi-automatic levels that require approval for core folders, for non-temp folders or for all folders, and 'No automated response'. Microsoft recommends Full for device groups generally, and notes that a semi-automatic level is still enough for automatic attack disruption to act without manual approval. Our usual shape is Full for standard user workstations, a semi-automatic level for the groups where an application owner has a legitimate fear, and 'No automated response' only for a small, named set with a review date — never as a default nobody chose.
Will Defender automatically delete a phishing email that got through?
Not on its own. Microsoft's documentation is explicit that no remediation actions are taken automatically for email and email content: an alert or policy can trigger an automated investigation, but the email actions wait in the Action center for someone to approve them. That is why this engagement treats the approval roster as a deliverable — including the Search and Purge role that email and content remediation requires in addition to the Defender permission — and why the runbooks state who approves what, and who covers them.
How many custom detection rules do we get, and what can they do?
Five by default, written against your scenarios rather than a generic list — common choices are inbox-rule forwarding to an external address, consent granted to a risky OAuth application, impossible travel or anomalous sign-in on a privileged account, mass file access or download, and the first appearance of a remote-access tool. A custom detection is an advanced hunting query with a schedule; besides raising an alert it can take approved actions on devices (isolate, collect investigation package, run an antivirus scan, initiate an investigation, restrict app execution), on files (block or quarantine), on users (mark as compromised, disable, force reauthentication) and on email (move to a folder, soft or hard delete). We enable only the actions you approve, and more rules can be scoped as additional work.
How often do custom detections run?
You choose per rule: every 24, 12 or 3 hours, hourly, or Continuous near-real-time where the query qualifies — Continuous is limited to specific tables, single-table queries using supported operators, and generally available columns. Tenants with Microsoft Sentinel onboarded to the Defender portal can also set a custom frequency between 5 minutes and 14 days for rules based purely on Sentinel data. Frequency also determines the lookback window Defender applies, so we choose it deliberately per scenario instead of setting everything to the fastest option.
Won't alert tuning just hide real attacks?
It can, which is why every rule is documented and scoped rather than applied broadly. Defender's alert tuning (previously called alert suppression) offers three actions: hide the alert, resolve it automatically, or convert the matching signals into behaviours that stay queryable for hunting. Hidden alerts remain in the AlertInfo and AlertEvidence tables, so the data is not lost. Microsoft's built-in tuning rules also reactivate a suppressed alert if an automated investigation finds something malicious. Our rules are written against the specific evidence that caused the noise, each carries a reason and an owner, and the review confirms nothing has been suppressed that would hide an incident type named in your runbooks.
How do incidents actually reach the right person — email, Teams or a ticket?
Defender's built-in notification rules are email, and they are more capable than most tenants use: you can filter by alert severity, by service or detection source and by device group, send a single notification per incident, include your organisation name and a tenant-specific portal link, and run a separate rule set that notifies on manual and automated response actions and whether they succeeded. Teams messages and tickets are not native — we build one agreed route on top with a Power Automate flow or Logic App, and that one route is included in the fee. Everything gets tested with real recipients before handover; an untested notification rule is a rumour.
Do we need to move to Defender unified RBAC?
Increasingly the question answers itself: Microsoft made unified RBAC the default permissions model for new Defender for Endpoint and Defender for Identity tenants from 2025, and extended that default to new Defender for Office 365 Plan 2 organizations from July 2026. If your tenant already uses it, we design roles within it. If it does not, we will show you what the move buys — least-privilege roles that span workloads instead of Security Administrator handed out as a shortcut — and we can either activate it within this engagement where the scope allows, or hand you a migration plan. What we will not do is leave your approval roster dependent on Global Administrator.
Do we need Microsoft Sentinel or Security Copilot for this?
No. This engagement works entirely within Defender XDR. Sentinel matters if you need non-Microsoft log sources, long retention, cross-source correlation or SOAR playbooks — that is Microsoft Sentinel SIEM/SOAR implementation — and it is also the prerequisite for Microsoft's preview Okta and AWS disruption actions. Security Copilot is optional and sits on top: the Microsoft Security Copilot deployment engagement covers it, and Microsoft's Security Compute Unit charges are billed to you by Microsoft, never inside our fee. Where either is already in place, we work with it.
What happens after the two weeks, and who owns it?
You do, and the handover is built for that: the as-built configuration, the exclusion and tuning registers, the detection inventory, the severity-to-owner map, five runbooks and a maintenance calendar that says what to review monthly, quarterly and after a Microsoft change. The closeout states plainly what is automated, what waits for a human and what nobody is currently watching. There is no lock-in and no minimum term — if you later want the queue watched, Multi-Platform Managed Detection and Response is a separate decision you make on its own merits, and if you buy your Microsoft licensing through us, business-hours break-fix support is included at no extra charge (which is support, not monitoring).
How does the $3,500 work commercially?
It is a fixed price for one tenant and two weeks, confirmed in writing before work begins, and you pay after you approve delivery. It covers everything on this page, including the agreed five custom detections, one Teams or ticketing route and the incident walk-through. Microsoft licences, any Security Copilot compute and any Azure or Sentinel consumption remain on your own bill. If scoping shows the tenant needs prerequisite work that amounts to a deployment project, we quote that separately and up front rather than discovering it in week two.