This article demonstrates how organizations can leverage Ardoq to address the EU Digital Operational Resilience Act (DORA) regulatory requirements. Building on concepts from the Application Risk Management Solution, Ardoq provides a framework for addressing application risks through controls supported by Policies, Principles, Standards, and Frameworks. The guide explains how to model the relationships between DORA’s regulatory requirements and these existing structures within the enterprise architecture, ensuring that critical business capabilities and supporting applications are risk-assessed and resilient.
Ardoq offers a step-by-step approach (pattern) that can be tailored to different organizational needs, enabling companies to integrate DORA’s requirements into their existing processes effectively. The guide describes the process, detailing the key considerations and steps necessary to model DORA’s regulatory requirements in Ardoq successfully. The guide addresses how to implement DORA in Ardoq and will introduce the critical components of a soon-to-be-delivered governance, risk, and compliance solution that Ardoq will release in 2024.
This guide introduces Solutions that Ardoq is delivering as future solutions in 2024, including:
Governance, Risk, and Compliance.
Prerequisites
To effectively implement DORA in Ardoq, it is essential to have a solid understanding of several key concepts and practices. Understanding Ardoq’s Application Lifecycle Management and Business Capability Modeling solutions is crucial for overseeing your organization's development, deployment, and ongoing support of applications and capabilities. Business Capability Realization focuses on the practical implementation and achievement of business goals, while Organizational Patterns provide frameworks for structuring and managing enterprise components. For those looking to enhance their approach further, Application Risk Management offers optional insights into mitigating risks associated with critical applications. Together, these areas of expertise form a comprehensive toolkit for enabling success in delivering DORA in Ardoq.
High-Level Overview
The following is a high-level overview of the implementation process:
Modeling DORA Regulation Requirements
Model DORA requirements as a ‘Requirement’ component type in a Policies, Principles, Standards, and Frameworks workspace model. (The Application Risk Management Metamodel introduces this workspace)
ARDOQ provides an Excel template to assist with importing the regulation requirements.
Model DORA Requirements against existing frameworks, controls, and policies
In organizations that implement relevant policies, principles, standards, and frameworks, architects must establish the relationships between the DORA requirements and those frameworks or standards.
Conducting & Modelling Capability Assessments
Identify DORA Critical Capabilities
Conducting & Modelling Applications Assessments for DORA Critical Capabilities
Document and Conduct associated 3rd Party Vendor Assessments
Model DORA Regulation Processes:
Information Sharing
Incident Management
Components Involved
This section explains the components and workspaces used in a DORA implementation. Ardoq introduces and defines these components in the prerequisite solutions.
Capabilities, Information Artifacts, Risks, Applications, Controls, and Frameworks and policies are the main component types utilized to address the EU DORA regulation.
The solution utilizes assessments to which Capabilities, Applications, and Organizations can be subject. The Architecture Records Metamodel further explains how to use an assessment component. (In the form of an Information Artifact)
|
Primary Metamodel Components relevant to implementing DORA in Ardoq |
Information Artifact
Use Information Artifact components to represent the EU DORA regulation in the Regulation (or Policy, Principles, Standards, and Frameworks) Workspace. The Assessment Workspace also includes an Information Artifact component type for representation. Ardoq introduces the Assessment workspace and Assessment component types for Capability, Application, and Vendor, with suggested fields specific to the DORA regulation.
For assessments, create fields to track DORA Criticality and the potential financial data being processed. Use these fields to generate reports, copy them to the subject component, and identify further actions.
Category
Category components structure the DORA requirements in a hierarchy. This hierarchy can be of arbitrary depth, with the leaf nodes being the component type organized within it. For additional guidance, please see the How to Use Categories Guide.
Requirement
A requirement is a specific obligation that the organization must meet in addressing the DORA regulation. It may be part of a broader collection of requirements or characteristics that belong to an information artifact, such as a policy, set of principles, or a formal specification (e.g., NIST Cybersecurity Framework or ISO 25010 Quality Model).
Application
An application is the configuration of lower-level software or technology to provide specific business capability or technology capability, perform a defined task, or analyze particular information.
Business Capability
Ardoq defines a business capability as a logical activity or group of activities the organization performs. Unlike a business process, we define a business capability by grouping activities that access or utilize a shared resource (like customer information) rather than in response to a particular trigger or event.
Capability Instance (Business Capability Variant) applies to Business and Technical Capabilities. Instead of creating a new component type, use the existing Capability component type (business or technical) with a field to indicate Atomic or Instance. Use a brief naming convention and an instance workspace to suggest that the component is an instance. Please refer to the Patterns for Large Enterprise Guide for further guidance on implementing Capability instances.
Organization
An organization is the top-level component representing an organization. This component type represents the organization and other organizations that form part of its broader ecosystem, such as partners.
Guide to Implementing DORA
Start by Modeling the DORA Requirements
Model DORA requirements as a ‘Requirement’ component type in a Policies, Principles, Standards, and Frameworks workspace model. (The Application Risk Management Metamodel introduces this workspace). ARDOQ provides an Excel template to assist with importing the regulation requirements.
If the Policies, Principles, Standards, and Frameworks workspace exists, Create an information artifact representing the EU DORA regulation.
Create the regulations’ categories (subject areas) as children of the EU DORA Regulation.
Create all the regulation requirements as ‘Requirement’ component types for children of the relevant category.
|
The Diagram above shows the hierarchy of Information artifacts, Categories, and Requirements. |
Connecting DORA Requirements with existing Frameworks
This section outlines the steps for integrating the DORA regulation requirements into existing organizational standards, frameworks, and internal controls, including frameworks like ISO 27001, NIST 800-53, or ITIL.
Once you have the baseline requirements for the DORA regulation in Ardoq, you can link that to any existing standards or frameworks you have in place today. These frameworks could be like ISO 27001 NIST 80053 or other relevant frameworks, particular to your organization, that you've already implemented.
Create links and relationships between the individual DORA regulations and the specific parts of the different frameworks you've implemented that support the DORA regulation requirements. You can create reports demonstrating compliance and show your progress in addressing DORA regulation requirements through the standards, frameworks, and policies you have already implemented.
Suppose you implement internal controls and policies as part of your internal risk management or IT service management practices. In that case, those should also be linked directly to the regulation to address the concerns outlined in DORA.
Conduct a Business Capability Assessment
The steps below guide you through creating and configuring an assessment workspace in Ardoq, including setting up a ‘DORA Capability Assessment’ to evaluate individual business capabilities. The process includes setting up fields to capture relevant data, establishing relationships between regulatory requirements and the assessed capabilities, and using tools like surveys and scripts to manage and analyze the assessment results. The ultimate goal is to identify critical business capabilities, prioritize resources, and ensure ongoing compliance with DORA.
To conduct a risk assessment in Ardoq, create an assessment workspace. This workspace may be new and should include an information artifact and category component types. The Architecture Records Metamodel, scheduled for release in the second half of 2024, will provide further details about the Assessment Workspace.
First, use the information artifact component type to create a ‘DORA Capability Assessment’ to assess your capabilities individually.
Create fields relevant to your assessment criteria that align with the aspect of the DORA regulation you are evaluating. These fields can capture details such as DORA criticality, the type of financial information being processed, and other relevant artifacts.
Then, create child assessments in the Assessment Workspace for every capability you assess as a 1:1 relationship. For example, if you have a card payment capability, assess it annually to ensure ongoing compliance with the regulation. In 2024, you would create a 2024 card payments assessment. Create the necessary questions for a survey on the information artifact using fields.
Establish an ‘is realized by’ reference from the DORA Regulation Requirement to the assessment component type you created in step 2.
Establish an ‘is subject of’ reference from the individual DORA Assessment and the related business capability that ‘is subject of’ the assessment component type you created in step 2.
Manually enter the data or use the survey function to populate the field values on the capability assessment to assess each capability.
After assessing the capabilities, use the assessment result to assign a 'DORA Criticality' field value to the capability. You can create a Gremlin script to copy the field values from your assessment to the capability. This process helps identify individual business capabilities, allowing you to heat map and report where DORA criticality exists in your enterprise. As a result, you can focus your resources, energy, and time on examining those capabilities more closely.
Identify DORA Critical Applications
To ensure you're prioritizing effort, and resources managing the correct applications, you’ll want to understand which applications directly support financial capabilities. For DORA critical capabilities, you must assess all the supporting applications that enable those capabilities within the organization.
Create a ‘DORA Application Assessment’ as a 1:1 relationship for each application that realizes a DORA Critical Business Capability in the assessment workspace.
Create the relevant field values for DORA criticality for those applications in the DORA Application Assessment. For example, use list fields for DORA Capability Criticality, multi-select list for DORA Data Types, and an application's DORA Status to identify an application's DORA Status and the types of information that are stored or processed in the application.
Establish an ‘is subject of’ reference from the individual DORA Application Assessment and the related application that ‘is subject of’ the assessment component type you created in step 1.
Using the survey functionality, have application owners respond to surveys to complete the assessment fields. You can automate this to send out regularly through the broadcast functionality in Ardoq.
After collecting data from the application assessment, create a Gremlin script to copy the DORA Criticality field values to the application from the assessment component. This allows you to generate heat maps and report where DORA criticality exists in your application portfolio.
g.V(ids). project('id', 'name', 'APP Assessment Dora Criticality'). by(id). by('name'). by(__.in('Is Subject Of').hasLabel('Business Capability').values('Application Dora Criticality')) |
Use Ardoq’s reporting and visualization to identify the relevant applications and their integration into the rest of the enterprise architecture.
Once you've determined which applications are relevant or applicable to the DORA regulation, you can do a further risk assessment using the Ardoq Application Risk Management solution as a guide and implement controls on the necessary applications.
Document and Assess DORA Critical Vendors
Identify and document the support or vendor organizations that provide critical DORA applications. Use the organization component type to create these organizations within an "External Organizations" workspace. Add fields to capture all relevant DORA-specific information, such as address, business operation numbers, company numbers, contact information, and support details.
Identify the support/vendor organizations that provide the critical DORA applications to get started.
Create these organizations using the organization component type in an ‘External Organizations’ workspace.
Add additional fields to the organization in the workspace using the organization component type to capture all necessary DORA-specific information. Examples of these fields include address, business operation numbers, company numbers, contact information, support information, and more.
Conducting a DORA Vendor Assessment within Ardoq starts by creating individual assessments for each vendor and establishing necessary relationships between the evaluations and the organization component. Once you complete the process, use the collected data to facilitate reporting, create heat maps, and demonstrate compliance with the DORA regulation.
Create a ‘DORA Vendor Assessment’ as a 1:1 relationship for each Vendor that supports or provides DORA Critical Applications in the assessment workspace.
Create the relevant field values for DORA criticality for those Vendors in the DORA Vendor Assessment.
Establish an ‘is subject of’ reference from the individual DORA Vendor Assessment and the related organization component that ‘is subject of’ the assessment component type you created in step 1.
Using the survey functionality, have application owners or relevant third-party contacts respond to surveys to complete the assessment fields. You can automate this to send out regularly through the broadcast functionality in Ardoq.
After collecting data from the vendor assessment, create a Gremlin script to copy the DORA Criticality field values to the relevant organization component. This enables you to generate heat maps and report on which suppliers are connected to DORA critical applications and how effectively they support the requirements outlined by the DORA regulation.
Complimentary Activities
Document your Incident Management Process in Ardoq
Ardoq doesn't directly address incident management. However, you may already have an ITSM process for incident management and response. Ardoq can easily be used to manage your processes and model the processes relevant to your organization in this area.
Following the guidance provided in Ardoq’s soon-to-be-released business process management solution, you can create each process relevant to your organization to demonstrate to external auditors and other organizations how you realize your incident management process.
Ardoq's integration with CMDB and ITSM tools can extract critical events within your organization and create reports using field values to address individual applications. For examples of how to extract data in detail, see the How to use ServiceNow incidents in conjunction with Ardoq Solution component types article.
Using the data from your ITSM tool in combination with ARDOQ and your enterprise architecture model allows you to create reports and visualizations to understand the impact of major incidents.
For example, suppose a critical event occurs on application. In that case, you can leverage existing references to capabilities and the technology pieces that underpin that particular application to identify the outage's impact on the organization. This provides a 360-degree view of critical incident impact. These visualizations and Ardoq's ability to create reports and dashboards can assist in DORA’s reporting requirements.
Document Application Resilience Testing
Ardoq doesn't directly address application resilience testing or the production of a business continuity plan. However, you can easily manage the documentation for these efforts and create groups to report on the current status of the latest resilience tests and whether a business continuity plan exists for an application.
Expand Application component fields to include the following:
Resilience Testing Results
Testing Documentation Scope URL
Testing Documentation Results URL
Resilience Test Date
Business Continuity Plan URL - If Required
Business Continuity Plan Approval Date
Use broadcasts to notify application owners annually to review and conduct resilience tests and update the business continuity plan as necessary.
Information Sharing
DORA highlights the need to report internal and external information related to critical incidents, threats, and vulnerabilities.
External Incident Reports can be compiled in Ardoq and could include organizational impact and information relating to connected components' capabilities, applications, and vendors specific to the incident. Compile Reports and presentations to be shared with external regulators.
You can compile Internal Incident Reports in Ardoq, including organizational impact and details about the capabilities, applications, and vendors connected to the incident. Then, you can create reports and presentations to share with internal stakeholders.
Model internal and external information-sharing processes within your organization to demonstrate how your organization can share information or will share information as necessary demands.
Ardoq recommends tracking threats and vulnerabilities in other systems and summarizing them in Ardoq.