ezesecops/rmf-ato-core huggingface dataset:
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX F > Conditions for Implementation of Ongoing Authorization

Conditions for Implementation of Ongoing Authorization

When the RMF has been effectively applied across the organization and the organization has
implemented a robust continuous monitoring program, systems may transition from a static,
point-in-time authorization process to a dynamic, near real-time ongoing authorization process.
To do so, the following conditions must be satisfied:
•
The system or common control being considered for ongoing authorization has received an
initial authorization based on a complete, zero-based review of the system or the common
controls.150
•
An organizational continuous monitoring program is in place that monitors implemented
controls with the appropriate degree of rigor and at the required frequencies specified by
the organization in accordance with the continuous monitoring strategy and NIST standards
and guidelines.151
The organization establishes and implements a process to designate that the two conditions are
satisfied and the system or the common controls are transitioning to ongoing authorization. The
process includes the authorizing official acknowledging that the system or common control is
now being managed by an ongoing authorization process and accepting the responsibility for
performing all activities associated with that process. The transition to ongoing authorization is
documented by the authorizing official by issuing a new authorization decision.152 The security
and privacy information generated through the continuous monitoring process is provided to
the authorizing officials and other organizational officials in a timely manner through security
and privacy management and reporting tools. Such tools facilitate risk-based decision making
for the ongoing authorization for systems and common controls.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER TWO > 2.7 SECURITY AND PRIVACY POSTURE > CONTEXT-DEPENDENT REQUIREMENTS

CONTEXT-DEPENDENT REQUIREMENTS

Security and privacy requirements and risks identified by the organization, lead to the need for
security and privacy controls to respond to the risk. The controls selected by the organization
subsequently lead to both specification requirements and statement of work requirements in
the systems engineering context. This is an important aspect of how systems engineers develop,
derive, and decompose requirements as part of the SDLC process. Thus, organizations manage
security and privacy requirements at various levels of granularity and specificity during the life
cycle of the system. Controls play an important part in the life cycle by providing high-level
statements of protection capability that can be refined and expanded upon by the organization.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX D > CONTROL ASSESSOR

CONTROL ASSESSOR

The control assessor is an individual, group, or organization responsible for conducting a
comprehensive assessment of implemented controls and control enhancements to determine
the effectiveness of the controls (i.e., the extent to which the controls are implemented
correctly, operating as intended, and producing the desired outcome with respect to meeting
the security and privacy requirements for the system and the organization). For systems,
implemented system-specific controls and system-implemented parts of hybrid controls are
assessed. For common controls, implemented common controls and common control-
implemented parts of hybrid controls are assessed. The system owner and common control
provider rely on the security and privacy expertise and judgment of the assessor to assess the
implemented controls using the assessment procedures specified in the security and privacy
assessment plans. Multiple control assessors who are differentiated by their expertise in specific
control requirements or technologies may be required to conduct the assessment effectively.
Prior to initiating the control assessment, assessors review the security and privacy plans to
facilitate development of the assessment plans. Control assessors provide an assessment of the
severity of the deficiencies discovered in the system, environment of operation, and common
controls and can recommend corrective actions to address the identified vulnerabilities. For
system-level control assessments, control assessors do not assess inherited controls, and only
assess the system-implemented portions of hybrid controls. Control assessors prepare security
and privacy assessment reports containing the results and findings from the assessment.
The required level of assessor independence is determined by the authorizing official based on
laws, executive orders, directives, regulations, policies, standards, or guidelines. When a control
assessment is conducted in support of an authorization decision or ongoing authorization, the
authorizing official makes an explicit determination of the degree of independence required.
Assessor independence is a factor in preserving an impartial and unbiased assessment process;
determining the credibility of the assessment results; and ensuring that the authorizing official
receives objective information to make an informed, risk-based authorization decision.
The senior agency official for privacy is responsible for assessing privacy controls and for
providing privacy information to the authorizing official. At the discretion of the organization,
privacy controls may be assessed by an independent assessor. However, in all cases, the senior
agency official for privacy retains responsibility and accountability for the privacy program of the
organization, including any privacy functions performed by the independent assessors.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX F > Denial of Authorization

Denial of Authorization

If the authorizing official, after reviewing the authorization package, including any inputs
provided by the senior accountable official for risk management or risk executive (function),
determines that the risk to organizational operations, organizational assets, individuals, other
organizations, and the Nation is unacceptable and immediate steps cannot be taken to reduce
the risk to an acceptable level, the authorization is not granted. A denial of authorization means
that the information system is not authorized to operate and not placed into operation;
common controls are not authorized to be provided to systems; or that the provider's system is
not authorized for use by the customer organization. If the system is currently in operation, all
activity is halted. Failure to receive an authorization means that there are significant deficiencies
in the controls.
The authorizing official or designated representative works with the system owner or the
common control provider to revise the plan of action and milestones to help ensure that
measures are taken to correct the deficiencies. A special case of authorization denial is an
145 The customer organization may develop memoranda of agreement/understanding, contracts, or other types of
agreements with the provider organization to help ensure security posture information about the provided system is
shared appropriately.
AUTHORIZATION
TO OPERATE
COMMON CONTROL
AUTHORIZATION
Authorizing
Official
System*
Common
Controls
Inherited by System
Authorizing
Official
System Owner
Common Control Provider
* Common controls also can be
implemented within a system as
hardware, software, or firmware
components.
AUTHORIZATION TO USE**
Shared and Cloud Systems, Services, Applications
** An ATU requires a completed
ATO by the organization
providing the shared or cloud
system, service, or application.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER THREE > DEVELOPING WELL-DEFINED SECURITY AND PRIVACY REQUIREMENTS

DEVELOPING WELL-DEFINED SECURITY AND PRIVACY REQUIREMENTS

The RMF is an SDLC-based process that can be effectively used to help ensure that security and
privacy requirements are satisfied for information systems or organizations. Defining clear,
consistent, and unambiguous security and privacy requirements is an important element in the
successful execution of the RMF. The requirements are defined early in the SDLC in collaboration
with the senior leaders and are integrated into the acquisition and procurement processes. For
example, organizations can use the [SP 800-160 v1] life cycle-based systems engineering process
to define an initial set of security and privacy requirements, which in turn, can be used to select
a set of controls* to satisfy the requirements. The requirements or the controls can be stated in
the Request for Proposal or other contractual agreement when organizations acquire systems,
system components, or services. Requirements can also be added throughout the life cycle, such
as with the agile development methodology where new features are continuously deployed.
The NIST Cybersecurity Framework [NIST CSF] (i.e., Core, Profiles) can also be used to identify,
align, and deconflict security requirements and to subsequently inform the selection of security
controls for an organization. Cybersecurity Framework Profiles can provide a link between
cybersecurity activities and organizational mission/business objectives, which supports risk-
based decision-making throughout the RMF. While Profiles may be used as a starting point to
inform control selection and tailoring activities, further evaluation is needed to ensure the
appropriate controls are selected. Some organizations may choose to use the Cybersecurity
Framework in concert with the NIST Systems Security Engineering publications-identifying,
aligning, and deconflicting requirements across a sector, an industry, or an organization-and
subsequently employing a systems engineering approach to further refine the requirements and
obtain trustworthy secure solutions to help protect the organization's operations, assets,
individuals.
* See Section 2.3 for specific guidance on privacy control selection and managing privacy risk.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER TWO > 2.6 REQUIREMENTS AND CONTROLS > EFFECTIVE AUTHORIZATION BOUNDARIES

EFFECTIVE AUTHORIZATION BOUNDARIES

Establishing meaningful authorization boundaries for systems and common controls is one of
the most important risk management activities carried out by an organization. The authorization
boundary defines the specific scope of an authorizing official's responsibility and accountability
for protecting information resources and individuals' privacy-including the use of systems,
components, and services from external providers. Establishment of meaningful authorization
boundaries is a foundation for assuring mission and business success for the organization.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX D > ENTERPRISE ARCHITECT

ENTERPRISE ARCHITECT

The enterprise architect is an individual or group responsible for working with the leadership
and subject matter experts in an organization to build a holistic view of the organization's
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX F > EVENT-DRIVEN TRIGGERS AND SIGNIFICANT CHANGES

EVENT-DRIVEN TRIGGERS AND SIGNIFICANT CHANGES

Organizations define event-driven triggers (i.e., indicators or prompts that cause a predefined
organizational reaction) for both ongoing authorization and reauthorization. Event-driven
triggers may include, but are not limited to:
•
New threat, vulnerability, privacy risk, or impact information;
•
An increased number of findings or deficiencies from the continuous monitoring program;
•
New missions/business requirements;
•
Change in the authorizing official;
•
Significant change in risk assessment findings;
•
Significant changes to the system, common controls, or the environments of operation;
•
Changes in the supply chain affecting security or privacy risks to operational systems; or
•
Exceeding organizational thresholds.
When there is a change in authorizing officials, the new authorizing official reviews the current
authorization decision document, authorization package, any updated documents from ongoing
monitoring activities, or a report from automated security/privacy management and reporting
tools. If the new authorizing official finds the current risk to be acceptable, the official signs a
new or updated authorization decision document, formally transferring responsibility and
accountability for the system or the common controls. In doing so, the new authorizing official
explicitly accepts the risk to organizational operations and assets, individuals, other
organizations, and the Nation. If the new authorizing official finds the current risk to be
unacceptable, an authorization action (i.e., ongoing authorization or reauthorization) can be
initiated. Alternatively, the new authorizing official may instead establish new terms and
conditions for continuing the original authorization, but not extend the original authorization
termination date (if not under ongoing authorization).
A significant change is defined as a change that is likely to substantively affect the security or
privacy posture of a system. Significant changes to a system that may trigger an event-driven
authorization action may include, but are not limited to:
•
Installation of a new or upgraded operating system, middleware component, or application;
•
Modifications to system ports, protocols, or services;
•
Installation of a new or upgraded hardware platform;
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER TWO > FLEXIBILITY IN RMF IMPLEMENTATION

FLEXIBILITY IN RMF IMPLEMENTATION

Organizations are expected to execute all steps and tasks in the RMF (apart from tasks labeled
as optional). However, organizations have significant flexibility in how each of the RMF steps
and tasks are carried out, as long as organizations are meeting all applicable requirements and
effectively managing security and privacy risk. The intent is to allow organizations to implement
the RMF in the most efficient, effective, and cost-effective manner to support mission and
business needs in a way that promotes effective security and privacy. Flexible implementation
may include executing tasks in a different (potentially nonsequential) order, emphasizing certain
tasks over other tasks, or combining certain tasks where appropriate. It can also include the use
of the Cybersecurity Framework to enhance RMF task execution.
Flexibility of implementation can also be applied to control selection, control tailoring to meet
organizational security and privacy needs, or conducting control assessments throughout the
SDLC. For example, the selection, tailoring, implementation, and assessments of controls can be
done incrementally as a system is being developed. The implementation of control tailoring
helps to ensure that security and privacy solutions are customized for the specific missions,
business functions, risks, and operating environments of the organization. In the end, the
flexibility inherent in RMF execution promotes effective security and privacy that helps to
protect the systems that organizations depend on for mission and business success and the
individuals whose information is processed by those systems.
Note: Since the RMF is an SDLC process that emphasizes ongoing authorization, organizations have the flexibility
to determine which RMF step to enter (or reenter) based on an assessment of risk and the tasks described in the
Prepare-System Level step. Determination of the appropriate RMF step requires an assessment of the current
state of the system, a review of the activities that have already been completed for the system, identification of
a proposed step and task entry into the RMF, a gap analysis to ensure that the risk is acceptable, documenting
decisions, notifying stakeholders, and approval from the Authorizing Official (or other relevant decision maker).
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX D > HEAD OF AGENCY

HEAD OF AGENCY

The head of agency is responsible and accountable for providing information security
protections commensurate with the risk to organizational operations and assets, individuals,
other organizations, and the Nation-that is, risk resulting from unauthorized access, use,
disclosure, disruption, modification, or destruction of information collected or maintained by or
on behalf of the agency; and the information systems used or operated by an agency or by a
contractor of an agency or other organization on behalf of an agency. The head of agency is also
the senior official in an organization with the responsibility for ensuring that privacy interests
are protected and that PII is managed responsibly within the organization. The heads of
agencies ensure that:
•
Information security and privacy management processes are integrated with strategic and
operational planning processes;
•
Senior officials within the organization provide information security for the information and
systems supporting the operations and assets under their control;
•
Senior agency officials for privacy are designated who are responsible and accountable for
ensuring compliance with applicable privacy requirements, managing privacy risk, and the
organization's privacy program; and
•
The organization has adequately trained personnel to assist in complying with security and
privacy requirements in legislation, executive orders, policies, directives, instructions,
standards, and guidelines.
The head of agency establishes the organizational commitment and the actions required to
effectively manage security and privacy risk and protect the missions and business functions
being carried out by the organization. The head of agency establishes security and privacy
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX F > Information Generation, Collection, and Independence Requirements

Information Generation, Collection, and Independence Requirements

To support ongoing authorization, security and privacy information for controls is generated and
collected at the frequency specified in the organization's continuous monitoring strategy.
Security and privacy information may be collected using automated tools or other methods of
assessment depending on the type and purpose of the control and desired rigor of the
assessment. Automated tools may not generate security and privacy information that is
150 System owners and authorizing officials leverage security and privacy information about inherited common
controls from assessments conducted by common control providers.
151 [SP 800-53] and [SP 800-53A] provide guidance regarding the appropriate degree of rigor for security assessments
and monitoring. Future publications will address privacy assessments.
152 Prior to transitioning to ongoing authorization, organizations have authorization decision documents that include
an authorization termination date. By requiring a new authorization decision document, it is made clear that the
system or the common controls are no longer bound to the termination date specified in the initial authorization
document because the system and the common controls are now under ongoing authorization.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX D > INFORMATION OWNER OR STEWARD

INFORMATION OWNER OR STEWARD

The information owner or steward is an organizational official with statutory, management, or
operational authority for specified information and the responsibility for establishing the
policies and procedures governing its generation, collection, processing, dissemination, and
disposal. In information-sharing environments, the information owner/steward is responsible
for establishing the rules for appropriate use and protection of the information and retains that
responsibility even when the information is shared with or provided to other organizations. The
owner/steward of the information processed, stored, or transmitted by a system may or may
not be the same individual as the system owner. An individual system may contain information
from multiple information owners/stewards. Information owners/stewards provide input to
system owners regarding the security and privacy requirements and controls for the systems
where the information is processed, stored, or transmitted.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX G > LEVERAGING EXTERNAL PROVIDER CONTROLS AND ASSESSMENTS

LEVERAGING EXTERNAL PROVIDER CONTROLS AND ASSESSMENTS

Organizations should exercise caution when attempting to leverage external provider controls
and assessment results. Controls implemented by external providers may be different than the
controls in [SP 800-53] in the scope, coverage, and capability provided. NIST provides a mapping
of the controls in its catalog to the [ISO 27001] security controls and to the [ISO 15408-2] and
[ISO 15408-3] security requirements. However, such mappings are inherently subjective and
should be reviewed carefully by organizations to determine if the controls and requirements
addressed by external providers meet the protection needs of the organization. The mappings
between different standards or guidelines also do not address the potential for differing scopes
and purpose for each publication.
Similar caution should be exercised when attempting to use or leverage security and privacy
assessment results from external providers. The type, rigor, and scope of the assessments may
vary widely from provider to provider. In addition, the assessment procedures employed by the
provider and the independence of the assessors conducting the assessments are critical issues
that should be reviewed and considered by organizations prior to leveraging assessment results.
Effective risk decisions by authorizing officials depend on the transparency of controls selected
and implemented by external providers and the quality and efficacy of the assessment evidence
produced by those providers. Transparency is essential to achieve the assurance necessary to
ensure adequate protection for organizational assets.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER THREE > MISSION/BUSINESS PROCESS (LEVEL 2) CONSIDERATIONS

MISSION/BUSINESS PROCESS (LEVEL 2) CONSIDERATIONS

Mission/business process considerations are addressed in the RMF Prepare-Organization Level
step and the RMF Prepare-System Level step by specifying mission/business process concerns;
by identifying the mission or business owners in primary or supporting roles; and by identifying
the mission or business objectives. Task P-8 and Task P-9 from the RMF Prepare-System Level
step are mission/business process level tasks conducted with a system-level specific focus.