Keep the records you need, find out when logging fails and be able to explain what happened.
Work through all nine requirements and 29 assessment objectives. Use your existing Microsoft tools where they fit, record the gaps and decide what your team can reliably operate. A log that expires before anyone needs it will not help an investigation.
Sources reviewed October 27, 2026. These instructions have not been tested in a Microsoft tenant. This guide does not establish compliance or replace an official assessment. Settings, example checks and manual worksheet states are working aids.
Know the scope. List the systems that store, process or transmit CUI and the services protecting them. Include identity, hosts, applications, remote access and provider responsibilities. If that is unclear, start with Do we handle CUI? and your scoping work.
Choose the events and fields. Ask what would explain an unauthorized sign-in, access change, file action or logging failure. Define the record contents and source needed for each question.
Choose retention and review arrangements. Document the period you need and why, the reviewer, the failure alert route and how you preserve evidence. A vendor default is not your approved requirement.
Check subscriptions and permissions. A basic Office installation does not grant every cloud audit feature. Check the tenant, workload, license, roles and destination before planning collection or buying anything.
Pilot safely. Use an approved test account, harmless files and a test location. Save current configuration and agree recovery before changes. Do not clear logs, disable production collection, fill storage or change clocks for an exercise.
Keep logs, exports and completed records in your own approved environment. They can contain sensitive account, personnel and system details. This website does not accept those records or collect exercise answers.
Keep the logs you will need when something goes wrong
Start with the questions an investigation would need to answer: what happened, when, where, to which resource and under which account. Decide which systems can supply those answers and keep the records long enough to use them.
Official requirement and assessment objectives
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.1
Objective
Official text
3.3.1[a]
audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified.
3.3.1[b]
the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined.
3.3.1[c]
audit records are created (generated).
3.3.1[d]
audit records, once created, contain the defined content.
3.3.1[e]
retention requirements for audit records are defined.
3.3.1[f]
audit records are retained as defined.
What to do
List sources and events
Use the log register to list the systems in scope, including identity services, Windows hosts, file services, applications and remote access. Choose events for the activities you need to investigate. Record successful and failed actions where relevant. A list of event numbers alone does not explain what each source covers.
Define the contents and retention
For each event, identify the time and time zone, source, account identifier, action, target and result you need. Decide the retention period, reason, destination and access restrictions. Compare that decision with the actual product limit. These requirements do not set one universal CMMC retention period; your contracts and other obligations may add specific terms.
Configure one source at a time
Use the Microsoft setup paths below. Preserve current settings, approve the change and pilot it on a suitable test system or workspace. Check event generation separately from forwarding and storage. Assign who checks collection health, available space and expiring records.
Retrieve and examine a real sample
With authorization, perform a harmless test action and find its record at the source and the retained destination. Compare its fields with your plan. Retrieve older records to test retention, then record the period actually demonstrated. A new archive cannot prove months of history on its first day.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.1[a]
Choose an in-scope service and show the events selected for monitoring, investigation and reporting, with the reason for each.
Records to keep: Approved source/event register and scope reference.
3.3.1[b]
Show the fields you require for those events, including identity, time, action, target and outcome where needed.
Records to keep: Record-content definition tied to each source and use.
3.3.1[c]
Find the record from an approved harmless action. Check that the relevant event is actually generated.
Records to keep: Test action/time, source record reference and observed result.
3.3.1[d]
Open the sample record and compare its contents with the defined fields. Record absent or ambiguous values.
Records to keep: Field comparison and unresolved content gaps.
3.3.1[e]
Locate the approved retention decision for each selected source, including its basis and storage location.
Records to keep: Retention decision, owner, obligations considered and destination.
3.3.1[f]
Retrieve records from the required period in the retained store and check they remain readable and complete enough for the planned use.
Records to keep: Retrieval date, oldest demonstrated record, missing intervals and collection evidence.
Records to keep
Source/event/content register and approved retention decisions.
Configuration and change references, collection responsibilities and capacity checks.
Observed generation, export and historical retrieval results, including missing periods.
If something is missing
If records are missing, preserve what remains and record when collection last worked. Check permissions, event selection, ingestion delays, forwarding and storage. Repair through the approved change process, then repeat the harmless test. Do not mark an unrecoverable interval as covered.
Use what you already have
Start with logs already available in your subscriptions and Windows. Secure manual exports can help with small volumes if someone reliably collects them before expiry. Collection, storage, access controls and staff review still cost time; plan a managed pipeline when manual work cannot meet your needs.
An account name is useful only when you can connect it to the person who used it. Shared administrator credentials, reused names and missing session records can leave that connection uncertain.
Official requirement and assessment objectives
Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.2
Objective
Official text
3.3.2[a]
the content of the audit records needed to support the ability to uniquely trace users to their actions is defined.
3.3.2[b]
audit records, once created, contain the defined content.
What to do
Define how you will identify the actor
Record the stable account identifiers and supporting session or authentication details each source provides. Keep the account-to-person assignment history under appropriate restrictions. Display names can change; an IP address or a shared device name alone does not identify a person.
Address shared and service accounts
Use individually assigned accounts for human work and separate administration where appropriate. Document service identities, their owners and any human-controlled access path. Where a shared account remains, determine whether approved session and access records can reliably establish individual use. Keep unresolved attribution as a gap.
Follow one approved action through the records
Use an assigned test account to perform a harmless action. Follow the sign-in or session and target action across the relevant sources. Record which identifiers connect them and which do not. For AVD, check both the connection and the session-host activity needed to explain the action.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.2[a]
Show which record fields and assignment/session records are needed to trace an action to an individual in this environment.
Records to keep: Attribution design, stable identifiers, assignment history and shared-account exceptions.
3.3.2[b]
Trace an authorized sample action to its assigned user using the defined contents. Identify any missing link without guessing who acted.
Records to keep: Linked source references, observed identifiers and remaining attribution limits.
Records to keep
Account assignments and approved session/access references.
Sample trace and an explanation of how identifiers connect.
Shared-account or provider attribution gaps and corrective actions.
If something is missing
Do not accuse a person based on a shared credential or display name. Preserve available records, state the attribution limit and correct the account or session design. Test a new action after the change; that does not repair old missing identity evidence.
Use what you already have
Use the account and session records you already have. A paid privileged-access product may help some deployments, but buying it does not establish that your records actually identify individual use.
This requirement concerns the selection of logged event types. Investigating yesterday's events is a separate activity. Revisit the selection when your systems, threats or investigation needs change.
Official requirement and assessment objectives
Review and update logged events.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.3
Objective
Official text
3.3.3[a]
a process for determining when to review logged events is defined.
3.3.3[b]
event types being logged are reviewed in accordance with the defined review process.
3.3.3[c]
event types being logged are updated based on the review.
What to do
Set a review process
Name who reviews the event selection, when that happens and what triggers an earlier review. Include system changes, new CUI workflows, incidents, investigation gaps and product changes. Choose timing your team can carry out; record the basis rather than presenting an example interval as a mandate.
Compare coverage with current needs
Walk through the source register with the system and incident owners. Ask whether you can explain relevant unauthorized actions, whether needed fields are present, and whether excessive volume is hiding useful activity or exhausting storage. Check applications and provider-managed services as well as Windows.
Update and test the selection
Approve the changes, pilot the affected policy or collection rule and repeat the relevant harmless activity check. Record additions, removals, reasons and any remaining gaps. If a change disrupts collection, restore the previous approved configuration through change control and investigate before a wider rollout.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.3[a]
Find the defined process for reviewing selected event types, including ownership, timing and triggers.
Records to keep: Review procedure and chosen schedule/change triggers.
3.3.3[b]
Examine a completed review and compare it with the source register and the stated process.
Records to keep: Dated review, participants, coverage questions and decisions.
3.3.3[c]
Follow a necessary change from the review into an approved configuration and a result check. If no change was needed, retain the reason.
Records to keep: Updated event selection, change reference and observed collection result.
Records to keep
Event-selection review process and dated review decisions.
Approved policy/collection changes and test results.
If something is missing
If reviews are overdue, assign one and keep the overdue state visible. If a needed event is not available from the source, document that limitation and decide how to address the resulting risk; do not silently remove it from the plan.
Use what you already have
Use the register and an existing change-review meeting. Spend the time on missing coverage and investigation needs before collecting every available event.
A quiet report may mean little happened, or it may mean records stopped arriving. Define failures worth alerting on and make sure an assigned person actually receives the alert.
Official requirement and assessment objectives
Alert in the event of an audit logging process failure.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.4
Objective
Official text
3.3.4[a]
personnel or roles to be alerted in the event of an audit logging process failure are identified.
3.3.4[b]
types of audit logging process failures for which alert will be generated are defined.
3.3.4[c]
identified personnel or roles are alerted in the event of an audit logging process failure.
What to do
Define the failures and recipients
Include failures relevant to your design: disabled logging, an unreachable source, forwarding or export failure, insufficient storage, rejected records and unexpectedly missing expected activity. Choose thresholds suited to each source. Name the primary recipient, backup and an out-of-hours route where needed.
Monitor the collection path
Check the source, transfer and destination. Use the health signals your chosen tool supports, and add an expected-event or heartbeat check where a source could disappear unnoticed. A manual daily review may discover a gap later; it does not by itself generate a failure alert.
Test delivery and recovery safely
Use an approved test notification to check delivery and acknowledgment. Test a representative failure only on an isolated test source with a restoration plan. Do not stop production logging, fill a disk or clear records. Record what was detected, the delay, who received it and how recovery was confirmed.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.4[a]
Locate the people or roles assigned to receive each logging failure alert and the fallback route.
Records to keep: Recipient assignments, coverage and escalation contacts.
3.3.4[b]
Compare defined failure types and thresholds with the actual collection design and health signals.
Records to keep: Failure/threshold list, source expectations and configured detection references.
3.3.4[c]
Observe a safe test that detects a representative test-source failure and delivers the alert to the assigned recipient. Record acknowledgment and limits.
Records to keep: Test authorization, trigger, notification/receipt times, recipient and recovery result.
Records to keep
Failure definitions, thresholds, recipients and fallback.
Detection configuration, notification tests and repaired-gap records.
If something is missing
Preserve available logs, establish the affected period and follow the failure procedure. If notifications are not reaching anyone, repair the route and test it. Keep the alerting gap open until detection and delivery work; a successful email test alone does not prove failure detection.
Use what you already have
Use existing collector or service health functions where available. Windows collection can be economical, but reliable health alerts still need design and maintenance. Azure Monitor rules, action delivery, ingestion and storage may have charges; do not describe them as universally free.
Bring the relevant records together for an investigation
A sign-in, a file action and a permission change may sit in different systems. The reviewer needs a defined way to connect relevant records and pass a clear account of the findings to the people handling the incident.
Official requirement and assessment objectives
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.5
Objective
Official text
3.3.5[a]
audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined.
3.3.5[b]
defined audit record review, analysis, and reporting processes are correlated.
What to do
Define review, analysis and reporting
Decide what routine reviews look for, who analyzes unusual activity, when to escalate and who receives reports. Include the period, sources, expected delays, approved handling and evidence-preservation steps. Agree the handoff with your incident process and any provider.
Build a supported timeline
Use stable account, resource and session identifiers alongside time and source references. Record the original time zone and any clock uncertainty. Compare relevant identity, Windows, workload and remote-access records. Two nearby events or matching display names do not by themselves establish a causal link.
Report findings and limitations
Separate confirmed events, possible explanations and unanswered questions. Retain the original records in approved storage and refer to them from the report. Assign follow-up and verify the receiving person can use the evidence. A provider alert is an input to this process, not the whole investigation.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.5[a]
Show the defined review, analysis and reporting processes and how suspected unauthorized activity moves between them.
Records to keep: Procedures, responsibilities, source list and incident handoff.
3.3.5[b]
Work through a fictional or authorized investigation linking relevant records to analysis and a report with clear references and limits.
Records to keep: Timeline, linking identifiers, report, escalation and follow-up references.
Records to keep
Review/analysis/reporting procedures and provider responsibilities.
Search records, supported timeline, report and follow-up.
If something is missing
If a source or identifier is missing, explain what cannot be established. Obtain authorized supporting records where possible, preserve the rest and assign the coverage fix. Do not fill gaps in a timeline with assumed facts.
Use what you already have
For a small bounded case, a restricted Excel timeline and saved exports can support the process. A SIEM may improve scale and timeliness; it still needs relevant sources, maintained rules, trained reviewers and an approved destination.
Find the useful records and produce a report when needed
Audit record reduction means selecting the records needed for a question, not deleting the source evidence. A reviewer should be able to filter by relevant fields and produce a usable report on demand.
Official requirement and assessment objectives
Provide audit record reduction and report generation to support on-demand analysis and reporting.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.6
Objective
Official text
3.3.6[a]
an audit record reduction capability that supports on-demand analysis is provided.
3.3.6[b]
a report generation capability that supports on-demand reporting is provided.
What to do
Provide a usable search method
Use the native search/filter capability for the source or an approved analysis tool. Define the questions it must answer and check the reviewer has the right access. For Windows, Event Viewer or Get-WinEvent can filter a bounded set; Purview searches cover supported Microsoft 365 activities.
Keep the query and the source intact
Record the sources, time range and time zone, filters, job status, limits and export method. Check whether the result was capped, delayed or incomplete before calling it the full result. Preserve original records separately from an Excel working copy, summary or screenshot.
Generate and review the report
Produce a report showing the question, selected records, findings, limits and evidence references. Have another authorized person follow a representative reference. Repeat a search with changed filters to show the capability works on demand rather than relying only on a scheduled dashboard.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.6[a]
Filter an authorized sample by time and relevant account/action fields, then change the question and run a different selection.
Records to keep: Search definitions, source boundaries, job status and result/limit checks.
3.3.6[b]
Generate a report from that selection and verify its source references, contents and limitations are understandable to the receiving person.
Records to keep: Report, export reference, reviewer and on-demand generation result.
Records to keep
Saved search definitions, result boundaries and export references.
Reports and checks that they can be traced to retained records.
If something is missing
If results are capped or incomplete, use a supported narrower search or export method and document how the sets relate. Keep the original evidence unchanged. Treat an empty search as a result to investigate, not proof that no relevant activity occurred.
Use what you already have
Use included search tools and Excel for modest exports. An Excel workbook is not a collection system, a protected evidence archive or a substitute for missing records.
Logs are difficult to compare when host clocks disagree. Know how the systems generating your timestamps compare and synchronize their clocks, and how you will detect a problem.
Official requirement and assessment objectives
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.7
Objective
Official text
3.3.7[a]
internal system clocks are used to generate time stamps for audit records.
3.3.7[b]
an authoritative source with which to compare and synchronize internal system clocks is specified.
3.3.7[c]
internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
What to do
Identify the timestamp sources
List the hosts and services producing records. Distinguish the event time from collection or ingestion time, and note whether a viewer converts UTC to local time. Include domain controllers, standalone or Entra joined devices, collectors and AVD session hosts.
Document the approved time arrangement
Name the authoritative time source or hierarchy and who maintains it. Domain members generally use the AD DS hierarchy; check the forest-root PDC arrangement. Entra join alone does not establish the device's chosen time source. For managed cloud services, record provider responsibility and supporting documentation rather than claiming to configure their internal clocks.
Check actual source and synchronization
Use the read-only Windows Time checks below and examine the last successful synchronization and configured source. Compare representative records across systems with their time zones intact. Investigate unexpected sources, failed synchronization and unacceptable differences under your chosen tolerance. Do not change clocks to manufacture a test event.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.7[a]
Examine sample records and establish which system clock produced the event timestamp and how the viewer displays it.
Records to keep: Timestamp fields, source-host/service mapping and time-zone interpretation.
3.3.7[b]
Locate the specified authoritative source or hierarchy and responsibility for each relevant environment.
Records to keep: Approved time-source design and provider/customer responsibility references.
3.3.7[c]
Inspect actual source, status and synchronization evidence on representative systems and compare them with the approved arrangement.
Records to keep: Dated source/status results, last successful sync, comparison and unresolved exceptions.
Records to keep
Time-source design and responsibility assignments.
Source/status results and recorded time uncertainty in investigations.
If something is missing
If time is wrong, preserve the current records and document the suspected offset before an authorized repair. Use the supported time-service procedure and check again. Avoid a broad clock change that could affect authentication, applications or the meaning of existing logs.
Use what you already have
Windows includes Time service tools. Staff still need to maintain reachable approved sources and investigate failures. A timestamp in a dashboard does not prove the originating host was synchronized.
Protect the records and the tools that collect them
Protecting an exported report is only part of this requirement. Check unauthorized reading, changes and deletion for both the audit information and the logging tools, including their configurations and collection path.
Official requirement and assessment objectives
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.8
Objective
Official text
3.3.8[a]
audit information is protected from unauthorized access.
3.3.8[b]
audit information is protected from unauthorized modification.
3.3.8[c]
audit information is protected from unauthorized deletion.
3.3.8[d]
audit logging tools are protected from unauthorized access.
3.3.8[e]
audit logging tools are protected from unauthorized modification.
3.3.8[f]
audit logging tools are protected from unauthorized deletion.
What to do
Map access to records and tools
List the source channels, collectors, agents, rules, scripts, export destinations, backups and reports. Identify who can read, change or delete each one. Include service identities, provider access and inherited permissions. Logs can contain sensitive information even when the tracker contains references only.
Restrict and preserve
Apply the approved access design to the source and destination, protect transfers, and retain recovery copies where the plan requires them. Separate evidence originals from analysis copies. Additional archive or immutable-storage features need their own design, cost and retention review; do not apply an irreversible retention lock as a trial.
Check the six protections
Review effective permissions and use an approved low-privilege test identity in a test location to check reading, editing and deletion are denied where intended. Check tool and configuration access as well as record files. Do not attempt to delete live audit evidence. Monitor authorized changes so misuse is also discoverable.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.8[a]
Review effective read access to audit information and safely check an unauthorized test identity is denied in a representative test location.
Records to keep: Record access list, effective permissions and read-access test result.
3.3.8[b]
Check who can modify source records, exports and retained copies. Test denial on a harmless representative copy.
Records to keep: Modification permissions, controlled originals and test result.
3.3.8[c]
Check deletion rights and the retention/recovery arrangement without deleting production records.
Records to keep: Deletion permissions, retention safeguards and safe test evidence.
3.3.8[d]
Check unauthorized access to collectors, agents, logging consoles and their configuration stores.
Records to keep: Tool access inventory, effective permissions and access checks.
3.3.8[e]
Check who can alter collection rules, agents, policies or scripts, including inherited and provider rights.
Records to keep: Configuration change rights, approval process and safe denial test.
3.3.8[f]
Check who can remove or disable logging tools and the controls that restrict that ability.
Records to keep: Removal/disable rights, safeguards and representative test or configuration evidence.
Records to keep
Access inventory for information, tools and collection configuration.
Effective permission reviews, safe test results and approved recovery arrangements.
If something is missing
If access is too broad, preserve current evidence and reduce it through an approved change with a recovery route. If evidence may have been altered or deleted, follow the incident process and state what can no longer be trusted.
Use what you already have
Use existing Windows and cloud permissions carefully. A shared drive open to all staff is not an appropriate default evidence store. An extra product cannot compensate for unrestricted administrators, weak service accounts or unprotected exports.
Not every administrator needs to change audit policy, disable collection or alter retention. Define the smaller group that does, and compare that decision with the permissions actually granted.
Official requirement and assessment objectives
Limit management of audit logging functionality to a subset of privileged users.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.3.9
Objective
Official text
3.3.9[a]
a subset of privileged users granted access to manage audit logging functionality is defined.
3.3.9[b]
management of audit logging functionality is limited to the defined subset of privileged users.
What to do
Name the authorized logging managers
Identify the people or roles allowed to manage logging for each system. Record why they need that authority, who approves it and how provider and emergency access are handled. Keep ordinary record review and export distinct from configuration management where the service supports it.
Apply the intended permissions
Review local and domain administrator rights, Windows audit-management rights, Purview role groups, Azure roles and archive permissions. Remove unnecessary grants through change control. Check nested groups and service principals as well as direct assignments. A custom group name does not restrict an existing broad administrator privilege.
Check effective management access
Use effective-permission review and an authorized test to confirm the intended manager can perform the necessary task and a non-manager cannot. Preserve emergency access and test recovery before removing the last working administrator. Recheck after role, provider or system changes.
Check each objective
Use these suggested checks with your scope and approved procedures. Record what you observed, the evidence reference and anything still unknown. One setting or sample event does not establish the full requirement.
3.3.9[a]
Locate the defined subset of privileged users allowed to manage each logging function and the reasons/approvals for their access.
Records to keep: Authorized manager list, scope of authority and emergency/provider arrangements.
3.3.9[b]
Compare actual effective management rights with that subset and examine safe allow/deny results for representative roles.
Records to keep: Role/group memberships, inherited access, test results and excess-access corrective work.
Records to keep
Approved logging-manager list and access approvals.
Effective access reviews, changes, test results and emergency-access checks.
If something is missing
If all administrators can still manage logging, record that gap and review the platform's control options. Do not claim separation based only on a policy statement. Fix unnecessary access while retaining a tested recovery path.
Use what you already have
Use built-in role separation before buying another platform. Check which permissions the service actually distinguishes; the name Audit Reader does not describe rights in Windows, Azure or a separate archive.
Set up the sources your Microsoft environment needs
These are starting paths to adapt and test. Microsoft 365 workload audit records, Entra sign-ins, Windows Security events and AVD diagnostics are separate sources. One does not provide all the others.
Microsoft 365 Commercial
In the correct tenant, check the subscription supports the needed Audit features and assign appropriate search/export roles. Microsoft distinguishes Audit Reader from Audit Manager; inspect actual membership and granted duties.
Open Microsoft Purview, select Audit and check recording status. Microsoft's auditing instructions say Business Basic, Business Standard and Business Premium may require manual enablement. Verify your tenant rather than assuming the default.
In Exchange Online PowerShell, connect to the correct cloud and tenant. The read-only command below checks unified audit ingestion. Run it in Exchange Online PowerShell, not the separate Security & Compliance session. True does not prove every workload or event you need is covered.
If recording is off, obtain change approval and use Microsoft's supported enablement steps. Allow for activation and ingestion delays. Perform a harmless supported activity in an approved test workspace, then search the correct account, operation and period. Check record contents and keep the reference.
This reads tenant configuration. It needs an authorized account and the correct Exchange connection. Do not grant broad administrative access just to follow a tutorial.
GCC, GCC High and Azure Government
Identify the actual Microsoft 365 and Azure cloud first. GCC and GCC High are distinct environments; Azure Government is a separate Azure environment. Use the matching portal and supported PowerShell connection for each service. Check the government service description and your subscription before following commercial screenshots.
Check recording status, a harmless supported event, required fields, retention, search/export roles and retrieval. Verify feature availability and endpoints in your cloud. Do not send government-cloud logs to a commercial workspace, free online analyzer or another destination without an approved handling and contract review. See Microsoft's GCC High planning guidance.
AD DS-only hosts
Select audit subcategories for domain controllers, servers and workstations according to their roles. Use the applicable Group Policy path: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Check effective policy on representative hosts and collect from the computer where the event is generated.
Object-access auditing may also need auditing entries on the selected file or folder. Pilot a harmless folder first; do not enable broad file auditing everywhere without checking volume and performance.
Hybrid joined hosts
Check Windows/AD DS auditing and Entra/cloud activity separately. Document which management system owns each device setting and resolve competing policies. Joining or syncing a device does not automatically collect its Windows Security log in the cloud.
Trace a test user through the relevant domain, cloud and host records using the appropriate identifiers. Keep failed collection and identity-link gaps visible.
Microsoft Entra joined hosts
Use your approved MDM policy, if licensed and supported, or an authorized local management method. The Audit policy CSP lists supported settings and Windows editions. Intune is not included just because Office is installed.
Check effective host policy and Windows events after assignment. An Entra sign-in record does not replace the local activity records needed for an endpoint.
Read-only Windows checks
Run only on an authorized in-scope host with suitable permissions. These read settings or records; they do not enable collection, configure alerts or establish compliance. Keep output in approved storage. An access error is an unresolved check, not proof that logging is off.
Use Command Prompt or PowerShell for auditpol and w32tm; Get-WinEvent needs PowerShell on Windows. The event query shows only a small recent sample. Open the relevant record to inspect actor, target and outcome fields; a row count or event number is not enough. Do not paste raw output into email or this site.
Forwarding and longer-term storage
Windows Event Forwarding and a Windows Event Collector can collect selected existing events using Windows components. You still need a supported collector, permissions, connectivity, capacity, protected storage and health monitoring. WEF does not enable source audit events or set log size. Plan authentication for your actual join model; a domain-based recipe does not automatically fit Entra-only devices. See Microsoft's WEF guidance.
Azure Monitor and other collectors can support larger deployments. Check destinations, retention, access and costs before enabling them. A SIEM is an option, not a named product mandated by these requirements. If manual exports cannot meet retention, alerting and timely review needs, record that operational gap and choose a more reliable method.
Azure Virtual Desktop
Configure required diagnostic categories on each relevant AVD resource, such as the host pool, application group and workspace. Verify the destination receives them. Collect session-host Windows events, identity activity and relevant application/file activity separately. Preserve needed host records before replacement or reimaging. AVD connection records do not describe every action inside the desktop.
Assign who manages collection, failures, retention and investigations across Microsoft, your provider and your team. Log Analytics ingestion, retention and alerting may incur costs. Check cloud availability and an approved destination. See AVD diagnostic setup and Azure diagnostic settings.
Do not confuse these retention periods
Microsoft 365 workload audit
Microsoft documents 180-day retention for Audit Standard. Longer retention and some richer events require eligible per-user Premium/add-on licensing and configuration. Check record type, user license, cloud and policy. This is a product limit, not a CMMC-prescribed period. See Audit capabilities.
Entra audit and sign-in history
Entra's native audit and sign-in reports retain seven days with Free and 30 days with P1/P2. They are separate from the Microsoft 365 unified audit log. Longer retention needs an eligible supported retention or collection arrangement; check license and storage costs. An upgrade does not restore expired records. See Entra retention.
Windows capacity and overwrite mode, archive settings and AVD destinations have separate limits. For each source, record the period needed, the period available, how you retrieve it and what happens if collection fails. Do not select “Never overwrite” without a capacity and failure-response design; a full log can stop recording.
Fictional practice, not observed customer results
Talk through three situations before an incident
These discussion exercises need no live tenant changes, failure injection, deleted records or production clock changes. The scenario is not a test result for your environment.
Supports 3.3.1, 3.3.3, 3.3.6
The sign-in history is already gone
Fictional example: Harbor Point Fabrication needs to examine a sign-in from 20 days ago. Its Entra Free tenant has no saved export or separate archive. The administrator expected Microsoft 365 auditing to keep the sign-in history for six months. A file activity search returns records, but the needed Entra sign-in record is unavailable.
Ask the group
Which source would contain the sign-in record, and what retention was actually available?
What can you establish from the records that remain, and what is still unknown?
Who will approve the required retention and a collection method the team can maintain?
How will you check that the next export or archive actually contains readable records?
What a useful response includes
Separate the Entra sign-in source from the Microsoft 365 unified audit log. Record the missing period and any other authorized sources worth checking.
Do not invent a sign-in result or assume a license upgrade will recover expired records. Preserve the evidence that still exists under the incident procedure.
Record the required retention, available retention, collection frequency, responsible person, access controls and any cost. Arrange collection before records expire.
Test retrieval from the chosen destination using harmless activity. Keep the gap open until the required period and contents can be demonstrated.
Talk it through
An existing subscription can provide useful logs without meeting the retention your organization needs. A file activity record does not replace a missing sign-in record. Treat the period you cannot reconstruct as a limitation in the investigation.
Keep a record: Use the log register for the retention gap and the review tracker for the investigation reference, known limits, owner and next check. These are fictional discussion results, not evidence that an archive works.
Supports 3.3.4, 3.3.7, 3.3.8
The collector looks quiet
Fictional example: a reviewer notices that one Windows host has sent no expected events since yesterday. The collector is reachable and other hosts are reporting. The last failure notification went to an unmonitored mailbox. A maintenance ticket also mentions a time-service problem on the missing host.
Ask the group
How do you distinguish no user activity from a collection failure?
Who should receive the alert, and how will you test that route without breaking production logging?
What source, time and receipt details should you preserve before making a repair?
What will demonstrate recovery, and how will you describe any missing interval?
What a useful response includes
Compare the source's expected activity or heartbeat with collector receipt times. Check the source log, forwarding status, storage and recent approved changes without clearing anything.
Use an approved test notification and a separate test source for any failure test. Record receipt, acknowledgment and the fallback contact. A calendar reminder to check tomorrow is not a failure alert.
Preserve available records and record time-zone and clock uncertainty. Inspect the time source and synchronization status; do not change the production clock as part of this exercise.
Repair through change control, confirm new expected records arrive, verify alert delivery and record whether missing records can be recovered. Keep unrecoverable gaps explicit.
Talk it through
An empty dashboard needs investigation. It does not prove nothing happened. A notification is useful only if the right person receives it and knows what to do.
Keep a record: Record the affected source, gap interval, alert delivery test, repair reference and follow-up in the review tracker. Keep raw event records in the approved evidence store.
Supports 3.3.2, 3.3.5, 3.3.6, 3.3.9
Which administrator made the change
Fictional example: a group membership change appears under a shared administrator account. Two people could use it. An AVD connection record identifies a session, but the team has not yet connected that session to the account change. The same broad administrator group can also change the logging configuration.
Ask the group
Which records and account identifiers could help explain the sequence?
What can the shared account record prove, and what can it not prove about a person?
Who needs to read records, and who actually needs to manage logging?
What should the report say if you cannot attribute the action reliably?
What a useful response includes
Build a timeline from the relevant identity, host and change records. Keep original identifiers, timestamps, source references and search limits; do not join records on display name alone.
Record the attribution gap. Use authorized account and session records to investigate without accusing either person based on a shared credential.
Plan individually attributable administration and a specifically approved subset for logging management. Separate search/export access from configuration privileges where the products allow it.
Report confirmed events, remaining uncertainty, retained source references and corrective work separately. A plausible timeline is not proof of who performed an action.
Talk it through
More records do not automatically solve shared-account attribution. The account design, session records, permissions and review process must work together.
Keep a record: Keep the fictional timeline and unresolved questions in the exercise notes. Use the real gap-and-action worksheet only for findings supported by your own evidence.
The Word exercise pack includes the same situations and space for notes. If you discover a real incident, stop the exercise and use the approved incident procedure.
Download the free audit materials
Use your existing Microsoft Office applications. Save local copies in an approved environment, replace the fields and have the responsible people review the documents before use. Blank inputs and fictional examples are separate. These templates do not calculate a compliance score.
Excel
Audit log register
List each source, the events and record fields you need, retention, collection checks and work still to do.
Use evidence references in the workbooks. Store originals separately with the required access, integrity and retention controls. A completed tracker is not an audit log or an official assessment result.
Turn missing evidence into a specific next action
For a fictional example, a team has chosen a retention period but cannot retrieve the oldest records it needs. In the Level 2 gap-and-action worksheet, it keeps 3.3.1[f] as Evidence to check, references the log register and assigns a retrieval/collection check to a named owner. It does not mark retention as met because a configuration screen shows the intended number.
Use the tracker for the result, missing interval and next action. Use Access Control for related access work and Awareness and Training for people assigned to review logs and respond to failures.
Sources and review notes
Sources reviewed October 27, 2026. Official text is separate from our suggestions. Product documentation supports the described features and limits; it does not prove your configuration works or establish that a service is suitable for your CUI.
Email cmmc@purposefulsecurity.com with a general description. Keep CUI, contracts, logs, account details, evidence and completed worksheets in your approved environment. Do not email them to us.