NIST SP 800-39 Chapter 2

From FISMApedia
Jump to: navigation, search




This chapter describes the fundamental concepts associated with managing information security risk across an organization including: (i) the components of risk management; (ii) the multitiered risk management approach; (iii) risk management at Tier 1 (organization level); (iv) risk management at Tier 2 (mission/business process level); (v) risk management at Tier 3 (information system level); (vi) risk related to trust and trustworthiness; (vii) the effects of organizational culture on risk; and (viii) the relationships among key risk management concepts.


Managing risk is a complex, multifaceted activity that requires the involvement of the entire organization--from senior leaders/executives providing the strategic vision and top-level goals and objectives for the organization; to mid-level leaders planning, executing, and managing projects; to individuals on the front lines operating the information systems supporting the organization's missions/business functions. Risk management is a comprehensive process that requires organizations to: (i) frame risk (i.e., establish the context for risk-based decisions); (ii) assess risk; (iii) respond to risk once determined; and (iv) monitor risk on an ongoing basis using effective organizational communications and a feedback loop for continuous improvement in the risk-related activities of organizations. Risk management is carried out as a holistic, organization-wide activity that addresses risk from the strategic level to the tactical level, ensuring that risk-based decision making is integrated into every aspect of the organization.[1] The following sections briefly describe each of the four risk management components.

The first component of risk management addresses how organizations frame risk or establish a risk context--that is, describing the environment in which risk-based decisions are made. The purpose of the risk framing component is to produce a risk management strategy that addresses how organizations intend to assess risk, respond to risk, and monitor risk--making explicit and transparent the risk perceptions that organizations routinely use in making both investment and operational decisions. The risk frame establishes a foundation for managing risk and delineates the boundaries for risk-based decisions within organizations. Establishing a realistic and credible risk frame requires that organizations identify: (i) risk assumptions (e.g., assumptions about the threats, vulnerabilities, consequences/impact, and likelihood of occurrence that affect how risk is assessed, responded to, and monitored over time); (ii) risk constraints (e.g., constraints on the risk assessment, response, and monitoring alternatives under consideration); (iii) risk tolerance (e.g., levels of risk, types of risk, and degree of risk uncertainty that are acceptable); and (iv) priorities and trade-offs (e.g., the relative importance of missions/business functions, trade-offs among different types of risk that organizations face, time frames in which organizations must address risk, and any factors of uncertainty that organizations consider in risk responses). The risk framing component and the associated risk management strategy also include any strategic-level decisions on how risk to organizational operations and assets, individuals, other organizations, and the Nation, is to be managed by senior leaders/executives.

The second component of risk management addresses how organizations assess risk within the context of the organizational risk frame. The purpose of the risk assessment component is to identify: (i) threats to organizations (i.e., operations, assets, or individuals) or threats directed through organizations against other organizations or the Nation; (ii) vulnerabilities internal and external to organizations;[2] (iii) the harm (i.e., consequences/impact) to organizations that may occur given the potential for threats exploiting vulnerabilities; and (iv) the likelihood that harm will occur. The end result is a determination of risk (i.e., the degree of harm and likelihood of harm occurring). To support the risk assessment component, organizations identify: (i) the tools, techniques, and methodologies that are used to assess risk; (ii) the assumptions related to risk assessments; (iii) the constraints that may affect risk assessments; (iv) roles and responsibilities; (v) how risk assessment information is collected, processed, and communicated throughout organizations; (vi) how risk assessments are conducted within organizations; (vii) the frequency of risk assessments; and (viii) how threat information is obtained (i.e., sources and methods).

The third component of risk management addresses how organizations respond to risk once that risk is determined based on the results of risk assessments. The purpose of the risk response component is to provide a consistent, organization-wide, response to risk in accordance with the organizational risk frame by: (i) developing alternative courses of action for responding to risk; (ii) evaluating the alternative courses of action; (iii) determining appropriate courses of action consistent with organizational risk tolerance; and (iv) implementing risk responses based on selected courses of action. To support the risk response component, organizations describe the types of risk responses that can be implemented (i.e., accepting, avoiding, mitigating, sharing, or transferring risk). Organizations also identify the tools, techniques, and methodologies used to develop courses of action for responding to risk, how courses of action are evaluated, and how risk responses are communicated across organizations and as appropriate, to external entities (e.g., external service providers, supply chain partners).[3]

The fourth component of risk management addresses how organizations monitor risk over time. The purpose of the risk monitoring component is to: (i) verify that planned risk response measures are implemented and information security requirements derived from/traceable to organizational missions/business functions, federal legislation, directives, regulations, policies, and standards, and guidelines, are satisfied; (ii) determine the ongoing effectiveness of risk response measures following implementation; and (iii) identify risk-impacting changes to organizational information systems and the environments in which the systems operate.[4] To support the risk monitoring component, organizations describe how compliance is verified and how the ongoing effectiveness of risk responses is determined (e.g., the types of tools, techniques, and methodologies used to determine the sufficiency/correctness of risk responses and if risk mitigation measures are implemented correctly, operating as intended, and producing the desired effect with regard to reducing risk). In addition, organizations describe how changes that may impact the ongoing effectiveness of risk responses are monitored.

As indicated in the four components of risk management described above, organizations also consider external risk relationships, as appropriate. Organizations identify external entities with which there is an actual or potential risk relationship (i.e., organizations which could impose risks on, transfer risks to, or communicate risks to other organizations, as well as those to which organizations could impose, transfer, or communicate risks). External risk relationships include, for example, suppliers, customers or served populations, mission/business partners, and/or service providers. For organizations dealing with advanced persistent threats (i.e., a long-term pattern of targeted, sophisticated attacks) the risk posed by external partners (especially suppliers in the supply chain) may become more pronounced. Organizations establish practices for sharing risk-related information (e.g., threat and vulnerability information) with external entities, including those with which the organizations have a risk relationship as well as those which could supply or receive risk-related information (e.g., Information Sharing and Analysis Centers [ISAC], Computer Emergency Response Teams [CERT]).

Figure 1 illustrates the risk management process and the information and communications flows among components. The black arrows represent the primary flows within the risk management process with risk framing informing all the sequential step-by-step set of activities moving from risk assessment to risk response to risk monitoring. For example, one of the primary outputs from the risk framing component is a description of the sources and methods that organizations use in acquiring threat information (e.g., open source, classified intelligence community reports). The output regarding threat information is a primary input to the risk assessment component and is communicated accordingly to that component. Another example is illustrated in the primary output from the risk assessment component--that is, a determination of risk. The output from the risk assessment component is communicated to the risk response component and is received as a primary input for that component. Another primary input to the risk response component is an output from the risk framing component--the risk management strategy that defines how the organization should respond to risk. Together, these inputs, along with any additional inputs, are used by decision makers when selecting among potential courses of action for risk responses.

File:SP800-39 Figure1.png

The bidirectional nature of the arrows indicates that the information and communication flows among the risk management components as well as the execution order of the components, may be flexible and respond to the dynamic nature of the risk management process. For example, new legislation, directives, or policies may require that organizations implement additional risk response measures immediately. This information is communicated directly from the risk framing component to the risk response component where specific activities are carried out to achieve compliance with the new legislation, directives, or policies, illustrating the very dynamic and flexible nature of information as it moves through the risk management process. Chapter Three provides a complete description of the organization-wide risk management process including specifications for inputs/preconditions, activities, and outputs/post conditions.


To integrate the risk management process throughout the organization, a three-tiered approach is employed that addresses risk at the: (i) organization level; (ii) mission/business process level; and (iii) information system level. The risk management process is carried out seamlessly across the three tiers with the overall objective of continuous improvement in the organization's risk-related activities and effective inter-tier and intra-tier communication among all stakeholders having a shared interest in the mission/business success of the organization. Figure 2 illustrates the three-tiered approach to risk management along with some of its key characteristics.

File:SP800-39 Figure2.png

Tier 1 addresses risk from an organizational perspective. Tier 1 implements the first component of risk management (i.e., risk framing), providing the context for all risk management activities carried out by organizations. Tier 1 risk management activities directly affect the activities carried out at Tiers 2 and 3. For example, the missions and business functions defined at Tier 1 influence the design and development of the mission/business processes created at Tier 2 to carry out those missions/business functions. Tier 1 provides a prioritization of missions/business functions which in turn drives investment strategies and funding decisions, thus, affecting the development of enterprise architecture (including embedded information security architecture) at Tier 2 and the allocations and deployment of management, operational, and technical security controls at Tier 3.

Other examples of Tier 1 activities that affect Tier 2 and Tier 3 activities include the selection of common controls, the provision of guidance from the risk executive (function)[5] to authorizing officials, and the establishment of the order of recovery for information systems supporting critical missions and business operations. Section 2.3 provides a more detailed description of the specific activities associated with Tier 1.

Tier 2 addresses risk from a mission/business process perspective and is informed by the risk context, risk decisions, and risk activities at Tier 1. Tier 2 risk management activities include: (i) defining the mission/business processes needed to support the missions and business functions of organizations; (ii) prioritizing the mission/business processes with respect to the strategic goals and objectives of organizations; (iii) defining the types of information needed to successfully execute the mission/business processes, the criticality/sensitivity of the information, and the information flows both internal and external to organizations; (iv) incorporating information security requirements[6] into the mission/business processes; and (v) establishing an enterprise architecture[7] with embedded information security architecture[8] that promotes cost-effective and efficient information technology solutions consistent with the strategic goals and objectives of the organization and measures of performance. Tier 2 activities directly affect the activities carried out at Tier 3. For example, the information security architecture portion of the enterprise architecture developed at Tier 2 influences and guides the allocation of information protection needs which, in turn, influences and guides the allocation of the security controls to specific components of organizational information systems at Tier 3. Enterprise architecture decisions at Tier 2 affect the design of information systems at Tier 3 including the types of information technologies acceptable for use in developing those systems. The activities carried out at Tier 2 can also provide useful feedback to Tier 1, possibly resulting in revisions to the organizational risk frame or affecting risk management activities carried out at Tier 1, for example those performed by the risk executive (function). Section 2.4 provides a more detailed description of the specific activities associated with Tier 2.

Tier 3 addresses risk from an information system perspective and is guided by the risk context, risk decisions and risk activities at Tiers 1 and 2. Tier 3 risk management activities include: (i) categorizing organizational information systems; (ii) allocating security controls to organizational information systems and the environments in which those systems operate consistent with the organization's established enterprise architecture and embedded information security architecture; and (iii) managing the selection, implementation, assessment, authorization, and ongoing monitoring of allocated security controls as part of a disciplined and structured system development life cycle process implemented across the organization. At Tier 3, information system owners, common control providers, system and security engineers, and information system security officers make risk-based decisions regarding the implementation, operation, and monitoring of organizational information systems. Based on these day-to-day operational risk-based decisions, authorizing officials make follow-on risk-based decisions on whether or not the information systems are initially authorized to operate within the designated environments of operation or continue to receive authorization to operate on an ongoing basis. These ongoing risk-based decisions are informed by the risk management process with guidance from the risk executive (function) and the various architectural considerations supporting the mission/business processes. In addition, the activities at Tier 3 provide essential feedback to Tiers 1 and 2. New vulnerabilities discovered in an organizational information system, for example, may have systemic implications that extend organization-wide. Those same vulnerabilities may trigger changes to the enterprise architecture and embedded information security architecture or may require an adjustment to the organizational risk tolerance. Section 2.5 provides a more detailed description of the specific activities associated with Tier 3.

Since mission and business success in organizations depends on information systems, those systems must be dependable. To be dependable in the face of sophisticated threats, the information systems must be used wisely in accordance with the degree of protection and resilience achieved.


Tier 1 addresses risk from an organizational perspective by establishing and implementing governance structures that are consistent with the strategic goals and objectives of organizations and the requirements defined by federal laws, directives, policies, regulations, standards, and missions/business functions. Governance structures provide oversight for the risk management activities conducted by organizations and include: (i) the establishment and implementation of a risk executive (function); (ii) the establishment of the organization's risk management strategy including the determination of risk tolerance; and (iii) the development and execution of organization-wide investment strategies for information resources and information security.

2.3.1 Governance

In general, governance is the set of responsibilities and practices exercised by those responsible for an organization (e.g., the board of directors and executive management in a corporation, the head of a federal agency) with the express goal of: (i) providing strategic direction; (ii) ensuring that organizational mission and business objectives are achieved; (iii) ascertaining that risks are managed appropriately; and (iv) verifying that the organization's resources are used responsibly.[9] Risks and resources can be associated with different organizational sectors (e.g., legal, finance, information technology, regulatory compliance, information security). Different sectors require specialized expertise in order to manage the risks associated with that sector. Thus, governance within organizations frequently is organized by sector.[10] The five outcomes of governance related to organization-wide risk management are:

  • Strategic alignment of risk management decisions with missions and business functions consistent with organizational goals and objectives;
  • Execution of risk management processes to frame, assess, respond to, and monitor risk to organizational operations and assets, individuals, other organizations, and the Nation;
  • Effective and efficient allocation of risk management resources;
  • Performance-based outcomes by measuring, monitoring, and reporting risk management metrics to ensure that organizational goals and objectives are achieved; and
  • Delivered value by optimizing risk management investments in support of organizational objectives.[11]

As part of organizational governance, senior leaders/executives in consultation and collaboration with the risk executive (function), determine: (i) the types of risk management decisions that are reserved for specific senior leadership roles (e.g., heads of agencies or chief executive officers, chief financial officers, chief information officers, chief information security officers);[12] (ii) the types of risk management decisions that are deemed to be organization-wide and the types of decisions that can be delegated to subordinate organizations or to other roles in the organization (e.g., systems and security engineers, mission/business owners, enterprise architects, information security architects, common infrastructure or service providers, authorizing officials); and (iii) how risk management decisions will be communicated to and by the risk executive (function). Three different types of governance models (i.e., centralized, decentralized, and hybrid) are described in Appendix F. Regardless of the governance model(s) employed, clear assignment and accountability for accepting risk is essential for effective risk management.

Strong governance is the best indicator of senior leadership commitment to effective, consistent risk management across the organization to achieve ongoing mission/business success.

2.3.2 Risk Executive (Function)

The risk executive is a functional role established within organizations to provide a more comprehensive, organization-wide approach to risk management. The risk executive (function) serves as the common risk management resource for senior leaders/executives, mission/business owners, chief information officers, chief information security officers, information system owners, common control providers,[13] enterprise architects, information security architects, information systems/security engineers, information system security managers/officers, and any other stakeholders having a vested interest in the mission/business success of organizations. The risk executive (function) coordinates with senior leaders/executives to:

  • Establish risk management roles and responsibilities;
  • Develop and implement an organization-wide risk management strategy that guides and informs organizational risk decisions (including how risk is framed, assessed, responded to, and monitored over time);[14]
  • Manage threat and vulnerability information with regard to organizational information systems and the environments in which the systems operate;
  • Establish organization-wide forums to consider all types and sources of risk (including aggregated risk);
  • Determine organizational risk based on the aggregated risk from the operation and use of information systems and the respective environments of operation;
  • Provide oversight for the risk management activities carried out by organizations to ensure consistent and effective risk-based decisions;
  • Develop a greater understanding of risk with regard to the strategic view of organizations and their integrated operations;
  • Establish effective vehicles and serve as a focal point for communicating and sharing risk-related information among key stakeholders internally and externally to organizations;
  • Specify the degree of autonomy for subordinate organizations permitted by parent organizations with regard to framing, assessing, responding to, and monitoring risk;[15]
  • Promote cooperation and collaboration among authorizing officials to include security authorization actions requiring shared responsibility (e.g., joint/leveraged authorizations);[16]
  • Ensure that security authorization decisions consider all factors necessary for mission and business success; and
  • Ensure shared responsibility for supporting organizational missions and business functions using external providers receives the needed visibility and is elevated to appropriate decision-making authorities.

The risk executive (function) presumes neither a specific organizational structure nor formal responsibility assigned to any one individual or group within the organization. Heads of agencies or organizations may choose to retain the risk executive (function) or to delegate the function. The risk executive (function) requires a mix of skills, expertise, and perspectives to understand the strategic goals and objectives of organizations, organizational missions/business functions, technical possibilities and constraints, and key mandates and guidance that shape organizational operations. To provide this needed mixture, the risk executive (function) can be filled by a single individual or office (supported by an expert staff) or by a designated group (e.g., a risk board, executive steering committee, executive leadership council).[17] The risk executive (function) fits into the organizational governance structure in such a way as to facilitate efficiency and to maximize effectiveness. While the organization-wide scope situates the risk executive (function) at Tier 1, its role entails ongoing communications with and oversight of the risk management activities of mission/business owners, authorizing officials, information system owners, common control providers, chief information officers, chief information security officers, information system and security engineers, information system security managers/officers, and other stakeholders at Tiers 2 and 3.

To be effective, organizationwide risk management programs require the strong commitment, direct involvement, and ongoing support from senior leaders/executives. The objective is to institutionalize risk management into the daytoday operations of organizations as a priority and an integral part of how organizations conduct operations in cyberspace--recognizing that this is essential in order to successfully carry out missions in threatladen operational environments.

2.3.3 Risk Management Strategy

An organizational risk management strategy, one of the key outputs of risk framing, addresses how organizations intend to assess, respond to, and monitor risk--the risk associated with the operation and use of organizational information systems. The risk management strategy makes explicit the specific assumptions, constraints, risk tolerances, and priorities/trade-offs used within organizations for making investment and operational decisions. The risk management strategy also includes any strategic-level decisions and considerations on how senior leaders/executives are to manage information security risk to organizational operations and assets, individuals, other organizations, and the Nation. An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk response strategies, a process for consistently evaluating risk across the organization with respect to the organization's risk tolerance, and approaches for monitoring risk over time. The use of a risk executive (function) can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive.

An important Tier 1 risk management activity and also part of risk framing, is the determination of risk tolerance. Risk tolerance is the level of risk or degree of uncertainty that is acceptable to organizations and is a key element of the organizational risk frame. Risk tolerance affects all components of the risk management process--having a direct impact on the risk management decisions made by senior leaders/executives throughout the organization and providing important constraints on those decisions. For example, risk tolerance affects the nature and extent of risk management oversight implemented in organizations, the extent and rigor of risk assessments performed, and the content of organizational strategies for responding to risk. With regard to risk assessments, more risk-tolerant organizations may be concerned only with those threats that peer organizations have experienced while less risk-tolerant organizations may expand the list to include those threats that are theoretically possible, but which have not been observed in operational environments. With regard to risk response, less risk-tolerant organizations are likely to require additional grounds for confidence in the effectiveness of selected safeguards and countermeasures or prefer safeguards and countermeasures that are more mature and have a proven track record. Such organizations may also decide to employ multiple safeguards and countermeasures from multiple sources (e.g., antivirus software at clients and servers that are provided by different vendors). Another example illustrating the impact of risk tolerance on risk response is that risk tolerance can also affect the organizational requirements for trustworthiness provided by specific information technologies. Two organizations may choose the same information technologies, but their relative degree of risk tolerance may impact the degree of assessment required prior to deployment.

There is no correct level of organizational risk tolerance. Rather, the degree of risk tolerance is: (i) generally indicative of organizational culture; (ii) potentially different for different types of losses/compromises; and (iii) highly influenced by the individual subjective risk tolerance of senior leaders/executives. Yet, the ramifications of risk decisions based on risk tolerance are potentially profound, with less risk-tolerant organizations perhaps failing to achieve needed mission/business capabilities in order to avoid what appears to be unacceptable risk; while more risk-tolerant organizations may focus on near-term mission/business efficiencies at the expense of setting themselves up for future failure. It is important that organizations exercise due diligence in determining risk tolerance--recognizing how fundamental this decision is to the effectiveness of the risk management program.

2.3.4 Investment Strategies

Investment strategies[18] play a significant role in organizational risk management efforts. These strategies generally reflect the long-term strategic goals and objectives of organizations and the associated risk management strategies developed and executed to ensure mission and business success. Underlying all investment strategies is the recognition that there is a finite amount of resources available to invest in helping organizations effectively manage risk--that is, effectively addressing risk to achieve on-going mission/business success.

Mission and Risk Priorities

Organizations generally conduct a variety of missions and are involved in different types of business functions. This is especially true for large and complex organizations that have different organizational components, each of which is typically focused on one or two primary missions. While all of these organizational components and associated missions/business functions are likely to be important and play a key role in the overall success of organizations, in reality they are not of equal importance. The greater the criticality of organizational missions and business functions, the greater the necessity for organizations to ensure that risks are adequately managed. Such missions and business functions are likely to require a greater degree of risk management investments than missions/business functions deemed less critical. The determination of the relative importance of the missions/business functions and hence the level of risk management investment, is something that is decided upon at Tier 1, executed at Tier 2, and influences risk management activities at Tier 3.

Anticipated Risk Response Needs

There is a great variation in the nature of potential threats facing organizations, ranging from hackers attempting to merely deface organizational Web sites (e.g., cyber vandalism), to insider threats, to sophisticated terrorist groups/organized criminal enterprises seeking to exfiltrate sensitive information, to a nation state's military attempting to destroy or disrupt critical missions by attacking organizational information systems.[19] The strategic investments required to address the risk from more traditional adversaries (e.g., hackers conducting small-group activities with limited capabilities) are considerably different than the investments required to address the risk associated with advanced persistent threats consistent with more advanced adversaries (e.g., nation states or terrorist groups with highly sophisticated levels of expertise and resources that seek to establish permanent footholds in organizations for purposes of impeding aspects of the organizational missions). To address less sophisticated threats, organizations can focus their efforts at Tier 3--investing to ensure that needed safeguards and countermeasures (e.g., security controls, security services, and technologies) are obtained, implemented correctly, operating as intended, and producing the desired effect with regard to meeting information security policies and addressing known vulnerabilities. In addition to these basic investments, organizations can also invest in continuous monitoring processes to ensure that the acquired security controls, services, and technologies are operating effectively throughout the system development life cycle.

When organizations need to address advanced persistent threats, it is likely that adequately addressing related risks at Tier 3 is not feasible because necessary security solutions are not currently available in the commercial marketplace. In those instances, organizations must purposefully invest beyond Tier 3 for significant response capabilities at Tier 2, and to some extent at Tier 1. At Tier 3, the nature of investment is likely to change from implementation of existing solutions to an added strategic focus on investing in leading-edge information security technologies (essentially experimenting with innovative security solutions/technologies and being an early adopter) or investing in information security research and development efforts to address specific technology gaps.[20] Information security investments to address advanced persistent threats may require expenditures over the course of several years, as new security solutions and technologies transition from research to development to full deployment. The long-term view of strategic investing in the risk response needs for organizations can help to reduce the continuing focus on near-term vulnerabilities discovered in information systems--vulnerabilities that exist due to the complexity of the information technology products and systems and the inherent weaknesses in those products and systems.

Limitations on Strategic Investments

The ability of organizations to provide strategic information security investments is limited. Where the desired strategic investment funding or strategic resources[21] are not available to address specific needs, organizations may be forced to make compromises. For example, organizations might extend the time frame required for strategic information security objectives to be accomplished. Alternatively, organizations might prioritize risk management investments, opting to provide resources (financial or otherwise) to address some critical strategic needs sooner than other less critical needs. All investment decisions require organizations to prioritize risks and to assess the potential impacts associated with alternative courses of action.


Tier 2 addresses risk from a mission/business process perspective by designing, developing, and implementing mission/business processes that support the missions/business functions defined at Tier 1. Organizational mission/business processes guide and inform the development of an enterprise architecture that provides a disciplined and structured methodology for managing the complexity of the organization's information technology infrastructure. A key component of the enterprise architecture is the embedded information security architecture that provides a roadmap to ensure that mission/business process-driven information security requirements and protection needs are defined and allocated to appropriate organizational information systems and the environments in which those systems operate.

2.4.1 Risk-Aware Mission/Business Processes

The risk management activities at Tier 2 begin with the identification and establishment of risk-aware mission/business processes to support the organizational missions and business functions. A risk-aware mission/business process is one that explicitly takes into account the likely risk such a process would cause if implemented. Risk aware processes are designed to manage risk in accordance with the risk management strategy defined at Tier 1 and explicitly account for risk when evaluating the mission/business activities and decisions at Tier 2.[22] Implementing risk-aware mission/business processes requires a thorough understanding of the organizational missions and business functions and the relationships among missions/business functions and supporting processes. This understanding is a prerequisite to building mission/business processes sufficiently resilient to withstand a wide variety of threats including routine and sophisticated cyber attacks, errors/accidents, and natural disasters. An important part of achieving risk-aware processes is the understanding of senior leaders/executives of: (i) the types of threat sources and threat events that can adversely affect the ability of organizations to successfully execute their missions/business functions); (ii) the potential adverse impacts/consequences on organizational operations and assets, individuals, other organizations, or the Nation if the confidentiality, integrity, or availability of information or information systems used in a mission/business process is compromised; and (iii) the likely resilience to such a compromise that can be achieved with a given mission/business process definition, applying realistic expectations for the resilience of information technology.

A key output from the Tier 2 definition of mission/business processes is the selected risk response strategy[23] for these processes within the constraints defined in the risk management strategy. The risk response strategy includes identification of information protection needs and the allocation of those needs across components of the process (e.g., allocation to protections within information systems, protections in the operational environments of those systems, and allocation to alternate mission/business execution paths based on the potential for compromise).

2.4.2 Enterprise Architecture

A significant risk-related issue regarding the ability of organizations to successfully carry out missions and business functions is the complexity of the information technology being used in information systems. To address this complexity and associated potential risk, organizations need a disciplined and structured approach for managing information technology assets supporting their mission/business processes. Providing greater clarity and understanding of the information technology infrastructure of organizations including the design and development of the associated information systems is a prerequisite for maximizing the resilience and wise use of these systems in the face of increasingly sophisticated threats. This type of clarity and understanding can be effectively achieved through the development and implementation of enterprise architecture.

Enterprise architecture is a management practice employed by organizations to maximize the effectiveness of mission/business processes and information resources in helping to achieve mission/business success. Enterprise architecture establishes a clear and unambiguous connection from investments (including information security investments) to measurable performance improvements whether for an entire organization or portion of an organization. Enterprise architecture also provides an opportunity to standardize, consolidate, and optimize information technology assets. These activities ultimately produce information systems that are more transparent and therefore, easier to understand and protect. In addition to establishing a roadmap for more efficient and cost-effective usage of information technology throughout organizations, enterprise architecture provides a common language for discussing risk management issues related to missions, business processes, and performance goals--enabling better coordination and integration of efforts and investments across organizational and business activity boundaries. A well-designed enterprise architecture implemented organization-wide, promotes more efficient, cost-effective, consistent, and interoperable information security capabilities to help organizations better protect missions and business functions--and ultimately more effectively manage risk.

The Federal Enterprise Architecture (FEA) defines a collection of interrelated reference models including Performance, Business, Service Component, Data, and Technical as well as more detailed segment and solution architectures that are derived from the enterprise architecture.[24] Organizational assets (including programs, processes, information, applications, technology, investments, personnel, and facilities) are mapped to the enterprise-level reference models to create a segment-oriented view of organizations. Segments are elements of organizations describing mission areas, common/shared business services, and organization-wide services. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting specific mission areas or common/shared services. The primary stakeholders for segment architecture are mission/business owners. Following closely from segment architecture, solution architecture defines the information technology assets within organizations used to automate and improve mission/business processes. The scope of solution architecture is typically used to develop and implement all or parts of information systems or business solutions, including information security solutions. The primary stakeholders for solution architectures are information system developers and integrators, information system owners, information system/security engineers, and end users.

The FEA concepts that define needsdriven, performancebased business processes are applied by organizations, recognizing that effectively managing risk arising from operating in a cyberspace environment with sophisticated, highend threats is a key need and measure of performance.

Enterprise architecture also promotes the concepts of segmentation, redundancy, and elimination of single points of failure--all concepts that can help organizations more effectively manage risk. Segmentation is important because it allows organizations to separate missions/business functions and operations and the information systems, system components, or subsystems supporting those missions, functions, and operations from other functions and operations and supporting systems. Segmentation helps to define more manageable components and to potentially reduce the degree of harm from a successful threat exploitation of a vulnerability. Segment architecture supports the concept of segmentation at the highest levels of organizations and the concept is carried forward through solution architecture (including decomposition of information systems and networks into subsystems and subnetworks, as appropriate).

The concept of redundancy is also very important in enterprise architecture. With the high probability of breaches or compromises when threats exploit vulnerabilities in organizational information systems, the failure or degradation of one or more information system components is inevitable. To enhance information system resilience as part of risk response, organizational information systems provide a failover mode that helps to ensure that failed components trigger appropriate backup components with similar capability. This type of capability is essential to address the advanced persistent threat in situations where organizations might be required to operate while under cyber attack in a degraded mode but still providing a sufficient level of capability to achieve mission/business success. Segment and solution architectures support the concept of redundancy by establishing a disciplined and structured approach to developing and implementing key architectural considerations that facilitate replication of critical information system components, where appropriate.

Finally, the concept of single point of failure and the elimination of such failure points is easily supported by enterprise architecture. Having the essential visibility and transparency provided in the architectural design at the organization level exposes potential single points of failure early in the development process. Thus, single points of failure are effectively addressed by segment and solution architectures. Failure to address potential single points of failure early in the architectural design can result in severe or catastrophic effects when those failure points are propagated to information systems and the actual failure causes a loss of mission/business capability.

2.4.3 Information Security Architecture

The information security architecture is an integral part of the organization's enterprise architecture. It represents that portion of the enterprise architecture specifically addressing information system resilience and providing architectural information for the implementation of security capabilities.[25] The primary purpose of the information security architecture is to ensure that mission/business process-driven information security requirements are consistently and cost-effectively achieved in organizational information systems and the environments in which those systems operate consistent with the organizational risk management strategy.[26] The information security architecture also incorporates security requirements from legislation, directives, policies, regulations, standards, and guidance into the segment architecture. Ultimately, the information security architecture provides a detailed roadmap that allows traceability from the highest-level strategic goals and objectives of organizations, through specific mission/business protection needs, to specific information security solutions provided by people, processes, and technologies.

Information security requirements defined in the segment architecture are implemented in the solution architecture in the form of management, operational, and technical security controls. The security controls are employed within or inherited by the individual information systems and the environments in which the systems operate. The allocation[27] of security controls is consistent with the information security architecture as well as concepts such as defense-in-depth and defense-in-breadth. Figure 3 illustrates the process of integrating information security requirements into the enterprise architecture and the associated information systems supporting the mission/business processes of organizations.

File:SP800-39 Figure3.png

To summarize, risk management considerations can be addressed as an integral part of the enterprise architecture by:

Enterprise architecture provides a disciplined and structured approach to achieving consolidation, standardization, and optimization of information technology assets that are employed within organizations. Risk reduction can be achieved through the full integration of management processes[29] organization-wide, thereby providing greater degrees of security, privacy, reliability, and cost-effectiveness for the missions and business functions being carried out by organizations. This integrated approach of incorporating the organization's risk management strategy into enterprise architecture gives senior leaders/executives the opportunity to make more informed risk-based decisions in dynamic operating environments--decisions based on trade-offs between fulfilling and improving organizational missions and business functions and managing the many types and sources of risk that must be considered in their risk management responsibilities.

The use of enterprise architecture can greatly enhance an organization's risk posture by providing greater transparency and clarity in design and development activities--enabling a more consistent application of the principle of `wise use' of technologies across the organization; optimizing the tradeoffs between value gained from and the risk being incurred through the information systems supporting organizational missions/business functions.


All information systems, including operational systems, systems under development, and systems undergoing modification, are in some phase of the system development life cycle.[30] In addition to the risk management activities carried out at Tier 1 and Tier 2 (e.g., reflecting the organization's risk management strategy within the enterprise architecture and embedded information security architecture), risk management activities are also integrated into the system development life cycle of organizational information systems at Tier 3. The risk management activities at Tier 3 reflect the organization's risk management strategy and any risk related to the cost, schedule, and performance requirements for individual information systems supporting the mission/business functions of organizations. Risk management activities take place at every phase in the system development life cycle with the outputs at each phase having an effect on subsequent phases.

For example, requirements definition[31] is a critical part of any system development process and begins very early in the life cycle, typically in the initiation phase. The latest threat information that is available to organizations, or current organizational assumptions concerning threat, may significantly influence information system requirements and the types of solutions that are deemed by organizations to be acceptable (from a technological and operational perspective) in the face of such threats. Information security requirements are a subset of the functional requirements levied on information systems and are incorporated into the system development life cycle simultaneously with the other requirements. The information security requirements define the needed security functionality[32] for information systems and the level of trustworthiness for that functionality (see Section 2.6 on the trustworthiness of information systems).

Organizations also address risk management issues during the development/acquisition phase of the system development life cycle (e.g., system design, system development/integration, and demonstration). Whether in response to specific and credible threat information or assumptions about the threat, potential design-related vulnerabilities in organizational information systems can be mitigated during this phase by choosing less susceptible alternatives. Supply chain risk during the acquisition phase of the information system is also an area of concern for organizations. To address supply chain risk during the development/acquisition phase, organizations implement specific security controls as deemed necessary by the organization. Organizations also consider risk from the standpoint of the environment in which the information systems are intended to operate when selecting the most appropriate security controls. To be effective, controls must be mutually supporting, employed with realistic expectations for effectiveness, and implemented as part of an explicit, information system-level security architecture that is consistent with the security architecture embedded in the organization's enterprise architecture. For example, when certain technical controls are less than effective due to achievable levels of trustworthiness in organizational information systems, management and operational controls are employed as compensating controls--thus providing another opportunity to manage risk.

Subsequent to initiation, development, and acquisition, the implementation phase of the system development life cycle provides an opportunity for the organization to determine the effectiveness of the selected security controls employed within or inherited by the information systems under development prior to the commencement of actual operations. Expectations generated during this phase can be compared with actual behavior as information systems are implemented. Given the current threat information that is available to organizations and organizational assumptions about the threat, the information discovered during effectiveness assessments, and the potential adverse impacts on organizational missions/business functions, it may be necessary to modify or change the planned implementation of the information system. Risk-related information can be developed to justify the proposed changes.

Once approved for operation, information systems move into the operations/maintenance phase of the system development life cycle. The monitoring of security control effectiveness and any changes to organizational information systems and the environments in which those systems operate ensure that selected risk response measures are operating as intended on an ongoing basis. Ongoing monitoring is paramount to maintaining situational awareness of risk to organizational missions and business functions--an awareness that is critical to making the necessary course corrections when risk exceeds organizational risk tolerance. During the disposal phase of the system development life cycle, it is standard procedure for organizations to verifiably remove prior to disposal, any information from information systems that may cause adverse impacts, if compromised, and also assess any risk associated with these activities.[33]

Early integration of information security requirements into the system development life cycle is the most cost-effective method for implementing the organizational risk management strategy at Tier 3.[34] Incorporating risk management into the system development life cycle ensures that the risk management process is not isolated from the other management processes employed by the organization to develop, acquire, implement, operate, and maintain the information systems supporting organizational missions and business functions. To support system development life cycle integration, risk management (including information security considerations) is also incorporated into program, planning, and budgeting activities to help ensure that appropriate resources are available when needed--thus facilitating the completion of program and project milestones established by organizations. To incorporate risk management into program, planning and budgeting activities, risk and information security professionals are an integral part of the teams and structures used to address information system and organizational requirements.

The overall resilience of organizational information systems (i.e., how well systems operate while under stress) is a key factor and performance measure in determining the potential survivability of missions/business functions. The use of certain information technologies may introduce inherent vulnerabilities into these information systems--resulting in risk that may have to be mitigated by reengineering the current mission/business processes. The wise use of information technologies during the design, development, and implementation of organizational information systems is of paramount importance in managing risk.

Making information securityrelated requirements and activities an integral part of the system development life cycle ensures that senior leaders/executives consider the risks to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation and use of information systems and take appropriate actions to exercise the organization's due diligence.


Trust is an important concept related to risk management. How organizations approach trust influences their behaviors and their internal and external trust relationships. This section introduces some conceptual ways of thinking about trust, defines the concept of trustworthiness, and shows how the concept of trustworthiness can be used in developing trust relationships. Appendix G describes several trust models that can be applied in an organizational context, and considers how trust can be measured. The importance of organizational governance, culture, and transparency[35] are also considered with regard to trust and its affect on risk management.

Trust is a belief that an entity will behave in a predictable manner in specified circumstances. The entity may be a person, process, object or any combination of such components. The entity can be of any size from a single hardware component or software module, to a piece of equipment identified by make and model, to a site or location, to an organization, to a nation-state. Trust, while inherently a subjective determination, can be based on objective evidence and subjective elements. The objective grounds for trust can include for example, the results of information technology product testing and evaluation. Subjective belief, level of comfort, and experience may supplement (or even replace) objective evidence, or substitute for such evidence when it is unavailable. Trust is usually relative to a specific circumstance or situation (e.g., the amount of money involved in a transaction, the sensitivity or criticality of information, or whether safety is an issue with human lives at stake). Trust is generally not transitive (e.g., you trust a friend but not necessarily a friend of a friend). Finally, trust is generally earned, based on experience or measurement. However, in certain organizations, trust may be mandated by policy (see Appendix G, mandated trust model).

Trustworthiness is an attribute of a person or organization that provides confidence to others of the qualifications, capabilities, and reliability of that entity to perform specific tasks and fulfill assigned responsibilities. Trustworthiness is also a characteristic of information technology products and systems (see Section 2.6.2 on trustworthiness of information systems). The attribute of trustworthiness, whether applied to people, processes, or technologies, can be measured, at least in relative terms if not quantitatively.[36] The determination of trustworthiness plays a key role in establishing trust relationships among persons and organizations. The trust relationships are key factors in risk decisions made by senior leaders/executives.

2.6.1 Establishing Trust Among Organizations

Parties enter into trust relationships based on mission and business needs.[37] Trust among parties typically exists along a continuum with varying degrees of trust achieved based on a number of factors. Organizations can still share information and obtain information technology services even if their trust relationship falls short of complete trust. The degree of trust required for organizations to establish partnerships can vary widely based on many factors including the organizations involved and the specifics of the situation (e.g., the missions, goals, and objectives of the potential partners, the criticality/sensitivity of activities involved in the partnership, the risk tolerance of the organizations participating in the partnership, and the historical relationship among the participants). Finally, the degree of trust among entities is not a static quality but can vary over time as circumstances change.

Organizations are becoming increasingly reliant on information system services[38] and information provided by external organizations as well as partnerships to accomplish missions and business functions. This reliance results in the need for trust relationships among organizations.[39] In many cases, trust relationships with external organizations, while generating greater productivity and cost efficiencies, can also bring greater risk to organizations. This risk is addressed by the risk management strategies established by organizations that take into account the strategic goals and objectives of organizations.

Effectively addressing the risk associated with the growing dependence on external service providers and partnerships with domestic and international public and private sector participants necessitates that organizations:

  • Define the types of services/information to be provided to organizations or the types of information to be shared/exchanged in any proposed partnering arrangements;
  • Establish the degree of control or influence organizations have over the external organizations participating in such partnering arrangements;
  • Describe how the services/information are to be protected in accordance with the information security requirements of organizations;
  • Obtain the relevant information from external organizations to determine trustworthiness and to support and maintain trust (e.g., visibility into business practices and risk/information security decisions to understand risk tolerance);
  • Appropriately balance mission/business-based requirements to support information sharing while considering the risk of working with competing or hostile entities and the risk that other organizations, while neither competing or hostile, may be a path through which such entities attack;
  • Determine if the ongoing risk to organizational operations and assets, individuals, other organizations, or the Nation resulting from the continuing use of the services/information or the participation in the partnership, is at an acceptable level; and
  • Recognize that decisions to establish trust relationships are expressions of acceptable risk.

The degree of trust that an organization places in external organizations can vary widely, ranging from those who are highly trusted (e.g., business partners in a joint venture that share a common business model and common goals) to those who are less trusted and may represent greater sources of risk (e.g., business partners in one endeavor who are also competitors or adversaries). The specifics of establishing and maintaining trust can differ from organization to organization based on mission/business requirements, the participants involved in the trust relationship, the criticality/sensitivity of the information being shared or the types of services being rendered, the history between the organizations, and the overall risk to the organizations participating in the relationship. Appendix G provides several trust models that organizations can use when dealing with external organizations.

In many situations, the trust established between organizations may not allow a full spectrum of information sharing or a complete provision of services. When an organization determines that the trustworthiness of another organization does not permit the complete sharing of information or use of external services, the organization can: (i) mitigate risk, transfer risk, or share risk by employing one or more compensating controls; (ii) accept a greater degree of risk; or (iii) avoid risk by performing missions/business functions with reduced levels of functionality or possibly no functionality at all.

Explicit understanding and acceptance of the risk to an organization's operations and assets, individuals, other organizations, and the Nation by senior leaders/executives (reflecting the organization's risk tolerance) are made in accordance with the organization's risk management strategy and a prerequisite for establishing trust relationships among organizations.

2.6.2 Trustworthiness of Information Systems

The concept of trustworthiness can also be applied to information systems and the information technology products and services that compose those systems. Trustworthiness expresses the degree to which information systems (including the information technology products from which the systems are built) can be expected to preserve the confidentiality, integrity, and availability of the information being processed, stored, or transmitted by the systems across the full range of threats. Trustworthy information systems are systems that have been determined to have the level of trustworthiness necessary to operate within defined levels of risk despite the environmental disruptions, human errors, and purposeful attacks that are expected to occur in their environments of operation. Two factors affecting the trustworthiness of information systems are:

  • Security functionality (i.e., the security features/functions employed within the system); and
  • Security assurance (i.e., the grounds for confidence that the security functionality is effective in its application).[40]

Security functionality can be obtained by employing within organizational information systems and their environments of operation, a combination of management, operational, and technical security controls from NIST Special Publication 800-53.[41] The development and implementation of needed security controls is guided by and informed by the enterprise architecture established by organizations.

Security assurance is a critical aspect in determining the trustworthiness of information systems. Assurance is the measure of confidence that the security features, practices, procedures, and architecture of an information system accurately mediates and enforces the security policy.[42] Assurance is obtained by: (i) the actions taken by developers and implementers[43] with regard to the design, development, implementation, and operation of the security functionality (i.e., security controls); and (ii) the actions taken by assessors to determine the extent to which the functionality is implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for information systems and their environments of operation.[44] Developers and implementers can increase the assurance in security functionality by employing well-defined security policies and policy models, structured and rigorous hardware and software development techniques, and sound system/security engineering principles.

Assurance for information technology products and systems is commonly based on the assessments conducted (and associated assessment evidence produced) during the initiation, acquisition/development, implementation, and operations/maintenance phases of the system development life cycle. For example, developmental evidence may include the techniques and methods used to design and develop security functionality. Operational evidence may include flaw reporting and remediation, the results of security incident reporting, and the results of ongoing security control monitoring. Independent assessments by qualified assessors may include analyses of the evidence as well as testing, inspections, and audits of the implementation of the selected security functionality.[45]

The concepts of assurance and trustworthiness are closely related. Assurance contributes to the trustworthiness determination relative to an information technology product or an information system. Developers/implementers of information technology products or systems may provide assurance evidence by generating appropriate artifacts (e.g., the results of independent testing and evaluation, design documentation, high-level or low-level specifications, source code analysis). Organizations using information technology products or systems may perform, or rely on others to perform, some form of assessment on the products or systems. Organizations may also have direct experience with the product or system, or may receive information about the performance of the product or system from third parties. Organizations typically evaluate all of the available assurance evidence, often applying different weighting factors as appropriate, to determine the trustworthiness of the product or system relative to the circumstances.

Information technology products and systems exhibiting a higher degree of trustworthiness (i.e., products/systems having appropriate functionality and assurance) are expected to exhibit a lower rate of latent design and implementation flaws and a higher degree of penetration resistance against a range of threats including sophisticated cyber attacks, natural disasters, accidents, and intentional/unintentional errors. The susceptibility of missions/business functions of organizations to known threats, the environments of operation where information systems are deployed, and the maximum acceptable level of risk to organizational operations and assets, individuals, other organizations, or the Nation, guide the degree of trustworthiness needed.

Trustworthiness is a key factor in the selection and wise use of information technology products used in organizational information systems. Insufficient attention to trustworthiness of information technology products and systems can adversely affect an organization's capability to successfully carry out its assigned missions/business functions.


Organizational culture refers to the values, beliefs, and norms that influence the behaviors and actions of the senior leaders/executives and individual members of organizations. Culture describes the way things are done in organizations and can explain why certain things occur. There is a direct relationship between organizational culture and how organizations respond to uncertainties and the potential for near-term benefits to be the source for longer-term losses. The organization's culture informs and even, to perhaps a large degree, defines that organization's risk management strategy. At a minimum, when an expressed risk management strategy is not consistent with that organization's culture, then it is likely that the strategy will be difficult if not impossible to implement. Recognizing and addressing the significant influence culture has on risk-related decisions of senior leaders/executives within organizations can therefore, be key to achieving effective management of risk.

Recognizing the impact from organizational culture on the implementation of an organization-wide risk management program is important as this can reflect a major organizational change. This change must be effectively managed and understanding the culture of an organization plays an important part in achieving such organization-wide change. Implementing an effective risk management program may well represent a significant organization-wide change aligning the people, processes, and culture within the organization with the new or revised organizational goals and objectives, the risk management strategy, and communication mechanisms for sharing risk-related information among entities. To effectively manage such change, organizations include cultural considerations as a fundamental component in their strategic-level thinking and decision-making processes (e.g., developing the risk management strategy). If the senior leaders/executives understand the importance of culture, they have a better chance of achieving the organization's strategic goals and objectives by successfully managing risk.

Culture also impacts the degree of risk being incurred. Culture is reflected in an organization's willingness to adopt new and leading edge information technologies. For example, organizations that are engaged in research and development activities may be more likely to push technological boundaries. Such organizations are more prone to be early adopters of new technologies and therefore, more likely to view the new technologies from the standpoint of the potential benefits achieved versus potential harm from use. In contrast, organizations that are engaged in security-related activities may be more conservative by nature and less likely to push technological boundaries--being more suspicious of the new technologies, especially if provided by some entity with which the organization lacks familiarity and trust. These types of organizations are also less likely to be early adopters of new technologies and would be more inclined to look at the potential harm caused by the adoption of the new technologies. Another example is that some organizations have a history of developing proprietary software applications and services, or procuring software applications and services solely for their use. These organizations may be reluctant to use externally-provided software applications and services and this reluctance may result in lower risk being incurred. Other organizations may, on the other hand, seek to maximize advantages achieved by modern net-centric architectures (e.g., service-oriented architectures, cloud computing), where hardware, software, and services are typically provided by external organizations. Since organizations typically do not have direct control over assessment, auditing, and oversight activities of external providers, a greater risk might be incurred.

In addition to the cultural impacts on organizational risk management perspectives, there can also be cultural issues between organizations. Where two or more organizations are operating together toward a common purpose, there is a possibility that cultural differences in each of the respective organizations may result in different risk management strategies, propensity to incur risk, and willingness to accept risk.[46] For example, assume two organizations are working together to create a common security service intended to address the advanced persistent threat. The culture of one of the organizations may result in a focus on preventing unauthorized disclosure of information, while the nature of the other organization may result in an emphasis on mission continuity. The differences in focus and emphasis resulting from organizational culture can generate different priorities and expectations regarding what security services to procure, because the organizations perceive the nature of the threat differently. Such culture-related disconnects do not occur solely between organizations but can also occur within organizations, where different organizational components (e.g., information technology components, operational components) have different values and perhaps risk tolerances. An example of an internal disconnect can be observed in a hospital that emphasizes different cultures between protecting the personal privacy of patients and the availability of medical information to medical professionals for treatment purposes.

Culture both shapes and is shaped by the people within organizations. Cultural influences and impacts can be felt across all three tiers in the multitiered risk management approach. Senior leaders/executives both directly and indirectly in Tier 1 governance structures set the stage for how organizations respond to various approaches to managing risk. Senior leaders/executives establish the risk tolerance for organizations both formally (e.g., through publication of strategy and guidance documents) and informally (e.g., through actions that get rewarded and penalized, the degree of consistency in actions, and the degree of accountability enforced). The direction set by senior leaders/executives and the understanding of existing organizational values and priorities are major factors determining how risk is managed within organizations.


As indicated by the discussions above, there are a variety of risk-related concepts (e.g., risk tolerance, trust, and culture), all of which have an impact on risk management. The concepts do not operate in a vacuum; rather, there is often a strong interplay among the concepts (e.g., an organization's culture along with its governance structures and processes, often influences the pace of change and the implementation of its risk management strategy). For this reason, the risk executive (function) and other parties involved in organizational risk-based decisions, need to have an awareness and appreciation for all of the concepts. Several examples of the relationships among the risk-related concepts are provided below. The list of relationships is not exhaustive and serves only to illustrate how combining risk-related concepts can produce unintended consequences, both positive and negative in scope.

2.8.1 Governance, Risk Tolerance, and Trust

As part of implementing the organization's risk management strategy at Tier 1, the risk executive (function) establishes practices for sharing risk-related information with external entities. With regard to the demonstration of due diligence for managing risk, organizations that are less risk tolerant are likely to require more supporting evidence than organizations that are more risk tolerant. Such organizations may only trust (and hence partner with) organizations with which they have had a long and successful relationship (see direct historical trust model in Appendix G). The amount of centralization[47] within an organization may be reflective of the organizational risk tolerance and/or its willingness to trust partnering organizations. Some organizations select a decentralized governance structure for reasons such as widely diverging mission/business areas or need for increased separation between mission/business lines due to sensitivity of the work. The reasons for decentralization may reflect and likely will influence risk tolerance. For instance, if there are no partnering organizations meeting the established trust qualifications, less risk-tolerant organizations may require significantly more supporting evidence of due diligence (e.g., access to risk assessments, security plans, security assessment reports, risk acceptance decisions) than is typically required in such situations (see validated trust model in Appendix G).

2.8.2 Trust and Culture

There is also potential interplay between the concepts of risk, trust, and culture. Changes in mission/business requirements (e.g., a new mission or business requirement to interconnect information systems for the purpose of sharing information) may require a greater acceptance of risk than is typical for that organization. In the short term, additional measures may be needed to establish and/or build trust (e.g., increase transparency between interconnecting organizations). Such measures facilitate building trust and evolving organizational beliefs and norms over the longer term. Interaction between trust and culture can also be observed when there are gaps and overlaps in responsibility among an organization's components that may impact the ability for proposed actions (especially new actions) to be carried out quickly. For example, many organizations with decentralized governance structures may be slower to embrace change unless there has been an extensive effort to expand coordination and improve trust among organizational components. Assume that some organizations are directed by higher authorities (see mandated trust model in Appendix G) to share information more freely with peer organizations. If the organizations have a history and culture of tightly controlling information, they may be reluctance to share information with outside entities, even though directed to do so. In such situations, organizations may require that partnering organizations provide concrete evidence of the steps taken to protect the information designated for sharing prior to release.

2.8.3 Investment Strategy and Risk Tolerance

Investment strategies and organizational risk tolerance also have linkages. Organizations may recognize that there is a need to address advanced persistent threats where adversaries have achieved some degree of penetration of and foothold within organizational information systems and the environments in which those systems operate. The strategic investments that are required to address these types of threats may, in part, be influenced by the risk tolerance of organizations. Less risk-tolerant organizations may focus investments on information technologies that prevent adversaries from gaining further access within organizations and/or limiting the damage done to the organizations even if at the expense of achieving some of the many mission/business benefits automation can provide. More risk-tolerant organizations may focus investments on information technologies that provide greater mission/business benefits even if these benefits are achieved at the expense of adversaries gaining some advantage or benefit from compromising the information systems and supporting infrastructure.

2.8.4 Culture and Risk Tolerance

A major part of managing risk within organizations is identifying what the organizational risk tolerance is for a particular type of loss. Risk tolerance can be described as a combination of the cultural willingness to accept certain types of loss within organizations and the subjective risk-related actions of senior leaders/executives. Risk-based decisions within organizations often reflect the blending of the risk tolerance of senior leaders/executives and the risk tolerance that is embedded within the culture of organizations. In establishing organizational risk tolerance, the values, beliefs, and norms of organizations are examined in order to understand why risk trade-offs are made. For some organizations, in particular those organizations that deal with critical and/or sensitive information, personally identifiable information, or classified information, the emphasis is often on preventing unauthorized disclosure. In contrast, in those organizations driven by a combination of organizational culture and the nature of their missions and business functions, the emphasis is on maintaining the availability of information systems to achieve an ongoing operational capability. As part of establishing organizational risk tolerance, a risk assessment identifies the kinds and levels of risk to which organizations may be exposed. This assessment considers both the likelihood and impact of undesired events (see Chapter Three, the risk management process).


  1. 13 Integrated, enterprise-wide risk management includes, for example, consideration of: (i) the strategic goals/objectives of organizations; (ii) organizational missions/business functions prioritized as needed; (iii) mission/business processes; (iv) enterprise and information security architectures; and (v) system development life cycle processes.
  2. 14 Organizational vulnerabilities are not confined to information systems but can include, for example, vulnerabilities in governance structures, mission/business processes, enterprise architecture, information security architecture, facilities, equipment, system development life cycle processes, supply chain activities, and external service providers.
  3. 15 Supply chain risk management guidance is provided in NIST Interagency Report 7622.
  4. 16 Environments of operation include, but are not limited to: the threat space; vulnerabilities; missions/business functions; mission/business processes; enterprise and information security architectures; information technologies; personnel; facilities; supply chain relationships; organizational governance/culture; procurement/acquisition processes; organizational policies/procedures; organizational assumptions, constraints, risk tolerance, and priorities/trade-offs).
  5. 17 The risk executive (function) is described in Section 2.3.2.
  6. 18 Information security requirements can be obtained from a variety of sources (e.g., legislation, policies, directives, regulations, standards, and organizational mission/business/operational requirements). Organization-level security requirements are documented in the information security program plan or equivalent document.
  7. 19 Federal Enterprise Architecture Reference Models and Segment and Solution Architectures are defined in the OMB Federal Enterprise Architecture (FEA) Program, FEA Consolidated Reference Model Document, Version 2.3, October 2003, and OMB Federal Segment Architecture Methodology (FSAM), January 2009, respectively.
  8. 20 The information security architecture describes the security-related aspects of the enterprise architecture that are incorporated into the enterprise architecture definition as an integral part of the architecture development--that is a sub-architecture derived from the enterprise architecture, not a separately defined layer or architecture.
  9. 21 This definition is adapted from the IT Governance Institute. The Chartered Institute of Management Accountants and the International Federation of Accountants also adopted this definition in 2004.
  10. 22 While governance is frequently organized by sectors, organizations are well served by establishing a single aligned governance approach. A unified governance approach can coordinate the individual sector governance activities and provide a consistent governance approach, organization-wide.
  11. 23 Information security governance outcomes adapted from IT Governance Institute, Information Security Governance: Guidance for Boards of Directors and Executive Management, 2nd Edition, 2006.
  12. 24 There is no implication by listing various titles within an organization of any particular relationship (peer or otherwise) or lines of authority.
  13. 25 A common control provider is an organizational official responsible for the development, implementation, assessment, and monitoring of common controls (i.e., security controls inherited by information systems).
  14. 26 Organizational risk decisions include investment decisions (see Section 2.3.4). Organizational risk tolerance is determined as part of the risk framing component (see Section 2.3.3) and defined in the risk management strategy.
  15. 27 Because subordinate organizations responsible for carrying out derivative or related missions may have already invested in their own methods of framing, assessing, responding to, and monitoring risk, parent organizations may allow a greater degree of autonomy within parts of the organization or across the entire organization in order to minimize costs. When a diversity of risk management activities is allowed, organizations may choose to employ, when feasible, some means of translation and/or synthesis of the risk-related information produced from those activities to ensure that the output of the different activities can be correlated in a meaningful manner.
  16. 28 NIST Special Publication 800-37 provides guidance on joint and leveraged authorizations.
  17. 29 Organizations emphasize the need for inclusiveness within the risk executive (function) by senior leaders/executives in mission/business areas to help ensure proper information security planning, resourcing, and risk management.
  18. 30 Investment strategies can include organizational approaches to: (i) replacing legacy information systems (e.g., phasing items in gradually, replacing entirely); (ii) outsourcing and using external providers of information systems and services; and (iii) internal development vs. acquisition of commercially available information technology products.
  19. 31 The threats described above are a subset of the overarching threat space that also includes errors of omission and commission, natural disasters, and accidents.
  20. 32 This investment strategy is a change from vulnerability and patch management to a longer-term strategy addressing information security gaps such as the lack of information technology products with the trustworthiness necessary to achieve information system resilience in the face of advanced persistent threats.
  21. 33 In some instances, the limitations may not be financial in nature, but limitations in the number of individuals with the appropriate skills/expertise or limitations regarding the state of technology.
  22. 34 The identification of organizational mission/business processes includes defining the types of information that the organization needs to successfully execute those processes, the criticality and/or sensitivity of the information, and the information flows both internal and external to the organization.
  23. 35 Risk response strategies are described in Appendix H.
  24. 36 The Federal Enterprise Architecture is described in a series of documents published by the OMB FEA Program Management Office. Additional information on the FEA reference models and the segment and solution architectures can be found in the FEA Consolidated Reference Model Document and FEA Practice Guidance, respectively.
  25. 37 In general, a version of an information security architecture exists for each of the enterprise architecture reference models; including Performance, Business, Service Component, Data, and Technical.
  26. 38 Organizations employ sound system and security engineering principles and techniques to ensure that information security requirements are effectively implemented in organizational information systems.
  27. 39 Security control allocation occurs down to the information system component level, employing security controls in selected system components assigned to provide a specific security capability. Specific guidance on how to incorporate information security requirements into enterprise architecture is provided in the FEA Security and Privacy Profile.
  28. 40 The activities required to effectively incorporate information security into enterprise architecture are carried out by key stakeholders within organizations including mission/business owners, chief information officers, chief information security officers, authorizing officials, and the risk executive (function).
  29. 41 A management process is a process for planning and controlling the performance or execution of organizational activities (e.g., programs, projects, tasks, processes). Management processes are often referred to as performance measurement and management systems.
  30. 42 There are typically five phases in system development life cycles: (i) initiation; (ii) development/ acquisition; (iii) implementation; (iv) operation/maintenance; and (v) disposal. Organizations may use a variety of system development life cycle processes including, for example, waterfall, spiral, or agile development.
  31. 43 Information security requirements can be obtained from a variety of sources (e.g., legislation, policies, directives, regulations, standards, and organizational mission/business/operational requirements).
  32. 44 Security functionality is the set of security controls employed within or inherited by an information system or the environment in which the system operates. The security controls, described in NIST Special Publication 800-53, are implemented by a combination of people, processes, and technologies.
  33. 45 While the presentation of the system development life cycle is expressed as a linear flow, in reality, the knowledge gained during a later phase of the life cycle or changes in system requirements or operational environments may dictate revisiting an earlier phase. For example, changes in the threat environment during the operation/maintenance phrase may dictate the need to initiate a new or revised system capability.
  34. 46 The Risk Management Framework (RMF), described in NIST Special Publication 800-37, provides a structured process that integrates risk management activities into the system development life cycle. The RMF operates primarily at Tier 3 but also interacts with Tier 1 and Tier 2 (e.g., providing feedback from authorization decisions to the risk executive [function], disseminating updated risk information to authorizing officials, common control providers, and information system owners).
  35. 47 Transparency is achieved by providing visibility into the risk management and information security activities carried out by organizations participating in partnerships (e.g., employing common security standards, specification language for security controls including common controls, assessment procedures, risk assessment methodologies; defining common artifacts and bodies of evidence used in making risk-related decisions).
  36. 48 Current state-of-the-practice for measuring trustworthiness can reliably differentiate between widely different levels of trustworthiness and is capable of producing a trustworthiness scale that is hierarchical between similar instances of measuring activities (e.g., the results from ISO/IEC 15408 [Common Criteria] evaluations).
  37. 49 Trust relationships can be: (i) formally established, for example, by documenting the trust-related information in contracts, service-level agreements, statements of work, memoranda of agreement/understanding, or interconnection security agreements; (ii) scalable and inter-organizational or intra-organizational in nature; and/or (iii) represented by simple (bilateral) relationships between two partners or more complex many-to many relationships among many diverse partners.
  38. 50 External information system services are services that are implemented outside of the system's traditional authorization boundary (i.e., services that are used by, but not a part of, the organizational information system).
  39. 51 External providers or mission/business partners can be public or private sector entities, domestic or international.
  40. 52 Assurance also represents the grounds for confidence that the intended functionality of an information system is correct, always invoked (when needed), and resistant to bypass or tampering.
  41. 53 The employment of appropriate security controls for information systems and environments of operation is guided by the first three steps in the Risk Management Framework (i.e., categorization, selection, and implementation).
  42. 54 A security policy is set of criteria for the provision of security services.
  43. 55 In this context, a developer/implementer is an individual or group of individuals responsible for the design, development, implementation, or operation of security controls for an information system or supporting infrastructure.
  44. 56 For other than national security systems, organizations meet minimum assurance requirements specified in NIST Special Publication 800-53, Appendix E.
  45. 57 NIST Special Publication 800-53A provides guidance on assessing security controls in federal information systems.
  46. 58 A similar situation can exist between subordinate elements of an organization when these elements are afforded a fair amount of autonomy and operational authority.
  47. 59 Additional information on governance models can be found in Appendix F.