Digital Operational Resilience Act (DORA) Extension to the Meta Model
Overview of fields, relations, and subtypes across application, IT component, business context, and provider fact sheets to support DORA compliance.
Introduction
The Digital Operational Resilience Act (DORA) is an EU regulation designed to ensure that financial institutions can effectively manage technology risks and remain resilient to disruptions in their information and communication technology (ICT) systems. DORA aims to enhance financial institutions' operational resilience by setting uniform guidelines for managing ICT risks, incident reporting, operational resilience testing, and third-party risk management.
With SAP LeanIX’s meta model extension, organizations can seamlessly integrate DORA regulatory requirements with enterprise architecture. You can create a regulatory dictionary, categorize DORA requirements, and link DORA obligations directly to specific IT and business architecture elements, making it easy to track and manage compliance. You can document scenario testing for resilience assessments, document the impacts, and evaluate vendor compliance. Additionally, during global incidents, you can conduct real-time impact assessment, ensuring that you can quickly respond to disruptions.
Activating DORA Meta Model Extension
Admins can activate the DORA extension in the administration area. Follow these steps:
- In the administration area, select Optional Features & Early Access under Advanced Settings.
- In the DIGITAL OPERATIONAL RESILIENCE ACT (DORA) section, click Activate
- Confirm your action by clicking Activate again in the resulting overlay.
Note
Once activated, it cannot be automatically rolled back. To revert the meta model extension, you have to manually remove the attributes from your meta model.
Activating DORA Meta Model Extension
Meta Model Extension
The meta model extension as part of the DORA extension includes the following:
Fields and Relations in Application and IT Component
Most of the DORA-related attributes are organized within a dedicated section called DORA (Digital Operational Resilience Act). These attributes are further grouped into subcategories to provide better structure and clarity.
Name & Description
In the ‘Name & Description’ subsection, the following field is added:
| Attribute Name | Type | Description |
|---|---|---|
| DORA Critical | Single Select | A binary field to indicate whether an application is considered critical for DORA compliance or not. |
Impact Assessment
The impact assessment consists of five attributes, each evaluated on a 4-point scale. Four of these attributes are used to document the impact assessment, while one attribute—impact classification—is automatically calculated based on the severity level selected in the other attributes:
| Attribute Name | Type | Description |
|---|---|---|
| Service Disruption | Single Select | Manual assessment of the potential disruption time in the event of service disruption. |
| Financial Impact | Single Select | Manual assessment of how high the financial impact would be in the event of an incident. |
| Reputational Damage | Single Select | Manual assessment of the potential damage to the organization's reputation in the event of an incident. |
| Regulatory Impact | Single Select | Manual assessment of potential regulatory sanctions in the event of data leaks. |
| Impact Classification | Single Select | Automatically calculated based on the severity level of the other attributes to show overall impact. |
Resilience Testing
This subsection groups attributes related to the resilience testing aspect of the DORA assessment:
| Attribute Name | Type | Description |
|---|---|---|
| Training & Awareness | Multi-Select | Available training delivery methods for the service regarding data classification, DORA, infosec, and related topics. |
| Test Date | Date Field | The date when resilience testing was last conducted for this application. |
| Confidentiality | Single Select | This field classifies the sensitivity of the information handled by the service. Ranging from public to highly confidential. |
| Integrity | Single Select | This field classifies the accuracy and consistency of data handled by the service. In the context of the CIA triad, ‘Integrity’ ensures that data is accurate, consistent, and protected from unauthorized modification throughout its lifecycle. |
| Availability | Single Select | Classifies the level of service availability during resilience testing, indicating how disruptions or failures affect the application's availability. |
| Scalability | Single Select | Indicates how well the application can adjust to varying load and usage levels. |
| Fault Tolerance | Single Select | The capability of a service to continue operating in the event of a fault or failure. |
| Robustness | Single Select | The ability of the service to maintain its functionality under stressed conditions, such as high load or temporary failure of its components. |
| Risk Types | Multi-Select | Potential types of risks associated with the application or IT component. |
| Cyber Security Measures | Multi-Select | Cybersecurity measures to address risks, including identity and access management policies. |
Relations
4 optional relations to capture dependencies and impacts of the affected application and IT component:
| Attribute Name | Type | Description |
|---|---|---|
| Recovery Plan Business Contexts | Many-to-many | A relation to the new fact sheet subtype 'Continuity Plan' of the business context fact sheet type. These are the recovery processes that can be executed based on the type of incident and are ideally maintained in SAP Signavio. |
| Affected Application | Many-to-many | Applications that are likely to be affected if this application is impacted. |
| Affected By Applications | Many-to-many | This application is likely to be affected if these applications are impacted. |
| Processing Location | Many-to-many | Relation to the subtype 'region' of the organization fact sheet type. This captures the region(s) where the application processes data. |
Fields and Relations in Business Context Fact Sheet
Additional Fact Sheet Subtypes
Two new subtypes are introduced to support DORA compliance tracking:
- Continuity Plan: This subtype groups continuity plans, like recovery strategies, crisis communication plans, and the like, that are in place to stay DORA compliant.
- Training & Awareness: This subtype groups trainings that helps the organization to remain DORA compliant.
They allow you to document which processes are critical for operational resilience (e.g., due to their sensitivity) and to track relevant business continuity strategies and training initiatives that help ensure ongoing DORA compliance.
Business Continuity Management
The following new fields and relations are introduced in the 'Business Continuity Management' subsection of the business context fact sheet:
| Attribute Name | Type | Description |
|---|---|---|
| DORA Critical | Single Select | A binary field to indicate whether the given process is considered critical for DORA compliance or not. |
| IT Disaster Recovery Plan | Single Select | 3-point scale status to track whether a disaster recovery plan has been developed. |
| IT Disaster Recovery Description | Text area | Description of the IT disaster recovery process. |
| Crisis Communication Plan | Single Select | 3-point scale status to track whether a crisis communication plan has been developed. |
| Crisis Communication Description | Text area | Description of the communication plan for crisis management. |
| Business Continuity Plan (BCP) | Single Select | 3-point scale status to track whether a business continuity plan has been developed. |
| Business Continuity Plan Description | Text area | Description of the business continuity plan detailing the processes and procedures to be followed in the event of a disruption or disaster. |
| Recovery Strategy | Single Select | 3-point scale status to track whether a recovery strategy has been developed. |
| Recovery Strategy Description | Text area | Description of the strategy and procedures for business continuity and disaster recovery. |
Relations
The following new relations are introduced in ‘Continuity Plans for Applications’ and 'Training Available For' subtypes of the business context fact sheet:
| Attribute Name | Type | Description |
|---|---|---|
| Continuity Plans for Applications | Many-to-many | This relation is conditional to—meaning only available in—the ‘Continuity Plans’ subtype of the business context fact sheet. It is used to track the specific applications to which this continuity plan applies. |
| Training Available For | Many-to-many | This relation is conditional to—meaning only available in—the ‘Training & Awareness’ subtype of the business context fact sheet. It is used to track all applications for which a specific training is relevant. A field on the relation tracks the last time the training was conducted. |
Fields and Relations in Provider Fact Sheet
Name & Description
In the ‘Name & Description’ subsection, the following fields are added:
| Attribute Name | Type | Description |
|---|---|---|
| DORA Critical | Single Select | A binary field to indicate whether the given provider is considered critical for DORA compliance or not. |
| ICT Provider Category | Single Select | Indicates whether the provider is internal or external. |
| Provider Type | Single Select | It classifies the type of provider based on the nature of services they offer, such as cloud service providers, software providers, risk management providers, among others. |
| Legal Entity Identifier | External ID | The Legal Entity Identifier (LEI) is an alphanumeric code based on the ISO 17442 standard. |
Criticality & Quality
This subsection groups attributes related to providers' criticality and quality in the context of the DORA assessment:
| Attribute Name | Type | Description |
|---|---|---|
| Financial Stability | Single Select | Indicates whether the vendor's financial health has been assessed to ensure they have the resources to deliver their services effectively and handle potential disruptions. |
| Integration Capabilities | Single Select | Indicates the evaluation of the vendor's ability to integrate their services with your existing enterprise architecture, including their use of standard protocols and APIs. |
| Reputation | Single Select | Indicates the assessment of the vendor's reputation in the market, including any past incidents, legal issues, or negative publicity. |
| Operational Resilience | Single Select | Indicates the assessment of the vendor's ability to maintain operations during disruptive incidents. This includes their business continuity plans, disaster recovery plans, and incident response plans. |
| Sourcing Risk | Single Select | Classifies sourcing risk from low to critical, indicating potential issues if a provider fails to meet obligations. Risks may arise from financial instability, regulatory issues, operational failures, or geopolitical factors—leading to disruptions, financial losses or reputational damage. |
| NPS | Integer Number | Net Promoter Score is a measure of customer satisfaction that ranges from -100 to 100, with a higher score indicating a more positive perception of the provider. |
| Exit Criteria | Single Select | Exit criteria refer to predefined conditions that, when met, mark the conclusion of a contract, project, or phase. They ensure both parties have a shared understanding of when and how an engagement should formally end. |
Contract Details
This subsection groups attributes related to the contract:
| Attribute Name | Type | Description |
|---|---|---|
| Contract Type | Single Select | Specifies the type of contract associated with the provider. |
| Currency | Single Select | The currency used in the contract details. |
| Renewal Status | Single Select | Indicates the status of the contract renewal process. |
| Duration (per Year) | Integer Number | The contract duration in years. |
| Payments Term | Single Select | Specifies the frequency of payment for the provider's services. |
| Cost (per Year) | Integer - Costs | The cost associated with the provider's contract details. |
| Service-Level Agreement | Single Select | An SLA is a contract between a service provider and a client that defines the expected quality and type of service. It includes measurable metrics—like system availability, response times, and performance—and outlines remedies if those standards aren’t met. |
| Service-Level Agreement Description | Text area | To summarize key items of the agreement. Tip: Add all additional resources for the SLA in the resource tab of this fact sheet. |
| Data Processing Agreement (DPA) | Single Select | A Data Processing Agreement (DPA) is a legally binding contract between a data controller and a data processor that outlines how personal data will be handled and protected. It ensures both parties comply with data protection laws and specifies responsibilities regarding data security, privacy, and breach notifications. |
| Data Processing Agreement Description | Text area | To summarize key items of the agreement. Tip: Add all additional resources for the DPA in the resource tab of the fact sheet. |
Updated about 7 hours ago