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

Ardoq’s approach to App Risk enables you to document how risks impact your applications and what controls that are in place to mitigate them

Simon Field avatar
Written by Simon Field
Updated over a week ago


What is Risk?

Risk is defined as:

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


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

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.

Purpose and Value

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 Value of Focusing on Application Risk Management

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

  • COO and CIO

  • Head of Risk and Compliance

  • Risk Owners and Control Owners

  • Application Owners and other roles that are accountable for applications

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.






  • Understand what the key risks in the enterprise application portfolio are

  • Minimize risks to the delivery of continued operations

  • Highlight areas that have the highest risk to continuous business operations

  • Identify the greatest areas of exposure

Risk and Compliance

  • Oversee the organization's risk management process

  • Reduce the overall level of risk in the enterprise to minimize the impact of risk events

  • Identify all the relevant risks associated with the application portfolio

  • Categorize risks as they relate to the application portfolio

  • Highlight where risks are above thresholds

  • Plan to reduce risk to acceptable levels

  • Produce an up-to-date risk register of risks that relate to applications

  • Highlight high-risk applications

  • Understand actions undertaken or to be taken to reduce overall application risk

Risk and Control Owners

  • Create a risk library for all risks relating to the application portfolio

  • Oversee and manage a control library that addresses the identified risks

  • Implement controls based on various policies and frameworks

  • Support the technical side of the organization's risk management practice

  • Implement relevant control frameworks like DORA, ISO, NIST, etc.

  • Report on areas of compliance and non-compliance

  • All relevant risks are entered into a risk register (library)

  • Relevant controls are known to the business

  • Controls are matched to the risks

  • Risks are communicated to relevant application owners to plan the deployment of controls

Application Owners

  • Understand which applications have the highest risk levels above threshold and put plans in place to address those risks and bring them to an acceptable level

  • Quantify the acceptable level of risk for each managed application

  • Reduce the overall level of risk to the managed applications through the implementation of relevant controls

  • Provide data on each application

  • Plan and implement relevant controls to bring risk to tolerable levels

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

The Value of Doing Application Risk Management With Ardoq

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.

Knowledge Graph

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

Data-driven enterprise architecture

  • Identifying which risks and controls are defined.

  • Describe risks and controls and their impact on applications.

  • Triggering processes automatically when circumstances change. For example, asking owners of impacted applications to react to the identification of newly discovered risks and respond with a treatment plan, such as implementing mitigating controls.


  • Each enterprise has a different approach to Application Risk Management. Use Ardoq’s approach for immediate time-to-value or adapt it to the way your company handles application risk. The application risk approach can also be applied to other areas, such as processes, information, products, and initiatives. By replacing the Application component with that of another type, risk can be evaluated with minimal refactoring.

Up-to-date information for decision making

  • Integrations to maintain up-to-date information from external information sources Risks and controls can be synchronized with other systems, such as a corporate GRC package.

  • Surveys and Broadcasts to get information from the people with the most up-to-date knowledge with the least effort

  • Data quality dashboards and policies automatically trigger relevant stakeholders when information needs to be updated

Ownership and Accountability

  • All information types - risks, controls, applications - have owners who are responsible for maintaining and updating information. These people are automatically notified to update information as data changes or as time triggers are met.

Scope and Rationale

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?

Questions to be answered using Application Risk Management


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


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


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


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

  • How are we progressing with the implementation of frameworks, policies, and controls?

Roles and Components of Risk

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 (Risk) Exposure = Raw Likelihood x Raw Impact

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:

  • Financial

  • Strategic

  • Operational

  • Hazard

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.

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






Almost certain not to happen

<20% chance

Never heard of in industry


Less likely to happen

20-40% chance

Expected once every five years


Equally likely/unlikely to happen

40-60% chance

Expected once every two years


More likely than not to happen

60-80% chance

Expected every year


Almost certain to happen

>80% chance

Expected multiple times a year

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.

Estimating Risk Impact

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.




Almost certain not to happen


Less likely to happen


Equally likely/unlikely to happen


More likely than not to happen


Almost certain to happen

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 and the Risk Table

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

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

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


[1] International Organization for Standardization, “ISO 31000:2018,” ISO, Feb. 04, 2022. (accessed Aug. 21, 2023).

[2] “IRM’s 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:

[5] D. Wolman, “Before the Levees Break: A Plan to Save the Netherlands,” Dec. 22, 2008. (accessed Feb. 20, 2010).

[6] “Application Lifecycle Management | Ardoq Knowledge Base.” (accessed Aug. 21, 2023).

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

[8] “Business & Technical Capability Management | Ardoq Knowledge Base.” (accessed Aug. 21, 2023).

[9] “Strategy to Execution Series | Ardoq Knowledge Base.” (accessed Aug. 21, 2023).







Simon Field


Did this answer your question?