Audit and Accountability family overview

The Audit and Accountability family is where many otherwise strong CMMC implementations start to show cracks. Most organizations do not fail this family because logging is completely absent. They fail it because logs are incomplete, retention does not match the SSP, alerting was never configured, correlation is weak, or too many people can manage audit settings without oversight.

That is what makes this control family so important. A CMMC assessor is not just asking whether Microsoft GCC High can generate logs. They are looking at whether your organization can create, retain, protect, review, correlate, and report on audit data in a way that supports real investigation and accountability.

In GCC High, Microsoft provides much of the underlying audit infrastructure. Unified Audit Log in Microsoft Purview captures activity across core Microsoft 365 workloads. Azure Government services support Log Analytics and Microsoft Sentinel for correlation and alerting. Azure Monitor can extend coverage into the infrastructure layer. But that does not mean the family is handled for you. Of the nine controls in Audit and Accountability, only three are primarily platform-provided. The other six depend on explicit configuration in your tenant and in your Azure Government environment.

This is Part 3 of the NIST 800-171 GCC High Configuration Guide. It assumes you already have a functioning GCC High tenant, understand the shared responsibility model, and are implementing against NIST 800-171  Rev. 2.

AU family overview

The Audit and Accountability family includes nine controls focused on creating audit records, retaining them appropriately, protecting them from tampering, limiting administrative access to them, and using them in a meaningful way during security monitoring and investigation.

At a practical level, the family divides into two groups. Some controls are mostly supported by the Microsoft platform itself, especially where the cloud service provides immutable audit data, authoritative time sources, and identity-linked records. The rest require real implementation work. That includes enabling and validating logging, setting retention policies, reviewing what is logged, alerting on audit pipeline failures, deploying SIEM workflows for correlation, and restricting management access to a small set of authorized users.

If Identity and Authentication is the gatekeeper of the environment, Audit and Accountability is its memory. It is the family that tells you what happened, who did it, whether your controls were enforced, and whether you can reconstruct an incident after the fact.

AU controls and CMMC scope

Audit and Accountability applies across the full CMMC assessment boundary. If a user, device, application, or workload is in scope, the actions it performs need to be logged and attributable to the extent required by the control family.

That has important implications for enclave architectures. An enclave can reduce the number of systems and users subject to full CMMC implementation, but the systems and identities inside the enclave still need complete audit coverage. If CUI is accessed in Exchange Online, SharePoint Online, Teams, or Entra ID, the relevant audit trails for those actions need to exist, be retained, and be reviewable within that boundary.

This is also why scope drift becomes so dangerous in the AU family. Organizations often think they have a narrow enclave, but then discover during readiness work that admin activity, sign-in events, file access, or cross-workload actions are happening outside the systems they expected to monitor. A strong scoping model for the AU family is not just about where CUI lives. It is also about where the evidence of activity around that CUI will come from.

How audit logging works in GCC High

Before walking through individual controls, it helps to understand the architecture you are actually working with in GCC High.

The Unified Audit Log in Microsoft Purview is the primary audit system for Microsoft 365 workloads. It captures user and admin activity across Exchange Online, SharePoint Online, OneDrive, Teams, Entra ID, and Purview itself. For enterprise licenses such as G3 and G5, it is commonly enabled by default, but you should never rely on that assumption. Especially in smaller GCC High environments or newer licensing combinations, verification matters.

Microsoft Sentinel runs in Azure Government and serves as the SIEM layer. This is where you move from passive logging to correlation, analytics, alerting, and incident grouping. Sentinel is also where many organizations either become assessment-ready or realize they are still only collecting data without actually operationalizing it.

Purview Audit Standard and Purview Audit Premium differ significantly. Standard gives you a basic audit capability with shorter retention. Premium extends retention and provides important event coverage, including records that are often relevant when CUI is handled in email and files. For a serious CMMC Level 2 implementation, Premium is strongly preferred.

Log Analytics and Azure Monitor matter because some audit data, especially longer-term archival and richer cross-source review, depends on routing logs into Azure Government workspaces rather than relying on the Microsoft 365 interface alone.

One practical note matters here more than it should: in GCC High, you need to stay disciplined about portal domains. Purview uses the .us experience, Entra uses .us, and Sentinel lives in portal.azure.us. If you are navigating to commercial portals out of habit, you are in the wrong environment.

What GCC High provides by default

Three AU controls are largely supported by the platform itself. Even here, though, the control is not something you can simply wave away with “Microsoft handles it.” You still need to understand what the platform provides, document that clearly in your SSP, and make sure your own environment is not undermining the control.

3.3.2 Ensure user accountability

This control requires that actions be traceable to individual users.

GCC High supports that well at the platform level. Unified Audit Log records include identifiers such as the acting user, operation, timestamp, IP address, and target object. Entra ID sign-in logs add even more context, including device information, location, application, Conditional Access outcomes, and MFA details. That gives you the raw technical capability to tie actions to identities.

The risk here is almost always self-inflicted. Shared service accounts, generic admin logins, or loosely controlled shared mailboxes can break individual attribution even if the platform itself is generating strong records. Your SSP and your operating practices need to make it clear that interactive access is tied to unique identities and that generic shared credentials are prohibited.

3.3.7 Provide an authoritative time source

This control is about time synchronization and trustworthy timestamps.

Microsoft GCC High satisfies this through the cloud service architecture. Audit records are timestamped based on the platform’s synchronized server-side time source, not on the local clock of the end user’s device. That means logs across M365 workloads can be correlated using a consistent time base, which is exactly what the control is trying to ensure.

The main caveat here is hybrid or endpoint-generated logs. If your environment includes on-premises systems or endpoint logs that you plan to use during investigations, those systems still need their own authoritative time source and documented synchronization process. Microsoft covers the cloud service. It does not automatically cover everything else in your boundary.

3.3.8 Protect audit information

This control requires audit records and audit tools to be protected against unauthorized access, modification, or deletion.

At the platform layer, GCC High is strong here. Unified Audit Log records are stored in Microsoft-managed infrastructure, customers do not get direct storage-level access, and the records themselves are not freely editable. Entra ID audit and sign-in logs are similarly controlled through built-in role-based access. In Azure Government, Log Analytics and Sentinel also support strong access control through Azure RBAC.

But this is another control where the platform can only take you part of the way. If you assign too many people Security Administrator or Global Administrator roles, or if your Log Analytics workspace can be deleted by broadly assigned contributors, then the practical protection of audit data becomes much weaker than the service’s underlying design. This is why resource locks, limited role assignment, and SSP documentation still matter even for a largely platform-supported control.

The six AU controls you must configure yourself

This is where the real implementation work begins. These six controls are where assessors most often find first-round issues, especially in organizations that assumed Microsoft’s built-in capabilities were enough on their own.

3.3.1 Create and retain system audit logs

This control is the foundation of the family. It requires you to define auditable events, generate records for those events, and retain them according to documented requirements.

In GCC High, that begins with verifying that Unified Audit Log is actually enabled and ingesting data. Even if your licensing suggests it should be on by default, you should still confirm it directly in Exchange Online PowerShell.

Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

You also need to verify mailbox auditing, because individual mailboxes can still be out of alignment even when organization-wide auditing appears healthy.

Get-OrganizationConfig | Format-List AuditDisabled

Get-Mailbox -ResultSize Unlimited | Where-Object {$_.AuditEnabled -eq $false} |
  Select-Object DisplayName, UserPrincipalName, AuditEnabled

Get-Mailbox -ResultSize Unlimited | Where-Object {$_.AuditEnabled -eq $false} |
  Set-Mailbox -AuditEnabled $true

After that, retention becomes the real issue. If your SSP says logs are retained for a year, your environment has to match that statement. Purview Audit Premium makes this much easier because Standard retention can leave organizations with a gap between what their documentation promises and what their tenant is actually configured to keep.

Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common

New-UnifiedAuditLogRetentionPolicy -Name "CMMC-AllEvents-1Year" -Description "1-year retention for all audit events" -RetentionDuration OneYear -RecordTypes @("All") -Priority 100

If you are serious about investigation readiness, you should also archive Entra ID logs into a Log Analytics workspace in Azure Government. That closes an important gap between Microsoft 365 logging and Azure-side retention and analysis.

The most common findings here are predictable. Unified Audit Log was never actually enabled. Mailbox auditing was disabled somewhere. Retention does not match the SSP. Entra ID logs were never archived beyond native short-term retention. These are all avoidable, but only if someone verifies the environment directly.

3.3.3 Review and update audited events

This control is less about the existence of logging and more about governance. It requires your organization to periodically review what events are being logged and update that set when the environment or risk picture changes.

That means you need a repeatable process. At minimum, your team should define a review cadence, identify who participates, establish what questions the review should answer, and record any changes that result. It is not enough to say “we log everything.” Assessors want to know whether the organization revisits that assumption and adapts as workloads evolve.

You can start by documenting the current event baseline through Unified Audit Log search and the Purview Audit interface. From there, you should decide whether additional Premium events need to be enabled for higher-value activities such as mail item access, SharePoint search, or Exchange search activity.

Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -ResultSize 1 |
  Select-Object -ExpandProperty AuditData | ConvertFrom-Json |
  Select-Object RecordType -Unique

This control usually fails when a procedure exists on paper but no one has actually performed a review, or when a new workload enters the environment and no one updates the logging strategy to reflect it.

3.3.4 Alert in the event of audit logging process failure

This control is one of the easiest to overlook because organizations often focus on generating logs and forget to ask what happens if the logging pipeline breaks.

The answer needs to be: you know quickly, and the right people are notified.

In practice, this means creating alerting in both Purview and Sentinel. Purview can alert on administrative actions that disable or change audit behavior. Sentinel can detect more operational failures, such as ingestion gaps or changes to diagnostic settings.

A simple example is creating a scheduled Sentinel rule that detects a change to the audit ingestion configuration or a meaningful gap in OfficeActivity data.

OfficeActivity
| where OfficeWorkload == "Exchange"
| where Operation == "Set-AdminAuditLogConfig"
| where Parameters has "UnifiedAuditLogIngestionEnabled" and Parameters has "False"
| project TimeGenerated, UserId, ClientIP, Operation, Parameters

The control is not satisfied just because an alert exists. You also need to define who receives it, what response time is expected, and how remediation works. A half-configured alert policy pointing at a generic shared inbox is not strong evidence.

3.3.5 Correlate audit review, analysis, and reporting

This is the control that usually forces organizations to confront the difference between “we have logs” and “we can investigate incidents.”

Correlation requires a SIEM or equivalent platform that can ingest logs from multiple sources and connect related events together. In GCC High, the most natural answer is Microsoft Sentinel running in Azure Government.

Once Sentinel is deployed, the work is not over. You still need to connect relevant sources, enable analytics rules, build useful workbooks, and configure incident grouping so investigations are not just raw data review exercises.

A typical correlation workflow might connect risky sign-ins from Entra ID to later file access events in SharePoint, allowing the team to see whether a suspicious authentication event was followed by meaningful data access.

let suspiciousSignIn = SigninLogs
| where RiskLevelDuringSignIn in ("medium", "high")
| project SignInTime = TimeGenerated, UserPrincipalName, IPAddress, RiskLevel = RiskLevelDuringSignIn;
let fileAccess = OfficeActivity
| where OfficeWorkload == "SharePoint" and Operation in ("FileDownloaded", "FileAccessed")
| project FileTime = TimeGenerated, UserId, ClientIP, Operation, OfficeObjectId;
suspiciousSignIn
| join kind=inner fileAccess on $left.UserPrincipalName == $right.UserId
| where FileTime between (SignInTime .. (SignInTime + 1h))
| project SignInTime, FileTime, UserPrincipalName, IPAddress, RiskLevel, Operation, OfficeObjectId

This control tends to fail when Sentinel has been provisioned but not truly operationalized, or when only one or two connectors are enabled and no meaningful analytics rules exist.

3.3.6 Provide audit reduction and report generation

This control is about being able to reduce large volumes of audit data into something useful and then generate reports from it on demand.

Purview Audit Search satisfies the most basic version of this requirement because it supports filtering by date, user, workload, and activity. But in most CUI environments, that is only the beginning. Log Analytics and Sentinel are what turn raw audit data into structured, reusable analysis.

For example, you should be able to generate a report showing privileged actions in the last week, summarize failed sign-ins by location, or build a workbook that lets you investigate all activity tied to a particular user across workloads.

OfficeActivity
| where TimeGenerated > ago(7d)
| where UserType == "Admin"
| summarize ActionCount = count() by UserId, Operation, OfficeWorkload
| order by ActionCount desc

This control often becomes visible during live assessments. If an assessor asks to see all admin actions in the last 30 days and the team cannot produce that report quickly, the issue is not whether logs exist. It is whether the organization can actually use them.

3.3.9 Limit management of audit logging functionality

This control is where governance and access control come back into the AU family.

Your organization needs to define which roles are authorized to manage audit settings and then make sure actual assignments match that intent. That usually means reviewing Compliance Administrator and Organization Management roles in Purview, security-related roles in Entra ID, and Azure RBAC permissions on Log Analytics and Sentinel resources.

Just as important, it often makes sense to separate those who can manage audit settings from those who only need to review audit data. That is where custom read-only roles or view-only groups become useful.

Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common

Get-RoleGroupMember -Identity "OrganizationManagement" | Select-Object DisplayName, PrimarySmtpAddress
Get-RoleGroupMember -Identity "ComplianceAdministrator" | Select-Object DisplayName, PrimarySmtpAddress

This is also one of the clearest places to use PIM. Permanent admin roles create unnecessary risk. Just-in-time elevation, approval requirements, and short activation windows all strengthen the defensibility of your implementation.

The usual findings here are too many Global Administrators, unclear separation between audit review and audit management, and actual role assignments that do not match what the SSP says is true.

A practical PowerShell reference for the AU family

Because this family relies so heavily on verification, configuration, and evidence collection, it helps to keep the most important administrative commands in one place.

At minimum, most organizations should maintain a working set of commands for connecting to GCC High Exchange Online, Security and Compliance PowerShell, Microsoft Graph, and Azure Government, along with the commands used to verify Unified Audit Log ingestion, mailbox auditing, audit retention policies, and role assignments for audit administration.

What evidence a C3PAO will usually want to see

For the AU family, evidence should tell a consistent story across configuration, process, and governance.

That usually includes proof that Unified Audit Log is enabled, mailbox auditing is active, retention policies are configured to match the SSP, and Entra ID logs are routed appropriately for retention and analysis. For review-oriented controls, assessors typically want to see procedures, review records, and evidence that those reviews actually occurred. For alerting and correlation controls, they will often ask for Sentinel analytics rules, workbook screenshots, action groups, alert test results, and incident documentation. For access-restriction controls, they usually expect role assignment exports, PIM settings, and documentation showing which roles are allowed to manage audit functions.

The most common AU findings in real assessments

The single most common issue in this family is audit logging that was assumed to be enabled rather than explicitly verified. Closely behind that is retention that does not match the organization’s SSP. If your documentation says one year and your environment keeps 180 days, that is an easy finding.

Alerting on logging failure is another frequent gap. Organizations often log aggressively but have no detection mechanism for when that logging stops or changes.

Correlation is also a common weakness. Purview Audit Search is useful, but it does not replace a SIEM-backed capability for correlating events across identity, email, file access, and administrative actions. Where organizations have deployed Sentinel, they sometimes still fail this control because connectors are incomplete, analytics rules are not operational, or nobody is actually reviewing the outputs.

Finally, access control around the audit stack is often too broad. Excessive Global Administrator membership, loosely scoped Azure RBAC roles, and no PIM are all patterns assessors notice quickly.

How the AU family supports other control families

Audit and Accountability is deeply connected to the rest of the framework.

Access Control becomes much easier to defend when access decisions and role changes are logged and reviewable. Identification and Authentication feeds the AU family because audit data has limited value if actions cannot be tied to unique identities. Incident Response depends on audit trails to reconstruct events and prove what happened. System and Information Integrity benefits from correlated logging when malware, anomalies, or suspicious changes need to be investigated.

That is why this family is so often cited in assessments. Logging is not a side function. It is the evidence layer that allows many other controls to be demonstrated.

Get started

Configuring audit logging is only the first step. The harder step is proving that the right events are captured, retained, reviewed, and protected continuously over time.

Secureframe Defense connects directly to your GCC High environment and continuously monitors the configurations that support the AU family, including Unified Audit Log status, retention settings, Sentinel deployment, and audit-related role assignments. When a C3PAO asks for evidence, the goal is not to start collecting screenshots from multiple portals. The goal is to already have the relevant evidence organized and ready.

See how Secureframe automates CMMC audit evidence collection by scheduleing a demo with a product expert.