Regulatory Compliance is a vital part of a comprehensive enterprise risk and compliance strategy. Failure to adequately manage regulatory risk can lead to serious legal, financial, and reputational consequences, threatening the enterprise's operations and continuity.
Armed with Ardoq’s Regulatory Assurance Solution, the Enterprise Architect can support regulatory and risk stakeholders in identifying, modeling, and assessing requirements from regulatory frameworks such as EU DORA, EU AI Act, NIS2, CPS230, and the GLB Act.
This solution strengthens the organization’s ability to demonstrate adherence to regulatory mandates and respond effectively to audits and supervisory reviews.
This document outlines the components, relationships, and fields of the regulatory assurance solution. It also provides guidance for structuring data in Ardoq workspaces to maintain a regulation register, internal control library, and supporting artifacts.
To better understand the foundation for the method, please refer to the Compliance Assurance Purpose, Scope, and Rationale document.
Table Of Contents
Introduction to Regulatory Compliance
This solution enables organizations to implement a structured, evidence-based approach to managing obligations under legislative and industry regulatory bodies. These could include regulations like EU DORA (Digital Operational Resilience Act), EU AI Act, NIS2 Directive, CPS230 (Australia), and the GLB Act (U.S.).
Regulatory stakeholders model legislative and supervisory requirements in a dedicated workspace. Using Ardoq's survey capabilities, internal risks and controls are assessed and mapped to those regulatory requirements.
This mapping establishes a clear relationship between specific regulatory mandates and the internal controls to fulfill them. It enables stakeholders to:
Evaluate the coverage and completeness of each regulation
Provide traceability from obligations to mitigations
Prepare for audits or regulator-driven reviews with confidence
Each requirement record captures metadata, including justification for inclusion, applicability to the organization's risk environment, and implementation status, providing a holistic view of regulatory readiness.
By implementing this solution in Ardoq, organizations can:
Map internal controls and compliance frameworks to regulatory obligations
Monitor risk exposure related to regulatory failures
Generate audit-supporting reports
Demonstrate proactive regulatory assurance to boards, auditors, and regulators
The Purpose, Scope and Rationale of Ardoq’s Regulatory Compliance solution provides greater insight into how the Regulatory COmpliance solution builds on the Compliance Assurance Solution.
Regulatory Compliance Solution Metamodel Overview
The Regulatory Compliance Metamodel comprises three core entities:
Regulatory Requirements (from legislative and industry regulatory bodies)
Framework Requirements (from legislative and industry regulatory bodies)
Internal Controls (measures taken to ensure compliance), either internal or framework-driven
Compliance Assessments, (which are optional), based on the specific regulation enable the organization to demonstrate where the assessment of compliance has occurred across the estate.
These components are modeled in separate workspaces and connected through references, enabling visibility and reporting across individual regulatory domains.
Full Compliance Assurance Metamodel
Regulations Workspace (Per Regulation)
The Regulations Workspace represents external regulatory requirements that guide compliance efforts for a single regulation. Each Requirement component details specific requirements derived from a specific regulation.
Each regulatory requirement represents a specific clause or expectation defined in regulations, such as:
EU DORA
EU AI Act
NIS2 Directive
CPS230 (Australia)
GLB Act (U.S.)
The Regulations workspace is composed of 3 component types:
Requirement Category - The Category component type is used to organize in a categorized hierarchy according to a given regulation 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 Artifact component type represents different security regulations.
Requirement - In this context, the Requirement component type represents the specific requirements from the regulation (ex. EU DORA a requirement of A.5.1.1 - Policies for information security)
Key Fields:
Field | Field Type | Description | Definition |
Regulation Name
(on requirement) | Text Field | Used for reporting and filtering | The name of the relevant regulation. |
In Scope
(On requirement) | Check Box | Used to identify requirements that are or are not relevant to the organization. | The regulation requirement is either in scope or excluded and does not apply to the organization. |
Exclusion Justification
(on Requirement) | Text | Text-based reasoning to exclude the requirement for the organization | If the requirement is deemed out of scope, then this field is used to provide evidence for potential audits. |
Is Implemented
(on Requirement) | Check box | Has the requirement been fulfilled by implementing a Framework, Policy, or Control? | Used to filter requirements to demonstrate that it has been implemented. |
Implementation Date
On Requirement | Date | Used as a compliance check to show when the requirement was implemented. | Date field for when the requirement was implemented |
Last Review Date | Date | Used as a compliance check to show that the requirement has been reviewed. Can be used to schedule broadcasts to review requirements. | Date field for when the requirement was last reviewed |
Key References:
Realized By – Connects a Requirement to the framework requirement, control or assessments (optionally) that fulfill it.
Each Regulation should be modeled in its own workspace to simplify traceability and auditing. These workspaces may reference respective compliance frameworks, assessment components, or a shared internal control library.
Frameworks Workspace (Per Framework)
The Frameworks Workspace represents standards, policies, and frameworks that guide compliance efforts. Each Requirement component details specific requirements derived from a single framework.
A given framework’s 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.
As mentioned, 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. This facilitates more granular reporting and control over framework specific visualization.
For more information regarding this implementation, please refer to the How to Represent Policies, Principles, Standards, and Frameworks article.
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. This is consistent with the definition and implementation of Control in both the Compliance Assurance and Application Risk Management Solutions.
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:
Field Name | Type | Description | Definition |
Likelihood Effect
| Number | Negative Value -4 to 0 | Indicates this Control has an effect in reducing the likelihood of Risks that it mitigates. |
Impact Effect
| Number | Negative Value -4 to 0 | Indicates this Control has an effect in reducing the impact of Risks that it mitigates. |
Review Date | Date | The date the control was last reviewed | Each control should be reviewed on a regular cadence to ensure its relevance to the organization's control library. |
Approved | Checkbox | Validate that the Control is approved in the organization | Determined by the control owner to represent the validity of the control. |
Compliance Assessment Workspace (Optional)
This captures the results of an assessment determining whether a particular subject component complies with a specific requirement. The requirement might, for example, be a policy or regulatory requirement, such as DORA or GDPR compliance, or a collection of requirements that collectively describe a framework, such as an organization’s architecture guiding principles. If modeled in Ardoq, they may be associated with the Assessment component with the Refers To reference. The implementation is consistent with the guidance outlined in the Architecture Records guide, with fields specific to the type of assessment being carried out.
Fields
The following table lists the set of fields from which a selection can be made to populate a particular “architecture record” component type.
Field Name | Field Type | Definition |
Decision YesNo | List | The decision (a Yes or No). |
Decision Rationale | Text paragraph | A description of the rationale behind the decision and the desirable outcomes |
Review Date | Date Time | The date this component was last reviewed. |
Next Review Date | Date Time | A forward date when this component should next be reviewed. |
Decision Live | Date Range | A date range representing the period during which this decision applies/has currency. |
Decision Status | List | One of: Proposed, Rejected, Approved, Retired |
References
The following reference types are available for use with Architecture Records:
Has Subject - a reference used to point from the Architecture Record to the component or components that are the subject of the record (e.g., pointing from an Architecture Standard component to the Technology Product component that represents the proposed or approved standard);
Refers To - a reference type used to link the Architecture Record to any component that is not the “subject” of the Record but is associated with, or provides evidence for, the record (e.g., pointing to the quality characteristics that underpin an architecture decision record);