Compliance Assurance Metamodel (Frameworks Driven Pattern)
Compliance Assurance is a vital part of a comprehensive enterprise risk management program. Failure to adequately manage risk can lead to serious consequences threatening the enterprise's operations.
Armed with Ardoq’s Compliance Assurance Solution, the Enterprise Architect can support risk and compliance stakeholders in identifying and assessing compliance framework requirements that may help the organization's overall enterprise risk management program.
This is valuable information for the CIO, CISO, and other corporate stakeholders, including the Information Security, Risk, Audit, Governance, and Compliance teams, which need to manage risks, prioritize mitigation efforts, adhere to standards, and protect their company from threats.
This article discusses the components, references, and fields of the Compliance Assurance solution. It also suggests structuring data in Ardoq workspaces to maintain your risk register, control library, and other information about corporate risk frameworks, policies, etc.
To better understand the foundation for the method, please refer to theCompliance Assurance Purpose, Scope, and Rationale document.
Table Of Contents
Introduction to Compliance Assurance
This solution provides you with a simple yet practical implementation of a baseline compliance assurance metamodel that could link together with other Ardoq GRC solutions, such as Application Risk Management and interaction with regulations such as EU DORA.
The solution requires compliance stakeholders to model framework requirements in a separate workspace. At the same time, it uses survey functionality to create internal controls and risks that may relate to the framework period.
This way, compliance stakeholders can create a relationship between a requirement and internal control and understand how a control mitigates certain risks. Once this has occurred, compliance stakeholders will be able to understand the compliance completeness associated with a particular framework.
Compliance personnel can capture the relevant fields relating to Information Systems Management System (ISMS) implementation justification and other fields specific to a particular compliance framework on the requirement component types. This allows for reporting on the completeness of a respective framework.
The surveys mentioned above assist in the following:
Creation of new Framework Requirements, Risks & Controls
Determine the relevance of a framework requirement to the organization and the organization's ISMS.
Set the default values on Risks and beneficial Control Effects.
Create references between Requirements, Risks, and Controls. These references are important to understanding the compliance landscape as it relates to a given framework.
Apply controls that adjust levels of risk on the reference mitigates.
Compliance Assurance Solution Metamodel Overview
Full Compliance Assurance Metamodel
The Core components of Ardoq’s Compliance Solution are Framework Requirements, Risks, and Controls.
Requirement Component Type (Frameworks Workspace)
The Frameworks Workspace represents standards, policies, and frameworks that guide compliance efforts. Each Requirement component details specific requirements derived from frameworks (e.g., ISO 27001, NIST Cybersecurity Framework).
The Frameworks Workspace is composed of 3 component types:
Requirement Category - The Category component type is used to organize in a categorized hierarchy according to framework (NIST, SOC2, ISO27001, etc.). This may be of arbitrary depth, with the leaf nodes being of the component type that is organized in the hierarchy.
Information Artifact - In this context, the Information Artefact component type represents different security frameworks (ex. SOC2, ISO27001, CCM, NIST, etc). The Information Artefact in the context of a policy represents a policy you have within your organization.
Requirement - In this context, the Requirement component type represents the specific requirements from the framework (ex. EU DORA a requirement of A.5.1.1 - Policies for information security)
Key fields include:
ISMS Applicability Field: Captures whether a requirement is relevant to the organization’s ISMS, ensuring alignment with security objectives. (Checkbox)
ISMS Justification Field: Documents the rationale for including or excluding a requirement, aiding decision-making and audit preparation. (Text Field)
Is Implemented Field: Tracks whether the requirement has been addressed through specific controls or other measures. (Checkbox)
Requirements are linked to controls using references such as:
Realized By: Connects requirements to the controls that fulfill them.
Each Framework should be modeled in its own workspace. These workspaces can often reference each other, but depending on how you have implemented frameworks, controls, and policies within your organization, they primarily have a direct relationship to an internal control library. Modeling in this manner simplifies reporting and visualizations on a framework-by-framework basis.
Risks Workspace
The Risk Workspace serves as a central repository for all identified risks. Each Risk Component represents a circumstance or event that could negatively impact the organization.
The Risks Workspace is composed of 3 component types:
Risk Category
The Risk Category component is adapted from the generic Category Component, which organizes components in a categorized hierarchy. This may be of arbitrary depth, with the leaf nodes being of the component type that is organized in the hierarchy.
Risk
Risks represent a potential circumstance or event that adversely impacts or threatens continued business operations. Risk also needs to consider the likelihood of the potential circumstance or event occurring. For example, Unauthorized Access is a risk that can carry a likelihood of occurring and impact depending on what function it is impacting.
The Risks workspace and related components enable organizations to:
Categorize risks based on business impact (e.g., operational, strategic, or financial risks).
Assign ownership to ensure accountability and timely updates.
Calculate risk exposure using parameters like likelihood and impact.
Track changes to risks over time, ensuring alignment with the organization’s evolving priorities.
Although not part of the compliance assurance solution, these risks and controls can be linked to apps as defined in the App Risk Management Solution. This would be accomplished by linking risks and controls to applications using the reference types defined in the Application Risk Management use case, such as:
Impacts: Connect risks to the applications or systems they affect.
Mitigates: Identify controls that address specific risks.
In Compliance Assurance, the workspace populated with risks constitutes a risk register. Ardoq recommends that the relevant risk owner regularly review, maintain, and update the risk registers. This is automated through the broadcast functionality, where Ardoq suggests six-month reviews of risks and controls. Additionally, this is highlighted in the Application Risk Playbook. Deprecated risks that are no longer relevant to your business should be removed periodically, ensuring good data hygiene.
For example, risks associated with the Y2K bug in your risk register are no longer relevant and should be removed. This represents good data hygiene and ensures the risk register remains relevant to your organization.
Risk Fields
Several metadata fields are used to capture risk attributes to help better classify and understand what that risk is and how it impacts the organization. As mentioned, these are gathered either through risk owner surveys or control owner surveys and automatic calculations.
Field | Field Type | Description | Definition |
Risk Category
(on the Risk component) | List Field | Used to classify the type of risks |
|
Raw Likelihood
(on the Risk component) | Number Field
Scale 1.0-5.0 | The likelihood of a risk occurring is a numerical measure that is mainly dependent on the nature of each defined risk on a scale of 0-5.
| Collected through the risk survey to set a default, base likelihood value for the specific risk when applied to different components in the enterprise architecture.
|
Raw Impact
(on the Risk component) | Number Field
Scale 1.0-5.0 | Impact is the consequences of risk events if they are realized. Typically measured in a 0-5 scale. | Collected through a survey to set a default, base impact value for the specific risk when applied to different components in the enterprise architecture. |
Raw Exposure
(on the Risk component) | Calculated Number Field | A 1 to 25 calculated field, the product of Likelihood and Impact | Baseline level of risk |
Target Impact (on the Risk component) | Calculated Number Field | This field represents the optimal state of impact if all mitigating controls are implemented. | A calculated field that takes the Raw Impact score and adds related Control Impact Effect of each Control that has a Mitigates reference to the Risk |
Target Likelihood (on the Risk component) | Calculated Number Field | This field represents the optimal state of likelihood if all mitigating controls are put into place | A calculated field that takes the Likelihood score and adds the Likelihood Effect of each Control that has a Mitigates reference to the Risk |
Target Exposure (on the Risk component) | Calculated Number Field | The product of target impact and target likelihood represents an optimal level for the risk component if all mitigating controls are deployed. | This represents the optimal state of risk that can be achieved if all the relevant controls are deployed to components in the enterprise architecture. |
Risk Calculations
Risk Fields provide the input for the Risk Calculations.
Raw Exposure = Raw Likelihood X Raw Impact
Target Impact = Risk.Raw Impact Score & Control.Impact Effect
Target Likelihood = Risk.Raw Likelihood Score & Control.Likelihood Effect
Target Exposure = Target Likelihood X Target Impact
Risk Category
Many different types of risks can impact organizations. We use the risk category field to classify the various types of risks in the register. These categories are consistent with the categories outlined by the Institute of Risk Management.
Strategic | It is defined as the probability that an event will interfere with a company’s business model. A strategic risk undermines the value proposition which attracts customers and generates profits. |
Operational | Can be defined as the risks of loss arising from improper implementation of processes, external issues (weather problems, government regulations, political and environmental pressures, and so on), etc. Operational risks can be better understood as a type of risk due to inefficiencies in business operations carried out by an organization. |
Financial | Can be defined as the potential losses incurred when a firm uses a large amount of debt, it incurs a significant interest expense and obligation to repay principal that makes it more likely to have financial difficulties if its cash flows decline. |
Compliance & Regulatory | Can be defined as the financial, legal, reputational or business impact on an organization of any size or structure of not adhering to a set standards, laws or frameworks. |
Knowledge | Can be defined as the potential for losses related to knowledge and knowledge processes. This includes risks related to low quality knowledge, knowledge gaps and incorrect information that lead to poor strategy, decisions and actions.
|
Information Security | Information security risks are concerned with the breach of the confidentiality of a company’s or clients’ sensitive data. The violation of such data can be a huge risk for an organization, and it might not just cause financial losses but also result in loss of goodwill |
Raw Likelihood
The likelihood of a risk occurring is a numerical measure mainly dependent on the nature of each defined risk. When a risk owner, via the risk owner survey, adds a detailed description to a newly created Risk component, they should also provide an estimate of that Risk’s likelihood of occurring because it will be used to establish a baseline or raw likelihood value used in further assessing the risk towards applications, Capabilities, initiatives, services, or other enterprise architecture components.
This is recorded on a scale of 1 to 5, with 5 representing the most likely.
These are often defined 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-39% chance | Expected once every five years |
3 | Equally likely/unlikely to happen | 40-59% chance | Expected once every two years |
4 | More likely than not to happen | 60-79% 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 only record a single risk likelihood level for each identified risk.
Raw Impact
The expected harm or adverse effect due to exposure to the risk. Measures how bad things could get if a particular Risk materializes. We ask risk owners to define this through the Risk Owner survey, similar to risk likelihood.
Risk owners should initially consider how the risk could affect continued operations security and how an event related to the risk could impact cost, schedule, or technical performance objectives. However, impacts are not limited to these criteria.
As an initial recommendation for risk owners, consider a consistent approach like identifying impact assessment criteria that considers the following factors that affect the Raw Risk Impact:
Size: The estimated size and number of the applications, Capabilities, initiatives, services, or other enterprise architecture components that risks may impact. The more widespread the risk proliferates across the enterprise architecture, the more severe it will be.
Complexity: The complexity of the risk is likely to impact the raw risk impact.
Criticality: Where applicable, criticality is the importance of its application to continued business operations. A small risk can significantly affect an organization if it impacts critical applications, capabilities, initiatives, services, or other enterprise architecture components.
Raw Exposure
Raw Exposure (is commonly referred to as the risk level) is the combination of impact and likelihood.
Ardoq’s ‘Raw Exposure’ represents a raw unmitigated risk value, is a reasonably straightforward calculation that follows industry standards;
Raw Likelihood x Raw Impact = Raw Exposure
This returns a risk value in the 1.0 - 25.0 scale.
The calculated value of the raw exposure can then be categorized on heat maps. Raw exposure values above defined threshold values can be categorized as High and represented accordingly to provide a basis for prioritization.
Target Likelihood
Is a field that takes the Raw Likelihood score and adds the Likelihood Effect of each Control with a Mitigates reference to the Risk. This allows the risk owner to identify the optimal state if all the mitigation controls are deployed to the at-risk applications.
Target Impact
Is a field that takes the Raw Impact score and adds the Impact Effect of each Control with a Mitigates reference to the Risk. This allows the risk owner to identify the optimal state if all the mitigation controls are deployed to the at-risk applications.
Target Exposure
Is a field that takes the Target Likelihood score in combination with the Target Impact score and provides a value for the optimal state of exposure if all the mitigation controls are deployed to the applications at risk.
Control Component Type (Controls Workspace)
The Control Workspace contains all controls implemented to mitigate risks and ensure compliance with policies or frameworks. Each Control component captures detailed information about the control’s purpose and implementation status.
The Controls Workspace is composed of 2 component types:
Control Category
The Control Category component type is derived from the general category component type and is designed to organize elements in a categorized hierarchy. This hierarchy can have arbitrary depth, with the leaf nodes representing the component types arranged within it.
Control
In Ardoq, controls are represented as a set of methods that mitigate one or more risks and can be deployed to the risk in isolation as part of compliance assurance or to one or more components in the enterprise architecture. When a control mitigates a given risk, it reduces the overall risk associated with that risk’s threat to the components in the enterprise architecture. The residual risk level is stored alongside the original, unmitigated risk level on the risk component.
Organizations can:
Define controls that address specific risks, such as technical measures (e.g., encryption) or organizational measures (e.g., training programs).
Establish linkages between controls and associated risks using the Mitigates reference type.
Ensure clarity by specifying how each control is implemented (e.g., policies, technologies, or processes).
Monitor the effectiveness of controls in reducing risk exposure and achieving compliance objectives.
The Controls workspace includes structured fields to:
Track control deployment across the risk register.
Understand the mitigating effect a control has on risks.
Understand how controls are linked to framework requirements.
Record compliance status and identify gaps in control coverage.
Gremlin Code for Risk Calculations
This section contains the Gremlin code used to implement the Calculated Fields of the Risk components.
Calculated Raw Exposure
This contains the Gremlin code that calculates the baseline exposure associated with a given Risk Component:
g.V(ids)// Assuming the label for risks is 'Risk' .project('id','name','value'). by(id). by('name'). by(project('impact', 'likelihood') .by(coalesce(values('raw_impact'),constant(0))) .by(coalesce(values('raw_likelihood'),constant(0))) .math('impact * likelihood'))
|
Calculated Target Impact
This contains the Gremlin code that calculates the optimal impact if all mitigating controls are deployed:
def getEffect = { __.in('Mitigates').hasLabel('Control').values('impact_effect').sum() }
def getImpact = { values('raw_impact') }
g.V(ids). project('id', 'name', 'value'). by(id). by('name'). by(project('effect','impact'). by(coalesce(getEffect(), constant(0))). by(coalesce(getImpact(), constant(0))). math('effect + impact'))
|
Calculated Target Likelihood
This contains the Gremlin code that calculates the optimal likelihood if all mitigating controls are deployed:
def getEffect = { __.in('Mitigates').hasLabel('Control').values('likelihood_effect').sum() }
def getLikelihood = { values('raw_likelihood') }
g.V(ids). project('id', 'name', 'value'). by(id). by('name'). by(project('effect','likelihood'). by(coalesce(getEffect(), constant(0))). by(coalesce(getLikelihood(), constant(0))). math('effect + likelihood')) |
Calculated Target Exposure
This contains the Gremlin code that calculates the optimal exposure if all mitigating controls are deployed:
g.V(ids)// Assuming the label for risks is 'Risk' .project('id','name','value'). by(id). by('name'). by(project('target_impact', 'target_likelihood') .by(coalesce(values('target_impact'),constant(0))) .by(coalesce(values('target_likelihood'),constant(0))) .math('target_impact * target_likelihood')) |