| NODIS Library | Program Management(8000s) | Search |

NASA Ball NASA
Procedural
Requirements
NPR 8000.4C
Effective Date: April 19, 2022
Expiration Date: April 19, 2027
COMPLIANCE IS MANDATORY FOR NASA EMPLOYEES
Printable Format (PDF)

Subject: Agency Risk Management Procedural Requirements

Responsible Office: Office of Safety and Mission Assurance


| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |

Appendix A. Definitions

Acquirer. A NASA organization that tasks another organization (either within NASA or external to NASA) to deliver a product (e.g., a system) or a service.

Aggregate Risk. The cumulative risk associated with a given goal, objective, or performance measure, accounting for all significant risk contributors. For example, the total probability of loss of mission is an aggregate risk quantified as the probability of the union of all scenarios leading to loss of mission.

Candidate Risk. A potential risk that has been identified and is pending adjudication by the affected programmatic or institutional authority.

Conditional Likelihood. A synonym of Conditional Probability (see definition thereof), more commonly used when qualitative ratings (such as “high likelihood,” or “low likelihood”) are provided instead of a numerical probability quantification.

Conditional Probability. The probability that some event or condition occurs, if (and only if) other specific events or conditions have already occurred 1.

Consequence. The key, possible negative outcome(s) of the current key circumstances, situations, etc., causing concern, doubt, anxiety, or uncertainty.

Continuous Risk Management. As discussed in paragraph 1.2.3, a systematic and iterative process that efficiently identifies, analyzes, plans, tracks, controls, and communicates and documents risks associated with implementation of designs, plans, and processes.

Cross-cutting Risk. A risk that is generally applicable to multiple mission execution efforts, with attributes and impacts found in multiple levels of the organization or in multiple organizations within the same level.

Cybersecurity. Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation [source: Office of Management and Budget Memorandum Circular A-130, Managing Information as a Strategic Resource, July 2016] 2.

Cybersecurity Risk. Threats to and vulnerabilities of cyber-assets – i.e., data, information, control systems, and information systems stored and/or implemented in digital form – and any related consequences caused by or resulting from unauthorized access, use, disclosure, degradation, disruption, modification, or destruction of cyber-assets, including such related consequences caused by an act of terrorism [adapted and extended from National Cybersecurity Protection Act of 2014, to explicitly include threats to digital control systems].

Deliberation. In the context of this NPR, the formal or informal process for communication and collective consideration, by stakeholders designated in the RMP, of all pertinent information, especially risk information, in order to support the decision maker.

Dispositions (of Risk):

a. Accept. The formal process of justifying and documenting a decision not to mitigate a given risk beyond some assessed or projected level. (See Section 3.5 and definitions of Risk Acceptance Criterion and Risk Acceptance).

b. Close. The determination that a risk no longer exists (e.g., the underlying condition no longer exists), has become a problem and is now tracked as such, because the associated scenario likelihoods are low (e.g., the likelihood has been reduced below a defined threshold), or the associated consequences are low (e.g., the consequence has been reduced below a defined threshold).

c. Elevate. The process of transferring the decision for the management of an identified source of risk to the risk management structure at a higher organizational level.

d. Mitigate. The modification of a process, system, or activity in order to reduce a risk by reducing its probability, consequence severity, or uncertainty, or by shifting its timeframe.

e. Research. The investigation of a risk in order to acquire sufficient information to support another disposition, i.e., close, watch, mitigate, accept, or elevate.

f. Watch. The monitoring of a risk for early warning of a significant change in its probability, consequences, uncertainty, or timeframe.

Graded Approach. The application of risk management processes at a level of detail and rigor that adds value without unnecessary expenditure of unit resources. The resources and depth of analysis are commensurate with the stakes and the complexity of the decision situations being addressed 3.

Information System. A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information [from 44 U.S.C., Sec. 3502].

Institutional Risks. Risks to infrastructure, information technology, resources, personnel, assets, processes, operations, occupational safety and health, environmental management, security (physical security and cybersecurity), or programmatic constraints that affect capabilities and resources necessary for mission success, including institutional flexibility to respond to changing mission needs and compliance with internal (e.g., NASA) and external requirements (e.g., Environmental Protection Agency or Occupational Safety and Health Administration regulations).

Intentional Threat. A threat originated, directly or indirectly (i.e., via the use of automated machinery or digital equipment) by human agents. See also Threat.

Knowledge Management. Getting the right information to the right people at the right time and helping people create knowledge and share and act upon information in ways that will measurably improve the performance of NASA and its partners.

Likelihood. Probability of occurrence, expressed in either qualitative (e.g., “Low,” “High,” etc.) or quantitative terms.

Organizational Unit. An organization, such as a program, project, Center, Mission Directorate, or Mission Support Office that is responsible for carrying out a particular activity.

Performance Measure. A metric used to measure the extent to which a system, process, or activity fulfills its intended objectives 4.

Performance Requirement. The value of a performance measure to be achieved by an organizational unit's work that has been agreed upon to satisfy the needs of the next higher organizational level.

Physical Security. The objective and function of securing an organizational infrastructure, program, project, mission, or activity, and protecting their material, functional, control, information, and human assets from interferences of a physical and material nature that are capable of causing damage, or of resulting in unauthorized possession or control of such assets 5.

Potential Vulnerability. The characteristic of a system, system security procedures, internal controls, or implementation that may represent a weakness in relation to the capabilities of a particular threat source and could be exploited by that threat source. (See also Vulnerability).

Provider. A NASA or contractor organization that is tasked by an accountable organization (i.e., the Acquirer) to produce a product (e.g., a system) or a service.

Risk. The potential for shortfalls with respect to achieving explicitly established and stated objectives. As applied to programs and projects, these objectives are translated into performance requirements, which may be related to mission execution domains (mission success, safety, physical and cybersecurity, cost, and schedule) or institutional support for mission execution 6. Risk is operationally characterized as a set of triplets:

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

b. The likelihood(s) (qualitative or quantitative; unconditional or conditional) of those scenarios.

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

Uncertainties are included in the evaluation of likelihoods and identification of scenarios.

Risk Acceptance Criterion. A rule for determining whether a given organizational unit has the authority to decide to accept a risk 7.

Risk Acceptance. A decision to accept the level of risk that remains after implementation of available net-beneficial mitigations of a given risk. Risk acceptance can be deliberate or not, depending on whether the risk implications of the decision are recognized, acknowledged, and taken into account by the decision-maker(s); or whether they remain for any reason undesirably hidden or overlooked 8.

Risk-Informed Decision Making. As discussed in paragraph 1.2.2, a risk-informed decision-making process that uses a diverse set of performance measures (some of which are model-based risk metrics) along with other considerations within a deliberative process to inform decision making 9.

Risk Leadership. One of the “NASA Senior Leadership Focus Areas” referred to in NPD 1000.0C, it is there described as the application by NASA of a risk culture that has the goal of “increasing ‘decision velocity’ within a proper risk posture.” It is implemented from the higher levels of management by communicating to the work force a clear and balanced understanding of risk and benefits, by defining and indicating appropriate technical standards, and by ensuring the workforce has the proper experience and commitment to collaboration [adapted from NASA NPD 1000.0C].

Risk Management. A coordinated flow of activities to identify, evaluate, and address risk with appropriate actions, which combines RIDM and CRM in an integrated framework. This is done in order to foster proactive management of risk items, to inform better decision making through better use of risk information, and then to manage more effectively implementation of risk-related activities and actions by focusing the CRM process on the baseline performance requirements informed by the RIDM process.

Risk Posture. An expression of the agreed upon limits of risk an organization’s leadership team is willing to accept in order to achieve one or more of its objectives. It is defined up front and in tandem with the development of objectives, consistently with Risk Leadership principles, and serves as the attitudinal framework for seeking a balance between the likelihood and benefit of achieving the objective(s), vs. the likelihood and severity of risks that may be introduced by the pursuit of achievement. Risk posture may change with time, in reflection of the evolution of leadership team attitudes or because of changes in priorities, but at any particular time, risk posture provides the de-facto basis for risk-informed decision making and continuous risk management 10.

Risk Review Boards. Formally established groups of people assigned specifically to review risk information. Their output is twofold: (1) to improve the management of risk in the area being reviewed and (2) to serve as an input to decision-making bodies in need of risk information.

Risk Tolerance. An expression of the limit of acceptable probability of a shortfall with respect to the achievement of an explicitly established and stated objective, which is defined consistently with the overall agreed upon Risk Posture and risk vs. benefit balance pursued by an organization, according to its established and communicated Risk Leadership principles 11.

Safety. In a risk-informed context, an overall condition that provides sufficient assurance that mishaps will not result from the mission execution or program implementation, or, if they occur, their consequences will be mitigated. This assurance is established by means of the satisfaction of a combination of deterministic criteria and risk-informed criteria 12.

Scenario. A sequence of events, such as an account or synopsis of a projected course of action or events.

Threat. A circumstance or event with the potential to adversely impact organizational operations and missions, organizational assets, individuals, other organizations, or the Nation through a system via unauthorized access, destruction, disclosure, modification of assets or information, and/or failure or denial of service [adapted from NIST-SP 800-30, Rev. 1, Guide for Conducting Risk Assessments]. A “threat” may exist in a given context as an intrinsic characteristic of the related activities and events, or be introduced by intentional adverse actions, including organized adversarial actions by an enemy entity, organization, or nation 13. See also Intentional Threat.

Threat Source. An intent and method targeted at the intentional exploitation of a system characteristic, which may become a system weakness in relation to such an intent or method; or a situation and method that may accidentally trigger a vulnerability or system weakness 14 [adapted from NIST-FIPS 200, Minimum Security Requirements for Federal Information and Information Systems].

Threshold. A level for a performance measure or a risk metric whose exceedance "triggers" management processes to rectify performance shortfalls.

Uncertainty. An imperfect state of knowledge or a variability resulting from a variety of factors including, but not limited to, lack of knowledge, applicability of information, physical variation, randomness or stochastic behavior, indeterminacy, judgment, and approximation.

Vulnerability. A known weakness in the characteristics of a system, system security procedures, internal controls, or implementation that could be exploited or triggered by a known threat source [adapted from NIST-SP 800-53, Rev. 5, Security and Privacy Controls for Information Systems and Organizations].


1 In a risk scenario described as a sequence of events, it is standard practice to quantify an event by means of its conditional probability, i.e., the probability that it will occur, if all the events that precede it in the scenario sequence have in fact occurred. As discussed in paragraph 1.2.1.5, in the case of a risk driven by an intentional source, the conditional probability or conditional likelihood of a resulting system or mission compromise is a useful metric to assess the system potential vulnerability to the type of threat that acts as the risk source, even if it may be difficult to estimate the likelihood or probability of the threat itself.

2 Achieving overall security at any level (institutional, program, project, or mission) may require consideration of interactive aspects of physical security and cybersecurity, as well as aspects of either type of security that may not be explicitly recognized in traditional definitions, such as the security of control systems that are implemented via a combination of networks, computers, and other electronic and/or mechanical components. As such, overall security requires the application of both physical security and cybersecurity provisions and protections

3 For example, the level of rigor needed in risk analysis to demonstrate satisfaction of safety-related performance requirements depends on specific characteristics of the situation: how stringent the requirements are, how complex and diverse the hazards are, and how large the uncertainties are compared to operating margin, among other things. Both RIDM and CRM are formulated to allow for this.

4 Performance measures should in general relate to observable quantities. For example, engine performance parameters, cost metrics, and schedule are observable quantities. Although safety performance measures can be observed in principle, many of them have to be modeled. Partly because of this, in ranking decision alternatives, one may use a risk metric (e.g., probability of loss of crew) as a surrogate for a performance measure.

5 Achieving overall security at any level (institutional, program, project, or mission) may require consideration of interactive aspects of physical security and cybersecurity, as well as aspects of either type of security that may not be explicitly recognized in traditional definitions, such as the security of control systems that are implemented via a combination of networks, computers, and other electronic and/or mechanical components. As such, overall security requires the application of both physical security and cybersecurity provisions and protections.

6 A risk is an uncertain future event, or combination of events, that could threaten the achievement of performance objectives or requirements. A "problem," on the other hand, describes an issue that is certain or near certain to exist now, or an event that has been determined with certainty or near certainty to have occurred and is threatening the achievement of an objective or requirement. It is generally at the discretion of the decision authority to define at what level of certainty (i.e., likelihood) an event may be classified and addressed as a "problem" rather than as a "risk." A risk may actually be conditional upon a problem, i.e., an existing issue may or may not develop into performance-objective consequences, or the extent to which it may is at the present time uncertain.

7 Not all risks satisfying a defined risk acceptance criterion are automatically accepted, nor a combination of such individual risks is always automatically acceptable in the aggregate; rather, subject to aggregate risk considerations, a given organizational unit has the authority to decide to accept individual risks satisfying the criterion.

8 A non deliberate risk acceptance condition may be the result of a decision not to investigate a potential risk beyond some initial qualitative level.

9 A decision-making process relying primarily on a narrow set of model-based risk metrics would be considered "risk-based."

10 Risk Posture is an indication provided by the executive managers / leaders of an activity or project as to their disposition towards risk concerning the key performance measures for that activity or project, in relation to, and balance with, the opportunities and benefits of achieving gains in some of those performance dimensions, or in some additional areas judged to be important to the project and to the organization. For example, the baseline risk posture for development of a new launch vehicle may be expressed in terms of the following performance requirements, and associated risk tolerance levels:
Baseline Performance:
minimum mass-to-orbit > 90 metric tons at 99% confidence;
reliability > 99% at 90% confidence
A more complete expression of risk posture by project leadership and stakeholders for this situation might also be provided by indicating, in addition to the above, that a lower level of confidence in achieving the reliability target may be acceptable if certain gains, above and beyond the minimum requirements, could be pursued and achieved. The following declarations of acceptable "deltas" in risk tolerance limits would then provide, together with the initial baseline indications, a definition of the project risk posture that reflects, in its balancing of pursued objectives vs. associated risk tolerances, more flexibility than would be expressed by the baseline performance measures and risk tolerances alone:

Delta Case A:
acceptable reliability performance > 98% at 90% confidence
IF mass-to-orbit > 100 metric tons at 95% confidence
Delta Case B:
acceptable reliability performance > 99% at 50% confidence
IF eco-friendly propulsion is employed in new launch vehicle

11 A Risk Tolerance threshold defines the level of risk declared to be acceptable with respect to the achievement of a performance measure requirement. This is usually expressed by what probability of not meeting a performance target can be tolerated and accepted, and is the "other side of the coin" of stating the "confidence level" by which a performance requirement is to be met. In the note and example discussion of Risk Posture provided above, Risk Tolerances are expressed or implied as follows:
Baseline Case:
Risk Tolerance for mass-to-orbit:
probability of not meeting 90 ton requirement < 1%
Risk Tolerance for reliability:
probability of not meeting 99% reliability requirement < 10%
Acceptable Delta Case A:
Risk Tolerance for mass-to-orbit:
probability of not meeting 100 ton requirement < 5%
Risk Tolerance for reliability:
probability of not meeting 98% reliability requirement < 10%
Acceptable Delta Case B:
Risk Tolerance for mass-to-orbit:
probability of not meeting 90 ton requirement < 1%
Risk Tolerance for reliability:
probability of not meeting 99% reliability requirement < 50%

12 This NPR uses the term "safety" broadly to include human safety (public and workforce), environmental safety, and asset safety.

13 In the context of this NPR, "threat" is a broad term that refers to a possible condition or combination of conditions, relative to a risk scenario, which can have a relevant role in the origination or realization of the risk. The means by which the threat may materialize may be physical, or non-physical (e.g., software-based), or even weapon-grade in case of an open aggression by an enemy entity
Example 1: the existence of a disgruntled employee with access privileges to a protected network constitutes a "threat" to the security objectives for that network.
Example 2: the existence of defective components in a space vehicle represents a "threat" to the success of the mission that such a vehicle is designed to execute.
Example 3: the jamming capabilities of an ill-intentioned enemy represent a threat to NASA satellite GPS and communication functions.

14 With reference Example 1 in the Note for the definition of "Threat," the "threat source" is that the disgruntled employee can use his/her access privileges to compromise network systems or information. In Example 2, the "threat source" is that defective components can prematurely fail and cause a mission failure.



| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |
 
| NODIS Library | Program Management(8000s) | Search |

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.