A managed detection provider inherits your logging gaps on the day they onboard. Whatever you never collected, they cannot see; whatever you retain for seven days, they cannot investigate on day eight. This build sheet establishes what your tenant actually produces and keeps, before you take a single vendor demonstration, so that the evaluation compares providers rather than accidentally measuring your own instrumentation.
Everything here is provider-neutral. You are not preparing for a specific vendor, you are establishing a baseline that any of them will need and that you should own regardless of whether you buy managed detection at all.
Step 1: Confirm the unified audit log is on and know its retention
The Microsoft 365 unified audit log is the substrate under almost every business email compromise investigation. It is on by default in current tenants, but tenants that have been through migrations, mergers or old configuration scripts are not reliably current tenants. Verify rather than assume.
Connect-ExchangeOnline
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabledIf that returns False, enable it and note the date, because you have no history before the moment you switch it on.
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $trueRetention is the part people miss. The default retention for most audit records is one hundred and eighty days, extended for certain record types where licensing permits, and configurable through audit retention policies for organisations with the appropriate licence. Establish your actual figure and write it down, because it is the hard boundary on how far back any provider can look.
Get-UnifiedAuditLogRetentionPolicy | Format-Table Name,RecordTypes,RetentionDuration,PriorityValidation for this step: search the log for an event you can generate on demand, a deliberate sign-in from a test account, and confirm it appears. An enabled setting is not the same as a working pipeline.
Step 2: Send Entra ID diagnostic logs somewhere durable
Entra retains sign-in and audit data inside the portal for a period governed by your licence, commonly thirty days with premium licensing and considerably less without. That is short. Any investigation into a slow-burn account compromise, and most of them are slow-burn, wants more than a month of sign-in history.
Configure a diagnostic setting on Entra ID that exports the relevant categories to a destination you control. The three destinations are a Log Analytics workspace for querying, a storage account for cheap long retention, and an Event Hub for streaming to a third party. Providers who ingest your telemetry generally want the Event Hub; your own investigations want Log Analytics; compliance wants the storage account. Choosing more than one is normal and the cost difference is not the interesting part of this decision.
The categories to enable at minimum:
| Category | Why it matters |
|---|---|
| SignInLogs | Interactive user sign-ins. The primary compromise signal. |
| NonInteractiveUserSignInLogs | Token refreshes and background auth. Where persistence hides after the interactive event. |
| ServicePrincipalSignInLogs | Application authentication. Where an attacker goes to survive a password reset. |
| AuditLogs | Directory changes: role assignments, consent grants, policy edits. |
| RiskyUsers and UserRiskEvents | Identity Protection output, if licensed. Feeds most providers’ identity detections. |
The two most commonly omitted are the non-interactive and service principal categories, and they are precisely the two that matter after the initial compromise. An estate that logs only interactive sign-ins can tell you an attacker got in and cannot tell you they are still there.
Step 3: Establish which Defender products are in active mode
Licensed is not deployed, and deployed is not active. This distinction decides both what a provider can do and, for the first-party service, whether you are eligible at all. Produce an honest inventory across the four Defender workloads: endpoint, identity, Office, and cloud apps. For each one record whether it is licensed, whether it is deployed, whether it is in active rather than passive mode, and what percentage of the relevant estate it actually covers.
Endpoint coverage is the one to measure rather than estimate. Onboarding drift is universal: machines rebuilt without the package, servers excluded during a project and never returned, an entire site that predates the rollout.
DeviceInfo
| where Timestamp > ago(7d)
| summarize arg_max(Timestamp, OnboardingStatus, OSPlatform) by DeviceName
| summarize Devices = count() by OnboardingStatus, OSPlatform
| order by Devices descCompare that count against your device inventory in Intune or your configuration management database. The delta between the two is the part of your estate no provider will ever see, and it is usually larger than anyone expects.
Do the same honest accounting for identity: are the sensors deployed on every domain controller, including the read-only ones and the one in the branch office that nobody has touched since the migration.
Step 4: Build the export path before you need it
Most commercial providers ingest your telemetry through an Event Hub. Standing one up during onboarding, under time pressure, with a vendor engineer waiting, is how misconfigurations get made. Build it in advance and test it empty.
Create a dedicated namespace rather than reusing an application one, so that access granted to a provider cannot reach anything else. A worked example, using the naming convention established below:
az eventhubs namespace create \
--resource-group rg-sec-telemetry-prod-eus \
--name evhns-sec-mdr-prod-eus \
--location eastus \
--sku Standard
az eventhubs eventhub create \
--resource-group rg-sec-telemetry-prod-eus \
--namespace-name evhns-sec-mdr-prod-eus \
--name evh-entra-signins \
--partition-count 4 \
--cleanup-policy Delete \
--retention-time-in-hours 168Grant the provider a listen-only authorisation rule on the specific hub rather than a namespace-wide connection string. This is the difference between handing over a key to one room and a key to the building.
az eventhubs eventhub authorization-rule create \
--resource-group rg-sec-telemetry-prod-eus \
--namespace-name evhns-sec-mdr-prod-eus \
--eventhub-name evh-entra-signins \
--name mdr-provider-listen \
--rights ListenPoint the Entra diagnostic setting from step two at this hub, then confirm messages are arriving before anyone external is involved.
Step 5: Govern the credential you are about to create
Every commercial provider in this market reaches your tenant through an application registration holding a secret, with permissions sufficient to disable accounts and isolate machines. Decide how you will govern that before you create the first one, because the pattern will repeat for every security vendor you ever engage.
A naming convention that makes the purpose unmistakable in a directory listing, and that sorts sensibly:
| Element | Value | Why |
|---|---|---|
| Prefix | svc-ext- | Marks it as an external party’s service principal, not an internal app. |
| Vendor | <vendorname>- | Who holds the secret. Obvious at a glance during a review. |
| Function | mdr-response | What it is for, so that scope creep is visible. |
| Owner | Named individual, not a group mailbox | Someone must be accountable for the review. |
| Secret expiry | Twelve months maximum, six preferred | Forces a review cadence that would otherwise never happen. |
Record the granted permissions at creation and diff them at every review. Vendors add capability over time and permission requests arrive framed as routine updates. A permission set that grew from monitoring to response without anyone noticing is a real finding in real environments.
List what exists today before you add to it:
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -Filter "servicePrincipalType eq 'Application'" -All |
Where-Object { $_.AppOwnerOrganizationId -ne (Get-MgContext).TenantId } |
Select-Object DisplayName, AppId, @{n='Created';e={$_.AdditionalProperties.createdDateTime}} |
Sort-Object Created -DescendingIf that list surprises you, deal with it before adding another entry to it.
Step 6: Close the hybrid gap in your own runbook
Two providers in this series independently engineered a guard against the same failure: disabling a synchronised account in the cloud alone, only for directory synchronisation to re-enable it. If two vendors built the same defence, your own incident runbook probably has the hole they were defending against.
Establish which of your accounts are synchronised, because the containment procedure differs and responders should not be working that out during an incident.
Get-MgUser -All -Property UserPrincipalName,OnPremisesSyncEnabled |
Group-Object OnPremisesSyncEnabled |
Select-Object Name, CountFor any synchronised account the containment sequence is: disable in Active Directory, disable in Entra, revoke sessions and refresh tokens, and only then consider the account contained. Doing the cloud half alone buys minutes and creates a false sense of resolution.
The end-to-end test
Everything above is configuration until you prove it works as a chain. Run this once, in production, with a test account you control and a change record so nobody panics.
Sign in as the test account from a location and device that will generate a risk signal. Consent it to a benign multi-tenant application to produce an OAuth grant. Create an inbox rule that forwards to an external address, which is the single most common artefact of a real business email compromise. Then, from the point of view of an investigator, answer four questions using only the telemetry you have configured: can you see the sign-in with its location and device, can you see the consent grant and what it was granted, can you see the inbox rule creation, and can you still see all three tomorrow and in ninety days.
Then confirm the same events arrived at the Event Hub, because a provider will be reading that rather than your portal.
Anything you could not answer is a gap that a managed detection contract will not fix. Fix it first, or accept it deliberately and tell your provider it exists, which at least converts a blind spot into a known limitation. Delete the inbox rule, revoke the consent and disable the test account when you are done.
The output of this exercise is the document you hand every provider during evaluation: this is what we collect, this is how long we keep it, this is what we know we cannot see. A provider who reads that and adjusts their proposal is one worth talking to. A provider who ignores it and sends the same quote either way has told you how the engagement will go.
MDR
‹ Previous: [MDR 10] What the Contracts Actually Say: Authority, SLAs, Overlap, and the GenAI Claim
Next: [MDR 10.2] Build Sheet: The Evaluation Scorecard and Proof-of-Value Plan ›
