Defender, Sentinel, Purview, Entra: A Control-Mapping Field Guide
You have four Microsoft security products producing signals but no map of which signal proves which control, and where the gaps are.
Your auditor just asked for evidence against 47 NIST 800-53 rev 5 controls. You know the signals exist somewhere in your Microsoft stack. Defender is producing findings. Sentinel is ingesting logs. Purview is classifying data. Entra is enforcing access policies. But when the auditor asks "show me continuous monitoring evidence for SI-4," you're opening four portals, running four queries, and hoping you pull the right artifact for the right control family.
This is the field guide that should have shipped with your E5 license. Which product proves which control family, what signal type it produces, and where the gaps live.
Why NIST 800-53 rev 5 as the baseline
800-53 rev 5 is the most granular federal control catalog: 1,189 controls across 20 families. If you can map to 800-53, you can derive SOC 2, ISO 27001, CMMC, and FedRAMP from there. Microsoft's own security baselines already reference 800-53 families. This guide completes what they started but never finished in one consumable format.
If your primary framework is SOC 2 or ISO 27001, the mapping still applies. SOC 2's CC6 maps to 800-53 AC and IA. ISO 27001's A.8 maps to SI, AU, and SC. The 800-53 mapping is the Rosetta Stone.
The master mapping table
Each row is a signal type that a Microsoft product produces, mapped to its primary NIST 800-53 family and evidence format.
| Microsoft Product | Signal Type | NIST 800-53 Family | Evidence Format | Cadence |
|---|---|---|---|---|
| Defender XDR | Security baseline compliance | SI (System & Info Integrity) | JSON compliance state per resource | Continuous (12-24h) |
| Defender XDR | Vulnerability assessment | RA (Risk Assessment) | CVE-scored findings | Continuous |
| Defender XDR | Automated investigation verdicts | IR (Incident Response) | Investigation graph + timeline | Event-triggered |
| Defender XDR | Device compliance state | CM (Configuration Mgmt) | Boolean per device policy | Continuous (8h) |
| Defender for Cloud | Regulatory compliance assessments | Multiple (SA, CM, SI) | Per-control pass/fail | Continuous |
| Sentinel | Security event ingestion + retention | AU (Audit & Accountability) | Normalized log tables | Real-time |
| Sentinel | Analytic rule detections | SI (System & Info Integrity) | Alert with MITRE mapping | Event-triggered |
| Sentinel | Playbook execution | IR (Incident Response) | Automation run history | Event-triggered |
| Sentinel | Threat intelligence matches | RA (Risk Assessment) | IOC correlation events | Continuous |
| Purview | Sensitivity label applications | MP (Media Protection) | Label audit events | Event-triggered |
| Purview | Data classification scans | SC (System & Comms Protection) | Sensitive type counts per location | Scheduled |
| Purview | DLP policy matches | SC (System & Comms Protection) | Policy match with context | Event-triggered |
| Purview | Insider risk signals | PS (Personnel Security) | Risk score + activities | Continuous |
| Entra ID | Conditional Access evaluations | AC (Access Control) | Grant/deny with policy ref | Real-time |
| Entra ID | PIM activations | AC (Access Control) | Role activation + approval | Event-triggered |
| Entra ID | Access review results | AC (Access Control) | Decisions per identity | Scheduled |
| Entra ID | Auth method registration | IA (Identification & Auth) | MFA inventory per user | Continuous |
| Entra ID | Sign-in risk detections | IA (Identification & Auth) | Risk event + source | Real-time |
| Azure Policy | Resource compliance evaluations | CM (Configuration Mgmt) | Compliance state per resource | Continuous (1h) |
| Azure Policy | Deny/audit action logs | CM (Configuration Mgmt) | Action with resource ID | Event-triggered |
| Azure Policy | Guest configuration | SA (System & Services Acq) | In-guest findings | Scheduled (15 min) |
That's 21 signal types across five products, covering nine NIST 800-53 families with continuous or near-continuous evidence.
Product-by-product highlights
Defender XDR (SI, IR, RA, CM): The security baseline findings are the highest-value signal. Each is a structured assertion: "Resource X evaluated against policy Y at time Z, result: compliant/non-compliant." For IR, automated investigation graphs provide machine-readable evidence chains mapping to IR-4 and IR-5.
Sentinel (AU, SI, IR): Primary value is proving AU-2, AU-3, AU-6, and AU-12. Logs exist, are retained, normalized, and queryable. Analytic rule detections prove SI-4 with specificity: "detected X at time Y using rule Z." Playbook execution logs prove IR-4 automation. We covered this in Sentinel Logs as Audit Evidence.
Purview (MP, SC, partial PS): The only Microsoft product covering Media Protection. Label applications prove MP-3 (Marking) and MP-5 (Transport). Classification scans address SC-28 (Protection at Rest). DLP matches prove SC-7 (Boundary Protection). Insider risk provides partial PS coverage, but PS controls largely require human processes.
Entra ID (AC, IA): Owns access control and authentication most completely. Conditional Access proves AC-2, AC-3, AC-7. PIM proves AC-5 (Separation of Duties) and AC-6 (Least Privilege). Authentication signals cover IA-2 through IA-8.
Azure Policy (CM, SA): Most systematic CM evidence available. Every resource evaluated against every assigned policy, continuously. Satisfies CM-2 (Baseline), CM-6 (Settings), CM-7 (Least Functionality), CM-8 (Inventory). Guest configuration extends into the OS layer for SA-4.
Where the gaps live
These NIST 800-53 families have minimal or zero Microsoft coverage:
| Control Family | Why No Coverage |
|---|---|
| PE (Physical & Environmental) | Cloud shared-responsibility. Microsoft covers Azure DCs, but YOUR office needs separate evidence. |
| PS (Personnel Security) | Background checks, termination procedures. Human process, no technical signal. |
| PL (Planning) | Security planning, SSP maintenance. Document lifecycle. |
| PM (Program Management) | Risk strategy, leadership engagement. Governance process. |
| SR (Supply Chain) | Procurement process. Partially addressed by Defender for DevOps. |
| AT (Awareness & Training) | Training delivery and records. Requires LMS integration. |
| CP (Contingency Planning) | DR testing evidence. Azure Backup provides signals, but most CP is test execution records. |
| MA (Maintenance) | System maintenance scheduling. Operational process. |
Eight families out of twenty. 40% of 800-53 where no Microsoft product produces sufficient evidence. These require organizational processes, human decisions, physical-world actions. Your team needs to know exactly where automated collection ends.
How Kyudo closes the loop
The table tells you which signals exist. It doesn't tell you how they become audit-ready evidence with provenance, freshness, and cross-framework mapping.
Kyudo's Microsoft integrations pull structured data from all five products via Microsoft Graph and Azure Resource Manager APIs. Not screenshots. The raw JSON with full metadata.
The Controls Hub stores each signal as a hashed, timestamped artifact. When a Defender finding enters, it maps automatically to every framework control it satisfies (not just 800-53, but SOC 2, ISO 27001, CMMC, PCI DSS) using the STRM Engine's relationship data.
For gap families, Kyudo assigns controls to human owners with cadence reminders. Manual evidence enters the same Evidence Hub with the same provenance chain as automated signals, but with freshness decay: stale after 30 days without renewal.
The counter-argument: "We already mapped this ourselves"
Most internal mapping documents have three problems. First, they're static. Microsoft updates product capabilities quarterly, and a spreadsheet drifts within 6 months. Second, they're incomplete: built for one framework, useless when the CMMC auditor arrives. Third, they're not evidence. The mapping tells you where to file a finding. It doesn't collect, hash, or timestamp the finding itself.
Kyudo treats mapping as executable infrastructure. When a Defender finding enters the system, the mapping is already applied. No analyst in the loop for the filing decision.
Cheat sheet: signal to control family
| Evidence Needed | Product | Signal |
|---|---|---|
| AC (Access Control) | Entra ID | Conditional Access, PIM, access reviews |
| AU (Audit & Accountability) | Sentinel | Retention proof, analytics rule fire history |
| CM (Configuration Mgmt) | Azure Policy + Defender | Policy compliance states, baselines |
| IA (Identification & Auth) | Entra ID | MFA registration, sign-in risk, auth methods |
| IR (Incident Response) | Defender + Sentinel | Investigation graphs, playbook logs |
| MP (Media Protection) | Purview | Label applications, encryption |
| RA (Risk Assessment) | Defender + Sentinel | Vuln findings, threat intel matches |
| SA (System & Services Acq) | Azure Policy | Guest configuration assessments |
| SC (System & Comms) | Purview + Azure Policy | DLP matches, classification, network rules |
| SI (System & Info Integrity) | Defender + Sentinel | Baselines, detections, malware findings |
Families not listed (PE, PS, PL, PM, SR, AT, CP, MA): manual collection required.
Your Monday morning checklist
-
Inventory active control families. Which of the 20 are in scope? Cross-reference against the master table to identify what you should be collecting automatically.
-
Verify API access. Defender compliance states, Sentinel queries, Purview audit logs, Entra sign-in data. Missing permissions are the most common reason automated collection fails.
-
Identify gap families. Which in-scope families appear in the "no coverage" table? These need manual workflows with clear owners.
-
Test freshness. Pull one artifact per product. If the most recent Defender state in your GRC tool is 72+ hours old, your pipeline is batch, not continuous.
-
Map cross-framework. That Entra Conditional Access evaluation proves NIST AC-3, SOC 2 CC6.1, ISO 27001 A.8.5, and CMMC AC.L2-3.1.1. If your tool stores it under one framework only, you're collecting the same signal multiple times.
The signals exist. The mapping is known. The gap between "security product output" and "audit-ready evidence" is an integration problem, not a data problem.
Kyudo's Microsoft integration layer pulls structured signals from Defender, Sentinel, Purview, Entra, and Azure Policy into a unified evidence pipeline. One signal, every framework, full provenance.
Book a demo to see your Microsoft signals mapped to controls in real time.