| 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 |

Chapter 3. Requirements for Risk Management

3.1 General

3.1.1 As discussed in Chapter 2, Roles and Responsibilities, the applicability of these requirements to individual organizational units is determined by the management of the organizational hierarchy within which those organizational units function.

3.1.2 Four categories of requirements are presented in this chapter: General Risk Management Requirements, Requirements for the RIDM Process, Requirements for the CRM Process, and Requirements for Risk Acceptance. Acceptance of risks to safety needs to be justified in part by a finding that all that can be done practically to eliminate or mitigate risks to safety has been done.

3.1.3 If it becomes evident that it is not practical to satisfy one or more requirements, it may be necessary to obtain a waiver to those requirements, rebaseline those requirements, or rebaseline the requirements overall. Insofar as such actions affect risk to safety or mission success, they constitute risk acceptance decisions and are treated with special formality (see paragraphs 3.5 (for project risks), 3.6 (for institutional risks), or 3.7 (for cross-cutting risks)). This is the case even if, administratively, the risk is not dispositioned as "accepted" under the CRM Plan requirements of paragraph 3.4.2.j.

3.1.4 In the following sections, requirements are levied on "the manager." This term is used in this NPR to refer to the manager of the organizational unit. The manager can delegate the execution of certain processes as specified in the Risk Management Plan. However, even in such cases the manager remains accountable for fulfilling the requirements of this NPR and for the decisions that are made, specifically including risk acceptance decisions as defined in the Risk Management Plan.

3.2 General Risk Management Requirements

3.2.1 Some of the following requirements apply specifically to either Acquirers or Providers. Those requirements are labeled either "Acquirer organizations" or "Provider organizations," according to their context.

3.2.2 The manager of each organizational unit (hereafter "the manager") shall:

a. Ensure that the RIDM and CRM processes are implemented within the unit and that key decisions of the organizational unit are risk-informed.

Note: Note: Examples of key decisions include: architecture and design decisions, make-buy decisions, source selection in major procurements, budget reallocation (allocation of reserves), and acceptance of risks to safety or mission success.

b. Allocate performance requirements to Provider organizations that are consistent with the unit's own performance requirements. (Acquirer organizations)

c. Ensure, during procurement activities, that risks are identified and analyzed in relation to the performance requirements for each offeror to the unit and that risk analysis results are used to inform the source selection. (Acquirer organizations)

Note: Appendix D contains good practices for procurement/contract risk management.

d. Establish elevation criteria to be applied by Provider organizations reporting to the unit. (Acquirer organizations)

e. Ensure that cross-cutting risks and interdependencies between risks are properly identified as cross-cutting and either managed within the unit or elevated.

Note 1: In general, the cross-cutting character of a given risk is best determined by an organizational unit at a level above the level at which that risk is first identified.

Note 2: Tools of KM are expected to be particularly valuable in this regard.

f. Coordinate the management of cross-cutting risks being managed within the unit with other involved organizational units, e.g., Centers, Mission Support Enterprise Offices, programs, projects, and other designated responsible authorities, e.g., the information system Authorizing Official with regard to cybersecurity.

Note: Note: Refer to Section 3.7 for special requirements on management of cross-cutting risks affecting both institutional and programmatic organizations.

g. Ensure that formal dissent arising during risk management decision making are handled through the formal dissent process as defined in NPD 1000.0.

h. Ensure that risk management activities of the organizational unit support, and are consistent with, ongoing internal control activities. For additional information, see NPD 1200.1.

i. Ensure the development of a Risk Management Plan (RMP) that:

(1) Reflects the risk leadership principles the organizational unit is directed to apply by the next higher level in the pursuit of its objectives, and defines a corresponding risk posture via the definition of risk tolerances and explicit risk acceptance criteria to be applied in the execution of the unit’s activities and projects.

(2) Explicitly scopes all the risk types within the purview of the organizational unit, e.g., for projects: safety, mission success, physical security and cybersecurity, cost, and schedule risks.

(3) Addresses all the principal possible sources of risk, e.g., for projects or defined activities: both internal and external random events, both internal and external intentional actions.

(4) Delineates the unit's approach for applying RIDM and CRM within a graded approach (see Definitions in Appendix A).

(5) Cites the documents that capture the complete set of requirements (within the scope established in (1), above) to be met by the organization, including the top-level Safety and Mission Success requirements levied on the organization, derived requirements, process requirements, and commitments (e.g., testing) (Provider organizations).

Note 1: This plan serves to clarify what detailed requirements (and commitments) the Provider expects to address in the ensuing development of the system. Satisfaction of these requirements is intended to provide evidence of satisfaction of the top-level requirements; correspondingly, risks to fulfillment of the commitments or satisfaction of the requirements are a key focus of Risk Management and, in particular, the specification of risk acceptance criteria (see item (8)below). The Acquirer's review of this portion of the plan provides an early opportunity to ensure that the Provider is adequately addressing the safety and mission success requirements and is implementing a risk-informed process in development of the system.

Note 2: For each requirement, this portion of the plan will designate whether the associated risks (including the aggregate risk) are to be assessed quantitatively or qualitatively.

Note 3: Describes processes for systematically treating top-level performance requirements and derived requirements implied by them. Accordingly, the present requirement allows for citation, rather than replication, of those requirements in the RMP. However, in addition to such requirements on performance of the system or service being developed, the RMP also contains Provider commitments (e.g., to perform tests) that are deemed to provide evidence (assurance) to the Acquirer of satisfaction of the performance requirements. For additional information, see NPR 7123.1, NASA Systems Engineering Processes and Requirements.

Note 4: Within this formulation, cancellation of commitments to perform tests or demonstrations amounts to either a rebaselining or a waiver proposal and is correspondingly subject to requirements on Risk Acceptance in paragraphs 3.5 (for project risks), 3.6 (for institutional risks), or 3.7 (for cross-cutting risks).

Note 5: Cost and schedule commitments are derived from JCL analysis in major programs and projects, or from simpler processes of estimations judged adequate for the purpose, in other programs or projects. For additional information, see NPR 7120.

(6) Is coordinated with other management plans, such as higher-level risk management plans and the Systems Engineering Management Plan (SEMP) when applicable. For additional information, see NPR 7123.1.

(7) Defines categories for likelihood and consequence severity, when risk characterization requires specifying risks in terms of such categories, and determines and documents the protocols for estimation of the likelihood and severity of the consequence components of risks, including uncertainty characterization and quantification. For risks resulting from intentional-action sources, where the likelihood dimension of risk may be characterized in conditional terms, i.e., assuming that an intentional source is present, provides and documents corresponding definitions and determinations for categories or metrics that it selects to characterize the conditional likelihood characterization of such risks.

Note 1: As part of the definition of likelihood / probability categories, the RMP can also establish criteria that can be used to apply practical distinction between conditions to be treated as risks and those that can be considered existing issues. Generally, a risk event can be considered to be an “issue” when its undesired consequences have already occurred, or are going to occur with very high likelihood if no remedial action is taken.

Note 2: The characterization of uncertainty is to be implemented in a graded fashion. If uncertainty can be shown to be small based on a simplified (e.g., bounding) analysis, and point estimates of performance measures clearly imply a decision that new information would not change, then detailed uncertainty analysis is unnecessary. Otherwise, some uncertainty analysis is needed to determine whether the expected benefit of the decision is affected significantly by uncertainty. In some cases, it may be beneficial to obtain new evidence to reduce uncertainty, depending on the stakes associated with the decision, the resources needed to reduce uncertainty, and programmatic constraints on uncertainty reduction activities (such as schedule constraints).

(8) Reflects the overall programmatic risk posture by documenting risk acceptance criteria/thresholds and elevation protocols (the specific conditions under which a risk management decision is elevated through management to the next higher level). (Agreement between Acquirer and Provider organizations)

Note 1: A "risk acceptance criterion" is a rule for determining whether a given organizational unit has the authority to decide to accept a risk.

Note 2: The RMP required in 3.2.2i. delineates (refer to subparagraph (3)) a body of performance requirements to be met by the Provider. Risk acceptance criteria are formulated to allow the Provider discretion, while still assuring satisfaction of those performance requirements. As long as the performance requirements are being satisfied, the Provider has discretion to act; if satisfaction of the requirements would be placed in doubt by acceptance of a risk, then either the risk is elevated, or the requirements are rebaselined.

(9) Identifies stakeholders, such as Risk Review Boards and the information system Authorizing Official (for cybersecurity risk), to participate in coordinated deliberations regarding the disposition of risks.

(10) Establishes risk communication protocols between management levels, including the frequency and content of reporting, as well as identification of entities that will receive risk tracking data from the unit's risk management activity. Also establishes guidance to make sure that communication between management levels and across the organization reflects any criteria established to distinguish “risks” from “issues,” especially when this is associated with different types of handling and assignment of order of priority.

Note 1: This communication may be accomplished using standard reporting templates defined in the RMP, including risk matrices (and conditional risk matrices for intentional-action risks; see Note 2 below), whose formulation and interpretation are agreed between the affected units, recognizing that communication of risk from one level to another level (e.g., from project to program level) must be executed consistently with the risk classification criteria of the receiving organization, in order to support decision-making at that level.

Note 2: In case of intentional-action risk scenarios, such as cybersecurity risk, conditional-risk matrices may be used, to communicate the risk level corresponding to a given type of intentional threat, if the latter is assumed to be present. This type of communication may be adopted when it is judged that a probability or frequency-based representation of the potential types of threat is not possible or meaningful.

Note 3: In general, elevation protocols and communication protocols are specific to levels and units. A risk decision that requires elevation from one level to the next may be manageable at the higher level, since the organizational unit at that level has more flexibility and authority.

Note 4: For Center mission support and institutional organizations, protocols are particularly important for reporting risks to affected project units and vice versa.

(11) Establishes a form for documentation of the manager's decisions to accept risks to safety or mission success, the technical basis supporting those decisions, the concurrence of the cognizant Technical Authorities, and, if applicable, the agreement of the Risk Takers’ responsible managers to assume the risk (refer to paragraph 3.5.3 for application of this form).

(12) Establishes an interval for the periodic review of the assumptions on which risk acceptance decisions are based.

(13) Delineates the processes for coordination of risk management activities and sharing of risk information with other affected organizational units and responsible authorities (e.g., the information system Authorizing Official for cybersecurity risk). This includes management of cross-cutting risks (risks affecting multiple organizational units), including risks affecting both programmatic and institutional organizations.

(14) Documents the manager's signature, as well as:

(a) the concurrence of the Acquirer to which the manager reports, which includes concurrence that the Risk Management plan meets the Acquirer's requirements (Provider organizations), and

(b) the concurrence of the cognizant Technical Authorities or other Institutional Authorities (e.g., Institutional Safety Authorities) that the Risk Management Plan meets the requirements of this NPR.

j. Ensure that decisions to rebaseline performance requirements, grant waivers, or modify RMPs that affect safety, mission success, or institutional risk are risk-informed consistent with the RIDM process described in Chapter 1 and that they are processed as risk acceptance decisions (refer to requirements in paragraphs 3.5 (for project risks), 3.6 (for institutional risks), or 3.7 (for cross-cutting risks)).

Note: Note: Per requirements in paragraph 3.2.2i., the RMP contains not only performance requirements, but also commitments (e.g., to testing or demonstration activities). A reduction in certain commitments could entail acceptance of some risk to safety or mission success.

k. Ensure that risk documentation for both RIDM and CRM is maintained in accordance with NPD 1440.6, NASA Records Management, and NPR 1441.1, NASA Records Management Program Requirements, and under formal configuration control, with a capability to identify and readily retrieve the current and all archived versions of risk information and the RMP.

3.2.3 Managers responsible for lower-cost, lower-risk-classification missions that have to satisfy less stringent success criteria (e.g., Cubesat, Risk Class D missions) may fulfill the above requirements according to the graded approach directives for risk management established by NPR 8705.4, Risk Classification for NASA Payloads.

3.3 Requirements for the RIDM Process

3.3.1 The manager shall ensure that key decisions, including risk acceptance decisions, are informed by Analysis of Alternatives carried out by applying the RIDM process (refer to Figure 3) with a level of rigor that is commensurate with the significance and the complexity of the decisions.

3.3.2 The manager shall ensure that:

a. The rationale for the selected decision alternative is developed and documented to include contending decision alternatives considered, a summary of risk analysis results for each alternative, and the pros and cons of each alternative.

b. The bases for performance requirement baselines (or rebaselines) informed by the RIDM process are captured and documented and that these baselines (including associated institutional requirements) are applied to scope the unit's CRM implementation.

3.4 Requirements for the CRM Process

3.4.1 The manager shall coordinate the unit's CRM process (refer to Figure 4) with the CRM processes of organizational units at levels above and below, including contractors.

3.4.2 The manager shall ensure that:

a. Risk identification is comprehensive and consistent with the baseline performance requirements of that unit. (related to IDENTIFY step)

b. Risk analyses performed to support RIDM (see paragraph 3.3.) are used as input to the "IDENTIFY" step of CRM. (related to IDENTIFY step)

c. The results of risk identification are documented to provide input to the "ANALYZE" step and to characterize the risks for purposes of tracking. (related to IDENTIFY step)

Note: When this documentation takes the form of a "risk statement" or "risk scenario," NASA/SP-2011-3422 uses the following format: "Given that [CONDITION], there is a possibility of [DEPARTURE] from the baseline adversely impacting [ASSET], thereby leading to [CONSEQUENCE]." (Refer to NASA/SP-2011-3422 for more information on risk statements.) Each risk statement or scenario is accompanied by a descriptive narrative, which captures the context of the risk by describing the circumstances, contributing factors, uncertainty, range of possible consequences, and related issues (such as what, where, when, how, and why).

d. When a risk management decision is elevated from a lower-level organizational unit, the associated risk is recalibrated with respect to the requirements, thresholds, and priorities that have been established at the higher level, and the recalibrated risks are entered into the "PLAN," "TRACK," and "CONTROL" steps (paragraphs h. through q.) at the higher level. (related to ANALYZE step)

e. Wherever determined to be feasible (as documented in the RMP), aggregate risk is characterized through analysis (including uncertainty evaluation), as an input to the decision-making process. (related to ANALYZE step)

f. Analyzed risks are prioritized and used as input to the "PLAN," TRACK," and "CONTROL" steps. (related to ANALYZE step)

g. The results of the "ANALYZE" step are documented. (related to ANALYZE step)

h. Decisions made on the disposition of risks, including decisions regarding implementation of control measures, are informed by the risk analysis results and are consistent with the defined thresholds established in paragraph 3.2.2i(8). (related to PLAN step)

i. Only one of the following possible risk dispositions is applied to any given risk. (related to PLAN step):

(1) When a decision is made to ACCEPT a risk, each acceptance is clearly documented in the organizational unit's risk database, including the rationale for acceptance, the assumptions (including the conditions (e.g., programmatic constraints)) on which the acceptance is based, the applicable risk acceptance criteria, and the interval (as required by the RMP) after which the assumptions will be periodically reviewed for any changes that might affect the continued acceptability of the risk. Additionally, for risk acceptance decisions, the requirements in paragraphs 3.5 (for project risks), 3.6 (for institutional risks), or 3.7 (for cross-cutting risks) apply.

(2) When a decision is made to MITIGATE a risk, a risk mitigation plan, including contingency planning, is developed and documented in the risk database. The parameters that will be tracked to determine the effectiveness of the mitigation are identified in the mitigation plan.

(3) When a decision is made to CLOSE a risk, the closure rationale is developed, and both rationale and management approval are documented in the risk database.

(4) When a decision is made to WATCH a risk, tracking requirements are developed and documented in the risk database. All risks categorized as "WATCH" have triggering events, decision points, dates, milestones, necessary achievements, or goals identified.

(5) When additional information is needed to make a decision, efforts to RESEARCH a risk (obtain additional information) are documented and tracked in the risk database.

(6) When dispositions (1), (2), (3), (4), or (5) above cannot be applied, the decision is elevated to the organizational unit management at the next higher level (typically the Acquirer) and the action taken is documented in the risk database.

j. For "MITIGATE," "WATCH," and "RESEARCH," an entity is designated to implement the disposition. (related to PLAN step)

k. A process for acquiring and compiling observable data to track the progress of the implementation of risk management decisions is developed and implemented. (related to TRACK step)

l. The cumulative effects of risk management decisions and risk acceptance decisions (i.e., the aggregate effect of accumulated, accepted risks, to ensure the aggregate risk remains tolerable) are tracked. (related to TRACK step)

m. The assumptions on which risk acceptance decisions are based (see 3.4.2.j(1)) are periodically tracked. (related to TRACK step)

n. Tracking data are disseminated to entities identified in the RMP as recipients of these data. (related to TRACK step)

o. Tracking data are evaluated in order to assess the effectiveness of decisions implemented in paragraph 3.4.2.j. (related to CONTROL step)

p. Feedback is provided to affected organizational units, including the Acquirer at the next higher level, on any changes in the status of tracked risks such as, but not limited to, acceptance of a risk or changing a mitigation plan. (related to CONTROL step)

q. If warranted by the tracking data, necessary control action(s) is(are) implemented. (related to CONTROL step)

Note: Because the "Document and Communicate" function of CRM is integral to all of the steps in the CRM process (Figure 4), requirements for documentation and communication are integrated into the preceding steps rather than treated as a separate step.

3.5 Requirements for Programmatic Decisions to Accept Risks to Safety, Mission Success, Physical Security, or Cybersecurity

3.5.1 Many decisions that are not necessarily couched as "risk acceptance" decisions nevertheless have implications for safety, mission success, or physical security and cybersecurity. For example, each KDP functions as an integrated system-level roll-up of the many decisions at different levels in the organization through which risk has been implicitly or explicitly accepted up to that point, and a decision to proceed represents both formal acceptance of this risk and accountability for this risk going forward. Such implicit risk-acceptance decisions need to be justified in the same way as decisions that are explicitly framed as risk-acceptance decisions.

3.5.2 All key project decisions that accept risks to safety or mission success - either implicitly or explicitly - are subject to the requirements of 3.5.3 on creation of the basis for the decision, TA or other cognizant authority (see Note below) concurrence, and, if human Risk Taker[s] are involved, the consent of their managers to the Risk Takers’ assumption of the risk. This includes decisions made at Key Decision Points (KDP); significant milestones (e.g., Flight Readiness Reviews), which entail consideration of decisions to proceed despite existing risks; when performance requirements are being rebaselined, e.g., rebaselining to relax safety requirements, which tacitly accepts safety risk; when waivers are being considered, e.g., waivers of safety or security requirements, which may increase risk; and when an Acquirer is taking delivery of a system or capability, which entails assumption of responsibility for managing the associated risks, including risks previously accepted by the Provider.

Examples of such decisions include:

a. Decisions and associated concurrence or consent acts that concern the procurement by an Acquirer of a system or of a specific set of services from a Provider on a turnkey basis;

b. Provider decisions that effectively rebaseline the Acquirer's top-level safety and mission success requirements levied on the Provider;

c. Provider decisions to rebaseline derived requirements developed by the Provider and accepted by the Acquirer as sufficing to demonstrate compliance with top-level requirements;

d. Reduction in other Provider commitments (e.g., commitments to conduct flight testing), or

e. Relaxation of physical security and cybersecurity requirements.

Note: In the case of a program or project risk involving the configuration or operation of an information system, the risk disposition decision requires coordination with the information system Authorizing Official (AO).

3.5.3 Each manager shall ensure that:

a. Each decision for accepting risk to safety, mission success, or physical security and cybersecurity (e.g., requirements definition/compliance/waiver, change requests, formal board directives and decisions, formal dissent dispositions, etc.) can be traced to the risk posture established for the affected mission or project, and

b. All such decisions and their rationales are clearly documented in the organizational unit's risk database, in the formal configuration management system where the associated decision was approved, or in a formal safety or security process system, on a program-defined form including:

(1) The manager's signature, documenting or referencing:

(a) The case, technical and programmatic, relied upon to justify the decision;

(b) The assumptions, programmatic constraints, evaluation of aggregate risk, and the acceptance criteria on which the decision is based;

(c) The rationale for acceptance, including satisfaction of the organization's risk acceptance criteria.

Note 1: The form and content of the "case (technical and programmatic) relied upon" depends on the circumstances. For example: 1) for acceptance of individual risks, the case may include Analysis of Alternatives considering the balance between safety, mission success, physical security and cybersecurity, cost, and schedule performance considerations; 2) at a KDP, a comprehensive, integrated case will have been developed to support a decision to progress to the next phase of the life cycle; for the decision to utilize a “turn-key” mission or flight service, the technical case may be based on the Acquirer’s development and communication to the turn-key system or service Provider of performance-based risk-control goals and objectives, and the correspondingly compatible, convincingly established safety and performance record of the turn-key system or service being accepted for use, evaluated within the context of the Agency’s current risk posture for those specific missions.

Note 2: The purpose of this requirement is not to compel execution of the formal processes for acceptance of every minor risk or decision individually but rather to foster the identification and management of credible risks, both individually and as a group, based on a technically sound analysis, in order to promote understanding of the aggregate risk being accepted, and to assign accountability for risk acceptance with the programmatic decision makers.

(2) The TAs' signatures with their concurrence positions, documenting or referencing their evaluations of the technical merits of the case, the manager's authority to accept the risk, and the acceptability of the risk.

Note: Refer to Note under paragraph 2.3.4.c.

3.5.4 In the event of TA nonconcurrence in a manager's risk acceptance decision, the TA shall elevate the risk acceptance decision one level up in the organizational hierarchy in accordance with the formal dissent process (NPD 1000.0).

3.5.5 In the event of TA concurrence in a manager's risk acceptance decision, the manager shall report each decision accepting risks to safety, mission success, or physical security and cybersecurity one level up in the organizational hierarchy.

Note: Risks are reported up one level because it is important to track and manage the aggregate risk at the Acquirer's level.

3.5.6 When an Acquirer takes delivery of a Provider’s system or service, acceptance and/or management of the outstanding risks of the system or service, including risks previously accepted by the Provider, becomes the Acquirer's current responsibility. The Acquirer shall integrate the outstanding risks into the Acquirer's risk management and/or acceptance process, based on:

a. The TA (at the Provider's level) findings accompanying the Provider's technical basis.

b. Independent evaluation of the technical basis by the TA at the Acquirer's level.

Note 1: Risks that were previously accepted by the Provider may now be reducible, given the additional resources and flexibility available to the Acquirer.

Note 2: A decision by the Acquirer not to accept responsibility for managing (or accepting) the risk is tantamount to refusing delivery of the system. This situation is intended to be precluded by the processes described above.

3.5.7 For lower-cost, lower-priority missions that may have lower likelihood of success (e.g., Cubesat, Risk Class D missions) responsible project managers may limit formal risk acceptance decisions (excluding those related to personnel or public safety) to milestone and flight readiness reviews (see paragraph 3.2.3). For additional information, see NPR 8705.4.

Note: Refer to paragraph 3.2.3 for "graded approach" considerations.

3.5.8 Besides all of the above, whenever specific Federal Government regulations apply to the acceptance of risk issues (e.g., as in the case of cybersecurity policies and regulations), they shall be complied with by the NASA authority accountable for risk acceptance, or by any contractor / provider to whom NASA has delegated that authority.

3.6 Requirements for Decisions to Accept Institutional Risks to Safety or Mission Success

3.6.1 For "institutional risks" (as defined in Appendix A) to safety or mission success, the Center Director shall develop, document in an institutional risk management plan, and implement a formal process for institutional risk acceptance that meets the intent of key requirements of paragraphs 3.5.3, 3.5.4, and 3.5.5.

Note: Per 3.2.2i, all organizations, including Centers, are managed to satisfy explicit performance criteria, including criteria for safety and mission success. Institutional risks to safety or mission success are either risks to the satisfaction of these criteria, or relaxations of the criteria themselves.

3.6.2 Depending upon the nature of the risk, the process should specify whether risk acceptance responsibility is formally delegated by the Center Director to the manager of a specific Center office, and who serves as the concurring authority (analogous to the TA role in paragraph 3.5). The Center Director remains ultimately accountable for institutional risk acceptance decisions at his/her Center, even when he/she has delegated the risk acceptance decision authority for certain risks to a manager who reports to the Director within the Center organizational structure.

Note: Center Directors should identify in the respective institutional risk management plans the circumstances and criteria under which they should communicate and coordinate institutional risk acceptance with other potentially affected stakeholders within the Agency.

3.7 Requirements for Decisions to Accept Risks to Safety and Mission Success Affecting Both Programmatic and Institutional Organizational Units

3.7.1 Some risks affect both programmatic and institutional organizations. Organizational units shall proactively communicate the status of that risk to affected organizations.

3.7.1.1 Risks created by institutional facilities are managed by institutional organizations, who should satisfy the requirements of 3.6 for risk acceptance and proactively communicate risk dispositions to affected programmatic organizations. Affected programmatic organizations can accept risks created by institutional organizations only if:

a. Those risks satisfy their risk acceptance criteria,

b. The requirements of 3.5 are followed, and

c. The affected programmatic organization's Acquirer (the organization that concurred in the organization's risk acceptance criteria) concurs in the acceptance of risks created by institutional organizations.

Note: In a case such as this, the affected programmatic organization’s acceptance and elevation protocols will not, in general, have been drafted with cross-cutting risks in mind. It is therefore necessary to keep the higher levels informed of such decisions. If human risk-takers are involved, their spokespersons’ concurrence will have been required at a high organizational level.

3.7.1.2 Risks created by programmatic organizations are managed by those organizations, who should satisfy the requirements of 3.5 for risk acceptance and proactively communicate risk dispositions to affected institutional organizations. Affected institutional organizations can accept risks created by programmatic organizations only if:

a. Those risks satisfy their risk acceptance criteria,

b. The requirements of 3.6 are followed, and

c. The affected institutional organization's Acquirer (the organization that concurred in the institutional organization's risk acceptance criteria) concurs in the acceptance.

Note: See preceding note. Risk acceptance and elevation protocols will not, in general, have been formulated with cross-cutting risks in mind.

3.7.2 Managers in all organizations potentially affected by a given risk should have access to current status information relating to that risk, and WATCH that risk. In the event that any of the affected organizations deems the risk to warrant proactive measures not being taken by the managing organization, that affected organization should take the following steps, iterating the process until managing and affected organizations agree on the appropriate approach to management of that risk.

a. Propose a different management approach to the managing organization.

b. If the managing organization does not take actions deemed adequate by the affected organization, the affected organization will elevate the risk to the next level in its hierarchy, which should either provide the originating affected organization with resources sufficient to address the risk in a different way, raise the issue with its counterpart in the managing organization’s hierarchy, or elevate the risk to the next higher level of its own hierarchy.

c. This process should be iterated until either the risk has been addressed by the managing hierarchy, addressed using an alternative risk control strategy by the affected hierarchy, accepted by the affected hierarchy, or elevated to the appropriate Management Council.



| 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.