Purview, Defender XDR, Sentinel, Log Analytics, KQL, Logic Apps, Power Automate, and Power BI should be the primary semantic and reporting foundation. Splunk should consume curated outputs when enterprise SIEM correlation is required. This avoids forcing Splunk engineers to reverse-engineer sparse, nested, and inconsistent Purview audit events into enterprise-class DLP reporting.
| Need | Best Owner |
|---|---|
| Policy and control definition | Purview |
| DLP alert investigation | Defender XDR |
| Microsoft security normalization | Sentinel / Log Analytics / KQL |
| Operational security dashboards | Sentinel Workbooks |
| Executive KPI dashboards | Power BI |
| Workflow and evidence automation | Logic Apps / Power Automate |
| Enterprise-wide SIEM correlation | Splunk |
| Cross-vendor detection / correlation | Splunk |
| Audit evidence register | SharePoint + Power Automate |
| Reference taxonomy (label / SIT / policy maps) | Sentinel Watchlists |
| KQL semantic functions / normalization | Sentinel / Log Analytics |
| Monthly leadership report | Power BI |
Purview is where the organization defines and operates DLP policies, DLP rules, Sensitive Information Types, EDM classifiers, sensitivity labels, auto-labeling policies, retention labels and policies, and Insider Risk / DSI controls.
But Purview alone is not the best place to build enterprise-class KPI reporting. Its portals serve administrators and compliance users — they are not a full SIEM, operational data lake, executive BI platform, or audit evidence warehouse.
Microsoft's own documentation separates responsibilities: Purview is the place to create and edit DLP policies. Defender XDR is the recommended place to investigate and manage DLP alerts.
The UAL / Office 365 Management Activity API is essential for audit trail coverage of user, admin, system, and policy actions across M365. But it is primarily an activity evidence stream, not a complete investigation model.
| Question | UAL usefulness |
|---|---|
| Did an event happen? | Strong |
| Who performed the action? | Strong |
| What workload was involved? | Usually strong |
| Was there a DLP / policy-related activity? | Useful, but variable |
| What was the full investigation outcome? | Weak |
| Was it true positive or false positive? | Weak |
| Who triaged it? | Weak |
| What incident did it roll into? | Weak without Defender/Sentinel |
| What is the executive risk trend? | Weak without normalization |
Defender XDR is where DLP alerts and incidents become operational security objects with alert lifecycle, severity, status, evidence, classification, determination, assignment, and related entities.
KPIs like alert queue depth, incident aging, MTTA, MTTR, false-positive rate, true-positive rate, analyst assignment, and incident closure quality are Defender/Sentinel investigation questions — not raw Purview questions.
The Defender XDR connector can stream incidents, alerts, and Advanced Hunting events into Sentinel while keeping incidents synchronized between both portals.
| Requirement | Best Microsoft layer |
|---|---|
| Normalize nested events | KQL functions |
| Correlate alerts and incidents | Sentinel / Defender XDR |
| Build operational dashboards | Sentinel Workbooks |
| Store security telemetry | Log Analytics |
| Create analytic rules | Sentinel |
| Route incidents | Sentinel automation rules |
| Trigger workflows | Logic Apps |
| Maintain mapping tables | Sentinel Watchlists |
| Create executive BI | Power BI |
Sentinel Workbooks are excellent for engineering and SOC users. They are not ideal as the final executive reporting layer.
Power BI is better for executive scorecards, trend visualizations, board/compliance reporting, scheduled refresh, governed sharing, row-level security, branded dashboards, exportable audit packages, and PowerPoint-ready reporting.
Microsoft supports creating Power BI reports from Sentinel / Log Analytics KQL query outputs directly.
Splunk should remain in scope if the SOC already uses it as the enterprise SIEM. Splunk is strong for cross-vendor correlation, enterprise SIEM workflows, non-Microsoft telemetry, long-term retention, and centralized SOC operations across Proofpoint, Zscaler, EDR, IAM, proxy, VPN, and firewall.
But Splunk should consume curated Microsoft security facts — not raw Purview telemetry as the primary source for executive Purview KPIs.
A pure Microsoft-only answer may be technically strong but politically difficult if leadership has already selected Splunk as the enterprise SIEM.
A Splunk-only answer may satisfy SOC direction but technically underperform for Purview-specific reporting.
The hybrid answer is defensible: Microsoft should generate the authoritative Purview/DLP security model. Splunk can consume that model for enterprise SIEM correlation. This gives each platform the right job.
Click any phase to expand steps and deliverables.
Steps
- Define reporting domains: Health, Effectiveness, Investigation Operations, Executive Risk, Audit Evidence
- Define authoritative systems per domain (Purview, Defender XDR, Sentinel, Power BI, Splunk, SharePoint)
- Build KPI catalog: name, definition, audience, source system, calculation logic, refresh cadence, owner, maturity state, known gap, remediation plan
Deliverables
Steps
- Confirm Purview audit logging is enabled
- Confirm DLP policies have alerting enabled
- Confirm Defender XDR is receiving DLP alerts
- Connect Defender XDR to Sentinel; stream incidents, alerts, and Advanced Hunting events
- Ingest Microsoft 365 audit activity where available
- Validate event freshness and volume; document unavailable sources explicitly
Deliverables
Sentinel Watchlists to Create
- DLPPolicyMap — policy name, owner, objective, enforcement mode, workload scope, deployment status
- DLPRuleMap — rule name, policy name, severity, owner, expected response, tuning status
- SITFamilyMap — SIT name, family, regulated category (NPI/PCI/PII/PHI/financial/credential)
- SensitivityLabelMap — label name, GUID, reporting family, protection level, sharing expectation
- KPIMaturityMap — KPI, status, owner, known gap, remediation action
- ControlOwnerMap — control, owner, delegate, business unit, escalation path
Deliverables
Core KQL Functions
Purview_DLP_Events()—Purview_DLP_Alerts()—Purview_DLP_Incidents()Purview_Label_Activity()—Purview_SIT_Activity()Purview_Control_Facts()— normalized single truth viewPurview_KPI_Health_Daily()—Purview_KPI_Effectiveness_Daily()Purview_KPI_Investigation_Daily()—Purview_KPI_Executive_Monthly()
Key Normalized Fields
EventTime·SourcePlane·Workload·PolicyName·RuleName·RuleActionUserPrincipalName·SensitivityLabel·SITNames·SITFamilyAlertId·IncidentId·Severity·Status·Classification·MaturityStatus
Deliverables
Workbook 1 — Purview Pipeline Health
- Data freshness · connector status · event volume by source · DLP event trend · parse success rate · zero-event days · failed automation runs
Workbook 2 — DLP Control Effectiveness
- DLP events by workload / policy / rule · block/warn/allow/override trend · SIT family distribution · sensitivity label distribution · top external domains · top risky users
Workbook 3 — Investigation Operations
- Incidents by severity / status · active queue depth · aging by severity · MTTA · MTTR · false-positive rate · true-positive rate · unassigned incidents
Workbook 4 — Audit Evidence Register
- Control objective · evidence source · last event seen · current maturity · owner · known gap · remediation action · evidence package link
Deliverables
Reports
- Executive Data Protection Scorecard · Control Health Dashboard
- DLP Effectiveness Trend · Sensitive Data Exposure Dashboard
- Audit Defensibility Dashboard · KPI Maturity Dashboard
Design Rules
- Use curated KQL outputs from Log Analytics — avoid raw nested JSON in Power BI
- Use stable KPI tables/views; monthly and weekly trend snapshots
- Separate Health from Effectiveness; clearly label proxy metrics
Key Executive Metrics
- Control Health Score — whether controls are operating
- Control Effectiveness Score — whether controls are reducing risk
- Override Rate — user/business override pressure
- False Positive Rate — tuning burden
- KPI Maturity — Blank / Partial / Live
Deliverables
Logic Apps — Security Operations
- High-severity DLP incident notification · incident aging escalation
- Failed connector notification · monthly evidence snapshot
- False-positive tuning backlog routing · override threshold escalation
Power Automate — Compliance / Business Workflow
- Update SharePoint evidence register · assign control owner tasks
- Route monthly attestations · trigger Planner tasks for KPI gaps
- Distribute Power BI report links · send executive report notifications
SharePoint Evidence Register
- KPI name · owner · source · maturity · last refresh · evidence link · known gap · remediation status · audit notes
Deliverables
Send to Splunk (not raw Purview exhaust)
- Normalized DLP control facts · Sentinel incidents · Defender XDR incident summaries
- High-severity DLP alerts · KPI summary tables · policy/rule/action trends
- User/file/entity risk facts · monthly audit evidence status
Splunk Use Cases
- Correlate DLP events with Proofpoint, Zscaler, EDR, IAM anomalies, proxy/firewall
- Enterprise SOC dashboards · cross-platform incident timelines
Deliverables
- Define KPI catalog
- Connect Defender XDR to Sentinel
- Validate DLP alerts in Defender
- Confirm UAL / audit availability
- Create initial Sentinel Watchlists
- Build basic ingestion health workbook
- Build first KQL normalization functions
- Build DLP Control Facts function
- Build Engineering + Investigation workbooks
- Normalize policy/rule/action/SIT/label mappings
- Create Power BI prototype from curated KQL output
- Build SharePoint evidence register
- Create first Logic App escalations
- Build executive Power BI dashboard
- Implement Health and Effectiveness scores
- Build monthly audit evidence workflow
- Add false-positive + override workflows
- Feed curated records into Splunk
- Validate with SOC, compliance, engineering, and audit