Know what you approved, check what is running and keep control of changes.
Work through all nine requirements and 44 assessment objectives. Start with the systems and Microsoft tools you already use. Build a clear record of baselines, inventory, change decisions and software restrictions, then check that the controls work.
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. Suggested checks and manual worksheet states are working aids.
Start with one system role and a safe change process
Confirm the scope. Include systems handling CUI and the services protecting them, cloud configuration, remote access and provider responsibilities. If the information or boundary is unclear, begin with Do we handle CUI? and your scoping work.
Separate approved from observed. Give the baseline a version and approval. Record the actual hardware, software, firmware and documentation in an inventory. Keep differences visible.
Assign decisions and access. Decide who requests, reviews, approves and implements changes, including emergencies. Define physical and logical access restrictions.
Check the platform and license. Confirm the Windows edition/build, device join, management source, tenant cloud and feature entitlement before choosing a path. Basic Office products do not include every endpoint or cloud control.
Test before wider rollout. Save the current configuration and agree recovery, including administrator access. Use a suitable test device, harmless files and approved test identities. Application-control or network changes can interrupt work or prevent startup.
Keep detailed configurations, inventories and completed records in your approved environment. Use references in ordinary trackers. This website does not accept CUI, configuration exports, credentials or exercise answers.
Know the approved configuration and what you actually have
A baseline describes the configuration your organization has approved. An inventory records what exists. Keep both current so a new device, changed cloud setting or retired host does not disappear from the picture.
Official requirement and assessment objectives
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.1
Objective
Official text
3.4.1[a]
a baseline configuration is established.
3.4.1[b]
the baseline configuration includes hardware, software, firmware, and documentation.
3.4.1[c]
the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle.
3.4.1[d]
a system inventory is established.
3.4.1[e]
the system inventory includes hardware, software, firmware, and documentation.
3.4.1[f]
the inventory is maintained (reviewed and updated) throughout the system development life cycle.
What to do
Define baselines by system role
Cover hardware, software, firmware and supporting documentation. Include relevant Windows settings, Microsoft 365 services, security tools, network devices and AVD images. Give each baseline an owner, version, approval and scope. A vendor recommendation is a starting point; record your approved choices and exceptions.
Connect the inventory to those baselines
Record approved identifiers and locations, hardware models, installed software and versions, firmware versions, and document references. Identify the assigned baseline and responsible owner for each system or group. Keep the detailed inventory restricted; the free register can hold references rather than copying sensitive contents.
Maintain records through the lifecycle
Update records when you acquire, build, change, replace or retire a system. Reconcile representative devices and services with the inventory and approved state. Record discrepancies, dates, owners and repairs. A discovery scan alone does not approve a configuration, and a spreadsheet alone does not prove it is deployed.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.1[a]
Locate an approved, versioned baseline for each relevant system role and check that its scope is clear.
Records to keep: Baseline versions, scope, owner and approval.
3.4.1[b]
Check the baseline includes hardware, software, firmware and documentation, not only Windows policy values.
Records to keep: Baseline contents and references for all four classes.
3.4.1[c]
Follow a build, change and retirement example through the baseline review and update process.
Records to keep: Dated reviews, change history and superseded versions retained as required.
3.4.1[d]
Find the system inventory and reconcile a representative sample with actual systems and services.
Records to keep: Inventory location, scope, observed sample and discrepancies.
3.4.1[e]
Check inventory coverage for hardware, software, firmware and documentation, including version and reference details needed to manage them.
Records to keep: Inventory fields, linked records and missing information.
3.4.1[f]
Check how acquisition, changes, replacement and disposal update the inventory and how missed updates are found.
Records to keep: Lifecycle records, reconciliation results and corrective actions.
Records to keep
Approved baseline and exception versions, owners and system scope.
Inventory and documentation references, lifecycle updates and reconciliation results.
If a check fails
When the records disagree, preserve the approved and observed versions. Establish whether the system changed without approval or the records were missed. Correct the cause through change control and recheck. Do not quietly redefine the baseline to match an unexplained difference.
Working with a small budget
Use Excel, existing asset records and supported Windows inspection tools to begin. Policy Analyzer can help compare Windows policies. Neither replaces firmware records, cloud configuration records or a person maintaining the inventory.
Write down the required settings and check they take effect. A policy assigned to a device can fail, conflict with another policy or cover only part of the configuration.
Official requirement and assessment objectives
Establish and enforce security configuration settings for information technology products employed in organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.2
Objective
Official text
3.4.2[a]
security configuration settings for information technology products employed in the system are established and included in the baseline configuration.
3.4.2[b]
security configuration settings for information technology products employed in the system are enforced.
What to do
Choose settings for each role
Compare an appropriate Microsoft baseline with your applications, system duties and security needs. Record the selected values, reason, management source and approved exceptions. Include relevant server, browser, Office and cloud settings; a Windows baseline does not configure everything else.
Pilot the chosen management path
Use GPO for appropriate AD DS-managed settings, supported MDM policies where licensed, or supported local policy for a small managed environment. Save the current configuration and test changes on a representative device. In a hybrid environment, establish which source manages each setting and investigate conflicts rather than assuming one source always wins.
Check the effective result
Inspect a representative device or workload after deployment and required refresh or restart. Compare actual values and a harmless behavior check with the approved baseline. Record unsuccessful settings, exceptions and work still to do. Recheck following relevant updates or configuration changes.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.2[a]
Find the approved security values and confirm they are part of the applicable baseline.
Records to keep: Versioned settings, scope, management source and exceptions.
3.4.2[b]
Compare effective settings and representative behavior with the approved values across applicable systems.
Records to keep: Dated observations, policy results, safe test results and unresolved failures.
Records to keep
Approved security values and exceptions.
Pilot, deployment and effective-setting checks with configuration references.
If a check fails
If a setting disrupts an application, use the approved recovery route and retain the failed result. Review the security effect of an exception before approving it. Removing a policy assignment may not restore its previous settings; check the supported behavior of that setting and verify the actual recovery.
Working with a small budget
The Microsoft Security Compliance Toolkit is available without buying Intune. Existing GPO or supported local policy can help, but still need testing and maintenance. Check subscriptions before choosing a cloud management feature.
Someone should be able to follow a change from the original request through review, the approval or rejection, and what actually happened. Rejected requests matter too.
Official requirement and assessment objectives
Track, review, approve or disapprove, and log changes to organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.3
Objective
Official text
3.4.3[a]
changes to the system are tracked.
3.4.3[b]
changes to the system are reviewed.
3.4.3[c]
changes to the system are approved or disapproved.
3.4.3[d]
changes to the system are logged.
What to do
Track requests before work starts
Assign an identifier, owner, affected systems, baseline version, business reason and proposed timing. Include routine configuration, software, firmware, cloud and image changes. Define how recurring approved changes are authorized and recorded; do not use a broad category to bypass review.
Review and decide
Check the security impact, dependencies, test and recovery plans and the people needed. An authorized approver records approval or disapproval and any conditions. The person doing the work must be able to find that decision before implementation.
Record the actual result
Record who changed what and when, the outcome, deviations, test evidence and baseline/inventory updates. Define emergency authority and minimum pre-change impact review. If emergency procedures require a later review, label it as later review, not a backdated approval.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.3[a]
Trace representative configuration changes to uniquely identified requests and their affected systems.
Records to keep: Request register, scope and assigned owner.
3.4.3[b]
Examine reviews that considered impact, dependencies, tests and recovery before implementation.
Records to keep: Dated review and supporting references.
3.4.3[c]
Find the authorized decision for approved and disapproved requests, including conditions and timing.
Records to keep: Approver, decision, date and emergency authority where applicable.
3.4.3[d]
Compare the request and decision with the actual implementation or rejected-request record.
Records to keep: Actor, time, actual change, outcome, deviations and updated records.
Records to keep
Requests, reviews, approvals and disapprovals.
Implementation history, results, exceptions and linked baseline/inventory updates.
If a check fails
If an unapproved change is found, preserve the record and assess its effect. Use the incident route if warranted. Decide whether to reverse or formally review it through the approved process; do not invent an earlier approval to close the ticket.
Working with a small budget
A restricted Excel register and existing ticket system can support a small team. The tool matters less than keeping the review, decision and actual outcome connected and accessible to authorized staff.
Review the security impact before making the change
Ask what the change could expose, weaken or interrupt before someone applies it. A successful installation does not establish that the security impact was acceptable.
Official requirement and assessment objectives
Analyze the security impact of changes prior to implementation.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.4
Objective
Official text
3.4.4
Determine if the security impact of changes to the system is analyzed prior to implementation.
What to do
Understand the affected path
Identify the systems, CUI flows, accounts, connections and provider responsibilities involved. Consider permissions, exposed services, authentication, logging, encryption, backups and application dependencies as relevant. State what is unknown and who can resolve it.
Choose checks and a safe failure response
Compare the current and proposed configuration. Define the security and business checks needed, a representative test, stop conditions and supported recovery. Review new external access or software separately rather than assuming the supplier has covered your obligations.
Record the review before implementation
Put the reviewer, date, findings, conditions and decision reference in the change record. Resolve significant unanswered questions before proceeding. An emergency can require a shorter review, but discovering the impact after deployment is not the pre-change analysis this requirement calls for.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.4
For representative changes, examine a security impact analysis completed before implementation and compare it with the affected configuration and actual timing.
Records to keep: Dated analysis, reviewer, affected scope, findings, conditions, decision and implementation time.
Records to keep
Pre-change security impact analysis and unresolved questions.
Test/recovery criteria and links to the decision and actual implementation.
If a check fails
If a missed impact is found, stop further rollout where appropriate and assess the affected systems. Use the approved recovery and incident routes. Record the original omission and improve the review; a later analysis does not change when the original review occurred.
Working with a small budget
Use a short structured review in the existing change record. A small team can still ask the important questions before acting; avoid replacing the analysis with a checkbox marked no impact.
Limit who can make changes and how they gain access
Changes can require physical access as well as administrator permissions. Define and approve both, then check the restrictions actually apply to employees, suppliers and providers.
Official requirement and assessment objectives
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.5
Objective
Official text
3.4.5[a]
physical access restrictions associated with changes to the system are defined.
3.4.5[b]
physical access restrictions associated with changes to the system are documented.
3.4.5[c]
physical access restrictions associated with changes to the system are approved.
3.4.5[d]
physical access restrictions associated with changes to the system are enforced.
3.4.5[e]
logical access restrictions associated with changes to the system are defined.
3.4.5[f]
logical access restrictions associated with changes to the system are documented.
3.4.5[g]
logical access restrictions associated with changes to the system are approved.
3.4.5[h]
logical access restrictions associated with changes to the system are enforced.
What to do
Define the physical restrictions
Include access to rooms, racks, device consoles, removable media and maintenance work where relevant. Specify permitted people, escorts, timing and authorization. Document provider responsibility for hosted hardware; do not omit physical access because the systems are in the cloud.
Define the logical restrictions
Specify the accounts and roles permitted to change GPO, MDM, cloud settings, images, application-control rules and local configuration. Include service identities, deployment pipelines and emergency access. Separate approval from implementation where practical and state the actual responsibilities.
Approve and enforce both
Record approval of the restrictions, apply the relevant access controls and review effective rights. Use an authorized test identity or representative access review to check restrictions without entering secure areas or modifying production. Link the access permission to the change authorization rather than treating administrator status as permission for every change.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.5[a]
Identify the defined physical restrictions associated with changes, including provider boundaries.
Records to keep: Physical change-access rules and responsibility map.
3.4.5[b]
Locate the documented physical restrictions and how staff obtain authorization.
Records to keep: Written procedure, locations, permitted roles and maintenance conditions.
3.4.5[c]
Find authorized approval of the physical restrictions.
Records to keep: Approver, approved version and effective date.
3.4.5[d]
Check the actual physical access arrangements against the approved restrictions.
Records to keep: Access review, visitor/maintenance process and authorized observations or provider evidence.
3.4.5[e]
Identify logical restrictions for human, service and deployment accounts that can make changes.
Records to keep: Role and privilege definitions for the relevant management paths.
3.4.5[f]
Locate documented logical restrictions and the authorization process.
Records to keep: Access procedure, permitted roles, scope and emergency arrangements.
3.4.5[g]
Find authorized approval of the logical restrictions.
Records to keep: Approver, approved rights and version/date.
3.4.5[h]
Review effective rights and safely check a representative unauthorized test identity cannot use the restricted change path.
Records to keep: Effective access results, safe denial check and unresolved inherited/provider rights.
Records to keep
Defined, documented and approved physical and logical restrictions.
Actual access reviews, safe test results and provider/customer responsibilities.
If a check fails
When access is too broad, preserve the finding and reduce rights through an approved change with a recovery account or route. Check service and deployment dependencies first. If someone has used unauthorized access, follow the incident process rather than only updating the permissions.
Working with a small budget
Start with existing facility controls and Windows/cloud role assignments. A new privileged-access product is not required just to document who may act, but the restrictions still need to be enforced and checked.
Define the capabilities a system needs before deciding what to remove. A CUI workstation, domain controller and AVD image have different jobs and different dependencies.
Official requirement and assessment objectives
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.6
Objective
Official text
3.4.6[a]
essential system capabilities are defined based on the principle of least functionality.
3.4.6[b]
the system is configured to provide only the defined essential capabilities.
What to do
Define essential capabilities by role
List business functions and supporting capabilities, including management, protection, logging, backup and recovery. Identify who owns each decision and which applications or services depend on it. Do not confuse a rarely used recovery function with an unnecessary one.
Configure for that purpose
Compare the installed roles, features, applications and services with the approved role. Restrict or remove unnecessary capabilities through a tested change. Keep justified exceptions specific, approved and reviewed. A standard image needs its own role and dependency review.
Check the result and business use
Inspect the actual configuration and use a harmless task to verify required functions still work. Recheck after major updates, role changes or image replacements. Keep unexplained extra capabilities and missing evidence open for follow-up.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.6[a]
Find the defined essential capabilities for each system role and the basis for those decisions.
Records to keep: Role/capability list, owners, dependencies and approved exceptions.
3.4.6[b]
Compare actual configuration and a representative safe task with the defined essential capabilities.
Records to keep: Configuration observations, functional checks, restrictions and discrepancies.
Records to keep
Approved role/capability definitions and dependency decisions.
Actual configuration checks, safe task results and exceptions.
If a check fails
If a removal breaks a required task, restore the approved working configuration using the tested route. Review why the dependency was missed before trying again. Do not disable management, security or recovery capabilities simply to make a feature list shorter.
Working with a small budget
Existing Windows inspection tools and documented application dependencies can help. The main investment is deciding what each role needs and checking the result, not buying a hardening product.
Restrict unnecessary programs, functions, ports, protocols and services
Make a separate decision for each of the five categories. Identify what is essential, define how nonessential use is restricted, and check the chosen restrictions. An installed-program list alone does not cover this requirement.
Official requirement and assessment objectives
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.7
Objective
Official text
3.4.7[a]
essential programs are defined.
3.4.7[b]
the use of nonessential programs is defined.
3.4.7[c]
the use of nonessential programs is restricted, disabled, or prevented as defined.
3.4.7[d]
essential functions are defined.
3.4.7[e]
the use of nonessential functions is defined.
3.4.7[f]
the use of nonessential functions is restricted, disabled, or prevented as defined.
3.4.7[g]
essential ports are defined.
3.4.7[h]
the use of nonessential ports is defined.
3.4.7[i]
the use of nonessential ports is restricted, disabled, or prevented as defined.
3.4.7[j]
essential protocols are defined.
3.4.7[k]
the use of nonessential protocols is defined.
3.4.7[l]
the use of nonessential protocols is restricted, disabled, or prevented as defined.
3.4.7[m]
essential services are defined.
3.4.7[n]
the use of nonessential services is defined.
3.4.7[o]
the use of nonessential services is restricted, disabled, or prevented as defined.
What to do
Work through all five categories
List essential programs, functions, ports, protocols and services for each role. Include direction and scope for network access, business and management dependencies, owner and reason. Treat an unfamiliar listening port as a question to investigate, not an instruction to disable it immediately.
Define nonessential use and restrictions
Record what is prohibited, disabled or allowed only under a narrow approved exception in each category. Choose the relevant controls, such as role/feature removal, service settings, host/network firewall rules or software execution policy. A list without implemented restrictions is incomplete.
Test the intended boundary
Use approved harmless checks in a suitable test environment to confirm restricted use is prevented and essential tasks still work. Record actual settings, applicable scope, expected and observed results, and recovery. Recheck exceptions and expiry dates. Do not probe third-party systems or disable production services for an exercise.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.7[a]
Identify the programs defined as essential for the system role.
Records to keep: Approved essential-program list and business dependencies.
3.4.7[b]
Find the defined restrictions on nonessential programs and any permitted exceptions.
Records to keep: Program restrictions, scope, reasons and exception conditions.
3.4.7[c]
Check program restrictions are implemented as defined using effective settings and safe tests.
Records to keep: Program control settings, allowed/denied results and gaps.
3.4.7[d]
Identify the functions defined as essential for the system role.
Records to keep: Approved function/capability list and dependencies.
3.4.7[e]
Find the defined restrictions on nonessential functions.
Records to keep: Function restrictions, scope and approved exceptions.
3.4.7[f]
Check nonessential function use is restricted as defined.
Records to keep: Effective feature/configuration results and safe functional checks.
3.4.7[g]
Identify essential ports, their purpose, direction and permitted sources or destinations.
Records to keep: Approved port matrix and owner/dependency references.
3.4.7[h]
Find defined restrictions on nonessential port use.
Records to keep: Port rules, network/host scope and exceptions.
3.4.7[i]
Check the port restrictions at the applicable host and network boundaries with authorized safe tests.
Records to keep: Effective rules and permitted/denied connection results.
3.4.7[j]
Identify the protocols defined as essential and where they are needed.
Records to keep: Approved protocol list, scope and dependencies.
3.4.7[k]
Find defined restrictions on nonessential protocols.
Records to keep: Protocol restrictions, exceptions and management source.
3.4.7[l]
Check actual settings and approved safe tests demonstrate the defined protocol restrictions.
Records to keep: Effective protocol configuration and observed results.
3.4.7[m]
Identify essential services and the business, management or protection functions they support.
Records to keep: Approved service list and dependencies.
3.4.7[n]
Find defined restrictions on nonessential services.
Records to keep: Service restrictions, scope, exceptions and owner.
3.4.7[o]
Compare actual service configuration and safe checks with the defined restrictions.
Records to keep: Effective service state/configuration, functional results and unresolved differences.
Records to keep
Five-category essential-use list, restriction decisions and exceptions.
Effective settings, authorized tests, dependencies and recovery references.
If a check fails
If a restriction interrupts essential work, use the approved recovery steps and retain the failed check. Review the dependency, exposure and narrower alternatives before approving an exception. Do not broadly reopen ports or re-enable services without documenting the effect.
Working with a small budget
Windows includes role/feature, service and firewall controls. They can support these decisions without another subscription, but still need the right platform support, careful administration and a maintained five-category record.
Decide which software may run and enforce that decision
Choose a software execution approach: block specified software, or allow only specified software. Document the choice and its limits. Permission to install and permission to run are separate questions.
Official requirement and assessment objectives
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.8
Objective
Official text
3.4.8[a]
a policy specifying whether whitelisting or blacklisting is to be implemented is specified.
3.4.8[b]
the software allowed to execute under whitelisting or denied use under blacklisting is specified.
3.4.8[c]
whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
What to do
Specify the policy and software
Record whether the policy uses deny by exception (a denylist) or deny all, permit by exception (an allowlist). Define the software and rule coverage, including scripts and installers where relevant, approved exceptions and who maintains it. Do not describe an incomplete denylist as an allowlist.
Prepare a controlled pilot
Check the App Control for Business or AppLocker feature table for the exact Windows build, edition and management path. Test on an isolated representative device. For App Control, review audit-mode events before enforcement and include required applications, updates, drivers, scripts and recovery tools. Audit mode records what would be blocked; it does not block.
Enforce only with a tested recovery route
Before enforcement, agree stop conditions and the supported policy update/removal process, including offline recovery where necessary. Signed base App Control policies have special removal requirements and a mistake can prevent startup. Use an approved harmless allowed and denied case to check enforcement, then progress through approved test groups. No blanket policy from this page should be deployed to production.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.8[a]
Find the specified denylist or allowlist execution policy, its scope and its management responsibilities.
Records to keep: Approved policy approach, platform scope and exceptions.
3.4.8[b]
Identify the software and rule definitions that are allowed or denied under that policy.
Records to keep: Versioned rule set, software identifiers and approved exceptions.
3.4.8[c]
On an authorized test system, check an allowed and denied case in enforcement mode and compare actual results with the policy.
Records to keep: Effective policy/mode, safe execution results, event references and tested recovery route.
Records to keep
Execution policy choice, allowed/denied software and versioned rules.
Audit observations, enforcement test, rollout decision and recovery procedure.
If a check fails
Stop a failing rollout and use the supported procedure for the deployed policy type and Windows version. Do not delete signed policy files or disable broad protections as a guessed fix. Ensure the deployment source will not simply reapply an unwanted policy. Recheck essential tasks and restrictions after recovery.
Working with a small budget
Windows provides application-control capabilities on supported platforms. Central deployment, reporting and optional security services may require licenses and operating effort. Read the feature table; do not assume a basic Office license includes endpoint management or advanced hunting.
Set the rules for user-installed software and check what appears on the systems. Removing administrator rights is useful, but per-user applications, portable tools and extensions can remain possible.
Official requirement and assessment objectives
Control and monitor user-installed software.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.4.9
Objective
Official text
3.4.9[a]
a policy for controlling the installation of software by users is established.
3.4.9[b]
installation of software by users is controlled based on the established policy.
3.4.9[c]
installation of software by users is monitored.
What to do
Write a usable installation policy
Define what users may install, what needs approval, permitted sources, who reviews requests and how exceptions expire. Include relevant per-user installations, extensions and nonstandard deployment routes. Make the policy available to users and the people supporting them.
Apply the installation controls
Use suitable account restrictions, approved deployment and platform controls. Check behavior with a standard test identity and harmless software in an isolated environment. Link software execution restrictions to 3.4.8 where needed; denying machine-wide installation alone does not establish that all unapproved software is prevented.
Monitor and follow up
Define who reviews installation/inventory changes, the chosen review timing or alerts, and what evidence is available for user-scope activity. Compare discoveries with approvals and investigate gaps. Record removal or approval decisions and recheck. A one-time installed-app list is not an ongoing monitoring process.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A sample setting or completed template does not establish the full requirement.
3.4.9[a]
Locate the established user-installation policy, approval route, permitted sources and exception rules.
Records to keep: Approved policy, scope, user guidance and responsible roles.
3.4.9[b]
Compare actual installation controls and safe standard-user tests with the stated policy, including relevant per-user paths.
Records to keep: Effective privileges/settings, approval records, safe results and limits.
3.4.9[c]
Examine installation monitoring or dated reviews and follow an unapproved or fictional discovery through a decision and recheck.
Records to keep: Monitoring coverage, review records, owner, follow-up and remaining blind spots.
Records to keep
User-installation policy, approval and exception records.
Monitoring/review results, discovered differences and resolved or open follow-up.
If a check fails
Preserve relevant records before removing an unexpected application. If it could be malicious, follow the incident process rather than trying it. For an ordinary unauthorized app, assess business and data dependencies, approve removal or an exception, update records and verify the result.
Working with a small budget
Use existing account controls, approved deployment records and a repeatable inventory review. Additional inventory tools can improve coverage; first establish which user and system locations the method actually sees and who acts on its findings.
Use these paths to plan and check your implementation. Exact screens, supported settings and licensing vary. Confirm them against the linked documentation for the product and cloud you use. Configuration management also covers non-Microsoft systems in your scope.
AD DS and hybrid joined Windows
Identify the domain, device role, applied GPOs, local settings and any MDM management. Back up the applicable policy and record the existing version before an approved change.
Compare the matching Microsoft security baseline with your chosen values. Policy Analyzer can help compare policy sets; LGPO can import or export local policy. Applying either policy changes settings, so perform the approved pilot first.
Use GPO results and direct setting/behavior checks to compare the effective result. In hybrid management, document the source for each setting and resolve conflicts. A successful GPO or MDM assignment is only one part of the evidence.
Microsoft Entra joined Windows
Check actual enrollment and management. Entra join by itself does not apply an Intune baseline or grant an Intune license.
If licensed and supported, use an approved Intune baseline or configuration profile for the selected settings. Record the profile version, assignments, exclusions and conflicts, then inspect the endpoint result.
For a small environment without MDM, supported local configuration can be a starting path. Plan who applies, checks and maintains it on every applicable device. Local policy is not a central monitoring service.
Commercial Microsoft 365 and Azure
Keep tenant and workload configuration decisions alongside endpoint baselines. Record the actual service, license, permitted administrator roles, approved settings and evidence of the observed state. A Windows baseline does not configure Exchange, SharePoint, Teams or an Azure subscription. Confirm the contractual and data-handling suitability of the cloud separately; this guide does not approve a commercial service for your CUI.
GCC, GCC High and Azure Government
Identify each service instance before selecting instructions or exporting a policy. GCC uses the commercial Intune instance; GCC High and DoD use its government service. Microsoft 365 and Azure have their own cloud boundaries. Check the government service description for current feature differences, endpoints and availability. Keep configuration exports and evidence in the approved environment; do not assume a commercial integration or preview feature is available or suitable.
Azure Virtual Desktop images and session hosts
Version the approved image, application set and related GPO/MDM policies. Record each host's image version, join, management, agent/application versions and deviations. Include profile storage and the surrounding network and identity configuration in the appropriate records.
Build and test a replacement image outside the production pool. Use harmless files to check sign-in, required applications, profile access, security settings, permitted connections and logging. A successful image build does not establish a working user session.
Use the supported, approved host replacement/update process for your cloud and host-pool design. Plan user notification and session draining. Preserve an approved recovery image and protect profile data before replacing hosts; an older image does not recover user data or automatically undo external configuration changes.
Reconcile new and retired hosts with the inventory and check effective policies after deployment. Correct repeated manual host changes in the approved image or management process where appropriate, rather than rebuilding the same discrepancy next time.
Read-only Windows inspection examples
An authorized administrator can use the following examples on a supported Windows system. Some commands need elevation or modules available on the target. They read selected information; they do not establish a complete inventory or prove every control. Keep output restricted and compare it with the approved record. A listening port alone does not establish its purpose or external reachability.
Use Excel and Word for the records, and supported Windows/GPO tools where they fit. Microsoft provides the Security Compliance Toolkit for baseline work. App Control and AppLocker capabilities depend on the Windows platform and management method. Intune, advanced reporting, Azure compute/storage and other cloud services may require additional subscriptions or usage charges. Free tools still need administration, testing and a person who follows up.
These situations are fictional. Discuss them with the people who request, approve and carry out changes. Use the Word exercise pack for facilitator notes and record technical checks as not performed until you actually perform them safely.
Supports 3.4.3, 3.4.4, 3.4.5, 3.4.7
The supplier needs a firewall exception today
Fictional exercise: a supplier asks the help desk to open a port and install a support service on a CUI workstation before a delivery deadline. The request says urgent but has no security review, named approver or removal date. No change has been made.
Discuss
What must be understood before anyone approves the change?
Who may authorize and carry out the physical or logical work?
How will the team limit the exception, test it and remove it?
What a useful response includes
Record the requested service, source and destination, business reason, affected baseline and CUI access path. Establish whether a narrower approved support method exists.
Analyze the security impact before implementation. Record approval or disapproval, permitted administrators and any physical access restrictions. An urgent label is not approval.
If approved, set the scope, end date, test criteria and supported recovery steps. Pilot on an appropriate test system before rollout. Record the actual change and later verify removal and restored restrictions.
Lesson: A completed ticket is useful only if it shows the decision, impact review and actual result. If the request is rejected, retain that decision too. Use the emergency process when justified; never backdate an approval.
Record: Save a fictional change-register row with the impact review, decision, authorized access, test, recovery plan and remaining questions. This discussion does not prove a firewall or support service was tested.
Supports 3.4.1, 3.4.2, 3.4.6
The new AVD host does not match the approved image
Fictional exercise: an AVD host reports a successful policy assignment, but a required setting differs from the approved baseline. Another host has a manually installed application that is missing from the image record. The team has not yet established which management source wins.
Discuss
Which records describe the approved state and which show the observed state?
Could image versions, GPO, MDM, local settings or an exception explain the difference?
What must work before a replacement host is accepted?
What a useful response includes
Compare the approved image and baseline versions with the host inventory and effective settings. Keep the mismatch open rather than treating assignment success as enforcement.
Trace the affected setting and software to the actual management source. Check the host join and enrollment, assignment scope, conflicts and change history. Agree a repair through change control.
Test a replacement in an appropriate test pool with harmless files. Check sign-in, required applications, profile access, security settings and logging. Preserve an approved recovery image and protect profile data before changing production hosts.
Lesson: Replacing a host does not restore a missing user profile or prove all settings applied. Record the image, policy and observed result separately, and update the inventory when hosts are replaced or retired.
Record: Record fictional approved and observed configuration references, the discrepancy, owner, proposed repair and acceptance checks. Do not use a live CUI host for this exercise.
Supports 3.4.8, 3.4.9
A standard user can still run an unapproved application
Fictional exercise: staff do not have local administrator rights, but a user can run a portable utility from a user-writable folder. The team also discovers an application-control policy is in audit mode. No malicious file is involved.
Discuss
What do installation restrictions cover, and what do they leave open?
Is the chosen software execution policy actually enforced?
How can the team test a correction without locking out essential work?
What a useful response includes
Compare the written installation policy with machine-wide, per-user, portable and browser-extension paths relevant to the environment. Record how installations and changes are monitored.
Confirm whether the approved execution policy is a denylist or an allowlist and which software it covers. Audit-mode observations help prepare enforcement; they do not demonstrate blocking.
Use an approved harmless test application on an isolated test device. Check an allowed and a denied case, required scripts and administrator recovery. Follow the supported deployment and removal procedure before considering a wider enforcement change.
Lesson: Removing administrator rights can reduce risk but does not prevent every application from running. Installation approval, monitoring and execution control need separate checks. Do not deploy a blanket blocking policy to production as a trial.
Record: Keep a fictional policy decision, permitted and denied software references, monitoring plan, safe test criteria and recovery requirements. Record technical checks as not performed until someone actually carries them out.
Five free Word and Excel materials
Download a copy and adapt it in your approved environment. Blank inputs and fictional examples are separate. These templates do not calculate a compliance score.
Excel
Baseline and configuration register
Record approved baselines, inventory references, observed settings, exceptions and the next check.
Use evidence references in the workbooks. Keep detailed inventories, settings, exports and decisions under the required access controls. Ready for record review means a row is prepared for a person to examine; it is not a compliance result.
Turn a configuration difference into a clear next action
In a fictional example, an AVD host has the intended baseline assigned, but the team has not checked the actual settings. In the Level 2 gap-and-action worksheet, it keeps 3.4.2[b] as Evidence to check, references the configuration register and assigns a setting check to an owner. It does not mark the objective met because the assignment screen shows success.
Sources reviewed October 27, 2026. Official text is separate from our suggestions. Product documentation supports the described features and limits; it does not establish that your configuration works or that a service is suitable for your CUI.
Email cmmc@purposefulsecurity.com with a general description. Keep CUI, contracts, configurations, account details, evidence and completed worksheets in your approved environment. Do not email them to us.