Attention: This article is part of the Application Risk beta program and this the associated use case is still under development. If you are interested in participating in the Application Risk beta test and you are an existing customer please contact your CSM.

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 risk registers with spreadsheets, and where there is a corporate risk tool in use, it is typically stand-alone, lacking information about the range of controls available, the technologies in use across the organization, or which business processes and organizational units depend on key applications.

The CIO is often bombarded with demands like:

Armed with Ardoq and the Application Risk Use Case, the Enterprise Architect can bring value to the CIO by addressing these questions while offering a joined up approach to IT Risk Management that will be of huge assistance to other corporate stakeholders, including the Information Security, Corporate Risk, Audit, Governance and Compliance teams.

Ardoq’s Application Risk Use Case enables you to describe the risks that impact your applications, quantify their effect on each application, and specify the controls that are, or will be put in place to produce a residual risk exposure that is acceptable. This document will explain the underlying concepts involved in this Use Case before articulating the unique combination of capabilities that Ardoq brings to Risk Management.

Risk has been defined as:

and

The consequences of a risk occurring and becoming an event can be devastating for a business. Risks may have existential consequences for an organization, or might lead to substantial business disruption or loss of reputation. The Institute of Risk Management identifies four main types of risk: Financial, Strategic, Operational and Hazard, and recognizes that specific risks of each of these types may have both external and internal drivers. The growth of digital business and the reliance of digital technology throughout a business mean that IT risks are typically a major component of corporate risk.

Risk Management consists of “coordinated activities to direct and control an organization with regard to risk” (source: ISO 31000 [1]). These activities seek to understand the range and level of risks facing an organization and reduce the likelihood of events and/or the consequences of their occurrence. Figure 1 below shows the four main steps of the overall risk management process as outlined in the M_o_R standard [3]. Ardoq’s ability to coordinate processes, target engagement to the right stakeholders, and automate workflows, is key to a successful IT Risk Management initiative. This Application Risk solution enables you to implement the key activities listed under each step.

Figure 1: The Risk Management Process

Following identification and assessment of risks, planning involves the identification of risk owners and actionees, and the development of a risk response for each threat. Responses typically fall into one of the following categories:

Reduction involves the application of controls:

Removal typically involves changing an aspect of the organizational activity. Transfer means that a third party takes on responsibility for an aspect of the risk (e.g. via the purchase of an insurance policy). Retention is the conscious and deliberate decision to retain the risk, for example having concluded that it is more economical to do this than implement a response. Risk sharing is common in procurement, where contracts with third parties include a form of risk sharing through the application of a pain/gain formula.

Risk Management as a discipline falls within the wider domain of corporate governance, some aspects of which are mandated by organizations and stakeholders that oversee or influence the environment in which the enterprise is operating (e.g. government departments and agencies, regulatory authorities, directors, shareholders, partners).

In many organizations, Risk Management is overseen by a central governance body, with responsibilities distributed across all parts of the organization. Corporate policies and regulatory requirements often mandate that specific controls are deployed to mitigate certain risks. International frameworks and standards, such as the NIST Cyber Security Framework [4], also provide guidance or instruction on the deployment of controls.

A risk management tool, typically part of a broader Governance, Risk and Compliance software package, is often used to support the cataloging, reporting, tracking and management of corporate risks. Such tools provide what is effectively knowledge management support to corporate risk teams. However, the use of spreadsheets to manage risks is not uncommon, and distribution of risk management responsibilities across organizational units often leads to variations in the application of tools, methods and practices that make coordinated oversight difficult. The result may be a set of activities that consume resources in the name of risk management, but fail to provide the right information that can lead to better decisions and the effective reduction in the likelihood or impact of risks.

Ardoq has a unique combination of capabilities that are able to make a valuable contribution to risk management.

This Use Case adopts the principles and processes of risk management outlined above and applies them to an organization’s application portfolio. Its scope is further defined by the following set of questions, grouped below by the four main steps of the risk management process:

Table 1: Use Case key questions

Figure 2 below shows the key components (Risks, Applications, Controls and Frameworks & Policy) 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 IT Risk Management (as articulated in “The value that Ardoq brings” above).

Figure 2: 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 in Table 1. 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 step shown in Figure 1.

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

These three values are on the same scale of 1.0 to 5.0 (i.e. the Risk Level is divided by 5 after following the above formula).

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

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 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 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 overall level of risk associated with that risk’s threat to the application. The result is the Residual Risk level which is stored alongside the original, unmitigated risk level.

A default measure of the effectiveness of a control is specified when the Control component is created, with a numeric value range of 0.0 to 5.0. This can be overridden when it is applied to different applications, representing the fact that a control may be more effective when applied to some applications than others. The override value is therefore stored on the reference that connects the Control to the Application.

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

Most risk management tools go no further than recording a single risk likelihood level for each identified risk. When it comes to Application risk, this is less than satisfactory. Whilst the likelihood of a risk occurring is primarily dependent on the nature of the risk itself, it may vary depending on the characteristics of the different applications that it threatens. For example, some operating systems may be more vulnerable to a risk than others. The use of an application by many customers, accessing it via the Internet, may increase the likelihood of some risks occurring compared with another application that is only accessed by staff via the Intranet.

To reflect this significant variation, the Use Case provides for the original risk likelihood, provided when the Risk component was first created, to be overridden with a different value in the context of each different Application component that it is linked to with an Impacts reference. This should be reviewed as part of the Assess process step outlined in Table 1 above, resulting in a separate risk likelihood value for each Risk/Application combination.

The business impact associated with a Risk is also recorded on a 1-5 scale. The product of the Impact and the Likelihood levels results in the overall Risk Level. As with Likelihood, the Impact (and therefore, also, the overall Level), is specific to the combination of a Risk and the Application that it potentially impacts. It is therefore recorded on the Impacts reference that connects the two.

Unlike Likelihood, which is mainly dependent on the nature of the risk, the Impact of a risk occurrence affecting an application is largely determined by the profile of the affected application. How many people rely on the application? What critical capabilities or business processes will be affected? Traditionally, the Risk Owner is asked to “guesstimate” the Impact level, based purely on their judgment. With this Use Case, we can use evidence contained within the knowledge graph to inform that judgment. Ardoq should already contain details of the number of users and business criticality of each application. So the Use Case uses this quantitative evidence to derive an estimate of the Impact level. How it creates an estimated impact value for every Application that has an incoming reference from a Risk is detailed below.

The Application component contains a list field User Base. In the Risk Impact calculation, this is converted to a number:

Table 3: User Base contribution to calculated Impact

The Application component contains a Criticality numeric field, expressed on a scale of 1 to 5, with 5 representing the highest level of business criticality.

The automated value for Impact is derived by calculating the average of the two numbers: User Base Number (from table 3 above) and Criticality. An application with a Criticality of 5 and a User Base of “50 - 200” will therefore have a calculated Impact level of 3.5.

The default calculation can be amended by changing the calculated field gremlin code. More factors can be added, provision has been made to weight the constituent factors in the average calculation, and the solution can be extended to apply to assets other than Applications, with different calculations being applied depending on the component type.

As with Risk Likelihood, the calculated Risk Impact value should be reviewed as part of the Assess process step outlined in Table 1 above, and can be overridden with a user-specified value, which might be required if the underlying contributory evidence is missing, or if the Risk Owner is aware of additional undocumented factors that would influence the impact level.

As indicated above, the overall Risk Level is a number of the scale of 1.0 to 5.0, being the product of Likelihood and Impact divided by 5. As both the Likelihood and Impact levels for a given risk may vary according to the impacted Application, the Risk Level is recorded in the Impacts reference that connects the Risk to each of its threatened Applications (alongside its constituent Likelihood and Impact levels). This overall Risk Level represents the exposure of the impacted Application without taking into account the mitigating effects of any deployed Controls.

In addition to storing a Risk Level on every Impacts reference that connects a Risk to an Application, the Use Case calculates a Residual Risk level alongside it. This calculated field represents the level of risk that remains after taking into account the mitigating effect of all the relevant controls that have been deployed to that Application.

A Control is only relevant to a risk if it has been deployed to the impacted Application and if it has a mitigating effect on the Risk in question (i.e. if the Control component has both a Deploys To reference to the Application component and a Mitigates reference to the Application’s connected Risk component). This field is regularly recalculated, so as new Controls are deployed to the Application, their mitigating effect will be taken into account and the Residual Risk level will reduce accordingly (or increase if Controls are removed).

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 do 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 control, 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).