CMMC Level 2 / NIST SP 800-171 Revision 2

3.12 Security Assessment

Check that controls work, follow corrections through and keep the system description current.

Work through four requirements and 14 assessment objectives. Define and perform effectiveness assessments, identify and implement corrective plans, monitor controls on an ongoing basis and maintain a system-specific system security plan, or SSP. All eight SSP objectives have separate checks.

Sources reviewed October 28, 2026. Microsoft procedures remain untested in a tenant. These working aids do not establish compliance, official findings, CMMC status or an assessment score.

Follow a control from its requirement to actual results

  1. Confirm the system. Use the approved CUI boundary, inventory, provider responsibilities and current SSP. Use Do we handle CUI? when information status needs clarification.
  2. Define and perform assessments. Record the approved frequency, method, samples and actual dated effectiveness review. Documentation and actual operating behavior both matter.
  3. Implement corrections. Link identified deficiencies to developed plans, actual implementation and verification. Keep missed, partial and failed actions visible.
  4. Maintain ongoing checks. Assign review ownership and responses for changed conditions, missing reporting and failing controls between periodic assessments.
  5. Update the SSP. Compare all eight SSP objectives with current facts and actual update history. A completed template is not a complete system security plan.

Use fictional records and harmless files for discussion. This guide runs no scans or production changes. Keep CUI, credentials, detailed boundaries, vulnerability information, logs and evidence in approved protected storage and use restricted references in trackers. This website does not collect completed worksheets or exercise answers.

Choose a requirement

Requirement 3.12.1

Assess whether controls actually work

Define how often security controls will be assessed and carry out those assessments. Examine implementation and effectiveness in the actual CUI system, including technical safeguards and the people, procedures and facilities that support them.

Official requirement and assessment objectives

Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.

NIST SP 800-171A, June 2018. Determine if:

Official objectives for 3.12.1
ObjectiveOfficial text
3.12.1[a]the frequency of security control assessments is defined.
3.12.1[b]security controls are assessed with the defined frequency to determine if the controls are effective in their application.

What to do

  1. Define the frequency and assessment coverage

    Approve an assessment frequency, responsible assessor/reviewer, system scope, methods, representative samples and protected evidence location. Tie coverage to the security requirements and objectives. Record how missed reviews and system changes prompt follow-up. The requirement does not set one universal annual interval.

  2. Examine records and actual behavior

    Compare approved policy, effective configuration, dated records and appropriate interviews/observations. Use separately authorized harmless checks where needed to determine whether controls work in application. A configuration assignment, provider report or high Secure Score does not cover every objective or establish effectiveness. Include local devices, services, physical procedures and provider/customer duties.

  3. Record actual dated results and gaps

    Retain what was assessed, when, by whom, evidence examined, expected versus observed behavior, scope limits and deficiencies. Reconcile actual dates with the defined frequency. Link corrective actions and subsequent verification. Do not backdate a missed review or copy a suggested response as a performed test.

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 assessed control worked.

3.12.1[a]
Find the approved frequency for security control assessments and its accountable schedule owner. Confirm it applies to the actual organizational systems in scope.
Records to keep: Approved assessment frequency, scoped schedule, responsible roles and overdue-review route.
3.12.1[b]
Compare actual assessment dates with the defined frequency, then examine evidence that controls were assessed for effectiveness in their application, including representative operating behavior.
Records to keep: Dated assessment scope/method, interviews or observations and authorized check records, actual results, evidence references, deficiencies and limitations.

Records to keep

  • Approved assessment scope, frequency, methods, roles, samples and evidence handling.
  • Actual dated assessments, effectiveness observations, overdue/missing coverage and linked corrective actions.

If a check fails

If evidence is missing or the review is late, keep that gap visible, assign a real assessment and consider interim protection with the responsible owner. Stop any check that exceeds authorization or affects service, preserve records and use agreed recovery. Use Incident Response for suspected exposure.

Working with a small budget

Start with existing Office, approved procedures, local policy reports and already available logs. Staff time and suitable expertise remain necessary. A specialist platform can help coverage but is optional; no product replaces the actual assessment.

References: NIST SP 800-171A, June 2018 · NIST SP 800-171 Revision 2 · Microsoft gpresult reference · Microsoft Secure Score · Microsoft shared responsibility in the cloud

Back to requirements ↑

Requirement 3.12.2

Identify deficiencies, plan corrections and implement them

Keep three distinct stages visible: identify the deficiencies and vulnerabilities, develop a plan to correct or reduce them, then implement that plan. A written plan or closed approval ticket is not evidence of actual implementation.

Official requirement and assessment objectives

Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.

NIST SP 800-171A, June 2018. Determine if:

Official objectives for 3.12.2
ObjectiveOfficial text
3.12.2[a]deficiencies and vulnerabilities to be addressed by the plan of action are identified.
3.12.2[b]a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
3.12.2[c]the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.

What to do

  1. Identify the deficient control and affected scope

    Link each action to the actual finding, requirement/objective, evidence, affected systems or process and remaining exposure. Include deficiencies from periodic assessments, ongoing checks and other valid sources. Keep detailed vulnerability and system information in protected storage; ordinary registers should hold restricted references.

  2. Develop an actionable approved plan

    Define corrective steps, accountable owner, resources, dependencies, milestones, target dates, change approval, interim safeguards and safe verification/recovery. Use risk information to prioritize work. Record unresolved obstacles and escalation rather than calling risk acceptance a correction.

  3. Implement, verify and review the result

    Carry out authorized actions and retain actual execution evidence. Check whether the deficiency was corrected or vulnerability reduced/eliminated across the affected scope, including replacement hosts or images where relevant. Reopen failed or partial actions. Keep implementation and verification distinct from plan approval and record residual limits.

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 assessed control worked.

3.12.2[a]
Trace the plan to identified deficiencies and vulnerabilities with reliable finding references and affected scope.
Records to keep: Finding/objective links, assessment or monitoring evidence, affected inventory/process references and remaining exposure.
3.12.2[b]
Examine a developed plan that specifies how identified deficiencies will be corrected and vulnerabilities reduced or eliminated.
Records to keep: Approved corrective steps, owner, resources, milestones/targets, dependencies, interim protection and verification/recovery arrangements.
3.12.2[c]
Trace planned actions to actual implementation records and examine whether the implemented work corrected deficiencies or reduced/eliminated vulnerabilities.
Records to keep: Actual execution/change records, dated outcome verification, reviewer, affected scope, residual issues and reopened actions where needed.

Records to keep

  • Identified deficiencies/vulnerabilities with restricted finding and objective references.
  • Developed plans, approvals, actual implementation, verification, remaining exposure and accountable follow-up.

If a check fails

For a failed change, use approved rollback/recovery and protect service and evidence. Keep the deficiency and any residual exposure open, assign a revised plan and review interim safeguards. Escalate overdue or blocked actions. Management approval alone does not make an unmet requirement satisfied.

Working with a small budget

The free action register supports internal coordination. Existing change tickets and protected evidence can avoid duplicate systems. Budget for implementation and verification, not just planning. Formal CMMC conditional-status POA&M rules are separate from this internal tracker.

References: NIST SP 800-171A, June 2018 · NIST SP 800-171 Revision 2 · 32 CFR 170.21: CMMC POA&M conditions

Back to requirements ↑

Requirement 3.12.3

Monitor continued effectiveness between assessments

Ongoing monitoring keeps controls under review as systems, users and threats change. It includes accountable human review and response, not simply the existence of a log service or a dashboard.

Official requirement and assessment objectives

Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.

NIST SP 800-171A, June 2018. Determine if:

Official objectives for 3.12.3
ObjectiveOfficial text
3.12.3Determine if security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.

What to do

  1. Choose ongoing checks for the actual controls

    Map control owners, relevant indicators, evidence sources, review rhythm, change triggers and escalation. Include technical reporting health, account/access changes, required operational procedures and provider evidence. Select checks that can reveal loss of effectiveness; no-alert is inconclusive when coverage or reporting is missing.

  2. Review and reconcile what is really covered

    Compare current inventories and responsibilities with reporting sources. Review recent exceptions, stale/missing devices, excluded populations, failed collection and changed service connections. Check existing Windows, Entra, Microsoft 365 and Azure evidence only for the coverage they demonstrate. A product monitoring interval is not the organization's complete review process.

  3. Act on loss of effectiveness

    Record actual review dates, observations, escalations and decisions. Open corrective actions, verify results and adjust monitoring when systems or responsibilities change. Periodic assessments and ongoing monitoring complement each other; one annual report or an unattended console cannot show both.

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 assessed control worked.

3.12.3
Trace selected controls through ongoing checks, actual dated reviews and responses to changed or failing effectiveness, including missing telemetry and manual controls.
Records to keep: Monitoring responsibility and review rhythm, source/coverage map, actual review and exception records, corrective actions and verified follow-up.

Records to keep

  • Ongoing control-check ownership, coverage, indicators, review rhythm and escalation.
  • Actual dated monitoring reviews, reporting gaps, changed scope, responses and follow-up verification.

If a check fails

When reporting fails, record the blind spot and use an approved alternative review or interim safeguard while the source is restored. Do not suppress the exception or infer safety from an empty report. Involve Incident Response when evidence suggests an incident.

Working with a small budget

Use existing logs, operational reviews and controlled records first. Extra retention, automated alerting, Defender, Intune, SIEM or third-party services can add cost and need feature-specific licensing. The register itself does not monitor a control.

References: NIST SP 800-171A, June 2018 · NIST SP 800-171 Revision 2 · Microsoft Entra sign-in logs · Microsoft Entra reporting retention · Microsoft Purview Audit solutions · Defender for Cloud regulatory compliance

Back to requirements ↑

Requirement 3.12.4

Maintain an SSP that describes the actual system

Develop a system security plan and keep it current. It must describe the real system boundary, operating environment, requirement implementation and relationships or connections. Review all eight objectives rather than treating a template title as completion.

Official requirement and assessment objectives

Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

NIST SP 800-171A, June 2018. Determine if:

Official objectives for 3.12.4
ObjectiveOfficial text
3.12.4[a]a system security plan is developed.
3.12.4[b]the system boundary is described and documented in the system security plan.
3.12.4[c]the system environment of operation is described and documented in the system security plan.
3.12.4[d]the security requirements identified and approved by the designated authority as non-applicable are identified.
3.12.4[e]the method of security requirement implementation is described and documented in the system security plan.
3.12.4[f]the relationship with or connection to other systems is described and documented in the system security plan.
3.12.4[g]the frequency to update the system security plan is defined.
3.12.4[h]system security plan is updated with the defined frequency.

What to do

  1. Develop and document the system description

    Identify the SSP owner/version and the system that processes, stores or transmits CUI. Describe the boundary and operational environment with controlled inventory, data-flow and diagram references. Include people, locations, endpoints, identity, applications, remote access, printing, backups, administration, providers and dependencies as applicable. A product subscription is not the boundary.

  2. Explain implementation and connected responsibilities

    Describe how each applicable security requirement is actually implemented, by which roles/components and with which evidence references. Identify requirements approved as non-applicable by the designated authority with their decision references; do not invent exemptions from product limitations. Describe relationships and connections to other systems, data flows, trust/access paths and customer/provider responsibilities. Link agreements and provider evidence that actually cover the service.

  3. Define and perform periodic SSP updates

    Approve the update frequency and responsible reviewer, then retain actual dated updates at that frequency. Use approved change records and new connections as additional review triggers. Compare the plan with current system facts and implemented safeguards; resolve contradictions and retain version/approval history. The supplied Security Assessment plan is a planning aid, not a complete SSP.

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 assessed control worked.

3.12.4[a]
Locate the developed system-specific SSP and confirm its owner, version and controlled record location.
Records to keep: Actual SSP document with system identity, accountable owner and version/approval references.
3.12.4[b]
Compare the SSP boundary description with current CUI processing, storage and transmission and scoped system components.
Records to keep: SSP boundary section, current inventory/diagram/data-flow references and reconciliation observations.
3.12.4[c]
Check that the SSP describes the actual operating environment, including relevant facilities, users, technologies, remote work, services and dependencies.
Records to keep: SSP environment description, current operational records and identified differences.
3.12.4[d]
Identify requirements approved as non-applicable by the designated authority and trace each to its actual decision and rationale.
Records to keep: Identified non-applicability list and designated-authority approval references, or a documented review that no such approved decisions apply. Product absence alone is insufficient.
3.12.4[e]
Compare requirement-by-requirement SSP implementation descriptions with the actual roles, settings, procedures and inherited/customer responsibilities.
Records to keep: System-specific implementation narratives, current technical/procedural evidence and unresolved discrepancies.
3.12.4[f]
Trace relationships and connections to other systems into the SSP, including provider, support, identity, remote and information-transfer paths that apply.
Records to keep: SSP relationship/connection descriptions, diagrams, data-flow/access records, agreements and responsibility/evidence references.
3.12.4[g]
Find the defined frequency for updating the SSP and the accountable schedule owner.
Records to keep: Approved SSP update interval, schedule, responsible role and missed-update escalation.
3.12.4[h]
Compare actual SSP update/version dates with the defined frequency and inspect changes reflecting the current system.
Records to keep: Dated SSP updates, review/approval and version history, change reconciliation and overdue-update actions.

Records to keep

  • System-specific SSP, boundary/environment and requirement implementation descriptions, relationships/connections and supporting evidence.
  • Designated-authority non-applicability decisions, defined update frequency and actual update/review/version records.

If a check fails

Keep discrepancies and unapproved non-applicability claims unresolved. Assign the actual boundary/implementation review and update, involve the designated authority where needed and preserve real dates and versions. Do not erase a deficiency by rewriting the SSP to claim an unimplemented safeguard.

Working with a small budget

A controlled Word document, diagrams and existing records can support the SSP without a new platform. The work is system-specific analysis and upkeep. A vendor template, certificate or provider service name does not supply the missing system description or customer evidence.

References: NIST SP 800-171A, June 2018 · NIST SP 800-171 Revision 2 · Microsoft shared responsibility in the cloud · Azure Virtual Desktop security responsibilities · 32 CFR 170.21: CMMC POA&M conditions

Back to requirements ↑

Microsoft evidence paths

Start with evidence you already have, then compare it with actual control coverage and behavior. Identify the Windows edition, join, management authority, tenant, service environment and entitlement first. These paths have not been tested in a tenant. Suggested future checks need owner authorization, representative harmless test accounts/files, expected results, stop limits and recovery. No cloud label establishes CUI suitability.

AD DS-only and hybrid Windows

  1. Link the assessment sample to the approved inventory and SSP. Identify the domain, relevant organizational unit, local settings and any cloud management of the device. Hybrid join alone does not prove a safeguard is applied.
  2. For an authorized local read-only review, gpresult /r can display Resultant Group Policy summary. Review the documented computer/user scope and necessary permissions; do not supply credentials on a command line. Keep any detailed report in protected storage. This covers Group Policy evidence, not every MDM or application setting.
  3. Compare the effective setting with the approved control and relevant dated Windows or application records. For an access control, for example, check authorized permitted/denied behavior using harmless approved accounts and files in a suitable environment. Keep proposed checks separate from actual observed results.
  4. In hybrid environments, reconcile local policy, Entra identity events and any Intune evidence for the same sample and date. Explain conflicts, stale devices and excluded scope. Do not weaken protection to create an exercise result.

Microsoft Entra joined Windows

Entra join is not evidence of Intune enrollment or control effectiveness. Where already licensed and used, compare assigned management policy with actual device reporting and authorized behavior checks. For identity evidence, Microsoft documents sign-in logs under Entra ID → Monitoring & health → Sign-in logs, accessible with an appropriate reader role. Review the relevant identity, application, resource, time and sign-in type. Check log coverage and available history before interpreting an absent event; retention and advanced features depend on licensing and configuration.

Commercial Microsoft 365 and Azure

Use existing Microsoft 365 audit records for relevant user/admin operations where available. Check the actual workload, time range, permissions and retention. Link a restricted evidence reference to the specific objective and assessment date. An export alone does not show who reviewed it or what the control achieved. Separate Audit Standard from Premium and additional retention entitlements.

Secure Score suggests posture improvements and can guide evidence selection. Recommendations may appear for features outside the current license. Its number is not a CMMC score or a compliance finding. Defender for Cloud can contribute scoped automated and manual assessment evidence; verify the assigned standard and subscription/resources and keep customer manual work explicit. Adding non-default standards requires an eligible paid Defender plan. No dashboard covers all people, facilities, local systems or SSP content.

GCC, GCC High and Azure Government

Record the actual identity, Microsoft 365, Defender and Azure service instances separately. National clouds use distinct environments and endpoints. Check current government capability and licensing documentation before reusing a commercial evidence path, query or export destination. GCC can use different Defender offerings, and GCC High or DoD feature availability may differ. Review provider evidence for the exact service and customer duties; do not infer inheritance or legal suitability from a subscription name.

Azure Virtual Desktop

Include clients, identities, applications, session-host operating systems, deployment configuration and network controls in customer/partner assessment coverage. Map Microsoft-managed components separately. Reconcile evidence with current hosts and the image used to create replacements, including short-lived hosts. Check actual host-pool, identity and application scope against the SSP relationships and CUI paths. A corrected live host does not establish that the deployment image or next replacement is corrected.

Included tools and optional licenses

The editable Word and Excel materials, supported local Windows reports and already available records can support a practical review process. They do not collect evidence automatically or replace necessary checks. Intune, Defender products, additional audit retention and centralized monitoring need their own actual entitlement, supported platform and cloud availability. Verify the gap and existing licenses before buying; no subscription completes this domain.

Safe verification, failures and recovery

Begin with existing restricted records. Compare one harmless sample reference, expected configuration, actual event or observed behavior, timestamp, reviewer and coverage limit. A stale source or empty result remains unresolved. Any later technical check or correction needs separate scoped approval and recovery arrangements; stop for unexpected access, lockout, service impact or scope overrun. Preserve protected records, contact the owner, use approved recovery and recheck the control before closing. No active scan, real CUI transfer or production restriction change is part of these exercises.

Windows policy evidence · Entra sign-ins · Microsoft 365 audit · Azure assessment scope · AVD responsibilities

Internal actions and formal CMMC conditions

The corrective-action register helps your organization identify, plan, implement and review work. It does not grant conditional CMMC status or establish formal POA&M eligibility. Current 32 CFR 170.21 places conditions on the select requirements permitted on a conditional-status POA&M and excludes SSP requirement 3.12.4 at Level 2. Check current official rules and the applicable assessment process for eligibility, required closeout and status decisions. These templates do not perform official scoring, determine MET findings or submit information to SPRS.

Three practical exercises

These situations are fictional. Discuss them with the system, security, provider 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.12.1, 3.12.3

The score improved but the assessment is overdue

In this fictional situation, a team has an approved quarterly control-assessment schedule, but the latest review was missed. A manager proposes using an improved Microsoft Secure Score as proof that all controls work. One Windows device has stale reporting and the team has no observation of the physical visitor process. Nobody can show who reviews monitoring exceptions between assessments.

Discuss

  1. Which defined frequency and actual dated assessments should the team find?
  2. What additional evidence would determine actual control effectiveness?
  3. How should stale reporting and missing ongoing reviews be handled?

What a useful response includes

  • Keep the real review dates and identify the overdue scope. Assign an actual assessment with an owner, method, representative samples and approved harmless checks.
  • Compare policy and configuration with actual behavior and records for each objective. Include people, physical procedures, endpoints and provider duties. Secure Score is a posture input, not a CMMC assessment result.
  • Assign an owner and review rhythm for ongoing checks, stale telemetry, changed scope and exceptions. Keep missing coverage open and link corrective actions to actual later verification.

Lesson: A dashboard can help select evidence. It cannot replace actual effectiveness assessments at the defined frequency or ongoing monitoring of controls outside its coverage.

Record: Record fictional missed dates, coverage and evidence gaps, decisions participants actually explain, owners and follow-up. No tenant check, assessment result or technical test is represented.

Supports 3.12.2

The corrective plan was approved but never implemented

In this fictional situation, an assessment found that an access restriction did not apply to a replacement AVD host. The team wrote an action plan and closed the internal ticket when management approved it. There is no execution record, no result from the replacement image and no permitted or denied access check. A manager suggests calling the spreadsheet an approved CMMC POA&M.

Discuss

  1. Which deficiency and affected scope must be linked to the action?
  2. What implementation and verification records remain missing?
  3. What does an internal action register establish about CMMC conditional status?

What a useful response includes

  • Identify the actual deficient control, affected hosts and deployment image, evidence reference and remaining exposure. Reopen the action until actual implementation and verification are reviewed.
  • Assign approved steps, owner, resources, milestones, target and safe recovery. Keep actual execution separate from approval; verify the corrected image and representative deployed host using an authorized harmless test.
  • Treat the workbook as an internal corrective-action record. Consult current official CMMC POA&M conditions and the applicable assessment process separately; management approval and a completed row do not establish eligibility or status.

Lesson: Identifying a deficiency, developing a plan and implementing that plan are three separate objectives. Approval alone does not correct a control.

Record: Record fictional deficiency, missing execution and verification, proposed recovery and accountable next actions. No production change or official CMMC decision is performed.

Supports 3.12.4

The system security plan missed a new connection

In this fictional situation, a team copied a generic system security plan and filled in its organization name. Its CUI service now connects to a new support provider and a remote printing path, but the boundary diagram and connection list are unchanged. The plan says every requirement is inherited from Microsoft and marks one requirement non-applicable without designated-authority approval. The defined update date has passed.

Discuss

  1. Which of the eight SSP objectives need distinct evidence?
  2. What boundary, environment, implementation and relationship details need correction?
  3. How should unsupported non-applicability and missed updates be recorded?

What a useful response includes

  • Locate the developed SSP and its version, actual system boundary, operating environment, requirement implementation descriptions, relationships/connections, approved non-applicability records, defined update frequency and actual update history.
  • Trace the changed CUI path, support connection, printing, identity, endpoint and provider responsibilities. Describe how requirements are actually implemented and link restricted evidence; a cloud label does not establish inheritance.
  • Resolve unsupported non-applicability through the designated authority and current applicable guidance. Preserve actual dates, assign the overdue update and review changed scope and implementations. Keep gaps open rather than claiming the template is complete.

Lesson: An SSP must describe the actual system and remain current. A filled template, provider name or unapproved non-applicability claim leaves material objectives unresolved.

Record: Record fictional SSP version and missed changes, eight-objective review gaps, designated-authority decision needed and update owner/date. No real system information or SSP approval is represented.

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

Control review and ongoing-check register

Schedule effectiveness assessments and ongoing checks, link actual results and retain missing coverage and follow-up.

Download Excel file ↓

Excel

Corrective-action register

Link identified deficiencies to approved plans, actual implementation, verification and remaining actions.

Download Excel file ↓

Word

Security Assessment plan

Set responsibilities, assessment frequency, ongoing monitoring, corrective-action decisions and SSP review requirements.

Download Word file ↓

Word

Assessment and SSP review procedure

Perform evidence reviews, implement and verify corrections, and examine all eight SSP objectives with editable record fields.

Download Word file ↓

Word

Security Assessment exercises

Discuss an overdue review, an unimplemented action plan and an SSP with a missing connection. All situations are fictional.

Download Word file ↓

Ready for record review means a row is prepared for someone to examine. It is not verified effectiveness, implemented correction, a current SSP or a compliance finding. Keep remaining limitations and next actions explicit.

Turn a review gap into an assigned action

In a fictional review, the SSP lists a support provider but omits its new connection and the update date has passed. Keep 3.12.4[f] and [h] as Evidence to check in the Level 2 gap-and-action worksheet. Link the restricted discrepancy and assign the actual connection review, SSP update and reviewer/date. The action register should show the developed plan, actual implementation and verification separately. A planned update does not show that either objective is satisfied.

Use Risk Assessment for risk-based prioritization, Configuration Management for inventories and controlled changes, Audit and Accountability for logging, and Incident Response for suspected incidents.

Sources and review notes

Sources reviewed October 28, 2026. Official text is separate from suggested actions. The Revision 2 baseline and June 2018 objectives are preserved. Product documentation supports the described features and limits, not a claim that your deployment works. Frequencies, evidence, provider duties and system descriptions depend on actual scope. Microsoft paths remain untested in a tenant; no assessment, monitoring review or correction was performed by this guide.

  • 32 CFR 170.14: CMMC model

    CMMC Level 2 uses the NIST SP 800-171 Revision 2 requirements. This guide preserves that baseline.

  • NIST SP 800-171A, June 2018

    Four Security Assessment requirements and 14 objectives, including all eight SSP objectives. The singleton 3.12.3 identifier is retained.

  • NIST SP 800-171 Revision 2

    Security Assessment discussion supports actual effectiveness reviews, corrective plans, ongoing monitoring and system-specific SSP descriptions.

  • 32 CFR 170.21: CMMC POA&M conditions

    An internal action register does not establish conditional CMMC status or POA&M eligibility. Check the current official conditions and assessment process separately; 3.12.4 is excluded from a Level 2 conditional-status POA&M.

  • Microsoft gpresult reference

    Resultant Group Policy can support AD DS and hybrid endpoint evidence. It does not report all cloud management or prove a control works.

  • Microsoft Entra sign-in logs

    Review existing sign-in details for the relevant identities, applications and resources using appropriate reader permissions. Different sign-in types need attention.

  • Microsoft Entra reporting retention

    Available history depends on report type, license and configured export/retention. A missing old event is not evidence that it never occurred.

  • Microsoft Purview Audit solutions

    Existing Microsoft 365 audit records can support a review. Check actual workload coverage, permissions, licensing and retention before relying on them.

  • Microsoft Secure Score

    Posture recommendations are inputs for investigation, not official CMMC scoring or proof of every objective. A visible recommendation does not establish entitlement to its feature.

  • Defender for Cloud regulatory compliance

    Check the assigned standard and subscription/resource scope and separate automated from manual evidence. Additional non-default standards require an eligible paid plan.

  • Microsoft shared responsibility in the cloud

    Map customer and provider duties for the actual service model; a provider statement alone does not demonstrate customer implementation.

  • Microsoft Entra national clouds

    Cloud instances have separate environments and endpoints. Confirm the actual service environment before collecting or exporting evidence.

  • Defender for Endpoint for US Government

    Check the actual commercial or government offering, current capability differences and desktop/server licenses. Do not assume parity between GCC, GCC High and DoD.

  • Azure Virtual Desktop security responsibilities

    Customers or partners retain duties for identities, clients, applications, session-host OS, deployment configuration and network controls.

Have a general question or correction?

Email cmmc@purposefulsecurity.com with a general description. Keep CUI, credentials, detailed boundaries, logs, evidence and completed worksheets in your approved environment. Do not email them to us.