SIEM Strategy

Microsoft Sentinel is a cloud-native SIEM and SOAR platform. While Defender XDR provides detection and response within the Microsoft security product family, Sentinel provides the aggregation layer: pulling signals from XDR plus infrastructure logs, non-Microsoft sources, and custom data, correlating them with analytics rules, and retaining them for the long-term audit period that Advanced Hunting's 30-day window cannot cover.

Why Sentinel for CMMC

CMMC Level 2 = NIST SP 800-171 Rev. 2's 110 practices. Three control families make a SIEM practically necessary:

• AU — Audit and Accountability (3.3.1 – 3.3.9). Create audit records, uniquely trace actions to users, review and correlate across sources, retain (3 years is DIB practice), protect from tampering, and limit audit-management privileges. This is one evidence surface covering Entra, M365, Azure, and endpoints — not something you assemble from per-product log viewers at assessment time.
• IR — Incident Response (3.6.1 – 3.6.3). Operational incident handling with tracking and testing. Sentinel incidents and playbooks give assessors the case-management framework they expect, with automated evidence capture that raw ticket logs don't produce.
• SI — System and Information Integrity (3.14.6 – 3.14.7). Monitor for unauthorized use; identify anomalous access. Analytics rules and UEBA produce the behavioral evidence raw ingestion alone can't.

Is Sentinel literally required? No. Any SIEM that aggregates across the boundary and retains immutably can pass — Splunk, Elastic, and QRadar are viable in Azure Government. But for organizations already paying for M365 GCC High and Azure Government, Sentinel is the lowest-friction path:

• Native connectors for Entra ID, Microsoft 365, Azure Activity, and Defender XDR — no connector engineering.
• Log Analytics archive tier hits the 3-year retention expectation cheaply.
• Immutable audit storage and Azure RBAC satisfy AU.L2-3.3.8 (protect audit information) and AU.L2-3.3.9 (limit audit management) out of the box.
• CMMC-specific Content Hub solutions ship posture assessment rules and a compliance workbook — no custom authoring for the baseline assessment artifacts.

For typical 50–500-seat DIB shops, Sentinel is the path a C3PAO will recognize and validate fastest. The rest of this chapter treats Sentinel as the choice; the conceptual deployment flow (connectors → posture rules → detection rules → retention) generalizes to other SIEMs, but the specific Content Hub solutions and Defender XDR unified-platform integration are Sentinel-only.

The XDR-Sentinel Relationship

Defender XDR is the detection plane — MDO, MDA, MDI, and MDE each generate their own alerts and aggregate them into XDR incidents. Advanced Hunting covers 30 days.

Sentinel is the aggregation and analytics plane — it ingests XDR incidents plus additional log sources, applies analytics rules beyond what XDR provides, stores logs for 90 days hot plus configurable cold retention spanning years, and hosts workbooks and SOAR playbooks.

In practice: XDR for day-to-day incident response; Sentinel for long-horizon hunting, compliance reporting, and cross-workload correlation.

Sentinel Cost Planning

Sentinel costs are entirely consumption-based — no per-user license, just per-GB ingestion plus optional per-GB retention beyond the 90-day Analytics-tier default. The good news: for organizations already on M365 G5 (or the M365 G5 Security add-on), the practical cost can be near-zero if free benefits are activated and high-volume tables are tuned. This section covers what's free, how Azure Government pricing differs, and two worked examples representing the most common GCC High customer shapes.

Free benefits — what you get without paying

Five distinct free programs apply, often stacking. Confirm each is enabled before estimating ingestion cost:

Benefit	Allowance	Eligibility	Reference
Always-free data sources	Unlimited for in-scope sources	Every Sentinel workspace	Free data sources
Sentinel-enabled retention extension	90 days Analytics-tier (hot) retention free per table — vs. 31 days for Log Analytics workspaces without Sentinel	Sentinel enabled on the workspace	Sentinel costs and billing
Microsoft 365 E5/A5/F5/G5 benefit	5 MB / user / day for select Microsoft sources (Microsoft Entra ID, Microsoft Defender XDR / Office 365 / Endpoint / Identity / Cloud Apps, Microsoft 365)	M365 E5/A5/F5/G5 or M365 E5 Security add-on per eligible user	Microsoft Sentinel benefit for Microsoft 365 E5, A5, F5, G5 customers
Defender for Servers Plan 2 data ingestion benefit	500 MB / server / day for eligible security tables	Defender for Servers P2 enabled in Defender for Cloud on the workspace	Use the data ingestion benefit
31-day free trial	First 10 GB/day free for 31 days (up to 20 workspaces per tenant)	Newly-enabled Sentinel workspaces	Free trial

Always-free sources include Azure Activity Logs, Sentinel Health, Office 365 Audit Logs (SharePoint / Exchange admin / Teams), and security alerts from Microsoft Defender XDR, Defender for Cloud, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Defender for Endpoint. Note the distinction: alert summaries from those products are free; the raw logs underlying them (DeviceProcessEvents, EmailEvents, etc.) are paid ingestion.

Azure Government pricing notes

Same SKUs, same free benefits, roughly 25% higher per-GB rate to fund Gov ATO infrastructure. Recent observed Azure Government PAYG is approximately $5.38 / GB for Sentinel + Log Analytics combined, versus approximately $4.30 / GB for Azure commercial East. There is no Gov-specific Sentinel SKU. Use the Sentinel pricing page and Defender for Cloud pricing page with the US Gov region selector for tenant-accurate quotes. Commitment tiers are available starting at 100 GB/day and reduce per-GB cost substantially when sustained volume justifies the commitment.

Worked example — small Entra-focused GCC High customer

A representative small GCC High customer (≈100 users, mostly G5; no on-prem servers; Entra + Defender connectors only) running Sentinel for 90 days produced this ingestion mix:

Table	GB / 90 days	% of total
AADNonInteractiveUserSignInLogs	11.4	61%
MicrosoftGraphActivityLogs	6.5	35%
AuditLogs + SigninLogs + provisioning + risk events	0.7	4%
Total	18.6 GB	100%

That's about 0.5 GB/day. At Azure Government PAYG ($5.38/GB), the unoptimized monthly cost is approximately $80. Three levers change the picture dramatically:

1. Activate the M365 G5 benefit. ≈100 G5 users × 5 MB/day ≈ 500 MB/day free allowance — closely matches current daily ingestion. The benefit scales linearly with G5-licensed user count (not total user count), so a tenant where 80 of 100 users are G5 gets a 400 MB/day allowance covering ≈80% of this ingestion. Activation is a one-time toggle in workspace settings (see below). For this customer profile, this single change drops the bill from ≈$80/month to ≈$0/month. The benefit isn't auto-applied — many customers pay this bill for months without realizing it.
2. Disable AADNonInteractiveUserSignInLogs if no detection rule needs it. Non-interactive sign-ins record every service principal token refresh, every background app reauthentication, every silent-renewal flow. They're typically 10× the volume of interactive SigninLogs and rarely the source of meaningful detections in customer-shaped environments. Disabling this table alone drops volume by ≈61% — from 0.5 GB/day to 0.2 GB/day. If the M365 G5 benefit is not applicable (sub-100 G5 users, or non-G5 tenants), this is the single highest-leverage cost optimization.
3. Move long-retention tables to the Sentinel data lake tier. Default retention is 90 days hot in the Analytics tier (free for Sentinel-enabled workspaces). Anything beyond 90 days incurs storage cost — the data lake tier is substantially cheaper than Analytics-tier retention for cold data, with KQL still queryable via promotion jobs.

Worked example — mid-sized GCC High enclave with Defender for Servers

A mid-sized CMMC enclave (100 M365 E5 users, 50 on-premises Windows Servers, full Defender + firewall + Intune connectors) has substantially more free allowance because the per-server benefit kicks in:

Free source	Calculation	Daily allowance
Always-free data sources	Azure Activity, O365 audit, security alerts	≈few GB/day variable
M365 E5 benefit	100 users × 5 MB/day	500 MB/day
Defender for Servers P2 benefit (if adopted)	50 servers × 500 MB/day	25 GB/day
Total free allocation		≈25–30 GB/day

A fully-instrumented enclave at this scale typically lands at 30–60 GB/day total ingestion. So a 50-server CMMC enclave that adopts both benefits realistically runs Sentinel at near-zero ingestion cost for the bulk of its volume, with only peaks above the free allocation billed at PAYG.

Why P2 is the right server-licensing choice when Sentinel is in scope

The Sentinel ingestion benefit doesn't just reduce cost — it inverts the apparent license-cost ranking. The naive picture (cheapest first) is standalone < P1 < P2; the picture once Sentinel ingestion of server data is included is the opposite. Walk through the math at 50 servers:

	Per-server/mo	50 servers × 12 mo	Sentinel ingestion benefit
MDE for Server standalone	$3	$1,800	None
Defender for Servers P1	$5	$3,000	None
Defender for Servers P2	$15	$9,000	500 MB / server / day

The license premium for P2: $6,000/year over P1 ($500/month for 50 servers); $7,200/year over standalone ($600/month for 50 servers).

What that premium buys back via the ingestion benefit: 50 servers × 500 MB/day = 25 GB/day = 750 GB/month free Sentinel ingestion of eligible security tables (SecurityEvent, DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents, WindowsEvent, etc. — the standard server-side Sentinel sources). At Azure Government PAYG ≈$5.38/GB, that's ≈$4,035/month worth of ingestion that would otherwise be billed.

Break-even: the P2 license premium is recovered if those servers would otherwise have ingested even ≈100 GB/month of security data into Sentinel — about 3 GB/day across the fleet, ≈60 MB/day per server. Any normal MDE-instrumented server fleet exceeds this threshold trivially. DeviceProcessEvents alone runs 50–150 MB/day per server; DeviceNetworkEvents 50–100 MB/day; WindowsEvent 50–200 MB/day; combined per-server Sentinel-bound telemetry is normally 200–500 MB/day.

Worked numbers at 300 MB/server/day average:

	Without P2 (P1 + PAYG)	With P2
License cost	$250/month (P1, 50 × $5)	$750/month (P2, 50 × $15)
Sentinel ingestion at Gov PAYG (50 × 300 MB/day = 450 GB/month × $5.38)	$2,421/month	$0/month (within 25 GB/day allowance)
Total monthly	$2,671/month	$750/month
Annual delta		P2 saves ≈$23,000/year

In other words: for any customer adopting Sentinel and ingesting server security telemetry, P2 is not the most expensive option — it's the cheapest, by roughly $23,000/year for 50 servers. P1 and standalone have no equivalent offset because they include no ingestion benefit.

When this argument doesn't apply

Three caveats:

1. No Sentinel = no benefit. If the customer isn't adopting Sentinel, the P2 ingestion benefit is wasted. At that point the $6,000/year P1→P2 premium has to justify itself purely on the P2-only features — Microsoft Defender Vulnerability Management, File Integrity Monitoring, Adaptive Application Controls, and the Regulatory Compliance dashboard. Whether that's worth $6,000/year depends on whether the customer would otherwise procure equivalent capabilities (Tenable, Qualys, Rapid7, etc.) separately.
2. Eligible tables only. The 500 MB/server/day applies to a defined list of eligible security tables, not arbitrary Sentinel ingestion. Custom logs, application performance telemetry, and non-security tables don't count toward the benefit.
3. Workspace placement matters. The benefit is applied to the Log Analytics workspace where each server reports. If servers report to a different workspace than the one where Sentinel is enabled, the benefit doesn't connect to the Sentinel ingestion bill. Verify single-workspace alignment before promising the cost flip in a CAB submission.

For the underlying server-licensing comparison and the recommendation matrix that distinguishes Sentinel-adopting customers from EDR-only customers, see Defender for Endpoint § Licensing.

Activating the M365 E5/G5 benefit

The benefit is not auto-applied — it must be enabled per workspace by an admin holding the Sentinel Contributor role:

1. Azure portal → Microsoft Sentinel → [workspace] → Settings → Pricing
2. Confirm the Microsoft Sentinel benefit for Microsoft 365 E5, A5, F5, G5 customers offer is listed and active. If the offer is available but not enabled, activate it. If it's missing entirely, the workspace doesn't have eligible licenses bound to it — verify the Microsoft Defender XDR connector is configured and that the tenant has E5/G5 licenses.
3. Verify on the next billing cycle that the meters Free Benefit - M365 Defender Data Ingestion and Free Benefit - M365 Defender Analysis appear with non-zero usage in the Azure cost export. See View data allocation benefits for the exact filtering steps.

The benefit applies prospectively from the activation date — it doesn't recover charges already incurred before activation. Tenants on G5 should activate this on day 1 of any new Sentinel workspace.

Cost optimization patterns

In rough order of leverage:

Pattern	Typical impact	When to apply
Activate the M365 E5/G5 benefit	Up to 100% reduction at small-customer scale	Always, if license profile qualifies
Disable AADNonInteractiveUserSignInLogs	≈60% volume reduction	Unless a detection rule explicitly hunts service-principal or non-interactive sign-in patterns
Move high-volume noisy tables to Auxiliary or Basic log tier	70–90% per-GB reduction on those tables	High-volume telemetry that must be retained but isn't queried real-time (raw network logs, verbose process telemetry)
Adopt commitment tier (100 GB/day+)	25–60% per-GB reduction	Workspace ingesting >100 GB/day sustained for 30+ days
Long-retention to Sentinel data lake tier	Substantial reduction on cold storage	Compliance retention requirements beyond the 90-day Analytics-tier free window

Deployment at a Glance

This chapter covers two phases: one-time Workspace Setup and sequential Content Deployment.

Workspace Setup — Azure Government infrastructure to host Sentinel:

Substep	Output
1. Create resource group	rg-sentinel-prod-usgovva exists
2. Create Log Analytics workspace	law-sentinel-prod-usgovva exists
3. Add Microsoft Sentinel	Sentinel blade is operational
4. Verify sovereign-cloud alignment	Workspace confirmed in USGov region

Content Deployment — seven sequential steps from bare workspace to compliance-ready SIEM:

Step	Produces
1. Install Content Hub solutions	Data connector cards appear in the connectors list
2. Configure each data connector	Telemetry flowing (SigninLogs, OfficeActivity, AzureActivity, etc.)
3. Enable CMMC 2.0 posture assessment	Defender for Cloud prereqs complete; CMMC posture rule templates created
4. Save workbook templates	Tier 1 workbooks + CMMC 2.0 workbook saved and parameterized
5. Demonstrate immediate operation	Eight shared KQL queries produce compliance-evidence screenshots
6. Verify NIST 800-171 data arrival	SecurityRegulatoryCompliance returns NIST rows; CMMC workbook tiles and posture rules now fully operational
7. Enable detection rule templates	Threat-detection analytics rules active from product solutions

Step 3 triggers a 12–24h Defender for Cloud assessment pass, but the only things gated by that wait are CMMC workbook tile rendering and first-fire of the CMMC posture rules — both verified in Step 6. Steps 4 and 5 proceed immediately and produce the full client-demo deliverable without waiting.

Sentinel Workspace Setup

Portal differences: Azure Government (GCC High) vs. Commercial

	GCC High	Commercial
Azure portal	portal.azure.us	portal.azure.com
Log Analytics endpoint	*.ods.opinsights.azure.us	*.ods.opinsights.azure.com
Sentinel region	usgovvirginia or usgovtexas	Any supported Azure region
Defender XDR connector	Available	Available

Workspace creation steps

1. Create the resource group

All Sentinel-related resources (the Log Analytics workspace, the Sentinel solution, any automation account, and later data-collection rules) live in a single resource group scoped to the Azure Government subscription.

1. Azure portal (portal.azure.us for GCC High) → Resource groups → Create.
2. Subscription: select the Azure Government subscription tied to the GCC High tenant.
3. Resource group name: use a standard naming convention that encodes purpose, environment, and region:
   • rg-sentinel-prod-usgovva (Virginia)
   • rg-sentinel-prod-usgovtx (Texas)
4. Region: USGov Virginia or USGov Texas — must match the region you will use for the Log Analytics workspace and must be an Azure Government region, not a commercial region.
5. Click Review + create → Create.

2. Create the Log Analytics workspace

The workspace is where Sentinel stores all ingested log data. Create it inside the resource group created in the previous step.

1. Azure portal → Log Analytics workspaces → Create.
2. Subscription: same Azure Government subscription.
3. Resource group: select the resource group from the previous step (e.g., rg-sentinel-prod-usgovva).
4. Name: use a naming convention that pairs with the resource group:
   • law-sentinel-prod-usgovva
5. Region: same region as the resource group. This determines where log data is stored at rest — for GCC High this must be an Azure Government region.
6. Pricing tier: Per-GB (default). Commitment tiers are available at 100 GB/day and above; evaluate after 30 days of ingestion data.
7. Retention: workspace default is 30 days. CMMC audit requirements typically call for 3 years — plan on 365 days hot plus 2 years archive as the baseline. See Log Retention for the per-table configuration model; the workspace default can stay at 30 days for now and be tuned per-table once ingestion is live.
8. Click Review + create → Create.

3. Add Microsoft Sentinel to the workspace

Sentinel is an overlay on top of Log Analytics — it adds the incidents queue, analytics rules, data connectors, content hub, SOAR playbooks, and workbooks.

1. Azure portal → Microsoft Sentinel → Create (or Add).
2. Select the Log Analytics workspace created in the previous step (e.g., law-sentinel-prod-usgovva).
3. Click Add. Sentinel provisions in under a minute. Once complete, the Sentinel blade opens with an empty workspace ready for data connectors.

4. Verify sovereign-cloud alignment

Before connecting any data, confirm the workspace is in the correct cloud. The Sentinel workspace overview has moved from the Azure portal to the Defender portal:

1. Open the Defender portal: security.microsoft.us/sentinelsettings/siem-workspace?tid=[YOUR-TENANT-ID] (replace [YOUR-TENANT-ID] with your GCC High tenant ID).
2. Confirm the workspace Region shows an Azure Government region (USGov Virginia or USGov Texas), not a commercial region.
3. Confirm the Subscription shows your Azure Government subscription, not a commercial subscription.
4. If either check fails, the workspace was created in a commercial subscription or region — delete it and start over. A commercial workspace cannot ingest GCC High log data.

Use a single workspace per tenant for most organizations ingesting less than 100 GB/day. Multi-workspace architectures are appropriate only when compliance requirements or data residency mandates separating workload types.

Sentinel Content Deployment

After workspace creation, deploy Sentinel content in six steps: install Content Hub solutions, configure data connectors, enable CMMC 2.0 posture assessment, save workbook templates, demonstrate operation, and enable detection rule templates.

The Sentinel data connectors page is at Defender portal → Microsoft Sentinel → Configuration → Data connectors (security.microsoft.us for GCC High). A fresh workspace shows only the pre-installed Microsoft 365 Insider Risk Management (Preview) connector. The remaining connectors are installed via Content Hub solutions — each solution bundles its data connector, analytics rules, hunting queries, and workbooks as a single package.

Step 1: Install Content Hub solutions

Content Hub solutions deploy the data connectors you need. Install solutions before attempting to configure individual connectors — the connectors do not appear in the Data connectors list until their parent solution is installed.

Navigate to Microsoft Sentinel → Content management → Content hub in the Defender portal.

Install the following solutions in priority order:

Priority 1 — Microsoft Security Products

Content Hub Solution	Connector it installs	What it ingests
Microsoft Defender XDR	Microsoft Defender XDR	All XDR incidents, alerts, advanced hunting data, raw event tables (EmailEvents, DeviceProcessEvents, IdentityLogonEvents, etc.)
Microsoft Entra ID	Microsoft Entra ID	Sign-in logs, audit logs, provisioning logs, risk events
Microsoft 365	Microsoft 365	Exchange/SharePoint/Teams audit events, DLP alerts
Azure Activity	Azure Activity	Azure control plane operations (resource creation, deletion, RBAC changes)
Microsoft Defender for Cloud	Microsoft Defender for Cloud	Azure resource security alerts

Priority 2 — Infrastructure

Content Hub Solution	Connector it installs	What it ingests
Azure Firewall	Azure Firewall	Network traffic logs, threat intelligence hits, IDPS alerts
Azure Key Vault	Azure Key Vault	Key access and management audit events
Azure Storage	Azure Storage Account	Storage access logs for sensitive data stores
Windows Security Events	Windows Security Events via AMA	Windows Event Log from servers (via Azure Monitor Agent)

Priority 3 — Non-Microsoft Sources (Syslog / CEF)

Content Hub Solution	Connector it installs	What it ingests
Common Event Format	CEF via AMA	On-premises firewalls (Palo Alto, Fortinet, Check Point), network devices that emit CEF-formatted logs
Syslog	Syslog via AMA	Linux servers, appliances with raw syslog output, any source that can forward syslog

Both solutions install a data connector whose configuration pane walks through AMA installation, Linux forwarder deployment, and Data Collection Rule creation. Install the solution first, then configure the connector in the Data connectors blade.

Common sources routed through CEF or Syslog:

• On-premises firewalls (Palo Alto, Fortinet, Check Point, SonicWall)
• Network devices (switches, routers, wireless controllers)
• Linux servers
• Any appliance that can forward syslog or CEF

For all Content Hub solutions: select the solution → Install → wait for installation to complete before moving to the next.

Step 2: Configure each data connector

After the Content Hub solutions are installed, the connectors appear in Microsoft Sentinel → Configuration → Data connectors. Each connector now shows a status of Not connected. Open each connector and follow its configuration pane:

1. Microsoft Defender XDR — in the unified Defender portal, this often does not appear as a connector card in the Data connectors blade. The Sentinel-to-Defender integration is handled through the platform unification rather than through a traditional data connector. If your Sentinel workspace shows Connected under the Defender portal's Microsoft Sentinel settings, XDR incident and alert sync is already active through the unified platform — no connector configuration required.

   To verify:

   • Defender portal → System → Settings → Microsoft Sentinel — confirm your workspace shows as Connected.
   • Once at least one XDR workload (MDE, MDO, MDI, or MDCA) is onboarded, run SecurityIncident | take 10 and SecurityAlert | take 10 in Sentinel → Logs to confirm data is flowing.

   If you do see a Microsoft Defender XDR connector card (older tenants or certain configurations may still show it), open it and click Connect incidents & alerts. Optionally enable raw event-table ingestion (EmailEvents, DeviceProcessEvents, etc.) for advanced hunting in Sentinel — raw tables increase ingestion volume and cost, so enable selectively based on your hunting and compliance needs.

   Note: this connector only produces data once at least one XDR workload is onboarded. On a fresh workspace with no XDR workloads, the SecurityIncident and SecurityAlert tables will not exist yet — this is expected, not a configuration error.

2. Microsoft Entra ID — select which log categories to enable: Sign-in logs, Audit logs, Non-interactive sign-in logs, Service principal sign-in logs, Managed identity sign-in logs, Provisioning logs, ADFS sign-in logs (if applicable), and Risky users / Risk detections (requires Entra ID P2). Enable all categories relevant to your CMMC evidence requirements. Data appears within 5 minutes — validate with SigninLogs | take 10.

3. Microsoft 365 — select workloads: Exchange, SharePoint, Teams. Enable all three for CMMC audit coverage. Under Advanced Options, you will be prompted to enable User and Entity Behavior Analytics (UEBA) — enable it (see the UEBA note below). M365 audit logs can take 15–30 minutes to appear. Validate with OfficeActivity | take 10.

4. Azure Activity — this connector may not appear as a card in the Data connectors blade. Configure it directly through subscription diagnostic settings:

   1. Azure portal → Subscriptions → select your Azure Government subscription.
   2. Activity log (left nav) → Export Activity Logs (or Diagnostic settings).
   3. Click Add diagnostic setting.
   4. Name: diag-activity-to-sentinel.
   5. Under Category details, check all categories: Administrative, Security, ServiceHealth, Alert, Recommendation, Policy, Autoscale, ResourceHealth.
   6. Under Destination details, check Send to Log Analytics workspace → select your Sentinel workspace.
   7. Click Save.
   8. Data starts flowing within 5–10 minutes. Validate with AzureActivity | take 10 — resource group and workspace creation events from the current session should appear.

5. Microsoft Defender for Cloud — in GCC High, this often does not appear as a connector card in the Data connectors blade even after the Content Hub solution is installed. Defender for Cloud alerts and compliance data flow into Sentinel through the Continuous export configuration on the Defender for Cloud subscription itself (see Step 3 — Prereq 3 below), not through a traditional Sentinel data connector. If you do see a Defender for Cloud connector card, open it and enable bi-directional alert sync; otherwise rely on continuous export as the primary path.

6. Azure Firewall — configure via Azure Firewall diagnostic settings pointing to the Sentinel workspace. Send both Azure Firewall Application Rule Logs and Azure Firewall Network Rule Logs.

7. Infrastructure connectors (Key Vault, Storage, Windows Security Events) — each uses diagnostic settings or Data Collection Rules (DCRs) pointing to the workspace. Follow the configuration pane for each.

Use Sentinel → Logs for KQL, not the Defender portal top-level search bar

The Defender portal's top-level search bar is a global navigation search, not a KQL surface — it will mangle your queries. Use Sentinel → Logs (or equivalently, Log Analytics workspace → Logs in the Azure portal) for direct KQL. Every KQL block in this chapter assumes that editor.

After connecting, allow 15–30 minutes for initial data to appear. Each connector bullet above names the table to validate against; use those per-connector | take 10 queries rather than a workspace-wide scan.

Microsoft 365 connector — what each workload covers

The connector exposes three workload checkboxes (Exchange, SharePoint, Teams), but they don't map 1:1 to the products users see. This table makes the routing explicit so you can answer client questions about coverage before they ask:

Workload checkbox	What lands in OfficeActivity	What does NOT come through this pipe
Exchange	Mailbox audit events, mail flow rules, transport changes, role assignments, eDiscovery actions, MFA-on-mailbox events	Message tracking (separate Get-MessageTrace stream); raw mail content (eDiscovery only)
SharePoint	SharePoint site operations plus OneDrive activity — file access, sharing changes, sync operations, permission grants, anonymous link creation. OneDrive does not have its own checkbox; it rides on the SharePoint workload as OfficeActivity | where Workload == "OneDrive".	Full file content scanning (Purview DLP / auto-labeling, not OfficeActivity)
Teams	Team / channel create-modify-delete, member adds and removes, federation events, app installs, settings changes, guest invites — OfficeActivity | where Workload == "MicrosoftTeams"	Chat message content (Microsoft Graph Export API or eDiscovery hold only); call records (Graph callRecords API); call quality (Call Quality Dashboard)

For CMMC L2 audit / control evidence the three checkboxes together are sufficient — they cover the "who did what to which CUI workload" questions an assessor asks. Teams chat content and call records are out of scope for CMMC L2 by default; ingest them via the relevant Graph APIs as a separate workstream only if a contractual flow-down or insider-risk policy explicitly requires them.

Common omissions worth raising with clients

The M365 + Defender + Azure Activity connectors cover most of the CMMC L2 audit surface, but a few signals clients sometimes assume are in Sentinel by default actually require additional ingestion. Confirm which of these the client expects to query in Sentinel before locking down the connector list — each one missing from the assumed list is an SSP-narrative gap that surfaces during audit scoping.

Source	How to ingest if needed
Power Platform audit logs (Power Apps, Power Automate, Dataverse)	Install the Microsoft Power Platform Content Hub solution; not part of the M365 connector
Dynamics 365 audit	Install the Microsoft Dynamics 365 Content Hub solution; separate from M365
On-premises Active Directory (DC events, Kerberos, LDAP)	Install Microsoft Defender for Identity (MDI) sensors on DCs, or stream the Security event log via AMA + DCRs
Exchange Online message tracking	Separate Get-MessageTrace PowerShell pull; not in OfficeActivity
Raw Defender XDR event tables (EmailEvents, DeviceProcessEvents, IdentityLogonEvents)	Free benefit covers them, but the Defender XDR connector must explicitly opt in to raw-table ingestion (off by default)
MDE Live Response session recordings	Stored in MDE; not exported to Sentinel — pull via Defender API if forensic capture is required
Teams chat content / call records / call quality	See the workload-coverage table above — three separate Graph or admin-center pipelines

UEBA (User and Entity Behavior Analytics)

When configuring the Microsoft 365 connector's Advanced Options, Sentinel prompts you to enable UEBA. Enable it. UEBA builds behavioral baselines per user and entity by analyzing sign-in patterns, resource access, and activity volume, then flags anomalies (impossible travel, atypical access, unusual data movement) as enriched incidents.

Why it matters for CMMC:

• NIST 3.14.6 (monitor organizational systems) and 3.14.7 (identify unauthorized use) are directly served by behavioral anomaly detection.
• When a C3PAO asks "how do you detect compromised accounts or insider threats?", UEBA is the answer — it produces the evidence that raw log ingestion alone does not.

What it costs: UEBA analyzes data you are already ingesting (Entra sign-in logs, M365 activity, Azure activity). It creates a few additional tables (BehaviorAnalytics, UserAccessAnalytics, UserPeerAnalytics) but the storage increment is small relative to the source tables. You are not paying for a new data source — you are paying for ML enrichment on existing data.

Expectation: UEBA needs 14–21 days of ingested data to build meaningful behavioral baselines. Until then, anomaly scores will be noisy or absent. Do not evaluate its usefulness until it has had three weeks to learn.

Step 3: Enable CMMC 2.0 posture assessment

The Microsoft Sentinel: CMMC 2.0 solution provides compliance posture assessment — not threat detection. It ships two analytics rule templates and a compliance workbook. Detection rules come from the individual product solutions installed in Step 1 (Entra ID, M365, Defender XDR, etc.).

The CMMC posture rules query the SecurityRegulatoryCompliance table, which is populated by Microsoft Defender for Cloud. Complete Prereq 1 → Prereq 2 → Prereq 3 so the table exists and begins receiving data, then install the solution and enable its rule templates. The 12–24h wait only affects when tiles render and posture incidents first fire — you can complete the install, rule-template creation, workbook saves (Step 4), and the client-demo artifact captures (Step 5) immediately.

Prereq 1: Enable Defender for Cloud plans

The Workload Protection page in Defender for Cloud may show "your subscriptions are not protected by Microsoft Defender for Cloud" with an Enable button that launches a blank Getting Started page. Skip the Getting Started page entirely — it is a known GCC High UX issue. Enable plans through Environment settings:

1. Azure portal (portal.azure.us) → Microsoft Defender for Cloud.
2. Management → Environment settings in the left nav.
3. Expand the hierarchy until your Azure Government subscription appears. Click the subscription name (not the expand arrow).
4. Enable the Defender plans relevant to your environment:

Plan	Recommendation for AVD / CMMC	Why
Foundational CSPM	On — automatic and free	Baseline capability enabled by default on every subscription. Populates MCSB only — it does not run non-MCSB compliance standards. Cannot be turned off.
Defender CSPM	On — required for CMMC/NIST posture assessment	The paid CSPM plan. Non-MCSB compliance standards (NIST SP 800-171, CMMC, FedRAMP, etc.) only run under Defender CSPM. Without it, enabling NIST SP 800-171 in Prereq 2 appears to succeed but produces no data in SecurityRegulatoryCompliance and no tiles in the CMMC workbook. This is the single most common trap in Sentinel-for-CMMC deployments.
Defender for Servers (P1 or P2)	On if you have servers (AVD session hosts count)	VM vulnerability assessment, adaptive application controls, file integrity monitoring
Defender for Resource Manager	On	Monitors Azure management-plane operations (suspicious ARM calls, control-plane lateral movement)
Defender for Key Vault	On if using Key Vault	Anomalous access to secrets and certificates
Defender for Storage	On if using storage accounts	Malware upload detection, anomalous access patterns
Defender for DNS	On	Detects communication from your VNet to known-bad domains
Databases, App Service, Containers	Off unless you run those workloads	Don't pay for plans covering workloads you don't run

5. Click Save at the top.

Prereq 2: Enable the NIST SP 800-171 compliance standard

Defender CSPM must be enabled first

Before toggling NIST on, confirm Defender CSPM is On in the subscription's Defender plans (Prereq 1 table). Toggling NIST while only Foundational CSPM is active appears to succeed — the standard shows as enabled in the UI — but nothing assesses the subscription and SecurityRegulatoryCompliance never receives NIST rows no matter how long you wait.

1. Defender for Cloud → Regulatory compliance (left nav).
2. Click Manage compliance standards at the top of the blade (label may also appear as "Manage compliance policies" in some portal versions — same destination).
3. Select your Azure Government subscription.
4. Toggle NIST SP 800-171 Rev. 2 to On.
5. You will be prompted to configure parameters for two Azure Policy built-ins that evaluate VM local Administrators group membership:
   • "Audit Windows machines missing any of specified members in the Administrators group" — inclusion list. Specify the Entra group containing authorized VM administrators (e.g., EID_VM_Administrators).
   • "Audit Windows machines that have the specified members in the Administrators group" — exclusion list. Specify accounts or groups that must not have local admin rights on VMs.
6. These parameters map to NIST control 3.1.1 (Limit system access to authorized users). The parameters are optional — the standard assigns regardless. If you do not have an approved admin group defined yet, leave the parameters empty and populate them later. The policy will audit only what you configure.
7. Click Save.

Prereq 3: Configure continuous export to the Sentinel workspace

1. Defender for Cloud → Environment settings → [your Azure Government subscription] → Continuous export → + Add continuous export.
2. Configure the dialog:
   • Export name: export-defender-to-sentinel (or similar).
   • Export target: Log Analytics workspace (not Event hub).
   • Exported data types: check all four — Security recommendations, Security alerts, Secure score, and Regulatory compliance. The last one populates SecurityRegulatoryCompliance; if unchecked, no posture data flows regardless of other settings.
   • Export frequency: Streaming for alerts and recommendations; Regulatory compliance is Snapshots-only (fine).
   • Target workspace: your Azure Government subscription → rg-sentinel-prod-usgovva → law-sentinel-prod-usgovva.
3. Scroll through the entire dialog before saving. The UI will accept a rule with unchecked data-type boxes without error — the rule appears Enabled in the list but produces no data. Re-open the saved rule and verify every field, especially the four Exported data types checkboxes.

Data begins flowing in 15–30 minutes for most types, but Regulatory compliance specifically takes 12–24 hours — Defender for Cloud's initial compliance scan must run before there's anything to export. Don't wait for it. Proceed immediately to the install below and complete Steps 4 and 5 — install, rule templates, workbook saves, and the full client-demo deliverable all work without NIST data. Only CMMC workbook tile rendering and first-fire of the two CMMC posture rules depend on that data, and Step 6 verifies both.

Install the solution and enable the rule templates

This subsection installs the CMMC 2.0 solution and creates the two posture rule templates. The CMMC compliance workbook itself is saved and configured later in Step 4 → Save and configure the CMMC 2.0 workbook alongside the other client-demo workbooks.

1. Microsoft Sentinel → Content management → Content hub → search for CMMC 2.0 → Install.
2. After installation, go to Microsoft Sentinel → Configuration → Analytics → Rule templates → filter by source CMMC 2.0. You will see two posture rule templates:
   • CMMC 2.0 Level 1 (Foundational) Readiness Posture — evaluates the 17 Level 1 practices.
   • CMMC 2.0 Level 2 (Advanced) Readiness Posture — evaluates the 110 Level 2 practices.
3. Create both rules. Enable Level 1 immediately for clients doing L1 self-attestation; enable Level 2 for clients targeting L2 assessment. No harm enabling both early — Level 2 shows gaps you will close during implementation.

Known issue: incorrect MITRE ATT&CK mapping on the posture rule templates

The default CMMC posture rule templates may carry a MITRE ATT&CK mapping (e.g., Discovery / T1082 System Information Discovery) that does not reflect the rule's actual purpose — the rules assess compliance posture, not adversary activity. This is a metadata labeling error in Microsoft's template. It does not affect rule function, but incident triage dashboards will show an incorrect MITRE tactic for posture-generated incidents. Consider editing the MITRE mapping on the created rule to remove the inaccurate tactic, or add a comment in the rule description noting that this is a posture assessment, not a detection.

Step 4: Save workbook templates for client demonstration

Save each workbook below from Microsoft Sentinel → Threat management → Workbooks → Templates. Open to verify it renders — first open may take 30–60 seconds while queries execute against your workspace. The CMMC 2.0 workbook requires additional parameter configuration (covered in its own subsection below); the rest are save-open-screenshot. The set is grouped by client-demo readiness.

Saving parameter changes requires the Azure portal

The Defender portal's workbook viewer is read-only — the toolbar exposes only Open in Azure, Share, Refresh, and Auto-refresh. Parameter changes you make while viewing in the Defender portal are per-session only. To persist parameter selections as the workbook's new defaults, click Open in Azure in the toolbar → in the Azure portal click Edit → set parameter values → Done Editing. The saved defaults then apply when the workbook is opened from either portal.

Tier 1 — Save now, renders demo-worthy data today. These are the client-facing wins for the interim status update:

Workbook	Why it's demo-gold
Microsoft Entra ID Sign-in Logs	Sign-in map, MFA status, Conditional Access outcomes. Strongest visual in the library. Evidence for AU.L2-3.3.1, SI.L2-3.14.6.
Microsoft Entra ID Audit Logs	Role changes, directory operations, application management. Evidence for AC.L2-3.1.5, AC.L2-3.1.7, AU.L2-3.3.2.
Conditional Access SISM (Summaries, Insights, Security & Monitoring)	CA policy outcomes visualized — high-impact client visual tied directly to the Conditional Access chapter.
Office 365	M365 activity panorama — Exchange, SharePoint, Teams in one consolidated view.
SharePoint & OneDrive	External-sharing detail. Direct evidence for AC.L2-3.1.3 (CUI flow control).

Tier 2 — Save, but expect sparse content until Defender XDR signal or UEBA baselines accumulate. Useful dashboards once incident telemetry or behavioral analytics mature; save them now so they're configured and ready:

• Identity & Access — leans heavily on UEBA-derived tables (IdentityInfo, BehaviorAnalytics, UserAccessAnalytics). UEBA needs 14–21 days of ingested data to build baselines; until then the workbook renders empty even with valid sign-in and audit data in the workspace. Revisit at the week-3 check-in.
• Exchange Online — populates from OfficeActivity for mailbox audit events; rich panels need MDO alerts to fire.
• Microsoft Defender for Office 365 Detection and Insights — requires MDO incident telemetry. Dashboard is ready when alerts arrive.

Tier 3 — Defer until preconditions are met. Save each when the listed condition becomes true, not before:

Workbook	Save when
CybersecurityMaturityModelCertification(CMMC)2.0	Save and configure in the subsection below — waiting for NIST 800-171 Rev. 2 data to populate SecurityRegulatoryCompliance before tiles render.
Azure Firewall	Azure Firewall is deployed in the subscription and firewall diagnostic settings stream to the workspace.
Azure Firewall Structured Logs	Structured log format is enabled on the firewall (preview/GA-dependent).
Azure Key Vault Security	At least one Key Vault has diagnostic settings sending AuditEvent to the workspace.
Common Event Format Logs Overview	A network appliance or third-party source is shipping CEF to the workspace via AMA.
Syslog Connectors Overview Workbook	A Linux forwarder or appliance is sending Syslog via AMA.
Event Analyzer	Power-user tool for exploring raw event payloads — not client-facing. Skip for demo deliverables.
Linux Machines	Linux VMs are onboarded to the workspace via AMA.
Microsoft Defender for Endpoint	At least one device is fully onboarded to MDE and generating DeviceProcessEvents.
Microsoft Defender for Identity	Skip permanently for cloud-only tenants — MDI requires on-premises AD sensor deployment.

Save the CMMC 2.0 workbook (configuration deferred to Step 6)

The CMMC compliance workbook depends on NIST SP 800-171 Rev. 2 rows in SecurityRegulatoryCompliance — data that takes 12–24 hours to populate after Prereq 3. Save the template now so it's available; opening it and setting parameters before the data lands triggers per-tile "parameter not set" errors that resolve only after the first Defender for Cloud assessment pass. The save is a one-click operation; the open-and-configure flow happens in Step 6 → Finalize the CMMC workbook and posture rules.

1. Go to Microsoft Sentinel → Threat management → Workbooks. Switch to the Templates tab (not "My workbooks" — installed workbooks start there).
2. Search for CMMC → the CybersecurityMaturityModelCertification(CMMC)2.0 template card appears.
3. Click the Save button on the template card — before clicking View template. Save is available from the Templates tab but hidden from the live template preview. Clicking View template first puts you into preview mode where only Refresh and Auto refresh are exposed; you have to return to Templates and click Save directly on the card.
4. Select the Azure Government region matching your Sentinel workspace (USGov Virginia or USGov Texas).

Stop here. The workbook is saved and visible in My workbooks, but unconfigured. Continue to Step 5 to assemble the immediate-operation deliverable; return to this workbook in Step 6 once the discovery query confirms NIST 800-171 data has landed.

NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 are the same 110 practices

CMMC 2.0 Level 2 was built to adopt NIST SP 800-171 Rev. 2 wholesale — identical control set, no additions. This is why Defender for Cloud typically does not offer CMMC 2.0 Level 2 as a separate assessable standard in its Manage Compliance Standards list — it would be literally duplicative. What you do see in the catalog:

• NIST SP 800-171 Rev. 2 — the correct standard to enable for CMMC Level 2 assessment.
• CMMC Level 3 — the enhanced-requirements tier (adds NIST SP 800-172 practices on top of Level 2). Only relevant for clients targeting Level 3.

The CMMC workbook renders from NIST 800-171 data — same controls, same evidence, just differently labeled in the source table. This equivalence is also why the workbook's CMMC 2.0 Level parameter (encountered in Step 6) defaults to All and offers no Level 1 / Level 2 alternatives — Defender for Cloud doesn't ship those as discrete standards, so the dropdown has nothing to populate with.

"Solution" vs. "workbook" — the same artifact, two layers

When you open the saved CMMC workbook from My workbooks in Step 6, its body header introduces itself with marketing copy starting "This solution enables Compliance Teams, Architects, SecOps analysts and Consultants..." — which is accurate but easy to misread as "this is a solution, not a workbook." Both labels describe different layers of the same package.

Sentinel content ships through Content Hub solutions — bundles that typically include a workbook plus a set of analytics rule templates, and sometimes hunting queries or playbooks. The CMMC 2.0 solution installed in Step 1 bundles two artifacts referenced throughout this chapter:

• The CMMC 2.0 workbook (saved here in Step 4, configured in Step 6).
• The two CMMC 2.0 Readiness Posture analytics rule templates (turned into rules in Step 3).

The artifact you save and edit is a workbook (Azure Workbooks resource type). The descriptive prose introducing it was authored once at the solution level by Microsoft and rendered inside the workbook header — which is why the workbook describes itself as a "solution."

Step 5: Demonstrate immediate operation of Sentinel and key workbooks

The eight queries below produce audit evidence for specific CMMC Level 2 practices. Save them once, screenshot their results, and present them alongside the Tier 1 workbooks saved in Step 4 for a complete client deliverable. This demonstrates same-day value from the Sentinel deployment and reassures the client that compliance-relevant telemetry is already flowing — independent of the 12–24h wait for NIST 800-171 assessment data to populate the CMMC workbook tiles.

The deliverable combines three artifact categories, assembled in the order below.

1. Plumbing-evidence portal screenshots — prove the deployment is operational:

1. Defender portal → Microsoft Sentinel → Configuration → Data connectors → filter by Connected status — shows the active connectors (Entra ID, Microsoft 365, Azure Activity, Defender XDR, etc.), direct proof the wiring is live.
2. Defender portal → Microsoft Sentinel → Content management → Content hub → Installed filter — the list of installed solutions establishes deployment breadth.
3. Defender portal → Microsoft Sentinel → Configuration → Analytics → Rule templates — filtered count of available templates per source, proving detection coverage is available to activate.
4. Azure portal → Log Analytics workspaces → law-sentinel-prod-usgovva → Usage and estimated costs — GB/day ingestion chart and per-table breakdown, proving data is actively flowing into the workspace.

2. Workbook narrative for the client deck (uses only Tier 1 workbooks saved in Step 4) — this sequence answers five separate questions a compliance stakeholder cares about, mapping cleanly to CMMC practice families AC, AU, CM, and SI:

1. Sign-in Logs (global sign-in map) — who is signing in.
2. Conditional Access SISM (policy outcomes) — whether CA enforced correctly.
3. Audit Logs (role activations, directory changes) — what administrators did.
4. SharePoint & OneDrive (external sharing) — how CUI is flowing externally.
5. Office 365 (cross-workload activity) — the overall M365 activity envelope.

3. KQL evidence queries — eight saved queries that each produce audit evidence for specific CMMC Level 2 practices. Screenshot each with results rendered for the client deliverable; the mapping table below doubles as a one-page client handout:

Saved name (Category: Security, Label: CMMC L2 Demo)	CMMC L2 practices
Sign-in Volume by Country (7d)	AU.L2-3.3.1, SI.L2-3.14.6
Privileged Role Activations (30d)	AC.L2-3.1.5, AC.L2-3.1.7, AU.L2-3.3.2
Failed Sign-ins — Top 20 Users (7d)	AC.L2-3.1.8, SI.L2-3.14.6, SI.L2-3.14.7
Azure Control-Plane Activity by Caller (7d)	CM.L2-3.4.3, AU.L2-3.3.1
OfficeActivity - Events by RecordType (7d)	AU.L2-3.3.1
External Sharing Events - Sharepoint + Teams	AC.L2-3.1.3, AC.L2-3.1.22
MIP Label Activity - Exchange (7d)	MP.L2-3.8.1, SC.L2-3.13.11
DLP Policy Matches - Exchange (7d)	AC.L2-3.1.3, MP.L2-3.8.7, SC.L2-3.13.8

Save each under Sentinel → Logs → Save → Query (Shared) using the settings below.

Save-dialog settings for all eight queries:

• Name: the recommended name shown in each comment header.
• Description: paste the Evidence for: practice list from the comment header (e.g., Evidence for AU.L2-3.3.1, SI.L2-3.14.6).
• Category: Security — the Category dropdown is a fixed picklist; pick Security for all eight.
• Labels: CMMC L2 Demo — Labels is the free-text field that creates the custom grouping. Typing this on the first save creates the label; reuse it on the remaining seven so all eight queries share the label and surface together when filtering by label in the saved-query pane.
• Save to: ensure the workspace-shared option is selected (not personal/"my queries"), so the client team can see the saved queries too.

Saving queries in Sentinel is non-intuitive — five stacked gotchas

Sentinel's Save Query experience has five quirks that together make it easy to "lose" a query you just saved. Know these up front and you won't waste time hunting:

1. Category is a fixed picklist; Labels is free-text. The naming feels inverted — in most systems Categories are customizable and Labels are fixed tags; in Sentinel's Save dialog it's the reverse. Pick a Category from the fixed list (Security for compliance/evidence work) and use Labels for custom groupings like CMMC L2 Demo.
2. Saves land in a Query Pack resource whose own blade does not show queries. The DefaultQueryPack-{region} resource opens to Resource Visualizer; there is no "list of queries in this pack" page at the resource level in the portal. Don't hunt for your query there — it's not a bug, it's the blade design.
3. The Queries pane in the Logs editor hides workspace-authored queries by default. The Source / Provider filter defaults to Microsoft / Solutions built-ins, which excludes your Query Pack saves. Toggle Source → Query Packs (or Workspace) to see what you actually saved.
4. Group by defaults to Category, not Labels. Your label-based grouping won't appear until you change Group by: Category to Group by: Labels in the Queries pane.
5. Forward slashes are not allowed in saved query names. The Save dialog silently rejects the save (or strips the name). Use +, -, or & instead — e.g., External Sharing Events - Sharepoint + Teams, not External Sharing Events — SharePoint/Teams.

Workflow that works every time

Sentinel → Logs → open the Queries pane (icon on left side of the editor) → set filter Source = Query Packs → set Group by = Labels → the CMMC L2 Demo group appears with exactly the queries saved under that label.

// Sign-in volume by country over last 7 days — quickly shows global identity activity
// Save as: Sign-in Volume by Country (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AU.L2-3.3.1 (create and retain audit records),
//               SI.L2-3.14.6 (monitor organizational systems for unauthorized use)
SigninLogs
| where TimeGenerated > ago(7d)
| summarize SignInCount = count() by Location, bin(TimeGenerated, 1d)
| render timechart

// Privileged role activations in the last 30 days (PIM or direct assignments)
// Save as: Privileged Role Activations (30d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AC.L2-3.1.5 (principle of least privilege),
//               AC.L2-3.1.7 (prevent non-privileged users executing privileged functions),
//               AU.L2-3.3.2 (ensure actions of individual users can be uniquely traced)
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName contains "Add member to role"
| project TimeGenerated,
    Actor = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName),
    OperationName,
    TargetRole = tostring(TargetResources[0].displayName)
| sort by TimeGenerated desc

// Failed sign-ins — top 20 users (potential password spray / brute force signal)
// Save as: Failed Sign-ins — Top 20 Users (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AC.L2-3.1.8 (limit unsuccessful logon attempts),
//               SI.L2-3.14.6 (monitor unauthorized use),
//               SI.L2-3.14.7 (identify unauthorized use)
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType !in ("0", "50140")  // 50140 = MFA interrupt, not a true failure
| summarize FailedCount = count() by UserPrincipalName, Location
| top 20 by FailedCount desc

// Azure control-plane changes by caller — admin-activity board
// Save as: Azure Control-Plane Activity by Caller (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: CM.L2-3.4.3 (track, review, approve/disapprove, and log configuration changes),
//               AU.L2-3.3.1 (create and retain audit records for control-plane operations)
AzureActivity
| where TimeGenerated > ago(7d)
| where ActivityStatusValue == "Success"
| where OperationNameValue !endswith "/read"  // filter noisy read ops
| summarize Operations = count() by Caller, OperationNameValue
| top 50 by Operations desc

// OfficeActivity events by RecordType — workload-level M365 audit summary
// Run first to see which workloads (Exchange, SharePoint, Teams, MIP, DLP) are emitting audit data
// Save as: OfficeActivity - Events by RecordType (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AU.L2-3.3.1 (create and retain audit records across M365 workloads)
OfficeActivity
| where TimeGenerated > ago(7d)
| summarize Events = count() by RecordType
| top 20 by Events desc

// External sharing activity from SharePoint / Teams
// Save as: External Sharing Events - Sharepoint + Teams    |  Category: Security  |  Label: CMMC L2 Demo
// Note: forward slashes are not allowed in saved query names — use "+" or another separator.
// Evidence for: AC.L2-3.1.3 (control CUI flow in accordance with approved authorizations),
//               AC.L2-3.1.22 (control information posted or processed on publicly accessible systems)
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType in ("SharePoint", "SharePointSharingOperation")
| where Operation in ("AnonymousLinkCreated", "SharingInvitationCreated", "AddedToGroup")
| project TimeGenerated, UserId, Operation, OfficeObjectId, Site_Url, TargetUserOrGroupName
| top 100 by TimeGenerated desc

// MIP label activity — sensitivity labels being applied or changed on Exchange items
// Save as: MIP Label Activity - Exchange (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: MP.L2-3.8.1 (protect CUI on media, including digital),
//               SC.L2-3.13.11 (employ cryptographic protection of CUI — labels drive encryption)
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType == "MIPLabel"
| summarize Events = count() by Operation, UserId
| top 20 by Events desc

// DLP policy matches on Exchange — CUI flow controls enforcing today
// Save as: DLP Policy Matches - Exchange (7d)    |  Category: Security  |  Label: CMMC L2 Demo
// Evidence for: AC.L2-3.1.3 (control CUI flow in accordance with approved authorizations),
//               MP.L2-3.8.7 (control use of removable media / external transport),
//               SC.L2-3.13.8 (implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission)
OfficeActivity
| where TimeGenerated > ago(7d)
| where RecordType == "ComplianceDLPExchange"
| summarize Events = count() by Operation, UserId
| top 20 by Events desc

Step 6: Verify NIST 800-171 data arrival

12–24 hours after Prereq 3, run this discovery query in Sentinel → Logs to confirm NIST SP 800-171 data has landed in SecurityRegulatoryCompliance:

SecurityRegulatoryCompliance
| summarize count() by ComplianceStandard

Interpret the output:

Output	Meaning
Zero rows	Continuous export isn't yet producing SecurityRegulatoryCompliance data. Re-verify Prereq 3's data-type checkboxes — the most common cause is that Regulatory compliance was never actually checked.
Only Microsoft-cloud-security-benchmark appears after 24h	Defender CSPM is not enabled on the subscription. MCSB is the only compliance standard the free Foundational CSPM plan runs. Return to Prereq 1 and toggle Defender CSPM to On, then wait another 12–24h — NIST rows arrive on the next assessment pass after enablement, not immediately. This is the canonical symptom of the Defender CSPM trap.
NIST-SP-800-171-Rev-2 (or similar) appears with any count	NIST data is live. Proceed to the finalization tasks below.

Optional: force an immediate assessment pass

Skip this subsection if NIST-SP-800-171-Rev-2 already appears in the discovery query above. The scan only helps when data hasn't yet arrived — running it once data is live just re-evaluates the same initiative and overwrites the result with itself, taking 30 minutes to several hours of compute for no functional change.

When the scan is useful: you've just enabled Defender CSPM or toggled the NIST standard and don't want to wait 12–24 hours for the first scheduled pass, or you corrected a Prereq 1 or 3 misconfiguration and want a fresh pass on-demand. The scan triggers an Azure Policy compliance evaluation, which re-evaluates every policy initiative assigned to the subscription — what Defender for Cloud's regulatory compliance view is built from.

Prerequisite: Defender CSPM must already be On and the NIST standard already toggled. Triggering the scan beforehand has no effect — there is no NIST initiative assigned yet.

From Azure Cloud Shell (inside portal.azure.us) or a local PowerShell with Connect-AzAccount -Environment AzureUSGovernment:

Set-AzContext -Subscription "<your-subscription-id>"
Start-AzPolicyComplianceScan -AsJob

Or via Azure CLI:

az cloud set --name AzureUSGovernment
Connect-AzAccount -TenantId "<your-tenant-id>"
az account set --subscription "<your-subscription-id>"
az policy state trigger-scan --no-wait

Expected timing after triggering: Microsoft describes the scan itself as "a long time to run" — 30 minutes to several hours, depending on subscription size. After it completes, Defender for Cloud still has to aggregate the policy-state results into the regulatory compliance view, and continuous export still has to snapshot that data to Log Analytics. Realistic end-to-end: 2–6 hours versus the default 12–24 hours. Re-run the discovery query every hour or so until NIST-SP-800-171-Rev-2 appears.

Finalize the CMMC workbook and posture rules

Once NIST data is live, finalize the two CMMC artifacts saved earlier — the CMMC workbook from Step 4 and the two CMMC 2.0 Readiness Posture analytics rules from Step 3:

1. Open the saved CMMC workbook — Defender portal → Microsoft Sentinel → Threat management → Workbooks → My workbooks → click CybersecurityMaturityModelCertification(CMMC)2.0. A pane opens with three buttons: View saved workbook, View template, Delete. Click View saved workbook — View template opens the read-only original and does not honor your parameters.

2. Confirm workspace-scope parameters at the top of the workbook — The parameter row at the top of the workbook contains three workspace-scope parameters:

   • Subscription: your Azure Government subscription.
   • Workspace: your Sentinel workspace.
   • Time range: Last 7 days (or whatever range you want for initial render).

   In a fresh save these typically already target the right workspace. The CMMC 2.0 Level parameter is not in this top row — it's a section-scoped parameter that only renders after a Control Family column is expanded (instruction 3).

3. Expand a Control Family column to reveal tiles and the Level parameter — The workbook body presents two columns of Control Family group checkboxes (column 1: Executive Summary, Controls Crosswalk, Access Control, etc.; column 2: Maintenance, Media Protection, Personnel Security, Physical Protection, etc.). Click the master Control Family checkbox at the top of either column. The column expands and a section appears below it containing per-tile data visualizations and the CMMC 2.0 Level dropdown — already defaulting to All. Confirm Level = All; do not change it. All is the only valid setting because Defender for Cloud doesn't ship CMMC 2.0 Level 1 / Level 2 as discrete standards (see the equivalence note in Step 4).

4. Verify Control Family tiles render and capture screenshot — With the column expanded and Level = All, per-tile queries resolve against NIST-tagged rows in SecurityRegulatoryCompliance and produce evidence for each practice family. Capture a screenshot to supplement the client deliverable from Step 5.

5. (Optional) Persist a top-row parameter default — Skip this unless you want to change the saved default for Time range (e.g., Last 30 days instead of Last 7 days). Only the top-row parameters can be persisted to the saved workbook resource; the Control Family expand state and the section-scope Level dropdown are per-session interactions — every time anyone reopens this workbook, the column will be collapsed and Level will default to All. This is by design in Azure Workbooks.

   To change a top-row default:

   • Click Open in Azure in the workbook toolbar to switch from the Defender portal's read-only view to the Azure portal's editable view.
   • Click Edit to enter edit mode and change the parameter.
   • Click the Save icon (floppy disk) in the workbook toolbar to persist the new default.
   • Click Done Editing to exit edit mode.

6. Confirm posture rules have fired — Defender portal → Microsoft Sentinel → Configuration → Analytics → open each of the two CMMC 2.0 Readiness Posture rules from Step 3 → verify recent execution time and any incidents produced. If neither has run in the last hour, the scheduled query trigger hasn't fired yet; give it another scheduling cycle.

After Step 6 passes, the CMMC posture assessment surface is fully operational and the deliverable set is complete.

Step 7: Enable detection rule templates from product solutions

Threat detection rules do not come from the CMMC 2.0 solution — they come from the individual product Content Hub solutions installed in Step 1. Each solution ships its own analytics rule templates.

After the Content Hub solutions are installed, go to Microsoft Sentinel → Configuration → Analytics → Rule templates (no source filter). Browse or filter by source to see rule templates from each connected product:

Source	Example rule templates
Microsoft Entra ID	Modified domain federation trust settings, MFA Spamming followed by Successful login, Azure RBAC (Elevate Access), Suspicious application consent similar to O365 Attack Toolkit, Bulk Changes to Privileged Account Permissions
Microsoft 365	Malicious Inbox Rule, Mail redirect via ExO transport rule, Multiple users email forwarded to same destination, SharePointFileOperation via previously unseen IPs, Office Policy Tampering
Azure Activity	Resource deletion alerts, RBAC role assignment changes, policy modifications. The Azure Activity source only appears in the filter after the Azure Activity solution is installed from Step 1 → Priority 1; if you don't see it, install the solution first.
Microsoft Defender XDR	LSASS Credential Dumping with Procdump, Service Accounts Performing Remote PS, C2-NamedPipe, Imminent Ransomware, AV detections related to specific malware families. Templates are present immediately on solution install; rules only fire once MDE / MDO / MDI telemetry is flowing into the workspace.
CMMC 2.0	CMMC 2.0 Level 1 (Foundational) Readiness Posture (evaluates the 17 Level 1 practices) and CMMC 2.0 Level 2 (Advanced) Readiness Posture (evaluates the 110 Level 2 practices). Posture assessment, not threat detection — created and enabled in Step 3. Out of scope for this step.

Examples observed April 2026; Microsoft adds and removes templates over time, so this list is illustrative rather than canonical. Filter Rule templates by source in your own tenant for the live set.

Scheduled vs. NRT rule types

The Rule type column on the Rule templates page is mostly Scheduled or NRT (Near Real-Time) — Sentinel's two main analytics rule kinds.

• Scheduled runs a KQL query on an author-defined cadence (typically every 5 minutes to every 24 hours) against a configurable lookback window. The query can join across tables, summarize over time windows, and use the full KQL surface — most useful detections live here.
• NRT runs every minute against the last minute of data. To keep that cadence cheap across every workspace, NRT restricts queries to a single table with simple filtering — no multi-table joins, no cross-table summarize, no lookups against externaldata. Fires within ~1–2 minutes of an event landing.

Most templates are Scheduled because most useful detections need a wider window than one minute or need to correlate across tables (e.g., "5 failed sign-ins in 10 minutes followed by success" — Scheduled; "federation trust setting changed" — NRT). The template author chose the rule type; you cannot convert between them when enabling, only adjust the cadence and lookback within the type's allowed bounds.

Other rule types you may see less frequently — Microsoft Security (creates Sentinel incidents from alerts already generated by Microsoft security products; largely superseded by direct alert sync), Fusion (Microsoft's managed ML correlation engine, not customizable), Anomaly (ML behavioral anomaly detection, surfaced under the Anomalies tab), and Threat Intelligence (auto-matches incoming logs against TI feeds).

Minimum set to enable immediately — seven Microsoft Entra ID rule templates that fire on data you already have post-Step 2 (no MDE / MDO / Linux onboarding required). Ranked by attack-pattern severity and false-positive ratio:

#	Rule Template	Why it's in the minimum set	CMMC L2 mapping
1	Modified domain federation trust settings	Federation trust manipulation is a top-tier persistence TTP (the SolarWinds technique). An adversary who edits the trust can mint forged tokens and bypass MFA tenant-wide. Extremely low false-positive rate — federation trust changes are deliberate and rare.	AC.L2-3.1.5, AC.L2-3.1.7, IA.L2-3.5.3
2	Authentication Methods Changed for Privileged Account	Adversary adds their own MFA method (FIDO2 key, Authenticator app) to a compromised admin account for persistence after a phishing or token-replay compromise. Very high fidelity.	AC.L2-3.1.5, IA.L2-3.5.3
3	MFA Spamming followed by Successful login	Catches MFA fatigue / push-bombing attacks that ultimately succeed — currently a leading initial-access vector against MFA-enabled users.	IA.L2-3.5.3, SI.L2-3.14.6
4	Conditional Access - A Conditional Access user/group/role exclusion has changed	Adversary or insider excludes a backdoor account from CA enforcement to bypass MFA / device-compliance controls. High fidelity — CA exclusions are infrequent administrative actions.	AC.L2-3.1.5
5	Admin promotion after Role Management Application Permission Grant	Multi-step pattern: a service principal granted directory role permissions, then a user promoted via that principal. Specific to a documented adversary attack chain.	AC.L2-3.1.5, AC.L2-3.1.7
6	New User Assigned to Privileged Role	General privilege-escalation detection — catches role assignments performed outside approved PIM workflows.	AC.L2-3.1.5
7	Privileged Accounts - Sign in Failure Spikes	Brute-force or password-spray activity targeting admin accounts.	AC.L2-3.1.8, SI.L2-3.14.6

Pair with NRT and Fusion. NRT Modified domain federation trust settings is the same event as row 1 with ~1-minute latency; enable both — NRT for fastest fire, Scheduled for redundancy on a high-stakes event. Advanced Multistage Attack Detection (Fusion) — Microsoft's managed ML correlation engine — ships enabled by default and creates cross-source incidents at no additional cost; confirm it shows status Enabled under Active rules.

How to enable additional rules as data sources come online. Sort Rule templates by Severity (High first), then check the Data sources column. A template that queries DeviceProcessEvents (MDE) won't fire until MDE is onboarded; templates against OfficeActivity need M365 audit logs streaming. Enable templates whose data sources are already populated, and revisit the rest (e.g., LSASS Credential Dumping with Procdump, Files Copied to USB Drives, AV detections related to Ukraine threats, Local Admin Group Changes, Unusual Volume of file deletion by users) as you onboard MDE, M365 audit logging, and other workloads.

---

Reference sections below

The sequential deployment flow ends with Step 7. The sections that follow — Analytics Rules, Workbooks, Log Retention, and SIEM — Compliance Control Mapping — are reference material to return to during tuning and as detection coverage matures. A library of custom KQL detection-rule examples and a SOAR playbook table are published online at docs.mindline.com/docs/m365security/siem-strategy.

Analytics Rules

Analytics rules run KQL queries against ingested logs on a schedule and generate Sentinel incidents when thresholds are met. Step 7 above covered enabling Microsoft-provided templates; this section focuses on custom KQL rules you author to fill detection gaps the templates don't cover.

Custom Analytics Rules — Examples

// GCC High: PIM activation outside business hours (ET)
// Detection-tuned variant of the panoramic demo query "Privileged Role Activations (30d)" in Step 5.
// Same AuditLogs source, narrowed to a specific PIM-complete event and off-hours trigger.
AuditLogs
| where OperationName == "Add member to role in PIM completed (permanent)"
| extend ActivationHour = datetime_part("hour", TimeGenerated)
| where ActivationHour < 7 or ActivationHour > 19  // outside 7am-7pm ET
| project TimeGenerated, InitiatedBy, TargetResources, ActivationHour

// Conditional Access block spike — potential attack
SigninLogs
| where ResultType == "53003"  // CA block
| summarize BlockCount = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where BlockCount > 10
| project TimeGenerated, UserPrincipalName, BlockCount

// Sensitive label downgrade followed by external email
AuditLogs
| where OperationName == "SensitivityLabelUpdated"
| where parse_json(tostring(AdditionalDetails))["LabelEventType"] == "2"  // 2 = Downgrade
| join kind=inner (
    EmailEvents
    | where RecipientEmailAddress !endswith "@yourdomain.com"
    | where SentDateTime > ago(4h)
) on $left.UserId == $right.SenderFromAddress
| project TimeGenerated, UserId, SubjectLine=SubjectLine1

// External sharing: anonymous link creation or external guest invitation in SharePoint/Teams
// Detection-tuned variant of the panoramic demo query "External Sharing Events - Sharepoint + Teams" in Step 5.
// Adds AnonymousLinkUsed to the operations list and narrows via TargetUserOrGroupType == "Guest" filter.
// Maps to AC.L2-3.1.3 (CUI flow control) and MP.L2-3.8.7 (media sanitization / external sharing)
OfficeActivity
| where RecordType in ("SharePoint", "SharePointSharingOperation")
| where Operation in (
    "AnonymousLinkCreated",
    "AnonymousLinkUsed",
    "SharingInvitationCreated",
    "AddedToGroup"
)
| where TargetUserOrGroupType == "Guest" or Operation startswith "Anonymous"
| project TimeGenerated, UserId, Operation, OfficeObjectId, Site_Url, TargetUserOrGroupName

// Log tampering: audit log cleared (Windows Security and System logs) or diagnostic settings modified
// Maps to AU.L2-3.3.8 (protect audit information) and AU.L2-3.3.9 (limit audit management)
union
(
    SecurityEvent
    | where EventID in (1102, 104)  // 1102 = Security audit log cleared; 104 = System log cleared
    | project TimeGenerated, Computer, EventID, Activity, Account
),
(
    AzureActivity
    | where OperationNameValue =~ "Microsoft.Insights/diagnosticSettings/delete"
        or OperationNameValue =~ "Microsoft.Insights/diagnosticSettings/write"
    | where ActivityStatusValue == "Success"
    | project TimeGenerated, CallerIpAddress, Caller, OperationNameValue, ResourceId
)
| sort by TimeGenerated desc

Note on PIM and elevated privilege coverage: The existing PIM activation outside business hours rule above, combined with the built-in template "New admin account creation," satisfies the elevated privilege monitoring requirement for AC.L2-3.1.6 and IA.L2-3.5.3. No additional rule is required for that control family.

Workbooks

Sentinel workbooks are interactive dashboards built on Log Analytics queries. Use them for executive security reporting, compliance evidence preparation, and threat-hunting visual analysis.

For the GCC-High-specific list of which templates to save and when — grouped Tier 1 (save now), Tier 2 (save but expect sparse content), Tier 3 (defer until preconditions are met) — see Step 4: Save workbook templates for client demonstration above.

CMMC 2.0 workbook prerequisites. The CybersecurityMaturityModelCertification(CMMC)2.0 workbook requires NIST SP 800-171 Rev. 2 enabled in Defender for Cloud, continuous export configured to the Sentinel workspace, and 12–24 hours for the initial assessment pass to complete. See Step 3: Enable CMMC 2.0 posture assessment for the full prerequisite chain and validation query.

SOAR Playbooks

Sentinel playbooks are Logic Apps that trigger automatically on incident or alert events.

Playbook	Trigger	Action
Enrich-IP-with-TI	New incident	Query threat intelligence for IPs in the incident; add verdict to incident
Block-EID-User-on-High-Risk	High-severity Entra Identity Protection alert	Call Graph API to block sign-in for the risky user
Revoke-Sessions-on-PIM-Anomaly	PIM activation outside hours alert	Revoke all active sessions for the user via Graph API
Notify-SOC-on-MDE-Isolation	Device isolation action in MDE	Send Teams notification to SOC channel with device and analyst details
Post-Incident-to-ServiceNow	Incident created	Create a ServiceNow ticket (or Jira issue) with incident details

Create playbooks: Sentinel → Automation → Create → Playbook (Logic App designer). For GCC High, Logic Apps must use Azure Government Logic Apps (logic.azure.us endpoints).

Log Retention

Free retention floor

A Sentinel-enabled Log Analytics workspace includes 90 days of free retention in the Analytics (hot) tier for every table — substantially more than the 31-day default for Log Analytics workspaces without Sentinel. Anything beyond 90 days incurs storage cost; the per-table retention controls (Log Analytics workspace → Tables → [Table] → Manage table) let you set total retention up to 12 years and configure the Archive boundary independently.

Why 90 days is not enough for CMMC

The control text doesn't pin a number. NIST SP 800-171 Rev. 2 (and CMMC L2 control AU.L2-3.3.7 — retain audit records) requires that audit records be retained "for an organization-defined time period." NIST SP 800-171A (the assessment guide) reads the same. Technically a documented 90-day period passes the control text — but it fails the forensic purpose audit retention exists to serve:

Driver	Period
DoD CIO Logging Requirements memo (Aug 2021, follow-on to EO 14028)	12 months minimum for audit and event-log data on DoD systems
Mandiant M-Trends median dwell time	≈10 days median in recent reports, but the tail extends to 6+ months for sophisticated APTs — 90 days routinely misses the initial-compromise window
DFARS 252.204-7012(c) — CUI cyber incident reporting	Requires preservation of forensic images, packet captures, and contractor system images for at least 90 days "to support DoD-led damage assessment" — separate from baseline log retention but signals DoD's expectation that you retain enough to investigate
DCMA / DCSA assessment practice	Typically expects 1–3 years of audit log retention as evidence of a mature audit program

Practical bar for a CUI enclave: 365 days Analytics-tier (hot) + 2 years long-term/archive = 3 years total. The 365-day hot window covers most forensic investigation depth at queryable speed; the 2-year archive satisfies long-tail "we kept it" requirements at low cost via on-demand restore. Document the period in the SSP and the Audit Log Retention Policy — assessors care more about the documented policy and its adherence than the exact number.

Retention tiers and how to choose

Tier	Cost shape (approximate, Azure Government PAYG — verify with the Sentinel pricing calculator)	Query performance	Use
Analytics (hot)	Free for first 90 days on a Sentinel-enabled workspace; ≈$0.16/GB-month beyond	Fastest — full KQL real-time	Active investigation, detection rule lookback. CMMC sweet spot is 365 days.
Auxiliary plan	≈$0.06/GB ingestion + ≈$0.005/GB-month retention beyond included	Slower KQL on long lookback; no joins	High-volume noisy tables that must be retained but rarely queried in real time (raw network logs, verbose process telemetry)
Basic Logs plan	≈$0.80/GB ingestion + ≈$0.005/GB-month retention beyond included	Limited query (no joins, no summarize)	Intermediate option — cheaper than Analytics but still queryable for compliance lookbacks
Long-term / Archive	≈$0.025/GB-month storage + restore-job cost when accessed	Requires restore (hours)	Cold-storage retention beyond 1 year
Sentinel data lake tier	New tier; substantially cheaper than Analytics for cold compliance archives	KQL via promotion jobs	Long-retention compliance archives where queries are rare but historical depth is non-negotiable

Cost example — small CUI enclave at 3-year retention

For a 100-user GCC High tenant ingesting 0.5 GB/day (the same profile as §Sentinel Cost Planning — small Entra-focused customer), the retention bill works out roughly as:

Component	Calculation	Approximate cost
90 days hot — Sentinel-enabled free tier	included	$0/month
91–365 days hot — Analytics tier extension	≈275 days × 0.5 GB/day = ≈137 GB at ≈$0.16/GB-month	≈$22/month
366 days–3 years long-term/archive	≈730 days × 0.5 GB/day = ≈365 GB at ≈$0.025/GB-month	≈$9/month
Total retention cost beyond ingestion		≈$31/month

Sustaining 3-year retention at this scale costs roughly the price of a daily coffee. Larger tenants scale linearly with daily ingestion — a 50-server enclave at 30 GB/day will see retention costs in the $1,500–2,000/month range at full 3-year hot-plus-archive depth, still small relative to the ingestion savings the M365 G5 and Defender Servers P2 free benefits deliver.

Configuration mechanics

Configure per-table retention: Log Analytics workspace → Tables → [Table] → Manage table — set the Analytics (interactive) retention for each table individually. The workspace-level default retention (set during creation) applies to any table that doesn't have a per-table override. For CUI environments, leave the workspace default at 30 days and override the following six tables to 365 days of Analytics-tier (hot) retention. These are the minimum load-bearing tables for CMMC L2 audit evidence; extending others (raw MDE event tables, non-interactive sign-ins, Windows AMA event logs) is appropriate when the data is flowing and incident-response lookback depth matters, but is not required for assessor evidence:

Table	What it proves	CMMC controls
SigninLogs	Who signed in, when, from where, MFA outcome, CA policy evaluation	AC.L2-3.1.1, AC.L2-3.1.2, AU.L2-3.3.1, IA.L2-3.5.3
AuditLogs	Entra admin actions — role assignments, group membership, app consents, policy changes	AU.L2-3.3.1, CM.L2-3.4.3
OfficeActivity	M365 audit — Exchange mailbox access, SharePoint/OneDrive file ops, Teams changes, MIP label events, DLP rule matches	AU.L2-3.3.1, AC.L2-3.1.3, AC.L2-3.1.22, MP.L2-3.8.1, SC.L2-3.13.11
AzureActivity	Azure control plane — resource creation/deletion, diagnostic-setting changes, subscription-level role assignments	AU.L2-3.3.1, CM.L2-3.4.3
SecurityIncident	Sentinel and Defender XDR incidents — "investigation occurred" evidence	IR.L2-3.6.1, IR.L2-3.6.2
SecurityAlert	The raw alerts that fed incidents — demonstrates that detection rules are firing	SI.L2-3.14.6, SI.L2-3.14.7, IR.L2-3.6.1

SIEM — Compliance Control Mapping

GCC High (CMMC)

SIEM CMMC Control Mapping

NIST Control	Sentinel Capability
AU.L2-3.3.1 — Audit records	Sentinel ingests and retains audit logs from all connected sources (Entra, M365, Azure, Intune)
AU.L2-3.3.2 — Audit review	Analytics rules provide automated review; workbooks support periodic manual review
AU.L2-3.3.5 — Audit analysis	Custom KQL analytics rules correlate events across sources
AU.L2-3.3.7 — Audit retention	Long-term retention configured to 3+ years; audit records immutable in Log Analytics
IR.L2-3.6.1 — Incident response	Sentinel incidents provide the case management and evidence collection framework
IR.L2-3.6.2 — Incident reporting	Sentinel playbooks automate notification workflows to the security team and stakeholders
SI.L2-3.14.6 — Monitoring for unauthorized use	Behavioral analytics rules detect anomalous access patterns
SI.L2-3.14.7 — Identify unauthorized use	Entity behavior analytics (UEBA) profiles users and devices for deviation detection

For CMMC assessors, Sentinel provides the technical evidence that AU.L2-3.3.1 and AU.L2-3.3.2 are implemented: audit records exist, are being reviewed analytically, and are retained. Export Sentinel analytics rule configurations and workbook screenshots as part of the audit evidence package.

DFARS 252.204-7012 — contract clause coverage

CMMC L2 implements NIST 800-171, but the contractual instrument most DIB customers actually sign is DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting. The clause has its own evidence and reporting requirements that overlap with, but aren't identical to, the NIST controls above. Sentinel covers the audit and forensic-preservation elements directly:

DFARS clause	Requirement	Sentinel coverage
252.204-7012(b)	Implement NIST SP 800-171 controls	All AU.L2 controls in the table above; CMMC posture rules from Step 3 produce the per-control compliance evidence
252.204-7012(c)(1)	Report cyber incidents to DoD within 72 hours of discovery	SOAR playbooks (Notify-SOC-on-MDE-Isolation, custom DIBNet-submission playbook) automate the 72-hour reporting workflow with a timestamped audit trail of who notified, when, and what was sent
252.204-7012(c)(1)(ii)	Preserve forensic images, packet captures, and system images for at least 90 days	Log Analytics archive tier holds 90 days of audit data minimum (recommendation is 3 years). For VM-level forensic images, pair Sentinel with Azure Backup snapshot retention on the affected VM
252.204-7012(c)(7)	Provide DoD with media or images on request during damage assessment	Sentinel restore-from-archive (cold tier) plus Recovery Services Vault snapshots together produce the response artifacts

Reference the DFARS clause directly in the SSP narrative for the audit-and-incident-response control family — assessors recognize the DFARS-to-NIST mapping and a direct citation often shortens the conversation.

Commercial

NIST SP 800-171 Rev. 3 and SOC 2 Mapping

NIST SP 800-171 Rev. 3

Control	Sentinel Capability
3.3.1 — Audit records	Multi-source log aggregation with configurable retention
3.3.2 — Audit review	Analytics rules and workbooks for continuous and periodic review
3.3.5 — Audit analysis	KQL correlation rules across all log sources
3.14.6 — Monitoring	Behavioral detection rules; UEBA

SOC 2 Type II

Trust Service Criteria	Sentinel Implementation
CC7.2 — Monitoring for anomalies	Analytics rules detecting anomalous sign-ins, privilege changes, data access
CC7.3 — Evaluate security events	Sentinel incidents with automated enrichment and severity classification
CC7.4 — Respond to identified anomalies	SOAR playbooks for automated response; incident management workflow
A1.2 — Monitoring for availability	Azure resource health alerts ingested via Azure Monitor connector

For SOC 2 Type II audits, provide the auditor with: the analytics rule list (exported), 12 months of incident data (Sentinel incidents export), and workbook screenshots showing monitoring dashboards were actively used during the audit period.