Correct flaws, maintain protection and review what your systems are doing.
Work through all seven requirements and twenty assessment objectives. Define flaw time frames, protect designated locations, act on advisories, maintain protection and scans, monitor systems and both traffic directions, and identify unauthorized use. Start with the actual CUI boundary and protected evidence.
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.
Connect protection coverage to actual records and action
Confirm the CUI system. Identify processing, storage, transmission, file entry points, applications and customer/provider duties. Use Do we handle CUI? when information status needs clarification.
Define separate flaw times. Approve identification, reporting and correction time frames, start triggers, owners and escalation. There is no universal CMMC patch SLA in this requirement.
Check actual protection. Map designated locations to the primary antivirus and service protections. Active, passive and disabled Defender Antivirus mean different coverage. Review intelligence, engine and platform maintenance.
Check both scan obligations. Define periodic malicious-code scan frequency and verify completion. Separately verify real-time scans of external files as downloaded, opened or executed. Vulnerability scans serve a different purpose.
Review and respond. Act on alerts and advisories, monitor the system plus inbound and outbound traffic, and compare actual activity with defined authorized use. Missing telemetry remains unknown coverage.
Use fictional records for discussion. No live malware, attack traffic, scan, security-disabling command, patch or tenant change is part of these exercises. Any later technical check needs separate authorization, exact scope, provider permission, impact limits, stop contacts and recovery. Keep CUI, credentials, detailed inventories, logs and evidence in approved protected storage. This website receives no worksheets or answers.
Make three time commitments visible: when flaws must be identified, when they must be reported and when they must be corrected. Keep evidence of each actual event. A patch schedule alone leaves identification and reporting unanswered.
Official requirement and assessment objectives
Identify, report, and correct system flaws in a timely manner.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.1
Objective
Official text
3.14.1[a]
the time within which to identify system flaws is specified.
3.14.1[b]
system flaws are identified within the specified time frame.
3.14.1[c]
the time within which to report system flaws is specified.
3.14.1[d]
system flaws are reported within the specified time frame.
3.14.1[e]
the time within which to correct system flaws is specified.
3.14.1[f]
system flaws are corrected within the specified time frame.
What to do
Specify three time frames and responsible roles
Approve identification, reporting and correction time frames for the system boundary. State the trigger and clock for each, severity or exposure categories, escalation, decision authority and dependencies. Use risk and applicable obligations to set practical targets. There is no fixed CMMC-wide patch SLA in this requirement; do not substitute an invented universal deadline.
Identify and report actual flaws
Use vendor advisories, authorized vulnerability findings, update failures, software support status and other reliable inputs. Identify affected operating systems, applications, firmware and deployment images. Record receipt/discovery, identification and report timestamps, affected scope and restricted evidence. Send reports to the designated security/system owner through the approved route within the defined time. A ticket creation time does not necessarily show when the flaw was identified.
Correct, verify and escalate late work
Authorize the supported patch, reconfiguration, removal or replacement with change testing, recovery and maintenance needs. Record the actual correction and suitable verification for affected instances, including restart and application health where applicable. Compare actual elapsed times with each defined time frame. Keep failed fixes, mitigations, unsupported scope and overdue work open with authority and next action; an exception does not prove correction.
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 protection, monitoring, scanning or correction actually occurred.
3.14.1[a]
Locate the approved time within which flaws must be identified, including the start trigger and accountable owner.
Records to keep: Identification time-frame decision, scope, categories, trigger, owner and escalation.
3.14.1[b]
Sample actual flaw identification records and compare their timestamps with the specified identification time.
Records to keep: Advisory/finding receipt, affected-scope determination, actual identification time and late-work follow-up.
3.14.1[c]
Check the separately specified reporting time, recipient and reporting route.
Records to keep: Approved reporting clock, roles, protected channel and escalation criteria.
3.14.1[d]
Trace identified flaws to actual reports received through the approved route within the reporting time.
Records to keep: Identification and report timestamps, recipient acknowledgement/reference and any reporting delay.
3.14.1[e]
Find the specified correction time, including priority rationale, approval and overdue escalation.
Records to keep: Approved correction time frames, categories, change responsibilities and exception authority.
3.14.1[f]
Compare actual verified corrections with the specified correction time on affected systems and images.
Records to keep: Affected inventory, authorized change, actual correction date, verification, remaining scope and late-work records.
Records to keep
Approved separate identification, reporting and correction time frames and trigger definitions.
Actual discovery, identification, report and verified correction timestamps; affected scope, authorization, exceptions and follow-up.
If a check fails
If a time frame is missed, record the real dates, inform the responsible authority and reassess exposure. Use approved temporary safeguards while arranging correction. If a change disrupts service, invoke approved rollback/recovery, verify service health and keep the flaw open. Follow Incident Response when exploitation is suspected. Never backdate a report or close on patch-job status alone.
Working with a small budget
Use vendor advisories, existing supported update mechanisms and the free action register. Windows Update does not maintain every third-party application, firmware or image. Staff time for applicability, reporting, change testing and verification remains necessary even when the update tool is included.
Name where malicious-code protection is needed, then demonstrate protection at those locations. Include relevant endpoints, servers, email/file entry points, external transfers and virtual desktops. A list of installed agents does not show active protection.
Official requirement and assessment objectives
Provide protection from malicious code at designated locations within organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.2
Objective
Official text
3.14.2[a]
designated locations for malicious code protection are identified.
3.14.2[b]
protection from malicious code at designated locations is provided.
What to do
Identify locations and the responsible provider
Map the CUI boundary, entry/exit paths, file stores, workstations, servers, hosted mail, applications and removable/external sources to designated protection locations. Explain how each location is protected and which customer or provider owns it. Document platform, encrypted-content, archive, file-size and exclusion limitations and authorized alternatives where relevant.
Verify the actual primary protection
On supported Windows, included Microsoft Defender Antivirus can provide primary protection in active mode. Check the actual provider, mode, real-time state, policy and health. Passive Antivirus has no antivirus real-time blocking. Normal configured scan schedules are generally ignored; Microsoft documents exceptions for idle scans, catch-up quick scans, scans after security intelligence updates and Windows Task Scheduler tasks. Check actual completed scan type, scope and frequency, and actual primary protection. Do not reject a completed scan solely because mode is passive. Disabled or uninstalled Defender Antivirus provides none. A running process, DLP activity or EDR block mode is not proof that Antivirus is active.
Reconcile all locations with demonstrated coverage
Check actual policy application and protected records for representative locations, including remote/offline systems and newly created AVD hosts. Endpoint Antivirus does not provide the separately licensed Defender for Endpoint EDR, Defender for Identity, or Defender for Office 365 services. Check hosted mail/collaboration protections and other platforms separately. Assign gaps, exceptions and expiry rather than claiming a product covers everything.
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 protection, monitoring, scanning or correction actually occurred.
3.14.2[a]
Compare the designated protection-location list with the actual system boundary, file entry points and provider duties.
Records to keep: Approved location inventory, data paths, protection method, platform limitations and customer/provider ownership.
3.14.2[b]
Sample actual protection at each location type, checking active primary antivirus and separate mail/service controls where applicable.
Records to keep: Provider/mode and real-time health records, actual policy result, exceptions, service protection evidence and unresolved coverage.
Records to keep
Designated location map with actual protection provider, platform, ownership and limits.
Actual primary protection mode, policy/health evidence, exclusions with authority and dated gap actions.
If a check fails
Treat missing or stale protection as a coverage gap. Contact the endpoint/service owner, assess exposure and use an approved repair or alternate protection path. Investigate conflicts through supported guidance; never disable security or add broad exclusions to make a worksheet green. Escalate suspected infection through Incident Response.
Working with a small budget
Supported Windows includes Defender Antivirus and local health tools. Those can protect an endpoint without buying an EDR service. They do not centrally supervise every location or protect mail/identity as separate services. Map existing coverage first and fund the remaining platform, service and review needs.
Give someone responsibility for both live security alerts and authoritative advisories, with defined response decisions and actual follow-through. Reading an advisory feed or subscribing to email does not demonstrate action.
Official requirement and assessment objectives
Monitor system security alerts and advisories and take action in response.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.3
Objective
Official text
3.14.3[a]
response actions to system security alerts and advisories are identified.
3.14.3[b]
system security alerts and advisories are monitored.
3.14.3[c]
actions in response to system security alerts and advisories are taken.
What to do
Define response actions and coverage
Identify sources such as endpoint/service alerts, Microsoft Security Update Guide and other relevant vendors. Assign a primary/backup reviewer, review schedule, urgency and escalation routes. Define triage, applicability, affected-scope review, false-positive validation, change/mitigation, incident escalation, owner and closure evidence. Include off-hours arrangements appropriate to risk.
Monitor actual sources and failed delivery
Review the actual configured queues/feeds and document dates, source health, missing telemetry, failed notifications and coverage during absence. Correlate advisories with inventory and versions, not only product names. Distinguish no alert from a silent or unlicensed sensor. Preserve restricted references instead of copying full alerts or vulnerable host details into public material.
Take and verify the appropriate action
Record applicability and rationale, actual action and timing, assigned owner and follow-up. Route flaws into the defined identification/reporting/correction clocks and suspected attacks into Incident Response. Use authorized change/recovery for updates and mitigations. Verify the outcome and review unresolved scope; a dismissed notification or assigned ticket alone is insufficient.
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 protection, monitoring, scanning or correction actually occurred.
3.14.3[a]
Check the identified response actions for alert/advisory types and the responsible primary/backup roles.
Records to keep: Approved sources, response playbooks, urgency, escalation, authority and expected verification.
3.14.3[b]
Review actual monitoring records and source health, including absences and failed delivery.
Records to keep: Dated queue/feed reviews, source coverage, receipt/delivery checks and unresolved monitoring gaps.
3.14.3[c]
Trace sampled alerts/advisories through applicability and actual action to verified results or open follow-up.
Records to keep: Decision rationale, affected scope, action dates, change/incident reference, outcome and remaining owner.
Records to keep
Alert/advisory sources, review ownership, response actions and escalation procedures.
Actual monitoring, applicability and action records, verified outcomes and failed-source follow-up.
If a check fails
If a source stops reporting, preserve the last known coverage, notify the owner and restore a supported delivery/collection route. Review the missed period and affected assets without inventing historical monitoring. For urgent exposure, use approved temporary safeguards and escalate. Do not suppress noisy alerts without an evidence-based approved decision.
Working with a small budget
Vendor advisories are available without an EDR purchase. Existing Windows and service logs can inform review but need reliable collection, protection and human follow-up. A paid alert platform still needs ownership, tuned coverage and action verification.
Update malicious-code protection when releases are available
Keep the protection mechanism current, including its intelligence, engine and platform as applicable. A current signature timestamp does not prove every protection component is maintained.
Official requirement and assessment objectives
Update malicious code protection mechanisms when new releases are available.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.4
Objective
Official text
3.14.4
Determine if malicious code protection mechanisms are updated when new releases are available.
What to do
Assign supported update sources and release review
Identify the actual primary product at each designated location and how its vendor announces/releases updates. For Defender Antivirus, distinguish security intelligence, engine and platform updates. Approve source/fallback, connectivity, management authority, scheduling and offline handling suitable for the environment. Review the alternate primary antivirus separately when Defender is passive.
Check actual deployed updates
Compare installed component versions, update timestamps and failures with current applicable releases and approved deployment records. Check endpoints, servers, remote devices and AVD images/new hosts. A policy, download job or portal color does not establish installation. Preserve failed or unsupported scope and product lifecycle gaps.
Resolve stale coverage safely
Investigate source reachability, management conflicts, supported OS/platform and errors through vendor guidance. Authorize repairs and verify actual update/health afterward. Use approved recovery if an update disrupts service and retain compensating safeguards and follow-up. Do not disable antivirus, tamper protection or network safeguards to bypass the failure.
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 protection, monitoring, scanning or correction actually occurred.
3.14.4
Compare available applicable protection releases with actual deployed intelligence, engine/platform or other vendor component versions and resolve missed updates.
Records to keep: Release/source references, actual versions/timestamps, installation/failure records, offline coverage, verified repair and remaining gaps.
Records to keep
Approved protection products, sources/fallback, management roles and release/deployment review.
Actual component versions, update times, failures and verified recovery for all location types.
If a check fails
Record the last known successful update and affected scope, escalate stale protection, restore a supported update path and verify health. Keep unsupported devices and failed image maintenance visible. Rollback requires the approved change/recovery decision and renewed exposure review; it is not a reason to leave protection disabled.
Working with a small budget
Defender Antivirus updates and Windows status tools support included endpoint protection. A central update service or paid management platform is optional, but disconnected systems, third-party products and fleet reconciliation still need maintained procedures and staff effort.
Run periodic scans and real-time external-file scans
Demonstrate both scheduled malicious-code scans of systems and real-time scanning of external files as they are downloaded, opened or executed. These are separate from vulnerability scanning under Risk Assessment.
Official requirement and assessment objectives
Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.5
Objective
Official text
3.14.5[a]
the frequency for malicious code scans is defined.
3.14.5[b]
malicious code scans are performed with the defined frequency.
3.14.5[c]
real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
What to do
Define the malicious-code scan frequency and scope
Approve a frequency and suitable scan type for in-scope platforms, including servers, offline devices and virtual hosts. Explain scope, exclusions, archives/removable media and operational limits. Microsoft recommends scans that supplement real-time protection; this requirement does not mandate one universal daily full scan. Align performance, catch-up handling and maintenance with the approved frequency.
Verify actual periodic completion
Review actual completed scan times, type, scope, result, failures and missed runs against the defined frequency. A configured task or running process is insufficient. Passive Antivirus has no antivirus real-time blocking. Normal configured scan schedules are generally ignored; Microsoft documents exceptions for idle scans, catch-up quick scans, scans after security intelligence updates and Windows Task Scheduler tasks. Check actual completed scan type, scope and frequency, and actual primary protection. Do not reject a completed scan solely because mode is passive. Record catch-up, inaccessible devices and scan limitations honestly. No scan is launched by these exercises.
Verify real-time protection across external file paths
Inspect actual primary protection state and applicable policies for file/program monitoring and downloaded files/attachments. Map email attachments, web downloads, external shares, transfers and removable sources as relevant to downloaded/opened/executed paths. Review exclusions and service responsibilities, then use existing authorized records for a harmless sample. No live malware, protection-disabling step or attack is needed. A proposed file check and a green setting are not proof of performed real-time scanning across all paths.
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 protection, monitoring, scanning or correction actually occurred.
3.14.5[a]
Locate the defined malicious-code scanning frequency, type and scope for the actual systems.
Records to keep: Approved schedule, platform/method map, responsibilities, scope/exclusions and missed-run handling.
3.14.5[b]
Compare actual completed periodic scans with the defined frequency and identify missed or incomplete systems.
Records to keep: Actual completed scan records, type/scope/timestamps and frequency comparison, failures, primary protection evidence and documented scheduling exceptions. Do not reject a completed scan solely because mode is passive.
3.14.5[c]
Trace external-file paths to actual real-time scan coverage as files are downloaded, opened or executed, accounting for product mode and exclusions.
Records to keep: External-source map, effective policy and primary-product health, existing authorized sample records, path/service limitations and gaps.
Records to keep
Defined scan frequency and type, platform scope, external-file paths and approved exclusions.
Actual scan completion/failures and real-time protection evidence for downloaded, opened and executed external files.
If a check fails
If scans are missed or real-time coverage is absent, identify exposure and the actual primary provider before changing settings. Arrange a separately authorized safe repair/scan window and verify completion without disrupting users. Preserve failed runs and partial scope. Escalate suspected malicious code through Incident Response rather than opening the file to investigate.
Working with a small budget
Active Defender Antivirus on supported Windows offers scheduled and real-time scanning without an EDR subscription. Included local logs and status help verification, but need review and retention. Other operating systems, service entry points and centralized reporting may need additional supported tools or licenses.
Monitor systems and both traffic directions for attacks
Keep system monitoring, inbound communications and outbound communications visible as three coverage questions. Antivirus alone, a firewall allow/deny rule or an inbound-only dashboard does not demonstrate detection across all three.
Official requirement and assessment objectives
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.6
Objective
Official text
3.14.6[a]
the system is monitored to detect attacks and indicators of potential attacks.
3.14.6[b]
inbound communications traffic is monitored to detect attacks and indicators of potential attacks.
3.14.6[c]
outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
What to do
Map detection coverage and responsibilities
Identify system, application, identity and network/service telemetry needed for attacks and indicators of potential attacks. Map inbound and outbound paths at relevant boundaries, including remote users, cloud services, AVD and customer/provider interfaces. Choose detection/review methods, source health checks, owners, escalation and protected evidence retention. Document blind spots such as encrypted payloads, missing egress sources and unmonitored services.
Operate system and directional monitoring
Collect and review the authorized system/security, endpoint and network/service evidence using supported tools. Active Windows Antivirus provides malware protection but not the full licensed EDR service. Included Event Viewer and configured host firewall logging can support a small boundary, but require collection, correlation, storage and review; bounded logs can roll over and do not inspect every attack or encrypted payload. For licensed EDR, verify actual capability, onboarding and healthy telemetry rather than assuming an agent means coverage.
Check detection decisions without generating attacks
Use approved existing records and a harmless fictional walkthrough to trace a system signal, inbound indicator and outbound indicator to the expected reviewer and action. Check source timestamps, actual collection, detections/review records and missing coverage. Keep discussion separate from technical effectiveness tests. Any later benign validation needs separate scope, authorization, stop/recovery criteria and protected results. Do not send exploit traffic or scan another tenant/provider.
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 protection, monitoring, scanning or correction actually occurred.
3.14.6[a]
Review actual system monitoring for attacks and potential indicators, including telemetry health and responsible review.
Records to keep: System-to-source/detection map, actual collection and review records, alerts, gaps and escalation.
3.14.6[b]
Trace inbound communication paths to actual attack-indicator monitoring and review, including hosted/provider boundaries.
Records to keep: Inbound path/source map, actual directional telemetry/detection or review records, health and limitations.
3.14.6[c]
Check outbound paths separately, confirming actual egress evidence and attack-indicator review rather than inferring it from inbound coverage.
Records to keep: Outbound path/source map, actual egress collection/detection or review records, missing sources and assigned recovery.
Records to keep
System/inbound/outbound coverage map, monitoring methods, provider duties, source health and review ownership.
Actual collection/detection/review records, direction, timestamps, actions and coverage gaps.
If a check fails
Treat silent sensors, rolled-over logs and absent egress data as unknown coverage. Restore supported collection, protect remaining records, review the missed period where evidence exists and escalate exposure. Do not manufacture attack traffic to compensate for missing evidence or claim that a firewall block proves comprehensive monitoring.
Working with a small budget
Included Windows logs and host firewall logs can contribute to an appropriately scoped monitored process. They do not automatically correlate attacks or replace network/service visibility. Assess available expertise, reliable collection and review workload before buying licensed EDR, managed monitoring or additional telemetry. A subscription alone closes no objective.
Define authorized use and identify unauthorized use
Define who may do what, for which purpose and under which conditions, then review actual activity against those expectations. Unauthorized use can involve an authorized account, excessive privilege or disallowed activity without any malware alert.
Official requirement and assessment objectives
Identify unauthorized use of organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.14.7
Objective
Official text
3.14.7[a]
authorized use of the system is defined.
3.14.7[b]
unauthorized use of the system is identified.
What to do
Define authorized system use
Link acceptable use, approved roles, applications, access paths, service accounts, privileged tasks, remote access and time/location conditions where applicable. Assign approval and exception authority. Include administrators and providers. Do not infer that any successful sign-in or any activity by an employee is authorized.
Review actual activity against approvals
Use protected authentication, application, privileged-action and other relevant system records. Correlate account/role permissions with approved work and deviations, including noninteractive identities, local accounts and disconnected systems. Windows logon auditing helps local/AD review; Entra sign-in activity concerns the cloud identity path and does not cover every local or application action. Licensed identity detection is separate from Antivirus.
Investigate and respond through the approved process
Record who reviewed the activity, why it was expected or unauthorized, affected scope, authority and actual response. Protect personal information and preserve evidence. Escalate suspected compromise through Incident Response and coordinate authorized access/change action. Missing logs and unclear permission remain gaps; no alert or no failed logon does not establish authorized use.
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 protection, monitoring, scanning or correction actually occurred.
3.14.7[a]
Locate the definition of authorized use and compare it with actual roles, applications, privileged/service use and provider permissions.
Records to keep: Approved use rules, role/access approvals, permitted activities/paths, exceptions and owners.
3.14.7[b]
Trace actual activity reviews to unauthorized-use identification and documented investigation or evidence-based disposition.
Records to keep: Restricted activity/approval comparison, reviewer/date, identified deviation, decision rationale, response and unresolved logs.
Records to keep
Authorized-use rules and current role, activity, provider and exception approvals.
Actual activity reviews, unauthorized-use findings, investigation decisions and authorized response.
If a check fails
If authorized use is unclear, obtain an accountable decision and keep the objective unverified. Preserve existing activity records and address collection gaps. For suspicious use, follow Incident Response and approved access actions; do not accuse a person or delete evidence based on an unexplained alert.
Working with a small budget
Use existing approvals and included Windows/application records with a responsible reviewer. Central identity, privileged-activity analytics and cloud log retention can require licenses and staff effort. Defender for Identity or an Entra plan must be confirmed separately and does not replace defining authorized use.
First record the actual operating system, join, management authority, primary protection, cloud instance, license and responsible provider. These suggested checks have not been tested in a Microsoft tenant. Inspect approved records before changes. A government-cloud label, subscription or installed sensor does not establish CUI suitability, current protection or complete monitoring.
AD DS-only and hybrid Windows
Map workstations, domain controllers, member servers, applications and external-file paths to designated protection and monitoring. AD DS Group Policy can manage supported Windows Defender Antivirus. Review the effective device policy and the actual primary provider, mode, health and exclusions. Hybrid join alone supplies no protection evidence.
For an authorized read-only sample review, open Windows Security, choose Virus & threat protection and review Manage providers where available. Check which antivirus is primary. On supported Windows, an authorized administrator can inspect Get-MpComputerStatus for AMRunningMode, RealTimeProtectionEnabled, intelligence/engine/product versions and scan end times. The guide does not run it. Correlate the protected output with product policy, update records and completed scans; process presence alone is insufficient.
Use existing Windows Security/Defender operational and Security logs, supported application records and configured host firewall logging as appropriate. Define collection, protected retention, review and attack-indicator decisions. Check system, inbound and outbound coverage separately. A bounded local log can roll over and a firewall record alone is not comprehensive attack detection.
If adding licensed Defender for Endpoint, confirm the specific plan and server entitlement, supported OS, onboarding method and cloud connectivity. Verify actual sensor health and data freshness. Domain or hybrid join is not onboarding. Passive Antivirus may coexist with an alternate primary product; verify actual primary protection and real-time coverage separately. Normal configured scan schedules are generally ignored in passive mode, with documented exceptions. Assess actual completed scan type, scope and frequency rather than rejecting a scan solely because mode is passive.
Microsoft Entra joined Windows
Entra join does not itself configure antivirus, onboard EDR or define authorized use. Included active Defender Antivirus can supply supported Windows malware protection. If Intune is licensed and used, select its supported Antivirus policy path and verify assignment, effective settings and actual device health. Intune is a separate product and is not included in every Defender subscription. Keep management conflicts and offline devices visible. Review Entra sign-in records for the cloud identity path alongside local/application activity; they do not establish every action on a device. Confirm access and log retention for the actual subscription before relying on them.
Commercial Microsoft 365 and Azure
Separate three decisions: primary antivirus, licensed endpoint detection and response, and identity/email protection. Defender Antivirus is built into supported Windows. Defender for Endpoint plans add different cloud capabilities; confirm EDR rights such as Plan 2 and actual onboarding rather than assuming Plan 1 has every investigation/automation feature. Servers need appropriate separate coverage. Defender for Identity has its own license and deployment prerequisites. Exchange Online built-in mailbox protection differs from Defender for Office 365 plans. Review each designated location against the current service description and actual tenant entitlement.
Cloud-delivered protection and sample submission can send information to a service. Approve data flows, connectivity and relevant government endpoints before adoption. Do not upload CUI, actual suspicious files or detailed logs to this website or an unapproved analysis service. Product availability does not decide your boundary or contractual obligations.
GCC, GCC High and Azure Government
Check the exact identity, mail, Defender and Azure environments. Microsoft documents government Defender portals at security.microsoft.com for GCC, security.microsoft.us for GCC High and security.apps.mil for DoD. Confirm the offering used by the GCC tenant and its documented connectivity. Consult the current government license and feature table, including server rights, platform support and unavailable capabilities; commercial parity is not assumed. Azure Government is a separate environment, so verify service availability, data paths and customer/provider monitoring duties there. These labels do not establish CUI suitability.
Azure Virtual Desktop hosts and images
Microsoft operates the AVD service components; customers or partners manage session hosts and supporting components. Record host OS/build, multi-session support, join, primary protection, licensed services and applications. Confirm protection and monitoring on every actual host, including short-lived replacement hosts.
Include deployment images and application packages in flaw correction and protection maintenance. An updated image does not prove existing hosts were corrected; a corrected live host does not update its source image. Check intelligence/engine/platform maintenance, periodic scan records and external-file paths on actual new hosts without assuming image state persists.
Coordinate approved changes and scans with active sessions, capacity, restart, image versioning, recovery and rollback. Separate system/inbound/outbound monitoring, identity/application activity and provider responsibilities. No scan, malware demonstration or security change runs in these exercises.
Included tools and lower-cost operation
Start with supported Windows Defender Antivirus in active mode, Windows Security, existing update mechanisms, Event Viewer, configured firewall logs, vendor advisories and the free records below. Assign a reviewer and reconcile actual coverage. This can support a small environment without purchasing EDR, but it still needs protected collection, retention, component maintenance, failed-run handling and staff time. Other operating systems, hosted mail, identity and network boundaries need demonstrated coverage through suitable services or tools. Paid automation does not replace the review or supply every missing source.
Safe verification and failure recovery
Begin with approved policies and existing restricted evidence. Compare one harmless asset reference with actual mode, component versions, scan timestamps and monitoring-source freshness. Do not launch scans, generate attacks, download live malware, open suspicious attachments, disable protection or add broad exclusions as a demonstration. A later benign technical validation requires separate authorization and an approved test plan. On missing telemetry or stale protection, record the last known good state and unknown period, notify the owner, arrange supported repair and verify recovery. On unexpected service impact, stop at the approved limits and invoke recovery. Follow Incident Response for suspected compromise.
These situations are fictional. Discuss them with the system, application, security, monitoring 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.14.1, 3.14.3
A flaw report with no identification time
Fictional Harbor Workshop receives a fictional vendor advisory about a CUI application. Its procedure gives a correction target, but no identification or reporting time. A support ticket says an update was installed. The team cannot find when the affected version was identified, who received the flaw report or whether all instances and the deployment image were corrected. No actual advisory, flaw, update or tenant is involved.
Discuss
Which separate identification, reporting and correction time frames and start triggers must be defined?
What actual records would connect advisory receipt to affected scope, identification and reporting?
What would verify correction, and how should missing dates, overdue work and an unchanged image remain visible?
What a useful response includes
Approve distinct time frames, triggers, owners and escalation using the organization's risk and obligations. Do not invent a universal CMMC patch SLA.
Record the missing identification/reporting evidence and arrange a truthful review. Trace the advisory's applicability, affected instances and actual recipient through restricted references.
Keep correction unverified until actual deployed versions and suitable authorized validation support it. Include image maintenance, recovery readiness and late-work escalation. No patch, scan or production change is performed in the discussion.
Lesson: A ticket and patch target do not answer all six flaw objectives. Defined clocks and actual timestamps are separate evidence, and correction needs a verified outcome.
Record: Record actual participant decisions, missing time frames/evidence, affected-scope questions, action owner and due date. Keep proposed checks separate from performed results.
Supports 3.14.2, 3.14.4, 3.14.5
A running antivirus process in passive mode
Fictional Cedar Lab lists Defender Antivirus as protection for an endpoint and AVD hosts. A fictional health note says Passive and a recent intelligence date. There is no current primary-provider record, periodic scan completion or external-file path check. The golden image has older platform information. These are invented discussion records, with no files downloaded, opened, executed or scanned.
Discuss
Why do a running process and recent intelligence date fail to establish active primary antivirus or full update maintenance?
How would the team identify the actual primary provider and check designated locations, periodic scan frequency/completion and real-time external-file coverage?
Which safe repairs, image actions and separate authorizations would be required before any later technical verification?
What a useful response includes
Separate active, passive and disabled Defender Antivirus from alternate primary protection and licensed Defender for Endpoint EDR. Passive Antivirus has no antivirus real-time blocking. Normal configured scan schedules are generally ignored; Microsoft documents exceptions for idle scans, catch-up quick scans, scans after security intelligence updates and Windows Task Scheduler tasks. Check actual completed scan type, scope and frequency, and actual primary protection. Do not reject a completed scan solely because mode is passive.
Keep location coverage, intelligence/engine/platform versions, defined scan frequency, actual completion and external download/open/execute paths unverified until supported records exist. Check alternate product and hosted-mail responsibilities separately.
Assign supported repair and image/new-host verification with owner, timing, impact limits and recovery. Never disable protection, broaden exclusions or introduce live malware to make a demonstration work.
Lesson: Product presence and fresh signatures are partial information. Protection mode, component maintenance and the two scan obligations each need actual evidence.
Record: Capture actual explanations and unknowns, product/platform/cloud/license checks, responsible owners and safely authorized follow-up. No exercise statement is a scan or protection test result.
Supports 3.14.3, 3.14.6, 3.14.7
Inbound alerts and an outbound monitoring gap
Fictional Pine Service reviews inbound firewall alerts. Its fictional inventory has no outbound source for one hosted application's path, and a local Security log has rolled over. A privileged service account performed an unexplained export in the scenario, but approved use of that account is unclear. No real activity, export, attack or alert was generated.
Discuss
What evidence is needed separately for system, inbound and outbound attack-indicator monitoring?
How should missing telemetry, rolled-over records and provider boundaries be handled?
How can authorized use be defined and actual activity reviewed without assuming a successful sign-in proves permission?
What a useful response includes
Map system and both traffic directions to actual sources, collection health, detection/review ownership and response. Keep the absent outbound path open rather than inheriting an inbound dashboard's conclusion.
Preserve available protected evidence, document the unknown period and assign supported collection/retention repair with provider duties and review. Do not invent historical monitoring or generate attacks to fill the gap.
Obtain authorized-use rules for the account, compare approved work and activity through an authorized investigation, and route suspected compromise to Incident Response. Identity analytics, email protection and licensed EDR are separate capabilities from Antivirus.
Lesson: Inbound monitoring does not prove outbound coverage, and malware detection does not define authorized use. Missing records are gaps that need owners and safe recovery.
Record: Record actual discussion observations, coverage/use-rule gaps, protected references, decision authority, action owner and due date. Technical detection or account changes require separate authorization.
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
Protection and monitoring coverage register
Map designated protection locations, actual antivirus mode, update and scan evidence, system and traffic monitoring, and unauthorized-use review.
Ready for record review means a row is prepared for someone to examine. It is not proof of active protection, successful scanning, complete monitoring, verified correction or a compliance finding. Keep remaining limitations and next actions explicit.
Turn an outbound coverage gap into an assigned action
In a fictional review, inbound alerts exist but one application has no outbound monitoring source. Keep 3.14.6[c] as Evidence to check in the Level 2 gap-and-action worksheet. Link the restricted coverage record and assign the application/network owner to map the path, agree provider duties, restore supported collection and verify actual review. An inbound dashboard does not close outbound coverage. Use the manual record state to expose what remains unknown.
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. Flaw time frames, designated locations, protection modes, scan frequency, monitoring coverage and provider responsibilities depend on your actual systems and obligations. These instructions remain untested in a tenant. No scans, attacks, malware demonstrations, tenant tests or remediation actions were performed.
Seven requirements and twenty objectives. Preserve the singleton 3.14.4 objective and the separate identification, reporting and correction time frames.
System and Information Integrity includes flaw correction, malicious-code protection, alerts, scanning, system/traffic monitoring and unauthorized use.
Included Windows antivirus is distinct from separately licensed cloud endpoint detection and response. Verify the supported operating system and actual protection.
Active mode provides primary antivirus protection. Passive mode has no antivirus real-time blocking. Normal configured scan schedules are generally ignored, with documented exceptions; evaluate actual completed scan type, scope and frequency. Disabled or uninstalled mode provides no Defender Antivirus protection. Verify actual primary protection separately.
Read-only status inspection can show mode, real-time state, intelligence versions and scan timestamps. Protect output and correlate with policy and actual records.
Real-time and behavior monitoring include file/program activity and downloaded files and attachments. Check exclusions, mode, actual state and external-file paths.
Licensed EDR supplies attack detection and investigation capabilities beyond ordinary antivirus. Confirm actual plan, onboarding, sensor health and supported features.
Plan 1 and Plan 2 capabilities differ. Do not infer full EDR, automation or server entitlement from an Antivirus installation or a generic Microsoft 365 label.
Included host logging can support review when configured and collected. Bounded files can roll over; a firewall log alone is not comprehensive inbound/outbound attack detection.
Windows logon auditing can inform unauthorized-use review. Authorized accounts can still be misused; correlate permissions, approved activity and other system/application records.
Cloud identity sign-in records include different identity types and need appropriate read access. They do not replace local, application or privileged-activity evidence; confirm actual availability and retention.
Exchange Online built-in protection and Defender for Office 365 plans have different capabilities. Local antivirus does not replace the required email/collaboration service protection.
Check exact GCC, GCC High or DoD license, portal, connectivity, OS and feature table. Government offerings differ from commercial, with separate server licensing.
Session hosts and supporting components are customer or partner responsibilities. Include protection, application/image maintenance, monitoring and safe session-aware changes.
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.