ezesecops/rmf-ato-core huggingface dataset:
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.3. Select

4.3. Select

The organization determines the approach for selecting, tailoring, and allocating controls for
systems based on system requirements. System plans identify the controls that are selected
and allocated to the system for implementation. [SP800-37] describes two approaches for
selecting controls:
• Organization-generated control selection: The organization uses its own process to
select and tailor the controls in the system plan based on a variety of factors, including
organizational mission or business priorities, system capabilities, the context in which
the system operates, and threats. Organizations may consider applicable Cybersecurity
18 This derives from the work done regarding third-party risks in the Zero Trust Data Security Guide [ZTDATASEC], which discusses third parties
and suppliers with incidental access to data. [SP 800-88] provides minimum sanitization requirements for use in determining recommended
sanitization methods for specific media to minimize data remanence and the availability of residual data.
and Privacy Framework Profiles to identify controls that support the achievement of
security and privacy risk management outcomes.
• Baseline control selection: Controls in the organizationally tailored control baselines
that were determined during the RMF Prepare step are factored into the control
selection process. The initial security baselines in [SP800-53B] group controls that are
designed to support the [FIPS200] minimum security requirements for systems based on
the [FIPS199] security impact level.
The initial privacy baseline in [SP800-53B] identifies controls for federal agencies to address
privacy requirements and manage privacy risks that arise from processing data about
individuals based on privacy program responsibilities under [OMBA-130].19 These controls are
rooted in privacy engineering objectives and are designed to respond to privacy risks with
effective data protection strategies. System privacy and security officials collaborate on the
selection of privacy controls to ensure that both privacy and security risks are managed,
particularly in areas where the risks overlap.
Organizations can use a control overlay (e.g., C-SCRM extended overlay20) as a starting point for
selecting controls with broad-based support across communities of interest for specific
circumstances, situations, and conditions [SCOR].
Completing the tasks in the RMF Select step results in system plans that explain how the
security, privacy, and C-SCRM risk management controls are being met for information that is
transmitted, processed, and stored by the system.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.3.2. Identification of Planned Control Implementations

4.3.2. Identification of Planned Control Implementations

System plans identify the intended system-specific application of each allocated control along
with an adequate level of implementation detail to support the assessment and monitoring of
the control and associated control enhancements. Controls that are partially implemented by a
common control provider are identified in the system plan as hybrid controls. Implementation
details for the system-specific part of hybrid controls describe the risk management
responsibilities that are shared between the system and the common control provider.
For fully inherited or hybrid controls, system plans reference the source of the common control
to avoid duplicating the common control implementation details.22 Notes may be added to the
implementation details to describe how fully inherited controls address system requirements.
Control implementation details in the system privacy plan describe how the controls meet
privacy-specific requirements, such as those that address risks related to the processing of
personal information, the context of data use, and potential consequences for individuals.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.3.3. Plan Review and Approval

4.3.3. Plan Review and Approval

The senior agency official for privacy is responsible for reviewing and approving the system
privacy plan or consolidated plan before it is submitted to the authorizing official or designated
representative. This review ensures that privacy risks have been thoroughly identified and that
21 The National Online Informative References Program maps CSF Subcategories to [SP 800-53] controls, and the NIST Privacy Engineering
Program maps the Privacy Framework to [SP 800-53] controls.
22 If the common control provider implementation details are considered controlled information (e.g., those associated with a cloud service
provider or cloud service offering), restrictions in applicable service agreements related to the distribution of organizational and system
information are followed.
privacy controls and risk management strategies are aligned with organizational policies, legal
requirements, and privacy objectives. When reviewing the system-specific C-SCRM plan in the
authorization package, authorizing officials consult with the C-SCRM PMO as well as
acquisitions personnel in cases of technology procurements. The C-SCRM review ensures that
the C-SCRM controls and risk management strategies align with the overall organizational risk
tolerances.
The authorizing official may request additional input from the senior accountable official for
risk management, CIO, senior agency information security officer, senior agency official for
privacy, or senior procurement executive to support the system plan approval decision.
• If the system plans are acceptable, the authorizing official or designated representative
approves the system plans, enabling the system owner to begin execution of the RMF
Implement step.
• If the system plans are unacceptable, the authorizing official or designated
representative may recommend changes for the system owner or common control
provider to implement.
Approving system plans at this step does not authorize system operation or the offering of
common controls for inheritance. System authorization to operate, authorization to use, or
common control authorization are tasks in the RMF Authorize step.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.4. Implement

4.4. Implement

Allocated controls are designed, built, tested, and deployed following the details in the system
plans. If a control is not implemented as planned or requires additional compensating controls,
the system plans are updated to reflect the details of the actual "as-implemented" controls and
the selected compensating controls.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.5. Assess

4.5. Assess

Control assessments are based on the information in system plans to prepare for, create, and
execute an assessment plan [SP800-53A]. Personnel update the system plans based on
remediation actions that are taken to resolve control deficiencies reported during the
assessment. At the conclusion of the control assessment, system plans provide a "point-in-
time" understanding of the system's operation and the implemented controls that support the
RMF Authorize step.23
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.6. Authorize

4.6. Authorize

The system owner or common control provider assembles and submits an authorization
package to the authorizing official for an authorization decision. The authorization package
23 A system may go through multiple assessments and system plan updates during the system development life cycle in preparation for the RMF
Authorize step.
includes the system security and system privacy plans as well as any additional artifacts that
demonstrate risk management activities (e.g., signed interconnection agreements, signed
SBOM artifacts, signed POA&M completion artifacts) to enable an informed authorization
decision. The C-SCRM plan is not required but is recommended if supply chain risk management
is a key organizational concern.
The senior agency official for privacy reviews the authorization package to verify that the
system aligns with organizational privacy objectives and legal obligations. The authorizing
official relies on information in the system plan and feedback from the system owner and
senior agency officials to:
• Authorize a system to operate or be used within the organization,
• Issue a common control authorization, or
• Deny authorization to the system or common control provider to protect the
organization from risks that are outside of established organizational risk tolerances.
The authorization decision is included in the authorization package, identified in the system
plans, and relayed to the system owner, common control provider, and other organization
officials as appropriate.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.7. Monitor

4.7. Monitor

System plans are reviewed and revised on an organization-defined schedule24 to ensure their
continued accuracy and relevancy after authorization. Reviews may occur in response to events
that affect security, privacy, or C-SCRM risks, such as:
• Revisions to the [SP800-53] security and privacy control catalog, [SP800-53B] control
baselines, or [SP800-53A] assessment procedures
• New or revised laws, regulations, and organizational policies that affect security,
privacy, or C-SCRM requirements
• Updates to the system risk assessment report, often resulting from threat intelligence,
that identify new risks that render existing controls less effective
• Weaknesses identified during control assessments and monitoring or after a security,
privacy, or supply chain cybersecurity incident or compromise (e.g., system data breach)
• Changes that significantly alter the risk posture of the system and justify control
reassessment and system reauthorization (e.g., revisions to the information types or
special factors that affect system categorization, the selection and implementation of
additional controls, additional tailoring activities that align control implementations with
identified risks)
24 [SP 800-53] controls PL-02, System Security and Privacy Plans, and SR-02, Supply Chain Risk Management Plan discuss requirements for the
frequency of system plan reviews.
• Changes to key system personnel (e.g., if the authorizing official changes, the incoming
authorizing official reviews the system plans and artifacts to confirm the existing
authorization or issue a new authorization decision)
• Changes to the operational status of the system (e.g., promoting the system from
"in development" to "operational," system disposal)
• Renewal of or modifications to existing agreements for information exchanges, the
creation of new information exchanges, or the termination of information exchanges
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Abstract

Abstract

The system security plan, system privacy plan, and cybersecurity supply chain risk management
plan are collectively referred to as system plans. They describe the purpose of the system, the
operational status of the controls selected and allocated for meeting risk management
requirements, and the responsibilities and expected behavior of all individuals who manage,
support, and access the system. This publication identifies essential elements of system plans
from security, privacy, and cybersecurity supply chain risk management perspectives to
promote consistent information collection across the organization, regardless of the system's
mission or business function.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Appendix B. List of Abbreviations and Acronyms

TASK M-7

System Disposal
Disposal strategy; up-to-date system component
inventory; up-to-date system plans.
•
System Component Inventory
•
System Operational Status
•
System Plan Change Records

Appendix B. List of Abbreviations and Acronyms

C-SCRM
Cybersecurity Supply Chain Risk Management
CIO
Chief Information Officer
CPRT
Cybersecurity and Privacy Reference Tool
CUI
Controlled Unclassified Information
DevSecOps
Development, Security, and Operations
FIPS
Federal Information Processing Standards
FISMA
Federal Information Security Modernization Act
FOCI
Foreign Ownership, Control, or Influence
GRC
Governance, Risk, and Compliance
IR
Internal Report or Interagency Report
ISCM
Information Security Continuous Monitoring
MOU
Memorandum of Understanding
NARA
National Archives and Records Administration
OMB
Office of Management and Budget
OSCAL
Open Security Controls Assessment Language
PIA
Privacy Impact Assessment
PMO
Program Management Office
PRA
Privacy Risk Assessment
PRAM
Privacy Risk Assessment Methodology
RMF
Risk Management Framework
SBOM
Software Bill of Materials
SCRM
Supply Chain Risk Management
SIEM
Security Information and Event Management
SOAR
Security Orchestration, Automation, and Response
SecCM
Security-focused Configuration Management
SORN
System of Records Notice
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Appendix D. Change Log

Appendix D. Change Log

NIST Special Publication (SP) 800-18r2 (Revision 2), Developing Security, Privacy, and Supply
Chain Risk Management Plans for Systems, provides guidelines for developing and maintaining
system security plans, system privacy plans, and C-SCRM plans.
• Section 2 defines and explains the system plan types based on the RMF [SP800-37],
[SP800-161], and the NIST Privacy Framework.
• Section 3 updates the suggested elements for system security, privacy, C-SCRM plans
and addresses the relationship between security risk management and privacy risk
management. Material has been added to address the use of information management
tools and automation to support the development, management, maintenance, and
protection of system plan information.
• Section 4 relates the development and maintenance of system security, privacy, and
C-SCRM plans to the implementation of the RMF.
In addition, the publication has been restructured and the following content changes have been
applied:
• Technical content from other NIST publications is now included by reference rather than
repeated.
• The terms general support system, major application, and minor application have been
deprecated to be consistent with OMB Circular A-130 (July 2016) [OMBA-130].
• The term system boundary has been updated to authorization boundary for consistency
with the terminology in [SP800-37].
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Audience

Audience

This publication is intended to serve a diverse audience, including:
• Individuals with information security, privacy, and risk management program oversight
responsibilities (e.g., authorizing officials, senior agency information security officers,
senior agency officials for privacy)
• Individuals with system development responsibilities (e.g., mission or business owners,
program managers, systems engineers, systems security engineers, systems privacy
engineers, software developers, systems integrators, acquisition or procurement
officials)
• Individuals with system security and privacy implementation and operations
responsibilities (e.g., mission or business owners, system owners, information owners or
stewards, system administrators, system security officers, system privacy officers)
• Individuals with cybersecurity supply chain risk management-related responsibilities
(e.g., C-SCRM program managers)
• Individuals with acquisition and procurement-related responsibilities (e.g., acquisition
officials, contracting officers)
• Individuals with logistical or disposition-related responsibilities (e.g., program managers,
system integrators, property managers)
• Individuals with control assessment and monitoring responsibilities (e.g., auditors,
Inspectors General, system evaluators, control assessors, independent verifiers and
validators, analysts)
• Commercial entities and industry partners that produce component products and
systems, create security and privacy technologies, or provide services or capabilities that
support information security or privacy
The material presented in this publication assumes that the audience has a basic understanding
of the concepts presented in NIST Special Publication (SP) 800-37, NIST Risk Management
Framework for Information Systems and Organizations: A System Life Cycle Approach for
Security and Privacy.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Authorization Boundary Description

Authorization Boundary Description

Discussion: Identify the subsystems and system elements that comprise the system to
be authorized for operation or use by an authorizing official (i.e., the scope of the
authorization). Summarize key aspects of the system architecture, including the use of
subsystems and external service providers; physical or logical separations; local and
remote management functionalities; customized or specialized components, functions,
or data flows; and the use of private, public, or hybrid cloud service provider services.
The description can also identify the following:
• Enabling systems that may provide services or functionalities used or inherited
by the system or other systems that interact with the operational environment
outside of the authorization boundary and may exist outside the environment of
operation, as explained in [SP800-37]
• System elements that are critical to both the mission and organization
• System functions that are subject to additional requirements, such as the
protection of CUI
• Any third-party authorization services and API implementations as part of the
identification of external system services that support the system
• The set of common controls to be authorized for inheritance purposes
While the system security plan may focus on broad cybersecurity risks, the system
privacy plan highlights the role of the system in handling personal data and the controls
implemented in response to associated privacy risks. For example, the system privacy
plan may address how risks related to the collection, use, and sharing of data across
multiple authorization boundaries are managed and how those practices align with the
organization's privacy policies
Related plan elements: System Type, Environment of Operation Diagrams, System
Component Inventory
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Control Assessment Status

Control Assessment Status

Discussion: Identify the assessment status of the control. The plan can specify whether
the control was "satisfied" or "other than satisfied" based on the requirements provided
in the assessment plan. The assessment status may specify when the control was last
assessed and provide a reference to the assessment report and the assessment plan
that explains the scope, breadth, and depth of the assessment performed.
The control assessment status indicator may be included in the control implementation
details. Automation can provide the ability to include the assessment history, including
the results of control monitoring activities. References to POA&Ms and retest artifacts
may be included for controls identified as "other than satisfied."
Related plan elements: Control Implementation Details, Control Implementation Status
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Control Implementation Status

Control Implementation Status

Discussion: Identify the implementation status of the control following the system plan
approval. The control implementation status indicator may be included in the control
implementation details.
Typical control implementation status indicators include:
• Planned: Control is selected but implementation has not started.
• Partially Implemented: Planned control implementation has started but has not
been completed. This may indicate that an implemented control is in the process of
being changed based on items in POA&Ms.
• Fully Implemented: The "as-implemented" state of the control has been fully
realized in the operational system.
Details related to the timeline for full implementation may be provided. For complex
systems, the control implementation status may differentiate the control
implementation status for individual subsystems that may be at different stages of
planning and development.
Related plan elements: Control Implementation Details
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Defining the Authorization Boundary

Defining the Authorization Boundary

The system plans identify how data flows through various subsystems, third-party services, and
external networks to ensure that privacy risks are managed comprehensively. The authorization
boundary establishes the scope of protection for the system based on mission, management, or
budgetary responsibilities. Privacy risks can arise at any stage of data processing because of the
interconnected nature of modern systems, and identifying and responding to them may require
looking beyond the authorization boundary.
System-specific C-SCRM concerns may include risks derived from suppliers that are several
layers removed from the end user or supply chain risks associated with specific organization-
defined technologies. For example, C-SCRM considers the complexities of new technologies and
dynamic system interdependencies that can result in suppliers gaining incidental access18 to
data. C-SCRM plan considerations include vendor-controlled SaaS offerings, hybrid or cloud
environments, open-source software, information and communications technology and
operational technology from suppliers outside of Trade Agreements Act nations, general
procurement from unauthorized resellers, and supply chains of emerging technologies, such as
artificial intelligence capabilities.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Digital Identity Acceptance Statement (DIAS) (optional)

Digital Identity Acceptance Statement (DIAS) (optional)

Discussion: Organization- and system-level risk assessments determine the extent to
which risk is managed by various processes,15 which in turn drive decisions regarding
applicable technologies and mitigation strategies. During the risk management process,
the organization determines the assurance levels for identity proofing, authentication,
and federation, if applicable; selects appropriate processes and technologies to meet
each assurance level; and identifies compensating controls when necessary.
The DIAS is not required to be included in the system plan but is required to be included
in the system authorization package for federal systems.
Related plan elements: System Authorization Decision