NIST SP 800-172

Employ dual authorization to execute critical or sensitive system and organizational operations affecting CUI.

• dual authorization policy
• list of critical operations requiring two approvers
• PAM workflow screenshots
• approval ticket samples
• audit logs showing two distinct approvers

• single-admin emergency override never reviewed
• no defined list of critical operations
• dual approval bypassed in maintenance windows

Restrict access to systems and components to only those information resources owned, provisioned, or issued by the organization.

• device enrollment records (MDM)
• certificate-based device authentication policy
• NAC posture rules
• BYOD prohibition policy
• list of organization-issued assets

• personal devices reaching CUI repos
• contractor laptops not enrolled in MDM
• no certificate pinning on VPN

Employ secure information transfer solutions to control information flows between security domains on connected systems.

• cross-domain solution (CDS) architecture
• data flow diagrams
• guard/diode configurations
• approval list for transfer types
• logs of inter-domain transfers

• unfiltered file shares between enclaves
• USB transfers without DLP scan
• no logging on transfer endpoints

Provide awareness training upon initial hire, annually, and when system changes occur, focused on recognizing and responding to threats from social engineering, APT, and supply chain attacks.

• APT-specific training curriculum
• training completion records
• phishing simulation results
• supply chain attack scenarios used in training

• generic awareness only, no APT module
• no annual refresh
• phishing simulations too simple

Include practical exercises in awareness training for managers, senior executives, and selected personnel that reinforce training objectives.

• tabletop exercise reports
• executive phishing simulation results
• exercise after-action reports
• attendance logs

• executives exempted from drills
• no after-action documented
• exercises run once and never repeated

Conduct penetration testing at least annually, leveraging automated scanning tools and ad hoc tests using subject matter experts.

• annual pentest reports from independent firm
• scope of work documents
• remediation tracking from pentest findings
• tester credentials

• vulnerability scan called pentest
• pentest scope too narrow
• findings not remediated within SLA

Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and vetted software components.

• software bill of materials (SBOM)
• internal artifact repository (Artifactory/Nexus) policy
• signing key inventory
• vetting workflow

• developers pulling from public registries without proxy
• no SBOM
• unsigned binaries deployed to prod

Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, remove the components or place them in a quarantine or remediation environment.

• allowlist tool configuration (e.g., AppLocker, WDAC, Carbon Black)
• drift detection reports
• quarantine workflow
• remediation tickets

• allowlist in audit-only mode
• no automated quarantine action
• drift detected but never remediated

Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.

• asset discovery scan logs
• CMDB sync reports
• reconciliation reports between discovery and CMDB
• agent coverage metrics

• manual spreadsheet inventory
• discovery only on managed subnets
• shadow IT not captured

Identify and authenticate systems and system components, where possible, before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant.

• device certificate issuance policy
• 802.1X configuration
• mutual TLS proof for service-to-service
• certificate lifecycle records

• MAC-based authentication only
• shared device certificates
• no certificate revocation enforcement

Employ automated mechanisms for the generation, protection, rotation, and management of passwords for systems and accounts not required to use multifactor authentication.

• enterprise password manager rollout (1Password, CyberArk, Bitwarden)
• vaulted secret inventory
• rotation policy
• shared account usage logs

• passwords in code or wikis
• no rotation for service accounts
• shared admin passwords

Employ automated or manual and procedural mechanisms that prevent a system component from connecting to organizational systems unless the component is known, authenticated, in a properly configured state, or covered by a trust profile.

• Network access control policy and the enforcement configuration that implements it
• Device attestation records, for example a cryptographic hash or TPM based measurement of component state
• Trust profile definitions covering user, authentication method, device type and physical location
• Quarantine or remediation network records for components that failed the check
• Reconciliation of connected components against the approved component inventory

• Access decisions made on the user account while the device presenting it is never checked
• Attestation performed at enrolment only and never repeated on reconnection
• Contractor, supplier and unmanaged devices exempted with no compensating control
• Failed devices logged as an exception and still permitted onto the network
• Trust profile defined but not enforced anywhere in the access path

Establish and maintain a security operations center that operates 24/7, with allowance for remote/on-call staff.

• SOC charter
• staffing roster with on-call schedule
• SIEM dashboards
• MSSP contract if outsourced
• SOC playbooks

• business-hours only coverage
• no on-call rotation
• alerts not triaged overnight

Establish and maintain a cyber incident response team that can be deployed by the organization within 24 hours.

• CIRT charter and roster
• RACI matrix
• retainer with external IR firm
• training and certification records
• incident drill reports

• no named CIRT lead
• no external retainer in place
• team never exercised

Conduct enhanced personnel screening that reflects applicable laws, executive orders, directives, policies, regulations, and the specific protection needs for organizational systems.

• enhanced background check policy
• screening records for CUI-cleared roles
• periodic reinvestigation schedule
• foreign national review records

• one-time screening at hire only
• no reinvestigation cadence
• screening scope below role sensitivity

Ensure organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI through an insider threat program.

• insider threat program charter
• UEBA tool configuration
• HR-Security adverse-information handoff procedure
• investigation case files

• no formal insider threat program
• no UEBA in place
• HR-Security disconnect

Employ threat intelligence, at a minimum from open or commercial sources and any DoD-provided sources, as part of a risk assessment to guide and inform the development of organizational systems, security architectures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.

• CTI feed subscriptions list
• TIP (threat intel platform) configuration
• risk assessments citing specific threat actors
• ISAC membership

• only generic open-source feeds
• CTI not integrated into risk decisions
• no sector-specific ISAC

Conduct cyber threat hunting activities to search for indicators of compromise in organizational systems and detect, track, and disrupt threats that evade existing controls.

• threat hunting program charter
• hunt hypothesis documents
• hunt reports (monthly/quarterly)
• EDR query history
• IOC findings and remediation

• reactive monitoring only, no proactive hunts
• hunts not documented
• findings not converted to detection rules

Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.

• SOAR playbook inventory
• ML/UEBA model documentation
• analyst-tool usage metrics
• MTTR before/after analytics

• SOAR purchased but unused
• no analytic models in production
• alerts not enriched with context

Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.

• system security plan with rationale section
• control selection justification
• residual risk register signed by AO

• SSP lists controls without rationale
• no risk acceptance signatures
• stale SSP not updated after architecture change

Assess the effectiveness of security solutions at least annually or upon receipt of relevant cyber threat information, or in response to a relevant security incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.

• annual control effectiveness reports
• purple team or BAS (breach and attack simulation) results
• post-incident control review reports

• controls assumed effective without testing
• no BAS tool deployed
• no review triggered by threat intel changes

Treats supply chain risk as a continuing cycle rather than a one-off review: identify the risk carried by systems, components and services, act on what is found, and keep watching it over time.

• supply chain risk assessment covering systems, components and services
• risk register entries with named supplier or component and assigned owner
• records of risk response decisions (accept, mitigate, avoid, transfer) with rationale
• evidence of ongoing supplier monitoring such as reassessment schedules, alerts and reviews
• criticality or dependency analysis feeding the assessment

• assessment done once at onboarding and never repeated
• risks identified but no recorded response decision or owner
• monitoring covers direct suppliers only, with no view of sub-tier dependencies
• no linkage between the assessment and the 3.11.7e supply chain risk management plan

Develop a plan for managing supply chain risks; protect against supply chain risks; and update the plan at least annually and upon receipt of relevant cyber threat information.

• dated C-SCRM plan
• update log with annual revisions
• evidence of trigger-based updates after incidents
• approval signatures

• plan written once, never updated
• no trigger criteria for revision
• no leadership approval

Introduce deliberate variety into a defined set of system components so that a single working technique cannot spread unchecked across the estate. A homogeneous mix of hardware, software and firmware is cheaper to run but lets one proven exploit replicate on every identical instance, however many there are and wherever they sit in the architecture. Organizations therefore choose the components where heterogeneity earns its cost and diversify those, for example by running different vendors at the server and endpoint tiers, tunnelling one vendor's VPN inside another, or relying on address space layout randomization to vary otherwise identical builds. The aim is to raise the adversary's work factor and blunt common mode failures, including those arriving through the supply chain, not to maintain every product in duplicate.

• Documented set of components designated for diversity, with the rationale for each
• Architecture records showing different technologies or vendors at named tiers
• Anti-malware and endpoint product inventory broken down by zone or tier
• Procurement records evidencing more than one approved supplier for a designated component class
• Risk analysis weighing the diversity benefit against the vulnerabilities and support cost the extra products introduce

• Diversity claimed from accidental vendor sprawl rather than a design decision
• No organization-defined set of components in scope, so the requirement cannot be assessed
• A second product deployed but never patched or monitored to the same standard as the primary
• Diversity at the endpoint only, with a single homogeneous server or hypervisor platform untouched
• Vulnerabilities introduced by the additional products never assessed

Make a defined set of changes to systems and system components, at a defined frequency, so that the attack surface stops presenting a fixed and predictable target. Attack planning assumes consistency in the points where an adversary can enter, act or extract data, so varying the timing and circumstances of routine actions removes that assumption. Shortening credential validity at irregular intervals, performing routine activities at different times of day, alternating between technologies or suppliers, and rotating the roles and responsibilities of personnel all inject uncertainty. The intent is to force miscalculation, delay adversary action, and make attackers more observable when they do move. The organization decides which changes qualify and how often each system and component receives them.

• Definition of which changes are in scope and their frequency, stated per system and component
• Credential lifetime and rotation configuration showing varied rather than fixed validity periods
• Records of routine security and administrative actions performed at varying times
• Role and responsibility rotation records for the positions covered
• Change records over the assessment window demonstrating the variation actually occurred

• A nominally random schedule that is in practice entirely regular and therefore predictable
• Unpredictability written into policy with no execution evidence behind it
• Changes applied to one system while the rest of the estate stays static
• No organization-defined list of qualifying changes, so nothing can be assessed
• Operational disruption never assessed, so the practice is quietly abandoned after early attempts

Employ chosen technical and procedural means that corrupt the picture an adversary is working from. Misdirection routes hostile activity into deception environments, virtual sandboxes where malicious code can be diverted and adversary tradecraft safely observed. Tainting seeds data specifically so that its later appearance proves exfiltration occurred and may indicate where the adversary sits. Disinformation makes false claims about system state or defenses available to be found, whether tactically through decoy credentials that track adversary movement or strategically by devaluing what the adversary believes it has stolen. The effect sought is to frustrate reconnaissance, slow lateral movement, divert attention away from CUI and reveal the adversary's presence. Any disinformation activity is coordinated with the federal agency requiring it and planned so that authorized users are not c

• Approved deception plan naming the technical and procedural means in use
• Deception environment configuration and evidence of its isolation from production
• Register of tainted data and the detection path that reports its reappearance
• Coordination record with the associated federal agency for any disinformation activity
• Plan limiting incidental exposure of false CUI to authorized users
• Alerting rules that treat interaction with decoys as a high confidence signal

• Decoys deployed with no monitoring, so adversary interaction is never noticed
• Disinformation run without the required agency coordination
• Authorized users misled by false material because no exposure limit was planned
• Deception environment reachable from production, turning it into a pivot point
• Tainted data seeded with no capability to recognize it if it surfaces elsewhere

Employ physical isolation techniques, logical isolation techniques, or both across organizational systems and system components, so that CUI is separated into security domains behind managed interfaces, the attack surface is reduced and adversary movement between components is impeded.

• Architecture diagram identifying the CUI security domain and every physical and logical isolation boundary
• Configuration of the managed interfaces between domains, including rule sets and permitted flows
• Build records for the isolated environment, for example enclave, VLAN, VRF or air gapped segment
• Evidence that administrative and management traffic crossing a domain boundary is handled as remote access
• Segmentation or isolation test results confirming the boundary holds

• Isolation asserted in a diagram with no managed interface actually enforcing it
• Management and monitoring traffic bypassing the boundary it is supposed to cross
• Isolation applied to production while development, test or backup copies of CUI sit outside it
• No test that isolation still holds after infrastructure change
• Boundary devices shared with lower trust domains, so a compromise crosses with them

Move a defined set of system functions or resources between locations at a defined frequency, so that what an adversary located yesterday is not where it sits today. Virtualization, distributed processing and replication make it practical to relocate the components carrying critical missions and business functions, and changing addresses, naming or network topology achieves the same targeting uncertainty. Fragmentation is a second route to the same end: partitioning a data set across several components means compromising any one of them yields only a portion of the whole, and the adversary must find them all. Organizations weigh this against the burden it places on their own defenders, and update management and security tooling and train staff accordingly.

• List of system functions and resources subject to relocation, with the defined frequency
• Records of relocation or redistribution events across the assessment window
• Architecture showing distributed or replicated processing and storage locations
• Fragmentation design where a data set is partitioned across components
• Evidence that asset inventory, monitoring and security tooling track the moves
• Runbook or training updates for staff operating an environment that changes under them

• Relocation designed on paper but never executed at the stated frequency
• Monitoring, inventory and access rules left pointing at the previous location
• Only non-critical functions moved, while the mission critical ones stay fixed
• Fragments held in the same location or on the same host, so partitioning gives no real separation
• The added defender workload not planned for, so the practice lapses after the first cycle

Verify the integrity of security critical and essential software using root of trust mechanisms or cryptographic signatures.

• code signing policy
• secure boot configuration
• integrity verification logs (FIM)
• signature failure response procedure

• unsigned firmware accepted
• FIM not deployed on critical files
• no boot integrity verification

Monitor organizational systems and system components on an ongoing basis for anomalous or suspicious behavior using advanced detection capabilities.

• EDR/XDR deployment coverage report
• behavioral analytics tuning records
• anomaly alert volumes and triage metrics

• EDR coverage gaps on servers
• anomaly detection alerts disabled due to noise
• no baselines established

Decide, for every system and system component in the inventory, whether it will be brought within the scope of the enhanced security requirements or instead placed on a network dedicated to its purpose. The convergence of information technology with operational technology and connected devices widens the attack surface considerably, and much of that equipment was never designed with security as a foundational property: its connections are commonly unencrypted, unauthenticated, unmonitored and unlogged. Some of it nonetheless stores, transmits or processes CUI, and some is needed for essential missions, so it cannot simply be removed. Where intermediary components cannot supply the missing encryption, authentication, scanning and logging, the remaining answer is to isolate the equipment from the internet and from general purpose networks.

• Inventory classifying each system and component as in scope or segregated, with the decision recorded
• Authorization boundary documentation and the rationale behind the scope decision
• Network diagrams showing purpose-specific networks and how they are kept separate
• Firewall, ACL or equivalent configuration enforcing that separation
• Records for any intermediary components supplying encryption, authentication, scanning or logging on behalf of legacy equipment
• Assessment results covering the components declared to be in scope

• Operational technology and connected devices missing from the inventory, so they are neither in scope nor segregated
• Segregation asserted while a vendor support or management path still reaches the internet
• A device declared out of scope that in fact stores or processes CUI
• Purpose-specific network sharing switching, wireless or identity infrastructure with the corporate network
• Scope decided once at accreditation and never revisited as equipment is added or repurposed

Refresh organizational systems and system components from a known, trusted state at a defined frequency to reduce dwell time and persistence of malicious code.

• refresh frequency policy
• golden image pipeline
• container/VM rotation logs
• evidence of scheduled rebuilds

• long-lived servers never refreshed
• no golden image standard
• manual rebuilds with drift

Conduct reviews of persistent organizational storage locations at a defined frequency and remove CUI that is no longer needed.

• periodic CUI review reports
• data retention schedule
• deletion certificates
• scope of storage reviewed

• CUI retained indefinitely
• no documented review cadence
• deletion not verified

Use threat indicator information relevant to the information and systems being protected and effective mitigations obtained from external organizations to inform intrusion detection and threat hunting.

• TIP integration with SIEM/EDR
• IOC ingestion logs
• membership in sharing communities (ISAC, DC3, CISA)
• detection rule update logs

• IOCs ingested but not actioned
• no sharing community membership
• detection rules outdated

Verify the correctness of security critical or essential software, firmware, and hardware components through review, analysis, testing, or evaluation.

• security function verification test plan
• test execution records
• third-party evaluation reports
• remediation of defects

• security functions never tested post-deployment
• no third-party evaluation
• test results not retained