ezesecops/rmf-ato-core huggingface dataset:
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Disposal of System Components

Disposal of System Components

System components and information assets may be disposed of at any time during the system
life cycle, which may introduce opportunities for the compromise of stored data. System plans
can include or reference the instructions for properly disposing of systems or components (e.g.,
sanitization of storage media) in accordance with applicable data and records retention
requirements, such as those provided by the National Archives and Records Administration
[NARARECM]. Component disposal records may be referenced in the system plan to indicate
the date of component disposal and details about the information assets that are transferred to
other systems. Updates to the system component inventory may trigger additional updates to
the system plans to reflect changes in the environment of operation.
Key considerations for the removal of a system or system elements from operation include the
responsibilities of the system owner for protecting system data, the responsibility of the
authorizing official for risks associated with data remanence,25 and the organizational liability
for inadequate data sanitization. Demonstrating due diligence can address the legal and
financial liabilities of data breaches caused by inadequate sanitization, unauthorized access to
residual data, or the improper transfer of data to another system.
25 [SP 800-88] defines remanence as "residual information remaining on storage media."
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Executive Summary

Executive Summary

System plans collectively refer to the system security plan, system privacy plan, and
cybersecurity supply chain risk management (C-SCRM) plan that describe the design and
implementation of security, privacy, and cybersecurity supply chain protections throughout the
system life cycle. System plans:
• Include information about the data being created, collected, disseminated, used, stored,
and disposed of;
• Identify individuals who are responsible for system risk management efforts;
• Describe the environment of operation, system components, and data flows within the
environment; and
• Account for risks associated with the sharing of information outside the scope of the
system.
The elements described in this publication provide building blocks for an organization to devise
an effective method of collecting and consolidating information about a system so that it is
readily available to organizational leadership, authorizing officials, system owners, and risk
managers to support risk-based decisions. Organizations may also consider more responsive
approaches to system plan structures (e.g., automated data collection methods, online
reporting dashboards) in lieu of traditional document-focused system plans that may not
support the rapid pace of modern system development.
NIST Special Publication (SP) 800-18r2 (Revision 2) addresses the development of system plans
in support of risk management activities, such as tasks in the NIST Risk Management
Framework (RMF) steps in [SP800-37]. This revision:
• Provides content considerations for elements in system plans;
• Discusses the use of automation to maintain system plans over the system life cycle,
including sharing and protecting system plan information; and
• Provides supplemental materials, including system plan outline examples and updated
roles and responsibilities associated with system plans, that may factor into system plan
development.
Office of Management and Budget (OMB) Circular A-130 [OMBA-130] requires federal agencies
to develop and maintain system plans for managing risks, including implementation details for
the controls allocated to address the requirements. Nonfederal organizations may voluntarily
apply the guidelines provided in this publication to develop and maintain system plans
consistent with their risk management strategies.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Information Exchanges Summary

Information Exchanges Summary

Discussion: Summarize the information exchanges that are defined between the system
and systems outside of the authorization boundary [SP800-47], whether inside or
outside the organization. Agreements can vary based on the impact level of the
information being exchanged, the relationship between the organizations exchanging
information, or the level of access granted to personnel from the interconnected
system.
The summary of information exchanges may include information about outstanding
risks from the interconnected systems to support the implementation of secure system
interconnections. Information collected about each valid information exchange in which
the system participates may include the following, as determined by the organization
implementation of the [SP800-53] CA-03, Information Exchange, control:
• Type of agreement used for the information exchange (e.g., information exchange
agreement, interconnection security agreement, memorandum of agreement,
memorandum of understanding)
• Effective start and end dates of the agreement based on the acceptance signatures
provided in the agreement artifact
• Systems participating in the agreement, including:
o Name, role, title, and organization of the system owner and authorizing official
o System name and unique system identifier assigned by the system owner's
organization
o FIPS 199 categorization of the system and the information being exchanged
o System authorization decisions status
• Brief description of the exchange, including purpose, type of data, and expected
outputs
• Method of information exchange (e.g., virtual private network, extranet, dedicated
data transfer application)
• Interface characteristics that explain how the information is being exchanged
between the systems
• Diagrams that show the data flows, system components, and technologies involved
• Findings and mitigation strategies that are relevant to the components involved in
the information exchange and may be identified in:
o Security, privacy, or cybersecurity supply chain risk assessment reports;
o Security and privacy control assessments; or
o Information security continuous monitoring (ISCM) processes that identify
security and privacy risks and mitigation strategies.
Exchanges that involve data about individuals have the potential to introduce additional
privacy risks. The system privacy plan describes protections for ensuring the
confidentiality and integrity of data about individuals during transmission and storage,
including details about the information being exchanged, the organizations and systems
involved, and data sharing and service agreements between the system and entities that
are outside of the authorization boundary.
Related plan elements: System Overview, Authorization Boundary Description,
Environment of Operation Diagrams, Control Implementation Details
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > [IR8179]

[FIPS199]

Categorization of Federal Information and Information Systems. (U.S.
Department of Commerce, Washington, DC), Federal Information Processing
Standards Publication (FIPS) NIST FIPS 199.

[FIPS200]

Requirements for Federal Information and Information Systems. (U.S.
Department of Commerce, Washington, DC), Federal Information Processing
Standards Publication (FIPS) NIST FIPS 200.

[IR8062]

An Introduction to Privacy Engineering and Risk Management in Federal
Gaithersburg, MD), NIST Interagency/Internal reports (IR) NIST IR 8062.

[IR8179]

Paulsen C, Boyens J, Bartol N, Winkler K (2018) Criticality Analysis Process:
Model Prioritizing Systems and Components. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Internal Report (IR) NIST IR 8179.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Keywords

Keywords

authorization boundary; authorizing official; common control authorization; control
implementation details; cybersecurity supply chain risk management plan; privacy plan; privacy
risk management; risk management framework; security plan; security risk management;
authorization to operate; authorization to use; authorizing official designated representative;
CASES Act; control implementation; controls; FASCSA; FISMA; ongoing authorization; Privacy
Act; supply chain; supply chain risk management; system privacy plan; system security plan;
system owner.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Laws, Regulations, and Policies Affecting the System Requirements

Laws, Regulations, and Policies Affecting the System Requirements

Discussion: Identify the sources of specific requirements for the:
• Confidentiality, integrity, or availability of the system components and
information
• Predictability, manageability, and disassociability of information processed,
stored, or transmitted by the system
• Acquisition of trustworthy system components through the supply chain
Organizational policies may identify the laws, regulations, and policies that are
applicable to all systems within the organization or include a standardized list of
requirement sources in an organizational template for system plans. As the legal and
regulatory landscape evolves, the system plans are updated to adapt to new security,
privacy, and cybersecurity supply chain risk management requirements, such as those
that arise from the use of emerging technologies, automated decision-making, and data
analytics. For example, privacy laws that govern data subject rights directly influence the
development of the system privacy plan, including how data is handled and how the
system protects individual rights, frames broader privacy risks, and addresses
organizational privacy goals. The C-SCRM plan identifies suppliers or products that are
prohibited by law, subject to regulatory exclusions, and constrained by organization- or
system-specific policies.
Related plan elements: System Overview, Control Implementation Details
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > List of Figures

List of Figures

Acknowledgments
The authors would like to thank everyone who took the time to review and make comments on
the revision of this publication, specifically Jon Boyens, Michaela Iorga, Victoria Yan Pillitteri,
Eduardo Takamura, Daniel Eliott, Robert Staples, Claire Barrett, Jim Foti, Isabel Van Wyk, and
of Fedwriters, Inc./Coralline; Michele Iversen of the Department of Defense; and Paul J.
DeNaray of The Aerospace Corporation.
The authors would also like to acknowledge the original authors - Marianne Swanson, Joan
Hash, and Pauline Bowen - as well as the individuals who contributed to the original version of
this publication.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Patent Disclosure Notice

Patent Disclosure Notice

NOTICE: ITL has requested that holders of patent claims whose use may be required for
compliance with the guidance or requirements of this publication disclose such patent claims to
ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has
not undertaken a patent search in order to identify which, if any, patents may apply to this
publication.
As of the date of publication and following call(s) for the identification of patent claims whose
use may be required for compliance with the guidance or requirements of this publication, no
such patent claims have been identified to ITL.
No representation is made or implied by ITL that licenses are not required to avoid patent
infringement in the use of this publication.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Prepare — System Level

Prepare - System Level

When the system life cycle is initiated, key information is collected to inform initial drafts of
system plans, including:
• The mission or business focus supported by the system
• System stakeholders
• The information types handled by system
• Unique security and privacy risks in the information life cycle that are managed across
the entire data ecosystem
• How the authorization boundary is defined within the organizational infrastructure or
enterprise architecture
The organization assigns a system identifier to associate component inventory records, device
event audit records, and system-related artifacts.
The system-level C-SCRM plan provides a context for how organizational C-SCRM policies are
applied at the system level by enumerating requirements, describing constraints, and
addressing other supply chain risk implications. C-SCRM plans for systems align with the
established organization-wide risk tolerances and C-SCRM strategy. Many organizations choose
to enable systems to inherit common controls that support the organization or enterprise
C-SCRM requirements. In cases where multiple components within an organization are
responsible for different subsets of the same system, the organization decides the scope of the
C-SCRM plan.
During each of the subsequent RMF steps, the system plans are revised or updated to add
additional information as the system is developed.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Reauthorization or Ongoing Authorization

Reauthorization or Ongoing Authorization

The operation of an authorized system requires periodic or ongoing assessments to verify that
the implemented controls continue to effectively satisfy security, privacy, and C-SCRM
requirements [SP800-53A]. Authorizing officials can reauthorize the system based on these
assessment results or update system plans to reflect changes to the control implementation
details and environment of operation after ISCM activities [SP800-137].
For example, the system privacy plan can define privacy metrics (e.g., access requests from
individuals, data sharing frequency, incidents) that are regularly analyzed during monitoring
activities to track trends and risks. The system privacy officer is responsible for identifying
assessment methodologies and metrics to determine whether privacy controls are
implemented correctly, operating as intended, and complying with applicable privacy
requirements. Appropriate updates to privacy controls and the system privacy plan can
strengthen protections.
Additionally, the system C-SCRM plan can identify a continuous monitoring capability for critical
suppliers to alert system owners to changes that might affect the system's risk posture. New
critical components or technology refresh activities can trigger reviews of and updates to the
C-SCRM plan, which may require system reauthorization.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Remediation Actions

Remediation Actions

Discussion: Identify the status of control remediation actions that result from
assessment activities. A list of outstanding risk remediation activities, including POA&M
items and system changes that result from control monitoring, can provide information
about the risk posture of the system to organizational leadership, risk managers, and
the managers of systems with which information exchange agreements are in place.
The control assessment status indicator may be included in the control implementation
details. Automating the generation of this information based on assessment reports and
monitoring results provides transparency about existing threats and vulnerabilities that
have not been fully remediated.
Related plan elements: Control Implementation Details, Control Implementation Status,
Control Assessment Status
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Reports on Computer Systems Technology

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and
Technology (NIST) promotes the U.S. economy and public welfare by providing technical
leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advance
the development and productive use of information technology. ITL's responsibilities include
the development of management, administrative, technical, and physical standards and
guidelines for the cost-effective security and privacy of other than national security-related
information in federal information systems. The Special Publication 800-series reports on ITL's
research, guidelines, and outreach efforts in information system security, and its collaborative
activities with industry, government, and academic organizations.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Role Identification and Responsible Personnel

Role Identification and Responsible Personnel

Discussion: Identify the role of each individual that has responsibilities for coordinating
system-specific risk management activities. An individual's organizational job title may
not clearly demonstrate or align with the risk management role and responsibilities.
Identified individuals are generally held accountable for the ongoing operation of the
system, the continuous monitoring of the implemented controls, and additional risk
mitigation efforts that are required throughout the system life cycle. Based on the plan
type, key roles include the system security officer, system privacy officer, and personnel
who support the C-SCRM Program Management Office (PMO).
Common roles and responsibilities of key participants involved in risk management
activities are provided in [SP800-37] Appendix D, Roles and Responsibilities. Additional
responsibilities for roles related to the development and management of system plans
are provided as a supplement to this publication. An organization may identify other
individuals in roles that directly support system plan development, as needed.
If an individual has multiple roles related to system security, privacy, or cybersecurity
supply chain risk management, the system plan may provide additional information for
managing the separation of duties and define the risk mitigations for any conflicts of
interest.
When applicable, identify the roles and responsibilities of personnel responsible for
external services supporting the system (i.e., account manager, service coordinator).
These individuals may be different from those identified in information exchange
artifacts that support [SP800-53] CA-03, Information Exchange.
Organizations include the following contact information for each identified individual:
• Name
• Risk-management-related role (e.g., system-specific role, organizational role)12
• Organizational unit, department, or division
• Primary business phone number
• Alternate business phone number
• Business email address
Restrict contact information to business information to avoid exposing personal
information. Using personal information (e.g., a home phone or personal cell phone
number as the "alternate business phone number") may create unnecessary privacy
risks for the individuals identified as having a role protecting the system.
12 Identifying the risk-management related role of an individual can be more indicative of system responsibility than a position or title.
Related plan elements: System Overview, Authorization Boundary Description
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > [SP800-37]

• Disposal: The system is no longer authorized or operational.
Organizations may use other operational status indicators as needed based on the
components and services within the environment of operation.
For complex systems, include the operational status of the subsystems within the
authorization boundary. Using automation, the operational status of key components
within the system or subsystems can be identified to provide organizational
management with a full accounting of the status of the mission or business process
supported by the system.
Related plan elements: System Overview, System Authorization Decision
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > [SP800-47]

• Changes to the organizational baseline supply chain risk strategy or inherited C-SCRM
controls due to:
o Changes in critical suppliers that potentially affect supply chain risks, including
ownership changes, mergers and acquisitions activity, and geopolitical or
environmental activity
o Reviews of suppliers' foreign ownership, control, or influence (FOCI)
o Cybersecurity attacks or data breaches that affect a supplier's ability to support
confidentiality, integrity, or availability objectives
Change management processes ensure that updates to system plans are tracked and noted.
Specific procedures for tracking and managing modifications, including the use of revision or
version identifiers to maintain a record of changes, can be included in the system configuration
management plan. Automating information collection methods (see Sec. 3.3) can result in more
efficient and effective system plan maintenance.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > [SP800-53]

• SP 800-53A, Assessing Security and Privacy Controls in Information Systems and
Organizations [SP800-53A]
• SP 800-53B, Control Baselines for Information Systems and Organizations [SP800-53B]
• SP 800-161, Cybersecurity Supply Chain Risk Management Practices for Systems and
Organizations [SP800-161]
• SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and
Organizations [SP800-171]
• SP 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified
Information [SP800-172]
• NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk
Management [NISTPF]
• The NIST Cybersecurity Framework (CSF) [NISTCSF]
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > Supplemental Content

Supplemental Content

The following materials are available on the publication details page to supplement the
guidelines provided in this publication:
• System Security Plan outline example
• System Privacy Plan outline example
• Cybersecurity Supply Chain Risk Management Plan outline example
• System Plan Roles and Responsibilities
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > System Authorization Decision

System Authorization Decision

Discussion: The authorization decision is made by the authorizing official before the
system is put into the operational environment and to maintain its operational status.
The system plan may refer to authorization decision artifacts, such as an authorization
to operate (ATO) letter or memorandum issued by the authorizing official, to explain the
terms and conditions of the authorization decision. If the organization implements a
15 [SP 800-63-4] guidelines refer to the Identity Assurance Level (IAL), Authenticator AL (AAL), and Federation AL (FAL) as xAL, where "x" refers
to either I, A, or F for the individual assurance levels.
program for ongoing system authorization, the ongoing authorization decision
information may be referenced in the system plan. The organization determines how to
identify the authorization status of the system as a part of an ISCM strategy that
includes ongoing authorization.