NASA Procedural Requirements

NPR 8000.4C Effective Date: April 19, 2022 Expiration Date: April 19, 2027

Subject: Agency Risk Management Procedural Requirements

Responsible Office: Office of Safety and Mission Assurance

Chapter 1. Introduction

1.1 Background

1.1.1 Generically, risk management is a set of activities aimed at understanding, communicating, and managing risk to the achievement of objectives. Risk management operates continuously in an activity, proactively risk-informing the selection of decision alternatives and then managing the risks associated with implementation of the selected alternative. In this NPR, risk management is defined in terms of the interfacing and reciprocally complementing RIDM and CRM processes. This NPR addresses the application of these processes to all Agency activities directed toward the accomplishment of Agency strategic goals, including: strategic planning and assessment; program and project concept development, formulation, and implementation; institutional management of infrastructure, including physical, human, and information technology resources; and acquisition. This NPR also adds requirements for a formal process of risk acceptance that assigns accountability for each risk acceptance decision to a single responsible, authoritative individual (e.g., organizational unit manager), rather than to a committee or group of individuals. In addition, institutional risks and the coordination of risk management activities across organizational units are addressed.

1.1.2 The purpose of integrating RIDM and CRM into a coherent framework is to foster proactive risk management: to inform better decision making through better use of risk information evaluated at activity-start by application of RIDM, and then to manage more effectively implementation risks using the CRM process, which is focused on managing, in the execution of an activity, the risk to the baseline performance requirements informed by the RIDM process, and is supplemented where appropriate by RIDM-enabled risk-control selection processes. Within a RIDM process informed by Analysis of Alternatives (AoA) at the start of an activity or project, decisions are made taking into account applicable risks and uncertainties; then, as the decisions are carried out, CRM is applied during activity execution to manage the associated risks in order to achieve the performance levels that drove the selection of a particular alternative. RIDM AoA steps are also included and integrated within the CRM process as part of the risk mitigation planning steps, whenever this appears to be necessary or useful for the identification and selection of risk control options optimized on a risk-reduction versus cost-of-implementation basis. For additional information, see NPD 1000.0 with regard to the topic of "Authority roles regarding risk." Figure 1 shows that this NPR identifies risk management objectives that are applicable to all NASA activities, but that are especially relevant in certain key domains, such as program and project management, safety and mission success, health and medical, physical security and cybersecurity, which are also governed by their own domain-specific directives and associated requirements. For additional information, see NPD 7120.4, NPD 8700.1, NPD 8900.1, NASA Health and Medical Policy for Human Space Exploration, and NPD 2810.1, NASA Information Security Policy.

1.1.3 This NPR supports NASA internal control activities as specified. For additional information, see NPD 1200.1, NASA Internal Control, Office of Management and Budget (OMB) Circular A-123, Management's Responsibility for Enterprise Risk Management and Internal Control, and the related Government Accountability Office Standards for Internal Control in the Federal Government GAO-14-704G, Standards for Internal Control in the Federal Government (the GAO Green Book). The framework in this NPR for conducting risk management across strategic, programmatic, financial, and institutional activities is compatible with the Enterprise Risk Management (ERM) integrated framework developed by the Committee of Sponsoring Organizations of the Treadway Commission (COSO). For additional information, see OMB Circular A-11, Preparing, Submitting, and Executing the Budget, and OMB Circular A-123. This risk management framework and associated activities provide a basis for establishing internal controls to ensure that identified risks are maintained within acceptable levels. The effectiveness of the internal controls is assessed and reported. For additional information, see NPD 1200.1.

Figure 1. Intersection of NPR 8000.4 with Program and Project and
Domain-Specific Directives and Requirements

1.1.4 This NPR supports NASA's security objectives at project, program, and institutional infrastructure level, including both physical security and cybersecurity activities. For additional information on such objectives, see NPD 1600.2E, NASA Security Policy, NPR 1620.3B, Physical Security Requirements for NASA Facilities and Property, NPD 2810.1, NASA Information Security Policy, and the National Institute of Standards and Technology (NIST) Special Publication (SP) 800 Series and Federal Information Processing Standards. The framework in this NPR for managing risks associated with physical security and cybersecurity threats is driven by the mission success and protection objectives of specific projects, maintaining at the same time full alignment and consistency with the broadly applicable national directives intended to ensure the protection or the institutional resources and infrastructure of all U.S. Government agencies, such as, in the cybersecurity domain, the Framework for Improving Critical Infrastructure Cybersecurity provided by NIST.

Note: The above cited NIST Framework presents a risk-based approach to managing cybersecurity risk, complementing NASA's existing risk management processes and cybersecurity programs, and supporting the implementation of and compliance with the Federal Information Security Modernization Act of 2014, Pub. L. 113-283, (2014). Application of the Framework is mandated by Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure), E.O. 13800 (2017).

1.1.5 This NPR is not intended to dictate organizational structure, but rather to be applied and implemented within existing organizations.

1.2 Risk Management within the NASA Hierarchy

1.2.1 Key Concepts

1.2.1.1 In general, risk is concerned with uncertainty about future outcomes. For the purposes of this NPR, risk is the potential for shortfalls with respect to achieving explicitly established and stated objectives. As applied to programs and projects, or any other objective-driven activity and mission, these objectives are translated into performance requirements, which may be related to institutional support for mission execution or related to one or more of the domains that are relevant to NASA activities carried out at any level (enterprise, program, or project), such as:

a. Safety.

b. Mission Success.

c. Physical Security and Cybersecurity.

d. Cost.

e. Schedule.

Note 1: The above identification of key domains of interest to NASA in relation to performance and risk management objectives is given for the purpose of making clear that risk items affecting such domains are relevant in any NASA activity and cannot be overlooked. This does not imply that the five listed risk domains are the only ones within which relevant risk issues can be identified, nor that any given risk must always be characterized as belonging to one of the five listed categories.

Note 2: The term “mission success” may in a general context be interpreted as referring to success of a mission or project in all relevant domains of performance, e.g., including technical, safety, security, cost, schedule, and any other performance objectives that may be of concern. However, in the context of this NPR and for consistency with NPD 8700.1, “mission success” takes on the more limited meaning of “success with respect to the technical performance objectives of an activity or mission.”

1.2.1.2 In this NPR, the term "Performance Measure" is defined generically as a metric to measure the extent to which a system, process, or activity fulfills its intended objectives. Performance Measures for mission execution may relate to safety performance (e.g., avoidance of injury, fatality, or destruction of key assets), mission success (technical performance (e.g., thrust or output, amount of observational data acquired)), cost performance (e.g., execution within allocated budget), schedule performance (e.g., meeting milestones), or cybersecurity (e.g., avoidance of data disclosure if a hacking attack occurs, avoidance of mission control interference if an adversary seeks to take control). Similar performance measures can be defined for institutional support (e.g., staffing levels, facility availability, supply chain metrics).

Note: Performance measures and associated risk metrics can be expressed in full quantitative terms if the performance dimension of concern is intrinsically quantitative (e.g., the mass to orbit capability of a launch system). For dimensions of performance that are more qualitative in nature (e.g., the degree of compliance of a design process with an applicable technical standard), constructed scales of discrete values associated with corresponding “binning” criteria and definitions may also be used. When possible, quantitative characterizations of performance and corresponding risk levels are preferable, as they more directly enable risk vs. benefit “analysis of alternative” (AoA) evaluations that constitute the foundation of the RIDM support to decision making.

1.2.1.3 Managing risk requires the coordination of risk identification, assessment, decision and communication activities. All levels of NASA executives and managers, at all levels of the organizational hierarchy, are responsible to enable such a coordination. Risk coordination starts at the agency executive level with the formulation and communication of risk leadership principles, to increase decision velocity and pursue mission and science development opportunities within the risk posture deemed appropriate, with input from the affected stakeholders, for major activities, programs, or projects of concern. The definition and common sharing of a risk posture, in turn, enables the definition of risk tolerances applicable in risk management and risk-informed decision-making processes applicable to a specific activity or project.

1.2.1.4 Risk proceeds from sources that may be internal or external to a mission or activity; either type may take the form of a randomly-occurring event or of an intentional action. Main resulting broad-class combinations include:

a. Internal Random Event (e.g,, the random failure of a mission-critical hardware component).

b. Internal Intentional Action (e.g., equipment sabotage by a mission insider, or intentional neglect by a responsible party to carry out a required safety procedure).

c. External Random Event (e.g,, a lightning strike).

d. External Intentional Action (e.g., hackers’ attack to an information system, or to a mission control network, or to a software-controlled physical system).

Note: The identification of the above categories of risk sources is provided to clearly indicate that risk sources may exist inside or outside the perceived boundaries of an activity and its attending organization(s), and also that risk scenarios may be originated by willful human actions as well as by randomly occurring events. This clarification is not to be interpreted as a requirement to mandatorily “bin” all risks into one of the four broad classes identified above.

1.2.1.5 Conceptually, and regardless of the type of source or mission-objective domain to which it relates, the risk to an objective can be represented via a set of triplets, each constituted by the following composing elements:

a. The scenario(s) leading from a source of risk to a degraded performance with respect to one or more performance measures (e.g., scenarios leading to injury, fatality, destruction of key assets; scenarios leading to exceedance of mass limits; scenarios leading to cost overruns; scenarios leading to schedule slippage; scenario leading to information system compromise),

b. The likelihood(s) (qualitative or quantitative) of those scenario(s); and,

c. The consequence(s) (qualitative or quantitative severity of the performance degradation) that would result if the scenario(s) was (were) to occur.

Note 1: In the representation of risk resulting from random events, "Likelihood" is the probability that a full scenario sequence, from source to consequences, will occur. Its assessment accounts for the frequency of the scenario and the timeframe in which the scenario can occur. For some purposes, it can be assessed qualitatively. For other purposes, it is quantified in terms of frequency or probability. Given that quantification must often be carried out without the benefit of large amounts of statistical evidence, a complete assessment of likelihood also calls for characterization of the uncertainty that may be present in its estimation.

Note 2: In the representation of risk resulting from intentional actions (e.g., a type of intentional cybersecurity-attack threat posed by a specific type of adversary), a quantification or even a qualitative classification (e.g., “high,” “low,” etc.) of the frequency or probability of such actions may be difficult to produce with sufficient degree of confidence. In such cases, a “Conditional Likelihood” evaluation is generally more meaningful, and as such recommended (see full discussion in Appendix C).

1.2.1.6 Each "Acquirer" is accountable for overseeing the risk management processes of its "Providers" at the next lower level, as well as for managing risks identified at its own level. The term "Acquirer" is used to denote a NASA organization that tasks one or more "Provider" organizations, either within NASA or external to NASA, to deliver a product (e.g., a system) or a service (see Glossary in Appendix A). In most cases, an Acquirer, at a given level within NASA negotiates with each Provider a set of objectives, deliverables, performance measures, baseline performance requirements, resources, and schedules that define the tasks to be performed by the Provider. Once this is established, the Provider is accountable to the Acquirer for managing its own risks against these specifications.

Note: The definition of the relationship between an "Acquirer" and a "Provider" in this NPR is not intended to supersede or alter any provisions of previously approved Agency directives or any other official NASA document (e.g., Program Plan, Memorandum of Understanding, etc.).

1.2.1.7 The Provider reports risks and/or elevates decisions for managing risks to the Acquirer, based on predetermined risk thresholds (illustrated below) that have been negotiated between the Provider and Acquirer. Figure 2 depicts this concept. Risk management decisions are elevated by a Provider when those risks can no longer be managed by the Provider. This may be the case if, for example, resources are not available, or the Provider lacks the decision authority needed in order to manage those risks. In many cases, elevation needs to occur in a timely fashion, in order to allow upper management to respond effectively. The approach is performance-based in the sense that each unit determines the best way to achieve its objectives and performance requirements, rather than being told in detail how these are to be achieved. Risk management decisions may be elevated beyond the next higher level, but it is assumed that a risk management decision is elevated through a stepwise progression.

Figure 2. Risk Management in NASA's Organizational Hierarchy

Note: The relationships between a performance requirement, risks, and associated thresholds can be illustrated using the following example. Suppose that for development of a particular science module, a "mass" performance measure has a baseline performance requirement of 50 kg. Lower mass is preferred; mass significantly greater than 50kg has not been allowed for. The risk associated with this performance requirement is characterized in terms of one or more scenarios leading to higher mass, their associated likelihoods, and the severity of the associated mass exceedance in each case. A threshold for elevation might be established probabilistically, e.g., as a specified probability (P) of exceeding the baseline mass requirement (50 kg in this case).

1.2.1.8 Mission Directorates are responsible for management of technical and programmatic risks within their domains and are responsible for elevating risks to the appropriate Management Council at the Agency level. Center Directors are responsible for management of institutional risks at their respective Centers and for coordinating institutional risk management activities with other Agency offices that are stakeholders for institutional risks. Headquarters Administrator Staff Offices and Mission Support Enterprise Offices are responsible for Agency-wide risk management in their domains. For additional information, see NPD 1000.3. Center Directors and Mission Support Enterprise Offices are responsible for elevating risks to the Mission Support Council. Program and project managers are responsible for program and project risks within their respective programs and projects, and are responsible for coordination in management of cross-cutting risks. Refer to Chapter 2 for a full description of roles and responsibilities.

1.2.1.9 Risk management at the Agency level addresses risks identified at the Agency level, as well as risk decisions elevated from Administrator Staff Offices, Mission Directorates, and Mission Support Enterprise Offices. These may have been elevated for any of several reasons, including:

a. A need for the Agency to allocate additional resources for effective mitigation.

b. Agency-level coordination/integration is needed with other organizations/stakeholders.

c. A finding that a risk identified within a Center or Mission Directorate is, in fact, an Agency-level risk.

d. A risk cuts across programmatic and institutional organizations, and needs to be addressed at the Agency level.

1.2.1.10 Risk management at the Agency level integrates the full spectrum of risks by:

a. Dealing with risk strategically from an Agency-level perspective. At the Agency level, emphasis is placed on achievement of the Agency's mission objectives and goals versus individual project or program goals/objectives. Per NPD 1000.0, this is carried out by the Agency's Management Councils.

b. Engaging all functions and line management levels.

c. Risk-informing program, mission support, and capability portfolio development and management.

d. Supporting institutional management of infrastructure, e.g., addressing cross-agency aspects of cyber-risk management above individual project or mission levels.

1.2.2 RIDM

1.2.2.1 As shown in Figure 3, RIDM within each organizational unit involves:

a. Identification of Alternatives: Formulate Objectives and a diverse set of Performance Measures (to support decision making); Formulate Decision Alternatives, Recognizing both Risks and Opportunities.

b. Analysis of Alternatives: Conduct Integrated Analysis of Risk of Each Alternative; Develop the Technical Basis for Deliberation.

c. Risk-Informed Alternative Selection: Deliberate; Select an Alternative and Accept the Associated Risk Informed by Risk Analysis Results; Document the Decision and its Rationale.

1.2.2.2 Rather than an isolated activity, RIDM is a key element of the risk management approach used by institutional and programmatic organizations. It informs all aspects of strategic, program and mission, and mission-enabling decision making and is, therefore, conducted in many different venues based on the organization and management processes of the implementing organizational unit. These include council, board, and panel meetings, Authority to Proceed milestone reviews, Safety Review Board meetings, Risk Reviews, Engineering Design and Operations Planning decision forums, and commit-to-flight reviews, among others.

1.2.2.3 Within the RIDM process, the complete set of performance measures (and corresponding assessed risks) is used, along with other considerations, within a deliberative process to improve the basis for decision making. Deliberation helps the organization to make the best possible use of its experience and institutional knowledge. For example, in order to inform decisions that affect safety, safety performance measures (such as crew safety) and related risks (such as contributions to the probability of loss of crew due to micrometeoroid impact) can be considered in light of aspects of performance history that are not captured in the risk models, or aspects of risk that do not relate immediately to existing performance measures. Moreover, deliberation may identify opportunities not only for improvements that are within the purview of the organizational unit, but also for improvements that could be realized by the acquiring organization or by the program as a whole. Communication of such opportunities to the organizational units best situated to seize them can result in modifications to previously selected alternatives and a rebaselining of the requirements (safety, mission success, cost, schedule) that are flowed down to Provider organizations.

1.2.2.4 RIDM interfaces with CRM in two main modes of risk management integration:

a. At the start or re-start of a project or activity, once a decision alternative has been selected for implementation, the performance measure values that informed its selection define the baseline performance requirements for CRM. An activity “re-start” may occur when, as discussed in paragraph 1.2.4.5, situations arise in which it is necessary to revisit the decision and rebaseline the performance requirements.

b. Within the execution of an activity or project, if alternative options appear possible for the mitigation and/or control of an identified risk, each with its risk-reduction value and its implementation resource costs, CRM should utilize the AoA capability of the RIDM processes to assist the identification and selection of an optimal solution that balances implementation cost versus risk reduction worth.

Figure 3. RIDM Process

1.2.3 CRM

1.2.3.1 NASA uses a specific process for the management of risks associated with implementation of designs, plans, and processes. This process, which is represented by the graphic in Figure 4, is referred to as CRM.

Figure 4. CRM Process

1.2.3.2 Steps in the CRM process include:

a. IDENTIFY: Identify contributors to risk (shortfalls in performance relative to the baseline performance requirements).

Note: Performance measures determine the scope of CRM. Sometimes, the relationship between an identified risk and performance measures is indirect, but risks within the proper scope of CRM are addressed because they may affect one or more performance measures.

b. ANALYZE: Estimate the probability and consequence components of the risk through analysis, including uncertainty in the probabilities and consequences and, if feasible, estimate aggregate risks.

c. PLAN: Decide on risk disposition and handling, develop and execute mitigation plans, develop contingency plans, and decide what will be tracked.

Note: Risk acceptance is among the possible dispositions (see paragraph 3.4.2i(1)). The requirements of paragraphs 3.5 (for program and project risks) or 3.6 (for institutional risks) apply to risk acceptance decisions.

d. TRACK: Track observables relating to performance measures (e.g., technical performance data, schedule variances), as well as the cumulative effects of risk disposition (handling) decisions.

e. CONTROL: Evaluate tracking data to verify effectiveness of mitigation plans, making adjustment to the plans as necessary and executing control measures.

f. COMMUNICATE AND DOCUMENT: Communicate and document the above activities throughout the process.

1.2.3.3 In order to focus effort and accountability during implementation of a selected alternative, CRM may focus on a set of individual risk contributors (i.e., specific "risks"). However, for some purposes, decision making needs to be supported by evaluation of the "aggregate risk" associated with a given performance measure, i.e., aggregation of all contributions to the risk associated with that performance measure. For example, it may not be sufficient to consider only a list of "risks" to the crew of a human-crewed space vehicle; in order to support some decisions, it is necessary to evaluate the total probability of loss of crew, considering all contributions, as an aggregated risk. Similarly, cost and schedule risk are analyzed probabilistically in an integrated fashion using a Joint Confidence Limit (JCL) analysis. For additional information, see NPR 7120.5, NASA Space Flight Program and Project Management Requirements. For some performance measures, it may not be practical to quantify the aggregate risk; the feasibility of quantifying aggregate risk is determined for each performance measure and then documented in the Risk Management Plan (see paragraph 3.2.2i) for each organizational unit.

Note: When considering risk produced by intentional threat sources, such as cybersecurity risk, aggregate risk representation will not be feasible in traditional form if the corresponding scenarios are only partially quantifiable (e.g., via “Conditional Likelihood” or “(Conditional) Potential Vulnerability,” as suggested in 1.2.1.5c Note 2). Surrogate aggregate risk indices can still be formulated for such kinds of scenarios, when this is still considered useful for specific purposes, by substituting threat weights (e.g., reflecting expert judgment supported by relevant and timely sources of information, such as intelligence input) to initiating threat frequency or probability measures.

1.2.4 Coordination of RIDM and CRM Within and Across Organizational Units

1.2.4.1 The right-hand portion of Figure 5 shows RIDM (previously shown in Figure 3) and CRM (previously shown in Figure 4) as complementary processes that operate within every organizational unit. Each unit applies the RIDM process to decide how to fulfill its performance requirements and applies the CRM process to manage risks associated with implementation.

1.2.4.2 The left portion of Figure 5 (previously shown in Figure 2) shows the hierarchy of organizations tasked with carrying out a mission. At any given level below the Agency level, there may be multiple organizational units conducting RIDM and CRM. Associated coordination activities include flowdown of performance requirements, risk reporting, and elevation of decisions. Coordination of risk management is suggested by Figure 5. This coordination enables the optimum flow of risk information at all levels of the Agency.

Note: Tools of Knowledge Management (KM) are expected to be particularly valuable in this regard.

1.2.4.3 Each organizational unit reports on its risk management activities to the Acquirer at the next higher level and may elevate individual risk management decisions to that level, if it is determined that those risks cannot be addressed by the originating unit. Refer to paragraphs 1.2.1.6 and 1.2.1.7.

1.2.4.4 Within each organizational unit, disposition of risks includes the use of defined thresholds whose exceedance should initiate a risk control response by the unit, including the possible elevation of risk management decisions to the Acquirer at the next higher level (as discussed in paragraphs 1.2.1.6 and 1.2.1.7).

1.2.4.5 It is the responsibility of the Acquirer to assure that the performance requirements assigned to the Provider reflect appropriate tradeoffs between/among competing objectives and risks. It is the responsibility of the Provider to establish the feasibility of managing the risks of the job it is accepting, including risks to fulfillment of derived requirements, and identification of mission support requirements. The performance requirements can be changed, if necessary, but redefining and rebaselining them needs to be negotiated with higher level organizations, documented, and subject to configuration control. Performance requirements work together, so redefinition and rebaselining one performance requirement may force redefinition and rebaselining of another, if the overall program or project objectives are to be satisfied. Redefinition and rebaselining, therefore, imply a tradeoff that needs to be approved by the Acquirer.

Figure 5. Coordination of RIDM and CRM within the NASA Hierarchy (Illustrative)

1.2.4.6 Both CRM and RIDM are applied within a graded approach (refer to the Definitions in Appendix A).

1.2.4.7 At each Center, management of institutional risks affecting programs and projects at the Center is done within the Center institutional hierarchy and coordinated with the program and project units as needed. Since program and project units may be affected by institutional risks without being in a position to control them, in the event that institutional risks threaten accomplishment of program and project unit performance requirements, the program and project units may need to coordinate with the Center institutional managers to elevate such risks to the appropriate level within the program and project or Center hierarchies.

1.2.4.8 Agency-wide institutional risks are addressed by NASA Headquarters Administrator Support Offices, Mission Support Enterprise Offices, and the Mission Support Council.

DISTRIBUTION:
NODIS

This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.