Microsoft Defender XDR alert setup
Security alerts reach a named person, and you can show they do.
The agreed data sources, alert rules, licensing, how long events are kept, and who responds are all set up. Each is tested with events you expect to see, then handed to a named owner with a runbook.
- What you get
- Configured security data sources and alert rules, with a response owner and operating runbook.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- Agreed test events are seen, routed and acknowledged; coverage gaps are documented and the owner accepts the response instructions. Ongoing monitoring is separate.
Illustrative sample · constructed example
Trace a controlled event to its assigned reviewer.
Safe test event · alert routing
Selected check
Did the named reviewer receive the test notification?
Safe test event · alert routing
| Dependency | What has to be established | Sample review |
|---|---|---|
| Test event | Use a safe test agreed with the technical owner. | Test generated |
| Alert route | Confirm the alert reaches the intended destination. | Delivery unconfirmed |
| Recipient | Ask the nominated reviewer to acknowledge the sample. | Acknowledgement pending |
| Ongoing response | Agree who will investigate alerts after handover. | Operating responsibility |
A tested alert route is distinct from a staffed monitoring and response service.
- Evidence
- Test event ingested; reviewer acknowledgment has not been recorded.
- Decision
- Routing test incomplete
- Next action
- Check the notification rule and destination with the assigned reviewer.
Setup establishes tested routing and ownership. Ongoing monitoring, staffing and future response are separate responsibilities.
Why now
The work starts here.
The business cannot say what its security tools actually watch, or who would look at an alert if one fired.
Scope at a glance
- One Microsoft 365 tenant
- Supported Defender licensing
- A named alert reviewer exists
If nobody acts
What waiting costs
An alert that fires with no named reviewer produces a signal without a response. The event is recorded, and the follow-up waits on someone happening to look.
The portals show what is connected, not what is missing. The first evidence that something was left unconnected tends to arrive during the incident that needed it.
Default retention settings decide how far back an investigation can look. That decision gets made silently, years before anyone needs the history.
A questionnaire answered with a monitoring claim you cannot support becomes a statement the business has to stand behind later.
Check your own environment
Sounds like you?
- Nobody can list which workloads feed the security portals
- Alerts route to a mailbox nobody reads, or to nobody
- Retention has never been set deliberately
- The last questionnaire asserted monitoring nobody could evidence
Save yourself the call
Not for you if
- A monitoring provider already watches your environment and sends you reports
- Your licensing does not include the Defender plans this sets up
- You want somebody watching around the clock, which is a monitoring service and not this
The work
What is different when we hand over
The connected data sources are enumerated against the workloads the business actually runs, and the gaps are named.
Alert policies are configured for the agreed scenarios, with routing to a named reviewer rather than an unread mailbox.
Retention is set deliberately against the agreed requirement instead of left on defaults.
Expected test events are generated and traced end to end: raised, visible, routed, and acknowledged.
The named owner takes over a runbook that says what is watched, where alerts land, and what to do with them.
Acceptance
Checks before handover
Done when expected test events are visible and routed, and the named owner accepts the runbook.
Every in-scope data source is connected and verified, or its gap is documented with a licensing or scoping reason
Expected test events are visible and routed to the named reviewer
Retention matches the agreed requirement
The response owner accepts the runbook
A fair question
Are you going to watch our alerts for us?
No, and any page that implies otherwise is selling you something different. This sets up what your Microsoft security tools watch, what they raise, and where those alerts go, then hands it over documented. Somebody has to be on the other end. If that has to be an outside team around the clock, that is a monitoring service, and this is the work that makes one worth paying for.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- Workloads and data sources in scope
- Licensing tier available for the connectors required
- Number of alert policies and routing rules
- Retention requirements beyond the defaults
Delivery calendar
The proposal names the start date, the change windows and the completion date before anything is agreed.
How engagements workScope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- Ongoing monitoring and alert response, which stay with the client or an MSP/SOC
- Emergency or same-day incident response
- Forensics or live breach containment
- SIEM migration or Sentinel build-out unless separately scoped
What we need from you
- Name the alert reviewer and response owner
- Provide licensing for the connectors in scope
- Approve the alert scenarios and change windows
Change and rollback method
- Configuration changes are staged in agreed windows; nothing is switched off while a replacement is unproven.
- Test events are generated against agreed test scenarios, never by weakening production controls.
- Rollback is the prior configuration state, captured before the first change.
What you keep at handover
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- The data-source coverage register, connected and gaps alike
- The alert policy set and routing configuration, documented
- The test-event trace: raised, seen, routed, acknowledged
- The response runbook, accepted by its owner
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Price the alert setupOr write to [email protected]