NIST security and privacy framework group: all 34 publications mapped

NIST 800-53 R4

US federal agencies operating legacy systems under FISMA and contractors referenced in pre-R5 contracts or existing FedRAMP R4 ATOs. R4 is no longer the current version but active ATOs issued under R4 remain valid during structured transition periods.

Treating Appendix J privacy controls as optional. R4 placed privacy in a separate appendix, which led most implementation teams to exclude it from scope. Those organisations carry a compounding privacy control deficit when they move to R5, where privacy is integrated throughout the catalogue.

256 controls across 18 families with Low, Moderate, and High baseline selections. Separates security controls (main catalogue) from privacy controls (Appendix J), treating privacy as an adjunct. R4 introduced the Supply Chain Risk Management family (SA-12 and related) but at a depth that later R5 expanded dramatically.

Mandatory for federal agencies under FISMA. FedRAMP R4 ATOs remain valid during the PMO-defined transition window. Agencies that fail to migrate on schedule risk ATO revocation and loss of cloud service authorisation.

Direct predecessor to 800-53 R5. The R4 baseline variants (Low, Moderate, High) mirror the same structure as R5 baselines but with fewer controls and weaker supply chain and privacy coverage. Any organisation mapping R4 to R5 will find control gaps primarily in the SR, PT, and CA families.

NIST 800-53 R4 (low baseline)

Federal systems categorised as Low impact under FIPS 199 -- systems where loss of confidentiality, integrity, or availability would have limited adverse effect on operations, assets, or individuals.

Accepting a vendor's self-classification as Low without independent FIPS 199 analysis. Systems with SaaS login portals, user account databases, or audit log repositories are frequently miscategorised as Low when their actual impact level is Moderate.

A subset of R4 controls selected for Low-impact systems. Roughly 100 controls from the full catalogue. Covers foundational access control, audit, configuration management, incident response, and system protection at minimal parameter stringency.

Required for FISMA compliance on Low systems. FedRAMP Tailored (now FedRAMP Li-SaaS) is derived from this baseline. Insufficient for systems that handle PII at scale or that support mission-critical functions -- misclassifying a Moderate system as Low and applying this baseline is a common and consequential error.

Subset of 800-53 R4. Superseded by 800-53B R5 (low) for new authorisations. The Low baseline does not satisfy 800-171 requirements -- nonfederal contractors handling CUI must implement 800-171, not 800-53 Low.

NIST 800-53 R4 (moderate baseline)

Federal systems categorised as Moderate impact -- the most common baseline for federal systems that process sensitive but unclassified information. Most agency systems and the majority of FedRAMP-authorised cloud services operate at this baseline.

Implementing the control requirement without implementing the Moderate-specific parameter values. 800-53 controls have parameters that are set differently across baselines -- the Moderate baseline specifies tighter values for things like session timeout, audit log retention, and contingency plan testing frequency. Teams that implement the control category but use Low parameter values fail Moderate assessments.

Approximately 261 control implementations from the R4 catalogue. Adds significant depth in audit and accountability, identification and authentication, system and communications protection, and contingency planning relative to the Low baseline. Requires multi-factor authentication for privileged accounts.

The standard baseline for FedRAMP Moderate authorisation. Cloud services used by federal agencies to process Moderate-impact data require a FedRAMP Moderate ATO. Failure to maintain controls at parameter levels specified in the Moderate baseline triggers Plan of Action and Milestones (POA&M) items that can jeopardise ATO status.

The R4 Moderate baseline is the ancestor of both FedRAMP Moderate and, indirectly, NIST 800-171 (which is derived from the R5 Moderate baseline). The control gap between R4 Moderate and R5 Moderate is most significant in the supply chain risk management, privacy, and zero trust-adjacent controls added in R5.

NIST 800-53 R4 (high baseline)

Federal systems where unauthorised disclosure, modification, or loss would have severe or catastrophic adverse effect -- systems supporting law enforcement, emergency services, financial systems, and health safety functions.

Applying High controls only to the primary system while leaving interconnected systems at Moderate or Low. High-impact systems typically connect to other agency systems through APIs and data feeds -- each interconnection extends the attack surface and potentially the required baseline.

The most extensive subset of R4 controls. Adds compensating controls across all families, stricter parameter values, more frequent testing and assessment cycles, and enhanced physical and personnel security requirements. Requires multi-factor authentication for all accounts, not just privileged ones.

Mandatory for FedRAMP High authorisation. A limited number of cloud services hold FedRAMP High ATOs due to assessment cost and control implementation burden. Agencies operating High-impact systems without appropriate controls face significant regulatory and mission risk.

Maps to R5 High baseline with gaps in supply chain and privacy. 800-172 enhanced requirements are designed for use in conjunction with High-baseline environments handling the most sensitive CUI.

NIST 800-53 R5

All US federal agencies and their contractors for new system authorisations. The current definitive control catalogue. Private sector organisations in highly regulated industries adopt R5 as a gold standard beyond their specific regulatory requirements.

Implementing control categories rather than control enhancements. R5 enhancements are not optional additions -- many enhancements are required at Moderate and High baselines. Teams that document the base control (e.g., AC-2, Account Management) without implementing required enhancements (e.g., AC-2(1) automated account management) produce an incomplete implementation that fails objective assessment.

Over 1,000 controls and control enhancements across 20 control families -- 18 from R4 plus the new Privacy (PT) and Supply Chain Risk Management (SR) families added in R5. Privacy is now integrated throughout all families rather than siloed in an appendix. The full catalogue without baseline selection is not intended to be implemented wholesale -- it is a selection pool from which baselines and overlays draw.

Mandatory for new federal information system authorisations. FedRAMP baseline transition to R5 is ongoing. Private sector organisations that hold older FedRAMP ATOs are migrating on PMO-defined schedules. Non-compliance with the applicable baseline results in failed assessment findings and POA&M obligations.

The foundation from which most other frameworks in this group derive. 800-171 R3 is a 110-requirement subset of the R5 Moderate baseline. 800-82 R3 overlays modify R5 parameter values for OT contexts. CSF 2.0 maps its subcategories to R5 controls. 800-161 R1 supply chain controls are embedded in the R5 SR family and extended by the 800-161 publication.

NIST 800-53B R5 (privacy baseline)

Federal systems that process Personally Identifiable Information (PII), regardless of their FIPS 199 impact level. The privacy baseline is orthogonal to Low/Moderate/High -- a Low-impact system that collects PII must implement the privacy baseline controls in addition to its impact-level controls.

Assigning privacy controls to the IT security team. Privacy controls in the PT family address individual rights, consent, data minimisation, and purpose limitation -- requirements that the IT team cannot implement alone without policy decisions from legal, compliance, and executive leadership. Organisations that route privacy controls entirely through their ISSO produce documentation that satisfies form requirements without addressing substance.

The PT (Privacy) family controls and privacy-related controls drawn from other families across the R5 catalogue. Requires privacy programme governance, data quality and integrity controls, privacy impact assessments, individual consent management where applicable, and system of records notice compliance. Privacy controls apply to both IT systems and organisational processes that handle PII.

Required under the Privacy Act of 1974, OMB Circular A-130, and FISMA for federal systems processing PII. Privacy programme deficiencies are reported in annual FISMA metrics. Significant PII breaches trigger mandatory notification requirements and can result in Congressional scrutiny and Inspector General findings.

Integrates with the NIST Privacy Framework 1.0, which uses similar outcome categories but maps to privacy regulations rather than FISMA. The 800-53 R5 privacy baseline is the mandatory federal implementation layer; the Privacy Framework is the voluntary organisational governance layer that maps to the same control objectives.

NIST 800-53B R5 (low baseline)

Federal systems categorised as Low impact under FIPS 199, using the R5 control catalogue. More current than R4 Low and includes controls from the new SR and PT families not present in R4.

Assuming R4 Low and R5 Low are equivalent. The SR and PT families are new in R5 and have no R4 equivalents -- an organisation migrating from R4 Low to R5 Low has genuine control gaps in supply chain governance and privacy programme management.

Approximately 125 controls from the R5 catalogue at Low parameter values. Includes foundational supply chain risk management controls (SR family) and basic privacy controls not present in the R4 Low baseline. Requires the same foundational security controls as R4 Low but with updated parameter values and additional control families.

Required for new FISMA Low authorisations and FedRAMP Li-SaaS equivalents under R5. Organisations that miscategorise Moderate systems as Low and apply this baseline expose significant uncontrolled risk, particularly in the audit, contingency planning, and access control families where Moderate parameters are substantially more stringent.

Subset of 800-53 R5. Does not satisfy 800-171 requirements. The Low baseline does not include the full set of 800-63B authentication controls required at higher assurance levels -- systems with privileged user accounts typically need Moderate or High authentication control parameters regardless of overall system categorisation.

NIST 800-53B R5 (moderate baseline)

Federal systems categorised as Moderate impact under FIPS 199 using the R5 catalogue. The baseline used by the majority of new federal system authorisations and the foundation for FedRAMP Moderate.

Treating supply chain controls (SR family) as documentation exercises. SR-2 (Supply Chain Risk Management Plan), SR-3 (Supply Chain Controls and Processes), and SR-5 (Acquisition Strategies, Tools, and Methods) require substantive supplier vetting, contractual flow-down requirements, and ongoing supplier monitoring -- not a one-time policy document.

Approximately 325 controls from the R5 catalogue at Moderate parameter values. Key additions over R4 Moderate include the full SR family (supply chain risk management), integrated PT family controls, and enhanced authentication requirements including phishing-resistant MFA for privileged access. Continuous monitoring requirements are also more explicit in R5 than R4.

The standard for FedRAMP Moderate and the majority of new federal ATOs. Assessment gaps at Moderate produce POA&M items with defined remediation timelines. Critical deficiencies (open high-severity findings) can cause ATO suspension during remediation.

Parent of 800-171 R3 -- the 110 CUI requirements in 800-171 are a derived subset of this baseline. Organisations that achieve solid R5 Moderate implementation are approximately 80% of the way to 800-171 R3 compliance, but the 20% gap includes control families where 800-171 uses different identifiers and assessment procedures that do not directly map.

NIST 800-53B R5 (high baseline)

Federal systems categorised as High impact under FIPS 199 using the R5 catalogue. Systems in law enforcement, emergency response, critical infrastructure control, and financial system categories. A small number of FedRAMP High-authorised cloud services.

Applying High security controls to the primary system while operating supporting infrastructure at Moderate. Log aggregation systems, identity stores, and backup systems that support a High-impact application are part of the same security boundary and must be assessed at the same baseline.

Approximately 425 controls from the R5 catalogue at High parameter values. Adds controls for penetration testing of organisational systems (CA-8), detailed audit log analysis (AU-6 enhancements), hardware-rooted trust mechanisms, and enhanced personnel security. Multi-factor authentication required for all users, not just privileged accounts. More frequent contingency plan testing, including full failover exercises.

Required for FedRAMP High authorisation and FISMA High system ATOs. Significantly higher assessment cost than Moderate. Non-compliance at High typically involves critical findings with immediate remediation requirements. Unmitigated High findings are not compatible with maintaining ATO status.

Maps to 800-172 usage context -- 800-172 enhanced requirements are typically invoked for environments already operating at R5 High baseline. 800-82 R3 High OT Overlay provides the equivalent parameter set for OT environments at High impact levels.

NIST 800-53 R5 (NOC)

Organisations implementing tailored 800-53 R5 control sets that need to apply controls not included in any standard baseline. NOC (Not Otherwise Categorized) controls are available for selection when an organisation's specific risk environment warrants controls beyond what the baseline provides.

Ignoring NOC controls entirely. Some NOC controls address threat scenarios that are common in specific industries but were excluded from standard baselines to keep assessment scope manageable. Organisations in high-threat environments benefit from reviewing the NOC set during their risk assessment and selecting applicable controls for explicit implementation.

No fixed requirement set -- the NOC designation identifies controls in the 800-53 R5 catalogue that do not appear in any of the Low, Moderate, or High baselines. These controls are available for tailoring -- organisations can add them to a baseline when their risk assessment identifies specific threats that baseline controls do not adequately address.

Not directly enforced. NOC controls appear in an organisation's SSP only when selected through tailoring. Selecting NOC controls without documenting the risk rationale creates assessment confusion -- assessors expect to see justification for any deviation from the standard baseline, including additions.

Supplement to all 800-53 R5 baselines. Relevant when reviewing 800-82 R3 OT overlays, which sometimes reference NOC controls for specific ICS security scenarios not covered by the standard baselines.

NIST 800-37 R2

Federal agencies and their contractors implementing the Risk Management Framework (RMF) process for system authorisation. The process guide for how to use 800-53 -- not a list of controls, but the methodology for categorising systems, selecting controls, implementing them, assessing them, authorising systems, and monitoring them continuously.

Treating the Assess step as a documentation review rather than an objective evaluation. 800-37 R2 requires that control assessments be conducted by assessors independent of those who implemented the controls. Organisations that have their implementation team self-assess produce Assessment Reports that authorising officials cannot rely on for risk decisions.

Six RMF steps: Prepare (establish organisational risk context), Categorise (determine system impact level per FIPS 199), Select (choose baseline controls and apply tailoring), Implement (deploy controls and document implementation), Assess (evaluate control effectiveness), Authorise (obtain ATO from authorising official), and Monitor (continuous monitoring of control status). R2 added the Prepare step and integrated privacy into all steps.

The mandatory process framework for FISMA compliance. Agencies that issue ATOs without completing all RMF steps produce invalid authorisations. Inspector General FISMA evaluations assess whether the RMF was followed correctly. Skipping or shortcutting the Assess step is the most common finding in IG reviews.

The process wrapper around 800-53. The RMF process produces the System Security Plan (which documents 800-53 control implementation), the Security Assessment Report (which records assessment results), and the Plan of Action and Milestones (which tracks remediation). 800-39 provides the enterprise-level risk management context within which the RMF operates.

NIST 800-39

Federal agency executives, risk executives, authorising officials, and security programme managers responsible for managing information security risk at the organisational level -- above the individual system level addressed by 800-37.

Implementing Tier 3 (system-level RMF) without establishing Tier 1 or Tier 2 risk governance. This produces a situation where individual system ATOs are granted or denied based on individual ISSO judgment rather than a defined organisational risk tolerance -- every risk acceptance decision becomes arbitrary.

A three-tier risk management hierarchy: Tier 1 (organisation level -- governance, risk tolerance, risk strategy), Tier 2 (mission/business process level -- risk to mission functions), Tier 3 (information system level -- system-level risk managed through RMF). Requires organisations to establish risk frames, assess risks at all three tiers, respond to risk, and monitor risk continuously.

Not independently audited but forms the conceptual foundation of FISMA compliance. Agencies that issue ATOs in isolation without Tier 1 risk governance produce compliance artefacts that do not support actual risk-informed decision making. OMB FISMA metrics assess organisational risk management maturity.

Sits above 800-37 in the governance hierarchy. 800-37 implements the RMF process; 800-39 establishes why that process exists and what organisational structures must govern it. Private sector organisations adopting the NIST framework often implement 800-53 and 800-37 without ever reading 800-39, which means their risk management programme lacks a defined risk tolerance framework.

NIST 800-63B

Federal agencies and their digital service providers implementing online authentication. Defines three Authenticator Assurance Levels (AAL1, AAL2, AAL3) that determine appropriate authentication mechanisms based on the consequences of authentication failure. Widely adopted in private sector as a technical standard for MFA implementation.

Counting SMS OTP as MFA for compliance purposes. It satisfies a checkbox reading of 'multi-factor' but does not meet AAL2 under 800-63B, does not satisfy OMB M-22-09 phishing-resistant requirements, and has a demonstrated real-world failure rate through SS7 attacks and SIM swapping.

AAL1: single-factor authentication, including passwords with defined complexity and breach checking requirements. AAL2: multi-factor authentication using an approved authenticator -- time-based OTP apps, hardware tokens, or smart cards satisfy this level; SMS OTP does not meet AAL2 due to SIM-swap risk. AAL3: hardware-based phishing-resistant authenticators (FIDO2/WebAuthn, PKI smart cards) with verifier impersonation resistance.

Referenced by OMB M-22-09 (zero trust strategy) which requires agencies to use phishing-resistant MFA (AAL3) for all federal staff. CISA guidance extends this to contractors. Agencies that continue to use SMS OTP or voice callback for privileged access are non-compliant with OMB M-22-09 even if they have an 800-53 ATO.

Implements the IA (Identification and Authentication) control family requirements in 800-53 at a technical specification level. 800-207 ZTA references 800-63B as the identity assurance foundation for zero trust decisions. 800-171 R3 references AAL requirements from 800-63B for CUI system authentication.

NIST 800-82 R3 (LOW OT Overlay)

Operators of industrial control systems, SCADA systems, distributed control systems, and other operational technology environments where system impact is categorised as Low under FIPS 199. Relevant to utilities, manufacturing, water treatment, and building automation systems where a disruption would have limited consequence.

Applying the Low overlay to systems that are actually Moderate or High impact. A water treatment facility that applies the Low OT overlay because it categorised its control system as Low-impact is applying insufficient controls to a system where compromise could affect public safety.

An overlay on the 800-53 R5 Low baseline that modifies specific control parameters to account for OT constraints. Key modifications include relaxed patch management timelines (many OT systems cannot accept automated patching without vendor validation), modified audit logging requirements, and adjusted access control parameters for physical control interfaces.

Referenced by CISA for critical infrastructure owners and operators. Not independently mandated for most private sector OT environments, but TSA cybersecurity directives for pipeline and rail operators reference 800-82 R3. Failure to apply OT-appropriate controls often means standard IT controls are applied to OT environments in ways that create operational risk.

One of three OT overlays derived from 800-82 R3. Must be used in conjunction with 800-53 R5, not standalone. 800-82 R3 also references 800-37 for the RMF process applied to ICS environments.

NIST 800-82 R3 (MODERATE OT Overlay)

Operators of OT and ICS environments where compromise would have serious adverse effects -- the most common category for critical infrastructure control systems in energy, water, and manufacturing sectors. Systems that control processes where a disruption could cause significant economic damage or health and safety consequences.

Treating IT/OT segmentation as a one-time firewall configuration exercise. Network segmentation in OT environments degrades continuously as operational requirements create exceptions -- temporary connections for vendor support, data historian feeds, and maintenance activities that were supposed to be closed but were not.

An overlay on the 800-53 R5 Moderate baseline with OT-specific parameter modifications. Adds requirements for IT/OT network segmentation (typically a demilitarised zone between enterprise IT and process control networks), out-of-band management channels for critical control systems, enhanced physical security for control room and field device access, and vendor remote access controls through jump servers with session recording.

The most applicable overlay for most critical infrastructure operators subject to CISA and sector-specific cybersecurity regulations. TSA pipeline security directives, NERC CIP for electric utilities, and AWIA for water utilities all reference controls that substantially overlap with the 800-82 R3 Moderate overlay scope.

Middle tier of the three OT overlays. The specific segmentation and remote access controls it requires overlap significantly with 800-207 Zero Trust Architecture principles applied to OT contexts.

NIST 800-82 R3 (HIGH OT Overlay)

Operators of OT environments where compromise could have severe or catastrophic consequences -- nuclear facilities, chemical plants, bulk electric system operators, and other critical infrastructure where a security failure could cause mass casualties, catastrophic environmental damage, or widespread infrastructure failure.

Implementing data diodes logically but not physically. Unidirectional gateways are sometimes implemented as firewall rules that prohibit return traffic rather than hardware-enforced one-way data flow. A misconfigured firewall rule is a software control that can be changed or bypassed; a hardware data diode is not.

An overlay on the 800-53 R5 High baseline with OT-specific modifications. Adds requirements for unidirectional security gateways (data diodes) on connections between OT and external networks, enhanced physical access controls with multi-person integrity for critical control rooms, hardware-based authentication for field device access, and formal change management processes with cybersecurity review for any modification to control system configuration.

Applicable to the most regulated OT environments. Nuclear facilities operate under NRC cybersecurity rules that substantially align with 800-82 R3 High. NERC CIP High Impact Bulk Electric System assets must meet requirements that map to this overlay. Non-compliance can result in civil penalties in regulated sectors.

Highest tier OT overlay. Paired with 800-53 R5 High baseline. Organisations implementing this overlay are typically also subject to sector-specific frameworks (NERC CIP, NRC 10 CFR 73.54) that reference 800-82 R3 either directly or through CISA cross-reference.

NIST 800-160

Systems engineers, security engineers, and programme managers responsible for designing and building federal information systems from scratch or conducting major modifications. Applies to the development lifecycle rather than operational security. Used by prime contractors on major federal acquisition programmes.

Applying 800-160 principles only to the initial design phase and ignoring security engineering during integration, testing, and modification phases. Security properties established in design degrade during integration as components from different vendors are assembled.

Systems security engineering principles integrated into the full system lifecycle: concept, development, production, utilisation, support, and retirement. Addresses trustworthiness (security, reliability, safety, resilience, privacy) as system properties that must be engineered in, not added on. Provides processes for defining security requirements at the system level, establishing security architecture, and conducting security verification.

Referenced in DoD acquisition regulations and large-scale federal IT programme requirements. Not independently audited for operational systems but required in systems engineering process documentation for major acquisitions. Programmes that deliver systems without documented security engineering processes produce operational systems where security controls were retrofitted rather than designed in.

Sits upstream of 800-53 in the lifecycle. 800-160 establishes what security properties the system must have; 800-53 provides the controls that implement those properties in the operational environment. 800-218 (SSDF) addresses the software development dimension of what 800-160 addresses at the system level.

NIST 800-161 R1 (full publication)

Federal agencies and critical infrastructure organisations developing enterprise-level C-SCRM programmes. The full publication provides the complete framework across all four tiers and all implementation levels. Organisations implementing 800-161 for the first time should start here to understand the full architecture before selecting the appropriate tier documents.

Treating 800-161 as a vendor questionnaire checklist. The framework requires substantive supplier risk assessment processes, contractual security requirements that flow down to sub-tier suppliers, and ongoing monitoring of supplier security posture -- not annual self-assessment forms.

A tiered C-SCRM programme operating at three levels: organisational (enterprise policies and governance), mission/business process (programme-level supplier risk decisions), and system (acquisition-specific supplier vetting and control flow-down). The publication defines C-SCRM policies, plans, risk assessments, supplier agreements, and monitoring requirements. Integrates with the 800-53 SR (Supply Chain Risk Management) control family.

Referenced by CISA as the authoritative US government guidance for supply chain cybersecurity. EO 14028 elevated C-SCRM requirements for federal agencies. Agencies without documented C-SCRM programmes are cited in FISMA metrics. Federal contractors increasingly receive C-SCRM requirements in contract language referencing 800-161.

Extends the SR family in 800-53 R5. The C-SCRM Baseline, Level 1, Level 2, Level 3, and Flow Down variants are each separately listed in the framework group as distinct entries because they have genuinely different scopes and applicability.

NIST 800-161 R1 (C-SCRM Baseline)

All organisations -- the C-SCRM Baseline represents the minimum foundation that every organisation should have regardless of their position in the supply chain or their size. Establishes that C-SCRM is a documented, governed discipline rather than an ad hoc activity.

Confusing an approved vendor list with a C-SCRM programme. An approved vendor list is an output of supplier vetting; the C-SCRM Baseline requires the documented process that governs how the list is maintained, how suppliers are assessed, and how supply chain risk informs procurement decisions.

Establishment of a C-SCRM policy, designation of responsible personnel, integration of supply chain risk into the enterprise risk management programme, and basic supplier identification and categorisation. Does not require advanced technical controls -- the Baseline is governance and programme establishment.

The starting point for any federal contractor C-SCRM assessment. Organisations that cannot demonstrate Baseline compliance are not ready for Level 1, 2, or 3 assessment. Primes that cannot demonstrate their own Baseline compliance cannot credibly assess their suppliers.

Foundation for all higher 800-161 tiers. Must be implemented before Level 1 controls are added. The Baseline maps to the introductory SR controls in 800-53 R5 (SR-1, SR-2, SR-3).

NIST 800-161 R1 (Flow Down)

Prime contractors responsible for flowing supply chain security requirements down to their subcontractors and sub-tier suppliers. Addresses the contractual and governance mechanisms by which an organisation's C-SCRM requirements extend beyond its direct suppliers.

Writing flow-down language that is unenforceable or unverifiable. Contract clauses that require subcontractors to 'maintain appropriate security controls' without specifying what controls or how compliance will be verified produce no actual security improvement -- just liability language.

Contractual provisions that require subcontractors to implement specified C-SCRM controls, mechanisms for the prime to verify subcontractor compliance, reporting requirements for supply chain incidents involving subcontractors, and right-to-audit clauses enabling the prime to assess sub-tier security. Flow Down requirements must be risk-calibrated -- not every subcontractor receives the same requirements.

Enforced through contract. Federal primes that fail to flow down required C-SCRM provisions may be in breach of their government contracts. Sub-tier supplier breaches that compromise federal data or systems are increasingly traced to flow-down failures in prime contractor agreements.

Companion to the C-SCRM Baseline and Levels 1-3. Flow Down is the mechanism that extends the programme downward through the supply chain. Without effective Flow Down, Level 2 and Level 3 programme controls at the prime level are undermined by uncontrolled risk at the sub-tier.

NIST 800-161 R1 (Level 1)

Organisations implementing C-SCRM controls at the organisational level -- enterprise-wide policies, governance structures, and risk management processes that apply across all programmes and acquisitions.

Building a Level 1 C-SCRM programme in isolation from procurement. C-SCRM at Level 1 requires that security requirements be integrated into acquisition strategy before RFP issuance -- not added as a checklist item during contract negotiation.

Documented C-SCRM strategy and implementation plans, integration of C-SCRM into enterprise risk management, C-SCRM-aware procurement processes, supplier security requirement templates, and C-SCRM training for procurement and programme staff. Level 1 is about governing the programme from the top -- not individual system acquisitions.

Required for federal agencies to demonstrate mature C-SCRM governance. FISMA metrics evaluate organisational-level C-SCRM maturity. Primes seeking to win federal contracts with C-SCRM requirements in their performance work statements must demonstrate Level 1 maturity.

Built on the C-SCRM Baseline. Level 1 controls provide the organisational governance that Level 2 (mission/process) and Level 3 (system) controls operate within.

NIST 800-161 R1 (Level 2)

Organisations implementing C-SCRM at the mission and business process level -- programme offices, acquisition teams, and mission owners responsible for specific programmes or business functions that rely on external suppliers.

Conducting criticality analysis once at programme inception and never updating it. Supplier landscapes change -- a component that was sourced from a low-risk supplier in year one may be re-sourced to a different supplier in year three without a corresponding update to the criticality analysis or the programme C-SCRM plan.

Programme-level C-SCRM plans, supplier risk assessments specific to programme dependencies, criticality analysis identifying which suppliers are critical to mission success, supplier monitoring processes, and C-SCRM integration into programme milestones. Level 2 is where the enterprise governance from Level 1 gets translated into programme-specific supplier risk management.

Required for federal programmes with significant supplier dependencies. Major acquisition programmes are expected to demonstrate Level 2 maturity through programme protection plans and supply chain risk assessments. Failure to conduct criticality analysis means programmes cannot identify which supplier compromises pose the greatest mission risk.

Middle tier of the three-tier 800-161 structure. Level 2 translates Level 1 enterprise governance into programme-level action and provides the context within which Level 3 system-level controls are applied.

NIST 800-161 R1 (Level 3)

System owners, programme managers, and contracting officers responsible for individual system acquisitions. Level 3 is where C-SCRM requirements are applied to specific contracts, components, and systems being acquired.

Requesting SBOMs from suppliers without having a process to analyse them. An SBOM is a list of software components -- its value is in identifying vulnerable or compromised components. Organisations that collect SBOMs without ingesting them into a vulnerability management process have a compliance artefact, not a security control.

System-level C-SCRM plans, supplier vetting for specific system components and software, software bill of materials (SBOM) requirements in contracts, component authenticity verification, malicious code scanning of acquired components, and hardware/software provenance documentation. Level 3 is the operational layer where C-SCRM requirements appear in SOWs and are verified through acceptance testing.

Federal acquisitions of systems above certain thresholds are subject to Level 3 C-SCRM requirements under current FISMA and EO 14028 implementation guidance. SBOM requirements in federal contracts are increasing -- organisations that cannot produce SBOMs for their software components are failing Level 3 requirements in current federal procurement.

The most operationally concrete tier of 800-161. Level 3 controls map directly to acquisition-specific security requirements. SBOM requirements at Level 3 overlap with 800-218 (SSDF) requirements for software producers to maintain and disclose component inventories.

NIST 800-171 R2

Nonfederal organisations -- primarily DoD contractors and subcontractors -- that process, store, or transmit Controlled Unclassified Information. R2 is the version governing most active DFARS 252.204-7012 compliance obligations and current CMMC Level 2 contracts until R3 transitions are fully mandated.

Scoping CUI systems too narrowly. The boundary for 800-171 compliance is the CUI system boundary -- all systems that process, store, transmit, or provide security protection for CUI. Organisations routinely draw this boundary around their primary CUI-handling application while excluding email servers, file shares, authentication systems, and network devices that support it.

110 security requirements across 14 practice families, each derived from NIST 800-53 R4/R5 Moderate baseline. Organisations must document implementation in a System Security Plan (SSP) and maintain a Plan of Action and Milestones (POA&M) for any unimplemented requirements. CMMC Level 2 requires third-party assessment of all 110 requirements by a C3PAO.

Mandatory for DoD contractors handling CUI under DFARS clause 252.204-7012. Self-assessments must be scored using the DoD scoring methodology and reported to SPRS. False certification of CMMC/800-171 compliance can result in False Claims Act liability. Contracts with C3PAO assessment requirements cannot be awarded to organisations with material unimplemented requirements.

Derived from 800-53 R4/R5 Moderate baseline but uses different control identifiers. 800-171A provides the assessment methodology. 800-172 adds enhanced requirements for critical programs above the 800-171 baseline. R2 will be superseded by R3 for new contracts on a timeline defined by OUSD(A&S).

NIST 800-171 R3

Nonfederal organisations handling CUI under future DoD contract requirements. R3 aligns with 800-53 R5 control structure and is the version that CMMC Level 2 will fully reference as the transition timeline progresses. Organisations beginning 800-171 implementation now should implement R3.

Assuming R2 compliance means R3 compliance. The structural similarity conceals genuine requirement differences. R3 added explicit requirements for supply chain risk management in the SA family, planning documentation in the PL family, and updated authentication requirements aligned with 800-63B AAL guidance that R2 referenced only indirectly.

110 requirements derived from 800-53 R5 Moderate baseline, reorganised using the same control identifier structure as 800-53 R5 (e.g., AC.01, AC.02 rather than 3.1.1, 3.1.2). Adds two new requirement families not in R2: Planning (PL) and System and Services Acquisition (SA), which address CUI system security plans and supply chain requirements respectively.

Will become the governing standard for CMMC Level 2 as DoD contracts transition. Organisations implementing R2 now will need a gap assessment to R3 requirements before CMMC assessment under R3 timelines. The SA family additions in R3 mean supply chain requirements for CUI systems are now explicit in the standard.

Derived from 800-53 R5 Moderate baseline. Companion to 800-171A R3 for assessment. Sits below 800-172 in the CUI requirement hierarchy. The addition of SA-family requirements in R3 creates explicit overlap with 800-161 R1 C-SCRM requirements.

NIST 800-171A

Third-party assessors, C3PAOs, and internal assessment teams evaluating 800-171 R2 compliance. Provides the assessment procedures that specify how each requirement is assessed -- the evidence required, the assessment methods (examine, interview, test), and the assessment objectives.

Preparing for assessment without reading 800-171A. The assessment objectives in 800-171A often require evidence that organisations do not collect because the requirement text alone does not indicate it is needed. For example, the access control requirement for separation of duties in 3.1.4 has assessment objectives that require examining the documented policy, interviewing personnel, and testing system enforcement -- all three must be satisfied.

Assessment procedures for each of the 110 800-171 R2 requirements. Each procedure specifies multiple assessment objectives that must individually be satisfied. An organisation may implement a requirement and still fail assessment if their implementation does not address all assessment objectives for that requirement.

C3PAOs conducting CMMC Level 2 assessments use 800-171A procedures. Assessors who deviate from documented procedures without justification produce unreliable assessment results. Organisations that prepare for assessment using only 800-171 requirement text without reviewing 800-171A assessment objectives are routinely surprised by the evidence requests.

Companion to 800-171 R2. Superseded by 800-171A R3 for assessments against R3 requirements. The assessment procedure structure in 800-171A mirrors the methodology in 800-53A (the 800-53 assessment guide) but scoped to the 110 CUI requirements.

NIST 800-171A R3

Assessment teams evaluating compliance with NIST 800-171 R3. Updated assessment procedures aligned with the R3 requirement structure, including assessment objectives for the new PL and SA requirement families added in R3.

Assuming that passing a CMMC assessment under R2/800-171A means the organisation will pass under R3/800-171A R3. The additional assessment objectives for SA and PL family requirements will expose gaps in organisations that have never documented supply chain risk assessments for their CUI systems or maintained CUI-specific system security plans at the level R3 requires.

Assessment procedures for all 800-171 R3 requirements, updated to reflect the new control identifier structure and the new requirement families. Assessment methods remain examine, interview, and test. The R3 assessment objectives add supply chain risk assessment evidence requirements (SA family) and CUI system planning documentation requirements (PL family) that did not exist in 800-171A.

Will govern C3PAO assessments once CMMC fully transitions to R3. Organisations should review R3 assessment objectives against their current implementation to identify gaps before their next assessment cycle.

Companion to 800-171 R3. Updated version of 800-171A. Assessment procedures for the SA family additions will explicitly reference and overlap with 800-161 R1 C-SCRM programme requirements.

NIST 800-172

Nonfederal organisations handling CUI associated with critical programs and high value assets -- typically prime contractors on programmes designated by DoD or the intelligence community as requiring enhanced protection due to the nature of the research, technology, or program information involved. Not applicable to the general population of CUI contractors.

Treating 800-172 as a checklist addition. The enhanced requirements for penetration-resistant architecture require substantive changes to system design -- things like multi-hop authentication, separate administrative networks, and cryptographic mechanisms that standard CMMC Level 2 environments do not have.

35 enhanced security requirements above the full 800-171 baseline. The requirements fall into four areas: penetration-resistant architecture (designing systems to resist compromise even by sophisticated adversaries); damage-limiting operations (containing and recovering from compromise quickly); design and development protection (protecting the design and development environment itself, not just production systems); and adversary detection (identifying sophisticated threat actor activity that standard controls do not detect). Implementing 800-172 without a fully implemented 800-171 baseline is specified as invalid -- 800-172 is explicitly additive.

Invoked selectively by contracting agencies when program sensitivity warrants it. CMMC does not currently define a Level corresponding to 800-172 -- its requirements are expected to be addressed through contract-specific requirements. Contractors who cannot satisfy 800-172 requirements when invoked may be ineligible for specific program awards.

Sits above 800-171 in the CUI protection hierarchy. Requires full 800-171 implementation as a prerequisite. The adversary detection requirements in 800-172 overlap with NIST CSF 2.0 Detect function outcomes at a maturity level well above what standard 800-171 environments achieve.

NIST 800-207

Federal agencies implementing zero trust architecture under OMB M-22-09 mandates, and private sector organisations redesigning their access architecture around zero trust principles. Relevant to any organisation moving away from perimeter-based security toward identity-driven, least-privilege access.

Relabelling existing network segmentation as zero trust. ZTA is about eliminating implicit trust based on network location -- a firewall rule that allows traffic from the corporate network to an application server is not zero trust, even if it is called a micro-segment. True ZTA requires that every access request be authenticated and authorised at the application layer, not validated by network position.

Seven ZTA tenets defining the logical model: all resources are treated as if network location provides no inherent trust; all communication is secured regardless of network location; access is granted per-session with minimum required privileges; access decisions incorporate dynamic policy based on observed identity and device state; the enterprise continuously monitors assets and traffic; authentication and authorisation are performed before any resource access is granted; the enterprise collects telemetry to improve posture. 800-207 defines ZTA logical components (Policy Decision Point, Policy Enforcement Point, Policy Engine) and deployment models.

Federal agencies are mandated to achieve specific ZTA milestones under OMB M-22-09, with multi-year implementation roadmaps. Agencies that have not deployed phishing-resistant MFA, inventoried all enterprise applications, and begun application-layer encryption of traffic are behind mandate timelines.

Maps to 800-53 R5 identity, access control, audit, and monitoring control families at an architectural outcome level. 800-63B provides the identity assurance layer that ZTA requires. 800-207 is referenced in OMB ZTA implementation guidance alongside 800-53 as the technical architecture standard.

NIST 800-218 (SSDF v1.1)

Software producers selling to the US federal government (mandatory via OMB M-22-18 self-attestation), and any organisation seeking to demonstrate secure software development practices to enterprise customers. Applicable to internal development teams, ISVs, and open-source project maintainers contributing components to enterprise software.

Self-attesting SSDF compliance based on the existence of security tools without validating that the tools are actually integrated into the development pipeline and producing actionable results. A SAST tool that runs but whose findings are routinely dismissed or suppressed does not satisfy the PW practice group outcomes.

Four practice groups: Prepare the Organisation (PO) -- establish security requirements and tooling before development begins; Protect the Software (PS) -- protect development environments, code repositories, and build infrastructure; Produce Well-Secured Software (PW) -- apply secure design principles, code review, automated security testing, and vulnerability remediation; Respond to Vulnerabilities (RV) -- identify, report, and remediate vulnerabilities in released software. Each practice includes example tasks and notional implementation examples, but the SSDF defines outcomes, not specific tools.

Software producers selling to federal agencies must self-attest SSDF compliance through a form submitted to CISA. False attestation is subject to False Claims Act liability. CISA can request supporting documentation for attestations. The attestation requirement has driven widespread adoption of SBOM generation, automated SAST/DAST tooling, and formal secure code review processes.

Addresses software supply chain security at the development stage. Overlaps with 800-161 R1 Level 3 SBOM requirements from the consumer side -- the producer obligation to create SBOMs and the consumer obligation to verify them are addressed by different frameworks in this group that organisations must coordinate. Maps to the SA control family in 800-53 R5.

NIST AI 100-1 (AI RMF 1.0)

Any organisation developing, deploying, or using AI systems. Voluntary for private sector. Mandatory in practice for federal agencies and contractors developing or procuring AI systems under current OMB and NIST AI governance guidance. Relevant to any organisation building AI-enabled products for enterprise or government customers.

Mapping AI systems to AI 100-1 without completing the Map function first. The Govern and Manage functions produce governance documents that look like compliance artefacts. The Map function -- which requires systematically identifying all contexts in which the AI system operates, all affected parties, and all potential failure modes -- is skipped or done superficially.

The AI RMF is organised around four functions: Govern (establish organisational policies, accountability structures, and risk tolerance for AI), Map (identify and classify AI risks in context), Measure (analyse and assess identified risks using qualitative and quantitative methods), Manage (prioritise and apply risk treatments and monitor outcomes). The framework defines AI risk in terms of six characteristics: valid and reliable, safe, secure and resilient, explainable and interpretable, privacy-enhanced, and fair with bias managed.

No direct regulatory enforcement for private sector. Federal agency AI use is subject to OMB M-24-10 which requires agencies to designate Chief AI Officers, conduct AI impact assessments, and implement governance consistent with AI 100-1. Vendors of AI systems to federal agencies face increasing contractual AI governance requirements.

Parent of AI 600-1. Maps to 800-53 R5 control families for AI system security (RA, SI, SA families most relevant). AI 100-1 does not replace 800-53 for AI systems deployed in federal environments -- it adds AI-specific risk management on top of the existing control baseline.

NIST AI 600-1

Organisations developing, deploying, or using generative AI systems specifically -- large language models, image generation systems, code generation tools, and other systems that produce novel outputs from training data. Extends AI 100-1 with risks specific to generative AI that the general framework does not address with sufficient specificity.

Applying AI 600-1 only to purpose-built generative AI products while ignoring generative AI features embedded in enterprise software. Most enterprise SaaS platforms now include LLM-powered features -- document summarisation, code assistance, customer service automation. These embedded features are subject to the same AI 600-1 risk categories as dedicated generative AI products.

A profile of AI 100-1 addressing 12 generative AI-specific risk areas: confabulation (hallucination), data privacy risks from training and inference, data poisoning, environmental impact, homogenisation of outputs, human-AI configuration risks, information integrity threats (deepfakes, disinformation), intellectual property risks, obscene content generation, psychosocial harms, rights violations, and value chain complexity. Each risk area maps to AI RMF functions and 800-53 control families.

No direct enforcement authority. Federal agencies using generative AI tools must conduct AI impact assessments that address AI 600-1 risk categories under OMB M-24-10. Enterprise customers of SaaS platforms with embedded generative AI features are increasingly asking vendors to demonstrate AI 600-1 risk assessment completion.

Extension of AI 100-1 for generative AI. Used alongside AI 100-1, not instead of it. The data privacy risk categories in AI 600-1 overlap with the NIST Privacy Framework 1.0 and with 800-53 R5 PT family controls for organisations processing personal data through generative AI.

NIST Privacy Framework 1.0

Any organisation managing privacy risk -- primarily private sector organisations seeking a voluntary privacy risk management structure, and federal agencies supplementing their mandatory 800-53 privacy controls with organisational privacy programme governance. Designed to be used alongside the CSF rather than as a standalone framework.

Using the Privacy Framework as a substitute for legal compliance analysis. The Privacy Framework is technology-neutral and law-neutral -- it describes organisational practices, not legal obligations. An organisation that implements the Privacy Framework without also mapping its practices to applicable privacy laws (GDPR, Thailand PDPA, CCPA, etc.) has a privacy risk management programme that does not address its actual legal exposure.

Five Functions: Identify-P (privacy risk governance and asset management), Govern-P (privacy policies, roles, and risk tolerance), Control-P (data processing management and rights fulfilment), Communicate-P (data processing transparency and notification), Protect-P (data protection controls). The Privacy Framework maps to 800-53 R5 PT family controls and to privacy law obligations (GDPR, CCPA, HIPAA) through a mapping document NIST maintains separately.

Voluntary. No direct enforcement. However, the Privacy Framework is referenced in FTC enforcement guidance and state AG privacy enforcement actions as evidence of reasonable privacy practices. Organisations that demonstrate Privacy Framework implementation have a stronger defence against unfair or deceptive practices claims than those with ad hoc privacy programmes.

Voluntary companion to the CSF and to 800-53 R5 PT family. The mandatory federal layer is 800-53 R5 privacy baseline; the Privacy Framework is the voluntary organisational layer that maps to the same outcomes at a strategic level. AI 600-1 data privacy risks map to Privacy Framework Identify-P and Control-P categories.

NIST CSF 2.0

Any organisation seeking a structured approach to cybersecurity risk management. CSF 2.0 removed the original CSF 1.1's critical infrastructure focus -- it is now explicitly designed for all organisations regardless of sector, size, or maturity. Used by private sector organisations as an internal governance framework and by federal agencies to communicate security posture to executive leadership.

Treating CSF 2.0 Govern function as a documentation exercise. The Govern function added in CSF 2.0 includes Cybersecurity Supply Chain Risk Management (GV.SC) subcategories that require substantive C-SCRM programme documentation -- the same content required by 800-161 R1. Organisations that complete CSF 2.0 governance documentation without the underlying C-SCRM programme substance produce framework compliance artefacts without the risk management programme the framework is supposed to document.

Six Functions: Govern (new in CSF 2.0 -- organisational context, risk management strategy, cybersecurity supply chain risk management, roles and responsibilities, policies and oversight), Identify (asset management, risk assessment, improvement planning), Protect (identity management, awareness training, data security, platform security, technology infrastructure resilience), Detect (continuous monitoring, adverse event analysis), Respond (incident management, analysis, mitigation, reporting), Recover (recovery planning, communication, improvements). Each function contains Categories and Subcategories that map to specific controls in 800-53, ISO 27001, and other frameworks.

Voluntary but widely referenced. CISA strongly encourages CSF 2.0 adoption. Insurance underwriters increasingly ask whether organisations follow CSF. Organisations that map their control programmes to CSF have an easier time demonstrating security posture across multiple audiences (executives, auditors, customers, insurers) because CSF provides a common vocabulary.

The outcome layer over all other frameworks in this group. CSF 2.0 Subcategories map to 800-53 controls, AI RMF functions, Privacy Framework functions, and other frameworks through NIST-published informative references. Using CSF 2.0 as the top-level framework and mapping downward to 800-53 for control implementation is the recommended approach for organisations managing multiple NIST frameworks simultaneously.

800-53 R5 Moderate uses control identifiers like AC-2, AU-6, CM-6. 800-171 R3 uses identifiers like AC.01, AU.02, CM.03. The underlying security objective is substantially the same but the identifier structures, assessment procedures, and documentation formats are completely different. A System Security Plan written for 800-53 Moderate does not satisfy 800-171 R3, and vice versa. Organizations that assume their FedRAMP Moderate SSP covers their CMMC obligations are wrong on the paperwork even when the controls are correctly implemented.

Access control, audit and accountability, configuration management, identification and authentication, incident response, media protection, personnel security, risk assessment, system and communications protection, system and information integrity

800-161 Level 3 addresses the obligation from the consumer side -- the acquiring organization must require SBOMs from software suppliers and verify component authenticity. 800-218 addresses the obligation from the producer side -- the software developer must maintain component inventories and be able to generate SBOMs on request. Neither framework references the other directly, which means organizations on both sides of this transaction are implementing overlapping requirements from different documents with no cross-reference. A defense contractor that builds software and also acquires commercial software has obligations under both frameworks that their compliance team typically treats as separate workstreams.

Software Bill of Materials (SBOM) requirements, software component provenance, and supplier security obligations for software acquired in federal contracts

800-63B specifies the technical authenticator requirements (AAL1, AAL2, AAL3) that determine what MFA mechanisms are acceptable. 800-207 specifies the architectural principle that access decisions must be made dynamically based on identity and device state. They are designed to work together -- 800-63B tells you what authentication strength is required, 800-207 tells you where and how that authentication must be enforced. The gap is that organizations implement 800-207 zero trust architecture documentation without upgrading their authentication to AAL2 or AAL3 as 800-63B requires, producing zero trust diagrams sitting on top of password-plus-SMS authentication infrastructure.

Identity verification, authentication assurance, and access policy enforcement

CSF 2.0 GV.SC subcategories describe supply chain risk management outcomes at a high level. 800-161 R1 specifies the actual programme content -- the policies, plans, supplier assessments, contractual provisions, and monitoring processes that produce those outcomes. Organizations that complete a CSF 2.0 self-assessment against GV.SC subcategories without the underlying 800-161 programme substance produce a compliance artefact that references outcomes they have not achieved.

Cybersecurity supply chain risk management -- CSF 2.0 Govern function (GV.SC subcategories) and 800-161 R1 C-SCRM programme requirements cover substantially the same ground

Treating 800-53 R5 Moderate compliance as equivalent to 800-171 R3 compliance

The logical chain seems sound: 800-171 R3 is derived from the 800-53 R5 Moderate baseline, therefore implementing 800-53 R5 Moderate should largely satisfy 800-171 R3. This reasoning is structurally correct about the control substance and completely wrong about the compliance mechanics. 800-171 R3 uses a different control identifier structure, a different SSP format, different assessment procedures (800-171A R3 rather than 800-53A), and is assessed by different people under different authority. A FedRAMP Moderate ATO and a CMMC Level 2 certification are two separate things even when the controls implemented to achieve them substantially overlap.

Organizations that present their FedRAMP Moderate ATO as evidence of 800-171 R3 compliance during CMMC assessment fail the assessment. The assessor is evaluating against 800-171 R3 requirements using 800-171A R3 procedures. The FedRAMP ATO is irrelevant to that evaluation. The organization then faces the cost of a full CMMC assessment gap remediation cycle on top of the FedRAMP costs they already absorbed.

Implementing 800-172 without completing 800-171

Contractors on programs designated as high-value assets sometimes receive contract language referencing 800-172 requirements. They read 800-172, see 35 specific enhanced requirements, and begin implementing those 35 requirements as their security programme. The 800-172 document itself states clearly that the enhanced requirements are additive to a complete 800-171 implementation. Implementation teams skim past this because they are focused on the specific 800-172 deliverables in the contract.

The organization implements 35 enhanced controls on top of a partially implemented or unimplemented 800-171 baseline. The 800-172 adversary detection requirements, for example, are designed to detect sophisticated threats that standard 800-171 controls have already contained. Without the 800-171 foundation, the 800-172 controls are monitoring for advanced threats in an environment that has not closed the basic vulnerabilities those threats would exploit first. The security posture is incoherent.

Reading CSF 2.0 as a substitute for 800-53 rather than a mapping layer above it

CSF 2.0 is readable. It has six functions, clear categories, intuitive language. 800-53 R5 has over 1,000 controls across 20 families with parameter values and enhancement specifications. Organizations that need to communicate security posture to boards and executives gravitate toward CSF 2.0 because it produces the kind of output executives can engage with. The mistake is stopping there -- using CSF 2.0 as the implementation framework rather than the governance communication layer.

Organizations that implement CSF 2.0 subcategories without mapping them to 800-53 controls produce security programmes with undefined implementation depth. The CSF subcategory 'PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed' could be satisfied by a password policy document or by a fully implemented IAM system with privileged access management, just-in-time access, and hardware token authentication. The CSF subcategory does not tell you which is sufficient. 800-53 does. Organizations that skip 800-53 discover the ambiguity when an assessor asks for evidence.

Treating the 800-161 R1 tier structure as a maturity progression rather than a simultaneous obligation

The Baseline, Level 1, Level 2, Level 3 naming convention reads like a maturity model -- start at Baseline, mature to Level 3 over time. This reading is wrong. The tiers describe different organizational layers (enterprise, mission/programme, system) that must all be operating simultaneously for a C-SCRM programme to be functional. Level 3 system-level controls require Level 2 programme context to determine which systems are critical. Level 2 requires Level 1 enterprise governance to define risk tolerance. An organization can have excellent Level 3 SBOM processes and no Level 1 governance -- that is not a Baseline-to-Level-3 progression, it is an upside-down programme.

Organizations that build system-level C-SCRM processes (Level 3) without enterprise-level governance (Level 1) cannot consistently apply their own supplier security requirements across programmes. Each programme office makes independent supplier risk decisions without reference to an enterprise risk tolerance, producing inconsistent outcomes and an inability to demonstrate programme-level C-SCRM maturity to assessors or contracting agencies.