All Collections
Ardoq Use Case Guides
Application Risk
Application Risk: Purpose, Scope, and Rationale
Application Risk: Purpose, Scope, and Rationale

Ardoq's Application Risk use case enables you to identify risks, assess risk levels, and understand the controls used to mitigate threats.

Jon Scott avatar
Written by Jon Scott
Updated over a week ago

Attention: Please note that the Application Risk beta program has concluded. We are currently refining the use case based on the feedback received. The Application Risk use case will be officially released within this quarter.

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:

  • “Please update your risk register and send us a copy” Corporate Risk Management

  • “The Board has approved a new policy. You must now implement the NIST Cybersecurity Framework” Corporate Governance

  • “Which applications can we apply this new 2FA control to?” Information Security

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.

Contents

Purpose and Value

What is Risk?

Risk has been defined as:

“The effect of uncertainty on objectives” (source: ISO 31000 [1])

and

“The combination of the probability of an event and its consequences”

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

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

  • Removal

  • Transfer

  • Retention

  • Share

Reduction involves the application of controls:

“Controls include any process, policy, device, practice, or other actions which modify risk.” (Source: ISO 31000)

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.

Tool Support for Risk Management

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.

The Value that Ardoq Brings

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

  • All-in-one view of applications risk and controls - Ardoqs underlying knowledge graph facilitates the modeling of the different elements that are involved in the risk management process and, crucially, the relationships that link them together. This is especially useful for managing IT risks, because an individual risk may impact many elements differently. For example, the likelihood of a risk occurring may vary by application depending on the technology in use, and its impact may vary depending on the business criticality of each application. Recording a single likelihood and impact value for this risk, in the manner supported by many risk management tools, will not adequately represent the nature of such a risk.

  • Ties application risk into the broader business context - Ardoq is used to create and sustain a data-driven enterprise architecture. The knowledge that has been collected provides a context in which risks and controls are defined. That context leads to better understanding, and can directly inform the data that is needed to describe risks and controls and their impact on applications. For example, Ardoq can automatically provide an initial estimated impact using the knowledge of an application’s business criticality and the size of its user base. The data in Ardoq’s knowledge graph is maintained, so any view of risks will be shown in a live context with the ability to show trends over time, such as the quantity and level of risks that are impacting the applications required to support a given business capability. The risks can, in turn, inform other architecture governance processes and decisions managed with Ardoq.

  • Routes right information to the right people - Ardoq can orchestrate the engagement of a wide community of stakeholders with automated governance processes. These can route information requests to the right people (such as risk, control, or application owners), trigger reviews based on time, or send reports and escalations to interested parties based on specified circumstances. It can present a user experience and interface appropriate to the role of the user, allowing all users to explore live data directly from presentations and dashboards.

  • Easily integrates with your other systems - Risks and controls can be synchronized with other systems, such as a corporate GRC package. For example, a risk register can be imported from an existing system or spreadsheet into Ardoq, which can then be used to connect risks and controls to people (such as owners and actionees), processes (such as risk reviews), information (such as policies and frameworks) and technology (such as applications) placing them in their wider context.

Scope and Rationale

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:

Step

Question

Identify

  • What are the set of risks that impact our application estate?

  • Who has overall ownership of each risk?

  • What controls do we have that can be deployed to address application risks?

  • Who owns these controls?

  • Which framework or policy requirements do they address?

Assess

  • Which applications are exposed to each risk, and to what extent?

  • Which applications are exposed to levels of risk above our risk tolerance threshold?

  • Can we understand the exposure to risk of the whole portfolio?

  • Which risks are most seriously impacting our most business critical applications?

  • Which organizational units bear the greatest burden of risk from the applications they use?

  • Which business or technical capabilities bear the greatest burden of risk from the applications they rely upon?

Plan

  • Who is responsible for taking action in response to each risk?

  • What actions will we take to manage the risks that impact each application?

  • How will the level of risk change after the proposed actions have been implemented?

  • What controls do we have, or plan to have, that can mitigate identified risks?

  • Which controls should be deployed to which applications?

  • To what extent will those controls have a mitigating effect on the risks to which individual applications are exposed?

  • Which frameworks or policies have we chosen to adopt that require the implementation of controls?

  • How have a framework’s or policy’s requirements been realized?

Implement

  • How are we progressing with the implementation of:

    • Frameworks?

    • Policies?

    • Controls?

  • By how much has our implementation of controls reduced risk levels over time (from different perspectives)?

Table 1: Use Case key questions

Roles and Components of Risk

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.

The Risk Component

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

Risk Level = Likelihood x Impact

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 Component

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.

The Control Component

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.

How to Estimate Risk Likelihood

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:

Likelihood

Descriptions

Probabilities

Frequencies

1

Almost certain not to happen

<20% chance

Never heard of in industry

2

Less likely to happen

20-40% chance

Expected once every five years

3

Equally likely/unlikely to happen

40-60% chance

Expected once every two years

4

More likely than not to happen

60-80% chance

Expected every year

5

Almost certain to happen

>80% chance

Expected multiple times a year

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.

How to Estimate Risk Impact

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:

User Base

Number

1

1

2 - 50

1

50 - 200

2

200 - 500

4

> 500

5

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.

How Controls Mitigate Risks

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.

Residual Risk = Overall Risk Level - the sum of all Effectiveness Levels for all relevant deployed Controls

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

The Frameworks and Policies Components

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

Modeling Controls in More Detail

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.

Four ways to represent Frameworks, Policies and Controls

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.

1 - Policy-driven Controls

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

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

3 - Policy-driven adoption of a Framework

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

4 - Framework-driven adoption of a Policy

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

Appendix

Sources

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

Version

Date

Author

Rationale

1.0

9/18/23

Simon Field

Published

Did this answer your question?