Risk is defined as:

When a risk turns into a reality, it can have severe effects on a business. These risks could threaten a company's existence, cause significant disruptions, or damage its reputation.

Risk management is a vital practice that carries out the identification, evaluation, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the likelihood or impact of unfortunate events or to maximize the realization of opportunities.

Risk management is a vital activity for everyone in an enterprise, and failure can lead to serious consequences that may even threaten the continued existence of the enterprise. Organizations spend considerable time and resources on risk management, with governance, risk, and security departments dedicated to addressing risk. Yet, this effort is often challenging and resource-intensive. It’s difficult to maintain updated and actionable risk registers with static spreadsheets. When organizations use a corporate risk tool, it is typically stand-alone, lacking information about the range of controls available, the technologies used across the organization, or which business processes and organizational units depend on key applications.

Armed with Ardoq and the Application Risk Use Case, the Enterprise Architect can bring value to the CIO by addressing these challenges while offering a joined-up approach to Application Risk Management. This more holistic approach will greatly assist other corporate stakeholders, including the Information Security, Corporate Risk, Audit, Governance, and Compliance teams.

The primary stakeholders for Ardoq Application Risk Management are the company roles who are responsible for its execution:

CEOs and CFOs are also relevant stakeholders needing an awareness of the application risk process. However, they are usually not active in the execution of the application risk management process.

Table 1: The primary stakeholder roles involved in Application Risk Management

Ardoq’s strength is to provide up-to-date insights from complex, interconnected and dynamic information that is updated across the entire company. Ardoq has a unique combination of capabilities that are able to make a valuable contribution to risk management.

The scope of the Application Risk Management use case is defined by the following sets of questions for enterprise stakeholders. They can be summarized as: what are we doing, why are we doing it, and what benefit will it bring to the organization?

Figure 1 below shows the key components (Risks, Applications, Controls, and Frameworks & Policies) and the main stakeholders involved in managing application risk. While Enterprise Architects rarely own these components, they have a vital role in coordinating the Risk Management process, bringing the unique capabilities of Ardoq to Application Risk Management (as articulated in “The value that Ardoq brings” above).

Figure 1: The Main Risk Management Components and Stakeholders

Each of the components has its owners, who have their own responsibilities and bring their own perspectives, creating a potential difficulty in coordinating the actions needed to address the questions outlined above. This is where the Enterprise Architect can take a valuable lead, providing a coordinating capability that spans the constrained views of the owners of Risks, Applications, Controls, Frameworks, and Policies. This Use Case creates that capability, opening views between the interested parties, and providing process and management tools that support the processes and activities of each of the above steps.

Each of the components is introduced below, but for a more detailed explanation of how they have been implemented in Ardoq, please see the Application Risk Metamodel guide.

Whilst accountability for risks often sits with a corporate risk management team, responsibility for both identifying and managing risks is usually devolved to risk owners across the organization. IT risks typically sit with the CIO, though cybersecurity risks may be owned by a separate security team. Where agile methods have been adopted, risks that relate to the application portfolio may also have been distributed across the business-owned product teams. The Enterprise Architect is often asked to assist the CIO in responding to requests from the corporate risk management team, and this is a great opportunity for the EA team to deliver business value to the CIO.

Ardoq’s implementation adopts the widely used formula for determining a numeric value for the level of a given risk [5]:

Raw Likelihood and Impact are on the same scale of 1.0 to 5.0 and the Raw Risk Exposure, the product of Likelihood and Impact, is therefore a value between 1 and 25. We refer to these values as “raw” because they represent the risk in its “raw” unmitigated state. If controls are applied to applications that are impacted by risks, the likelihood of the risk occurring, or the impact of its occurrence, or both (and therefore also the exposure) will be reduced.

Details of how Likelihood, Impact, and Exposure levels are handled, calculated, and, potentially, modified are given in corresponding sections below, after their related components, Applications, and Controls have been described.

The risk component is categorized into four main types of risk:

This is consistent with the categorization of risk by the Institute of Risk Management. Further, these categories identify and recognize that specific risks of each of these types may have both external and internal drivers. The growth of digital business and the reliance on digital technology throughout a business mean that IT risks are typically a major component of corporate risk.

The Application Lifecycle Management Use Case is a pre-requisite for the adoption of this Use Case (see Application Lifecycle Management [6] for more details). Applications can be impacted by multiple risks and have multiple controls applied to them. Calculated fields in each Application component show the cumulative effect of impacting risks and deployed controls, allowing dashboards and reports to facilitate detailed exploration of the risk landscape from an application portfolio perspective.

Applications are typically related to other component types. For example, the model may represent which Organizational Units use the applications. Other references may indicate which Business Capabilities an application realizes. The degree to which an application is impacted by risks can be passed on to these higher-level components, allowing analysis of the total exposure of organizational units or business capabilities to application risks across the estate.

Controls are represented with their own component type in Ardoq. They may have a mitigating effect on one or more Risks and can be deployed to one or more Applications. Where a Control that mitigates a given risk has been deployed to an application, it will have the effect of reducing the exposure level of risk associated with that risk’s threat to the application. The result is the Current Risk levels (Current Likelihood, Current Impact, and Current Exposure recorded on the reference between the Risk and the Application) which can then be compared with the original “raw” (unmitigated) exposure level recorded on each Risk.

A Control can have a beneficial effect on risks that impact an application in two different ways. Some controls might have the effect of reducing the likelihood of the risk occurring. Others might reduce the impact of the risk, should it occur (but not reduce the likelihood). And it is possible that a control has a beneficial effect on both likelihood and impact.

When the Control component is created, Likelihood Effect and Impact Effect values must be specified. These indicate by how much these values will reduce the likelihood and/or impact of risks that are impacting the application once the control has been deployed to it (i.e., the Controls deployment date to the Application is in the past). Of course, they only affect the scores of risks that the control mitigates (as shown by its Mitigates reference(s) to Risk component(s)). These two Effect fields are, therefore, negative numbers on a scale of 0 to 4. The effect of Controls is cumulative, so multiple controls that address one risk can offer better protection than just one. Controls cannot reduce Likelihood or Impact levels below their minimum possible scores of 1.

The likelihood of a risk occurring is a numerical measure that is largely dependent on the nature of each defined risk. When a risk owner adds a detailed description to a newly created Risk component, they should also provide an estimate of that Risk’s likelihood of occurring. Ardoq expects this to be recorded on a scale of 1 to 5, with 5 representing the most likely. These are often given definitions as part of a corporate risk model using descriptions, probabilities, or frequencies. Examples are given in Table 2 below:

Table 2: Example Likelihood Scales (Source: Management of Risk [3])

In this Use Case, the original estimated Risk Likelihood is known as the Raw Risk Likelihood, because when it impacts an application, the likelihood might be modified downwards as a consequence of one or more Controls being deployed to the Application. Of course, the beneficial effect of the Control will only apply if it is a Control that has a mitigating effect on that particular Risk, and only if the Control has Deployment Date in the past.

The business impact associated with a Risk is also recorded on a 1-5 scale. This should also be indicated at the time that a new Risk component is created. And like Likelihood, it is quite common to use a descriptive phrase to help arrive at the right level of Impact for a given Risk. A numeric scale can be quite abstract, so mapping from words can help give different people a shared idea of what each level means.

Table 3: Example Impact scales (Source: Management of Risk [3])

As with likelihood, the original estimated Impact is known as the Raw Risk Impact because it, too, may be modified when it impacts a given application in light of Controls that may have been deployed to that application.

Risk Exposure is the product of Risk Likelihood multiplied by Risk Impact. With our 1-5 scales, this produces an exposure scale of 1 - 25. Most organizations that model their risks in this way also apply color coding to the resulting Exposure score, with thresholds to categorize every Risk as Red, Amber, or Green according to its score. A typical risk table will, therefore, look like this:

Figure 2: A Typical Risk Table

In the above example, any exposure score of 4 or below is considered a “Green” risk, any score of 15 or above a “Red” risk, and all scores between are considered an “Amber” risk.

This Use Case adopts this approach but with a difference that recognizes the particular situation of managing risk as applied to Applications. The consequences of two different applications being exposed to the same risk may be different. For example, two applications may be exposed to the same cyber risk. If one of those is a business-critical application used by customers, it may be a bigger threat than one that supports a back-office function used by a small number of staff. So, the Use Case provides for a separate set of thresholds to categorize risks as Red, Amber, or Green for each Application. In this way, the same Risk might be considered to be Red in the context of one Application but Amber for another.

Frameworks, such as the NIST Cybersecurity Framework [4], and internal organizational Policies are represented in the same way, as Information Artifacts that may be broken down into a more detailed collection of Requirements. The requirements may be linked directly to Controls, indicating which controls are realizations of the requirements either of adopted frameworks or corporate policies.

The Information Artifact Component Type is used in Ardoq to represent “an item of unstructured information, like a document” [7], and the components can usefully contain a URL link to the source document. Corporate Policy documents, control frameworks (and official standards such as ISO 31000 and ISO 25010) are unstructured in that they contain a lot of text, but the document itself is typically broken into sections that form a logical structure. The sections typically address different aspects of the policy, framework, or standard. We’ve chosen to use the generic term Requirement for the Component Type that can model these sections and, where appropriate, subsections within them.

You should only consider modeling sections or subsections of a framework or policy document if they have distinct significance in their relationship with controls or other frameworks or policies. If, for example, different sections of a framework suggest the implementation of different controls, it is useful to represent each of these sections as different Requirement components within the same parent Information Artifact (representing the framework document as a whole). These can each have their own Realized By references to their corresponding Control components, allowing the knowledge graph to capture which parts of the framework have been, or are planned to be, addressed with one or more controls and which have no corresponding controls available.

Figure 3: Policy Requirements and their realizations

Below, we give an example of a framework document, and how it can be modeled in Ardoq. Table 4 reproduces the table of Functions and Categories that define the high-level structure of the NIST Cybersecurity Framework [4]. Each Category contains a set of Subcategories, which are individual recommended activities.

Table 4: NIST Cybersecurity Framework Functions and Categories

Figure 4 below shows how the framework has been modeled in Ardoq, using Requirement components to represent Functions, Categories, and Subcategories, within the parent Information Artifact that represents the framework document. The Recover function of the framework is shown open with its three categories and their corresponding sub-categories, modeled with child Requirement components.

Figure 4: Ardoq model of NIST framework document

You may wish to describe how a Control has been realized in more detail with Ardoq. This can be done using references to applications, processes, organizational units, and information artifacts, showing how the control has been implemented and by whom. Most Controls that are deployed to Applications involve technology (e.g., bringing technology services or other applications to bear upon the risk-impacted application). But some Controls might be implemented as published policies and procedures (which will be represented with Information Artifacts), and others with particular Processes carried out by Organizational Units. The Control may also form part of the realization of a Business Capability or a Technical Capability (see Business & Technical Capability Management [8] for more details).

Plans to implement a control can be represented with realization references from Initiatives, allowing the delivery of an initiative to be tracked, with a date field recording when a control’s deployment to an application becomes live. See Strategy to Execution Series [9] for more details about Initiative components and their role in the wider Strategy to Execution context.

The relationship between frameworks, policies, and controls will vary with differing circumstances. Whilst the metamodel shows possible Is Realized By references between all three elements, different circumstances will only call upon a subset of these. Four common situations are described below.

Figure 5 below shows the situation where a corporate policy (modeled as an Information Artifact) contains a requirement that is realized with the deployment of a control.

Figure 5: Policy-driven Controls

Figure 6 below shows the situation where a framework has been adopted and its requirement is realized by a deployed control. In this situation, there may not be a related corporate policy.

Figure 6: Framework-driven Controls

Figure 7 below illustrates the situation where a corporate policy requires the adoption of a framework, which in turn drives the implementation of a set of controls. Both the policy and the framework are modeled with Information Artifact components, each in corresponding workspaces (one representing corporate policies, the other adopted frameworks and standards).

Figure 7: Policy-driven Adoption of a Framework

There can also be circumstances where a requirement of a framework can be satisfied with the creation and adoption of a policy. This is illustrated in Figure 8 below.

Figure 8: Framework-driven adoption of a Policy

[1] International Organization for Standardization, “ISO 31000:2018,” ISO, Feb. 04, 2022. https://www.iso.org/standard/65694.html (accessed Aug. 21, 2023).

[2] “IRM’s risk management standard.” https://www.theirm.org/what-we-do/what-is-enterprise-risk-management/irms-risk-management-standard/ (accessed Aug. 21, 2023).

[3] Axelos, M_o_R® 4: Management of Risk: Creating and Protecting Value. PeopleCert International Ltd, 2022.

[4] “Framework Documents,” NIST, Feb. 2018, Accessed: Aug. 21, 2023. [Online]. Available: https://www.nist.gov/cyberframework/framework

[5] D. Wolman, “Before the Levees Break: A Plan to Save the Netherlands,” Dec. 22, 2008. http://www.wired.com/science/planetearth/magazine/17-01/ff_dutch_delta?currentPage=all (accessed Feb. 20, 2010).

[6] “Application Lifecycle Management | Ardoq Knowledge Base.” https://help.ardoq.com/en/collections/10362-application-lifecycle-management (accessed Aug. 21, 2023).

[7] Ardoq, “Ardoq Use Case Solutions Metamodel Version 1.4.” Aug. 2023.

[8] “Business & Technical Capability Management | Ardoq Knowledge Base.” https://help.ardoq.com/en/collections/10345-business-technical-capability-management (accessed Aug. 21, 2023).

[9] “Strategy to Execution Series | Ardoq Knowledge Base.” https://help.ardoq.com/en/collections/10374-strategy-to-execution-series (accessed Aug. 21, 2023).