Understand the risk, find the weaknesses and verify the correction.
Work through all three requirements and nine assessment objectives. Define assessment and scanning frequencies, examine consequences for operations, assets and individuals, scan systems and applications, and remediate according to risk. Start with the system boundary and evidence you already have.
Sources reviewed October 28, 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.
Confirm the CUI system. Identify processing, storage, transmission, dependencies and customer/provider duties. Use Do we handle CUI? when the information status needs clarification.
Define two schedules. Approve the risk-assessment frequency and the system/application vulnerability-scanning frequency. The requirements do not impose one universal annual interval or patch deadline.
Assess consequences. Explain threats, vulnerabilities, safeguards, likelihood, impact and uncertainty for organizational operations, assets and individuals. CVSS measures technical severity and is only one input.
Keep scanning coverage visible. Check systems and applications on schedule and when new relevant vulnerabilities are identified. Failed authentication, missing targets and unsupported applications remain gaps.
Verify the correction. Link the risk decision to an owner, approved change and actual rescan or supported validation. A plan, dashboard or closed ticket does not show that the correction worked.
Use fictional records for discussion. No active scan, exploit test, real patch or production change is part of these exercises. Separate authorization is needed for technical checks, including exact scope, provider permission, impact limits and recovery. Keep CUI, credentials, detailed inventories, findings and evidence in approved protected storage. This website does not receive worksheets or exercise answers.
Understand what a CUI system could do to your organization and the people affected by it. Include mission, functions, image or reputation, organizational assets and individuals. A list of technical severity numbers is not an assessment of these consequences.
Official requirement and assessment objectives
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.11.1
Objective
Official text
3.11.1[a]
the frequency to assess risk to organizational operations, organizational assets, and individuals is defined.
3.11.1[b]
risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
What to do
Approve a repeatable assessment schedule and method
Define the frequency, accountable owner, scope, likelihood and impact criteria, evidence sources and decision authority. Link the assessment to the actual CUI system boundary and processing, storage and transmission. Select additional review triggers such as a major change or new threat where useful. The requirement does not prescribe a universal annual interval.
Evaluate plausible events and their consequences
Connect threats, vulnerabilities, existing safeguards and uncertainty to likely consequences. Address disrupted operations, damaged assets and harm to individuals, including relevant confidentiality, integrity and availability effects. Include dependencies and provider responsibilities. Explain the basis for likelihood and impact rather than copying CVSS into a risk field.
Perform, approve and revisit the assessment
Keep dated actual assessments at the defined frequency, participants, evidence references, decisions and next review date. Assign treatment and verification to responsible people. Risk acceptance requires the approved authority and review timing; it does not erase an unmet security requirement or prove remediation. Escalate overdue assessments and unknown coverage.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the assessment, scanning or remediation actually occurred.
3.11.1[a]
Find the approved frequency for assessing risk to operations, assets and individuals and verify who owns the schedule.
Records to keep: Approved method, scope, frequency, responsibility, decision authority and next scheduled review.
3.11.1[b]
Trace dated assessments to the defined frequency and the CUI system. Sample the analysis of effects on operations, assets and individuals, including uncertainty and existing safeguards.
Records to keep: Actual completed assessment records, supporting references, likelihood/impact rationale, responsible participants and treatment decisions.
Records to keep
Approved assessment frequency and method, CUI boundary and customer/provider responsibilities.
Dated assessments showing risk rationale for operations, assets and individuals, decisions, review authority and next review.
If a check fails
If a review is late or incomplete, record the missing scope and assign a dated assessment. Escalate urgent exposure through the approved process, apply authorized temporary safeguards and revisit the risk decision after reliable evidence arrives. Do not backdate an assessment or call unknown risk low.
Working with a small budget
Use the free register, existing asset/boundary records and a focused meeting with system, business and security owners. Expert analysis may be needed for unfamiliar dependencies. An Office subscription stores decisions but does not perform a risk assessment.
Scan systems and applications on schedule and for new vulnerabilities
Keep two coverage questions visible: did you scan the organizational systems, and did you scan their applications? Both periodic scans and scans triggered by newly identified relevant vulnerabilities need actual results, including failed, unreachable and unsupported targets.
Official requirement and assessment objectives
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.11.2
Objective
Official text
3.11.2[a]
the frequency to scan for vulnerabilities in organizational systems and applications is defined.
3.11.2[b]
vulnerability scans are performed on organizational systems with the defined frequency.
3.11.2[c]
vulnerability scans are performed on applications with the defined frequency.
3.11.2[d]
vulnerability scans are performed on organizational systems when new vulnerabilities are identified.
3.11.2[e]
vulnerability scans are performed on applications when new vulnerabilities are identified.
What to do
Define frequency, coverage and safe authorization
Set the scanning frequency for systems and applications and map each in-scope asset to a supported assessment method. Identify OS, installed applications, web applications, dependencies and appliances as relevant. Record exclusions and gaps. Before any active scan, approve exact targets, provider permission, credentials, permitted checks, maintenance window, load limits, stop contacts and recovery. Do not scan shared cloud infrastructure without authorization.
Perform periodic scans and check completion
Use current supported tools and vulnerability content for the approved scope. Verify authentication and coverage where applicable, actual scan times, successful targets and failures. Reconcile scan output with system and application inventories. A green dashboard, missing finding or onboarded endpoint alone does not prove that every application was assessed. Antivirus malware scans and port discovery alone are insufficient vulnerability coverage.
Respond to new relevant vulnerability information
Assign an owner to review vendor and other authoritative advisories, establish applicability and initiate scans of affected systems and applications when a new vulnerability is identified. Do not wait for the next periodic run. If detection content is unavailable, record the gap, use authorized vendor-supported checks and temporary safeguards, and arrange a supported scan as coverage becomes available. Keep trigger, scan and follow-up evidence distinct.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the assessment, scanning or remediation actually occurred.
3.11.2[a]
Check the approved scanning frequency and coverage plan for both organizational systems and applications.
Records to keep: Defined intervals, inventory-to-method map, responsibility, authorized scope, exceptions and safe operating limits.
3.11.2[b]
Sample actual organizational-system vulnerability scans against the defined frequency, checking successful coverage and failures.
Records to keep: Dated scan/job references, target inventory reconciliation, tool/content versions, authentication success where applicable and follow-up on missed systems.
3.11.2[c]
Sample actual application vulnerability scans against the defined frequency, including the application coverage that endpoint inventory does not supply.
Records to keep: Application-to-method map, dated application scan results, authenticated context where relevant, dependencies, exclusions and unresolved coverage.
3.11.2[d]
Trace a newly identified relevant vulnerability to scans of the affected organizational systems and treatment of scanning failures.
Records to keep: Advisory/applicability decision, trigger date, actual system scan results, detection limits and assigned follow-up.
3.11.2[e]
Trace a newly identified relevant vulnerability to scans of the affected applications, with application coverage checked separately.
Records to keep: Affected application/dependency references, trigger date, actual application scan results, unsupported checks and next actions.
Records to keep
System and application scanning frequencies, authorized methods, targets, credentials references, safe limits and provider agreements.
Actual periodic and newly identified-trigger scan results, coverage reconciliation, failures, detection-content limits and follow-up owners.
If a check fails
Stop an authorized scan if it exceeds approved impact limits. Contact the service owner, preserve restricted job/error records, recover through the approved procedure and revise scope or timing before retrying. An unreachable host or failed application login is a coverage gap, not a clean result. Escalate urgent relevant vulnerabilities while arranging safe coverage.
Working with a small budget
Use supported coverage already licensed, then identify what remains. Defender for Endpoint Plan 2 core vulnerability capabilities are optional licensed services, not part of ordinary Windows Antivirus. Community tools can help an authorized evaluation but need skilled operation, maintained feeds, protected credentials, compute and support. A free tool does not authorize scanning or make it safe for production.
Remediate identified vulnerabilities according to risk
Turn reliable findings into risk-based corrections and confirm what changed. A patch request, CVSS number or accepted exception does not show that the vulnerability was corrected on the affected systems and applications.
Official requirement and assessment objectives
Remediate vulnerabilities in accordance with risk assessments.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.11.3
Objective
Official text
3.11.3[a]
vulnerabilities are identified.
3.11.3[b]
vulnerabilities are remediated in accordance with risk assessments.
What to do
Identify and validate the finding
Link a vulnerability to actual affected assets, applications and evidence. Check vendor applicability, versions, exposure and scan quality. Record false-positive reasoning with evidence instead of deleting an inconvenient result. Check other affected installations and deployment images. A missing dashboard entry may reflect stale or incomplete telemetry.
Choose treatment using the risk assessment
Consider exploitation information, reachable paths, CUI use, business dependency, effect on operations/assets/individuals and existing safeguards alongside technical severity. Assign an owner, approved action, risk-based target date and change/recovery plan. The three requirements do not prescribe a universal CMMC patch SLA. Check contract and other applicable obligations separately. Record temporary mitigations and any accepted residual risk with authority and expiry.
Verify correction before closure
Use approved change management to patch, reconfigure, remove or replace affected components as appropriate. Check deployed versions/configuration and perform an authorized suitable rescan or supported validation, including any needed restart and application health check. Record actual result, remaining scope and reviewer. Reopen failed fixes. A mitigation can reduce exposure while the underlying vulnerability and follow-up remain open.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the assessment, scanning or remediation actually occurred.
3.11.3[a]
Trace identified vulnerabilities to the actual affected systems/applications and reliable detection or vendor applicability evidence.
Records to keep: Finding IDs, affected inventory, scan/advisory references, validation, uncertainty and supported false-positive decisions.
3.11.3[b]
Sample corrections from risk rationale through approved action to actual verification on affected assets. Check that failed fixes, mitigations and exceptions remain visible.
Records to keep: Risk decision, accountable owner and target date, change record, actual correction and rescan/validation result, remaining exposure and reviewer.
Records to keep
Validated findings, affected scope, likelihood/impact rationale, treatment, owner, target date and authorized exceptions.
Actual changes, recovery readiness, verification results, remaining vulnerabilities, residual-risk review and closure authority.
If a check fails
If a fix fails or disrupts service, use the approved rollback or recovery route and protect the affected service. Reassess exposure, record temporary safeguards and arrange another approved correction and verification. Follow incident response if evidence suggests exploitation. Never close a vulnerability because the update job merely started.
Working with a small budget
Existing supported update mechanisms, vendor advisories and the free action register can organize corrections. Third-party apps, unsupported products, specialist testing and recovery may require additional effort or cost. Product scores and automatically created tickets do not replace the risk decision or actual verification.
Identify the actual cloud, operating systems, device join, management authority, licenses and application inventory first. These suggested checks have not been tested in a Microsoft tenant. Obtain authorization before changes or scan traffic. A Microsoft subscription or a government-cloud label does not establish CUI suitability or comprehensive vulnerability coverage.
AD DS-only and hybrid Windows
Use the approved asset and software inventories to map workstations, domain controllers, member servers, applications and appliances to actual supported scan methods. AD DS join supplies identity and policy management, not a vulnerability scanner. Include offline and remote devices and explain unreachable targets.
If using licensed Defender for Endpoint, choose its documented onboarding method for the actual Windows/server platform, such as eligible Group Policy or management deployment. Check supported updated OS, service connectivity and permissions. Hybrid join alone does not onboard a device or prove healthy reporting. Servers require the appropriate entitlement separately.
For an already authorized read-only review, compare a harmless sample asset reference with the approved inventory, the reported OS/software and last-seen or sensor-health information. Check missing or stale devices and software coverage before interpreting findings. Keep real hostnames, paths and exported results in protected records.
For additional authenticated system or application scanning, use a currently supported tool with approved credential handling, target permissions and change/impact limits. Do not weaken authentication or firewall safeguards as an exercise. Microsoft's retired Windows authenticated scan is unavailable and has no direct replacement documented.
Microsoft Entra joined Windows
Entra join alone does not supply device vulnerability assessment. Where eligible Intune and Defender entitlements exist, confirm supported management/onboarding, assigned scope, successful device reporting and platform-specific capabilities. Intune management is optional licensed capability and a configuration or update report is not complete application scan evidence. With only existing Windows and Office tools, you can maintain the registers and review installed software/vendor advisories, but must arrange supported scanning for uncovered scope.
Commercial Microsoft 365 and Azure
Defender for Endpoint Plan 2 includes core vulnerability-management capabilities for supported onboarded endpoints. Premium features require the relevant Defender Vulnerability Management add-on or standalone entitlement; server plans have their own coverage. Ordinary Defender Antivirus malware scans do not supply this service. Microsoft documents regular collection of device vulnerability information, with capabilities varying by OS. Treat supported recommendations and inventories as evidence for the coverage actually demonstrated, then account for web applications, embedded libraries, appliances and other gaps separately. Do not describe it as comprehensive active network or application scanning.
Before relying on a paid feature, use the current licensing terms and exact product comparison, updated supported OS and Defender prerequisites. Use appropriate read permissions for review and separately authorized manage permissions for remediation. Portal navigation can differ: Microsoft documents Vulnerability Management under Exposure management for the specified preview experience. Locate the actual capability in your tenant rather than treating a menu name as evidence.
GCC, GCC High and Azure Government
Record the actual identity, Defender and Azure service instances. Microsoft documents Defender portals at security.microsoft.com for GCC, security.microsoft.us for GCC High and security.apps.mil for DoD, with government-specific connectivity and licensing. Check whether a GCC tenant uses the commercial or government Defender offering before selecting endpoints. Check the government feature table and exact capability instead of assuming commercial parity. The documented Defender Vulnerability Management trial is unavailable for GCC High and DoD. Azure Government is a separate service environment; verify the chosen scanning/management service and authorized data flows there. None of these labels authorizes scanning provider infrastructure or establishes a CUI boundary.
Azure Virtual Desktop: include hosts, applications and images
Map the host pool, actual session-host OS/join, installed applications, application packages, dependencies and images used to create new hosts. Confirm the exact OS/build, multi-session support and feature entitlements before relying on a sensor or service. Include customer-managed supporting systems and provider responsibilities.
Use the approved scanning coverage for both operating systems and applications. Reconcile results with current hosts, including replaced or short-lived machines. A healthy host agent does not prove coverage of a library inside a package or an unpublished image.
Risk-assess and authorize corrections to live hosts and deployment images. Coordinate user sessions, maintenance, restart, backup/recovery and rollback. Confirm the actual corrected component and appropriate authorized rescan/validation after deployment, then check a fresh host created from the image. Avoid introducing scan load or patch disruption into active sessions as an exercise.
Included tools and lower-cost options
The free Office materials organize evidence and decisions without buying a vulnerability platform. Supported vendor advisories and existing update/software records help applicability review, but they do not establish all scanning objectives. Reuse already licensed supported assessment coverage before selecting additional tools.
Greenbone Community Edition is an option to evaluate for system scanning. Its community container documentation names supported Linux distributions, container knowledge and compute/storage prerequisites, and explicitly says that guide is not intended for production setups. Plan maintained feeds, protected scan credentials, skill, support and an approved production deployment or alternative before relying on it. Local operation still needs approved data handling and authorized network reachability.
ZAP is a free open-source web application tool with Windows, Linux and macOS options and runtime prerequisites. Its active scan sends attack traffic and can change or disrupt an application; use only an explicitly authorized suitable environment with harmless test data and approved limits. Passive analysis, active scans and manual logic checks answer different questions. ZAP does not replace general OS scanning or discover every application flaw. No scanner is run by this guide.
Safe verification and recovery
Begin by inspecting approved schedules, inventories and existing restricted scan records. For an authorized sample check, reconcile one harmless asset/application reference, expected coverage, actual run time, successful authentication where required and unresolved targets. Keep proposed scans separate from performed results. Any later active check needs exact targets, owner/provider approval, current content, credentials references, permitted checks, a maintenance window, load and stop conditions, contacts and recovery. Stop on unexpected service impact, preserve job/error records and contact the owner before retrying. A rescan or supported correction check also needs authorization.
These situations are fictional. Discuss them with the system, application, business, security and change-approval owners. Use the Word exercise pack for facilitator notes. Record what participants actually did and what was only proposed. These example answers are not test results.
Supports 3.11.1
The assessment date passed while the system changed
In this fictional situation, a small team has an approved risk-assessment frequency, but the most recent review is overdue. Its CUI system now supports a new external service and more remote users. The old register lists technical severity numbers without explaining consequences for mission delivery, organizational assets or individuals. A manager suggests changing the date and calling every risk low because there have been no reported incidents.
Discuss
Which approved frequency, scope and responsible roles should the team find?
How should the review address operations, assets and individuals?
What should be recorded when the assessment is late or its evidence is incomplete?
What a useful response includes
Keep the actual dates and record the overdue review. Assign a dated assessment using the approved boundary, method and decision authority.
Examine threats, vulnerabilities, existing safeguards, likelihood, impact and uncertainty, including service dependencies and potential harm to operations, assets and individuals.
Assign treatment and verification, next review and responsible approvals. Do not treat no reported incident or a technical severity number as evidence of low risk.
Lesson: Risk assessment requires actual analysis at the defined frequency. A changed date and a technical finding list do not supply it.
Record: Record fictional boundary changes, missing analysis, decisions participants actually explained, owner and due date. No actual assessment or tenant result is represented.
Supports 3.11.2, 3.11.3
The dashboard missed an application dependency
In this fictional situation, an advisory identifies a new vulnerability in a library used by an internal web application and an AVD application package. A team points to Defender recommendations for its onboarded Windows hosts and proposes waiting until the next routine scan. The application library is absent from the report, one host has stale telemetry, and nobody has confirmed application scanning coverage or authorization for an active test.
Discuss
Which system and application targets need an applicability decision and newly identified-trigger scans?
What does the Defender report establish, and where is coverage still unknown?
What authorization, impact limits and recovery arrangements are needed before any active scan?
What a useful response includes
Map the advisory to affected systems, applications, dependencies, session hosts and deployment images. Assign actual triggered scans for both systems and applications without waiting for the periodic run.
Check supported product/platform coverage, successful telemetry and scan context. Keep the stale host and missing library as gaps. Windows authenticated scanning retired in December 2025 is not an available fallback.
Approve exact targets, provider permission, tools/content, credentials references, window, load/stop conditions and recovery. When detection content is unavailable, record the limit, use authorized vendor-supported checks and safeguards, and arrange supported scanning follow-up.
Lesson: Supported endpoint assessments contribute evidence for their coverage. They do not establish comprehensive active scanning or every application dependency.
Record: Keep fictional advisory/applicability, system and application coverage, proposed checks, authorization gaps and next actions. No scanning or production traffic is performed.
Supports 3.11.1, 3.11.3
The patch ticket closed before the correction was checked
In this fictional situation, a high-severity finding affects a service used for time-critical CUI work. A patch job reports success, but the application still uses an old component after restart. Another lower-severity finding has a reachable path and credible exploitation information. The team proposes closing the first finding and handling all work strictly in CVSS order. No correction verification or risk-based treatment decision is attached.
Discuss
Which business impact, exposure and exploitation facts affect priority?
What actual evidence is needed before the first finding can close?
How should a failed fix, temporary mitigation or accepted residual risk be recorded?
What a useful response includes
Use the approved risk method to consider operations, assets, individuals, reachable paths, CUI use, exploitation and safeguards alongside technical severity. Assign accountable actions and risk-based target dates.
Keep the first finding open until actual deployed component/configuration and an authorized appropriate rescan or supported validation show the result. Include restart requirements, other installations and application health.
Use approved rollback/recovery for disruption, document temporary protection and remaining vulnerability, and obtain authorized time-limited residual-risk review where appropriate. A closed ticket or accepted risk is not proof of correction.
Lesson: Risk guides the remediation decision, and actual verification shows whether the correction worked. Neither a severity number nor job status proves both.
Record: Record fictional priority rationale, missing verification, recovery decision, remaining exposure, owner and due date. No real patch or rollback is performed.
Five free Word and Excel materials
Download a copy and adapt it in your approved environment. Blank inputs and fictional examples are separate. Use restricted references; keep CUI, credentials, detailed system records and evidence in approved storage. The templates do not calculate a compliance score.
Excel
Risk assessment register
Connect a CUI system, threat and vulnerability to likelihood, impact on operations, assets and individuals, and an approved treatment decision.
Ready for record review means a row is prepared for someone to examine. It is not a completed risk assessment, successful scan, verified correction or a compliance finding. Keep remaining limitations and next actions explicit.
Turn a coverage gap into an assigned action
In a fictional review, an application library is absent from the host vulnerability report and the team has no newly identified-trigger application scan record. Keep 3.11.2[e] as Evidence to check in the Level 2 gap-and-action worksheet. Link the restricted coverage record and assign applicability review, authorized scanning and follow-up. A host dashboard cannot close the missing application objective.
Sources reviewed October 28, 2026. Official text is separate from our suggestions. Product documentation supports the features and limits described; it does not establish that your deployment works or that a service is suitable for your CUI. Assessment frequency, scanning coverage, risk decisions and provider responsibilities depend on your actual systems and obligations. These instructions remain untested in a tenant. No scans or remediation actions were performed.
Assess risk to operations, assets and individuals. Scan systems and applications periodically and when new relevant vulnerabilities are identified, then remediate according to risk assessments.
Endpoint Plan 2 core assessment capabilities differ from the premium add-on or standalone product. Server plans differ. The comparison is not a licensing contract.
Check entitlement, supported updated devices, Defender for Endpoint prerequisites and read/manage role permissions before relying on reports or remediation features.
Vulnerability information is gathered from onboarded devices. Platform and feature coverage differ; this does not promise coverage of every application, library or network appliance.
Customer-managed session hosts and their applications and deployment images need vulnerability assessment and patch management. AVD is not automatic coverage.
A community option for an authorized evaluation, with supported Linux/container prerequisites and resource costs. This particular container guide explicitly is not intended for production setups.
Free open-source web application tool for Windows, Linux and macOS. Check Java/runtime prerequisites and keep credentials and reports within the approved boundary.
Active scans send attack traffic and can affect targets. Authorize exact scope and impact limits; automated scans do not find every application logic issue.
Email cmmc@purposefulsecurity.com with a general description. Keep CUI, credentials, detailed system records, logs, evidence and completed worksheets in your approved environment. Do not email them to us.