DORA & Power Platform Dataverse: technically secure your Microsoft CRM

DORA regulation: the fundamentals to remember

What is the DORA regulation?

DORA, or Digital Operational Resilience Act (Digital Operational Resilience Regulation), sets a common framework for the digital operational resilience of the financial sector. Adopted in December 2022 and applicable since January 17, 2025, it strengthens the ability of financial institutions and their service providers to endure and recover from the most serious computer incidents.

The scope is broad: banks, insurance companies, asset management companies, asset management companies, payment institutions, payment institutions, electronic money issuers, market infrastructures, investment service providers and all their critical third-party ICT service providers. If you manage information systems for clients in the financial sector, you are entering the scope, especially if you are a CIO or critical infrastructure manager.

Regulation (EU) 2022/2554 is based on five pillars:

Operational resilience: the backbone of DORA

Operational resilience refers to your ability to Prevent, detect, resist and recover quickly ICT incidents that threaten your critical activities.

In practice, DORA requires:

• real-time monitoring with proactive detection measures;
• an ability to quickly restore services with documented goals;
• regular testing of your continuity plans;
• complete traceability of all events.

Note that to be successful, the operational resilience of a computer system is a continuous process which requires a robust infrastructure and rigorous operation.

Why are IT service providers directly concerned?

DORA introduces the concept of critical third party ICT service provider. If you manage critical systems for clients in the financial sector, you become a link in their operational resilience chain.

Indeed, here, the principle of shared responsibility is central: your customer remains responsible for its compliance, but must demonstrate that its service providers respect resilience requirements.

Why is Microsoft Dataverse directly affected by DORA?

Dataverse, a critical platform for business operations

Microsoft Dataverse powers Dynamics 365 and Power Platform. In doing so, Dataverse centralizes your customer data, orchestrates your critical business processes and hosts automated workflows, in short, it is the technical basis of your corporate CRM.

More specifically, for a financial institution, Dataverse hosts both customer data, transaction history, onboarding processes, credit validation workflows, and contractual information.

That is why, If Dataverse falls, the entire operational chain stops.

DORA requirements translated into Dataverse challenges

The pillars of DORA involve concrete technical requirements in your Dataverse environment:

• Access and identity management : RBAC finely configured in Dataverse using a security by design approach, mandatory MFA via Entra ID, Risk-based Conditional Access.
• Incident management and classification : Centralized Dataverse audit logs, Application Insights for application monitoring, Azure Monitor for infrastructure monitoring.
• Business Continuity and Recovery : Granular backup strategy, backup environments with geo-redundant replication, regular recovery tests with defined RTO/RPO.
• Monitoring and detection : Performances monitored in real time, anomaly detection, exhaustive event logging.
• Resilience tests : Dataverse load tests, fault simulation, validation of disaster recovery plans.
• Secure lifecycle : Automated ALM pipelines, rigorous version management, control of production deployments.

Dataverse is not “DORA-ready” by default

Microsoft provides a robust cloud infrastructure with advanced security, monitoring, and high availability capabilities. The announced SLA is 99.9% for Dataverse, or around 8.76 hours of potential downtime per year. But these capabilities are not enabled or configured by default to meet the specific requirements of DORA, which imposes a much stricter approach in detection, reaction and recovery capacity.

This situation is explained by the model of shared responsibility in the cloud. Microsoft is responsible for physical infrastructure, data center security, and platform availability. You remain responsible for data security, identities, configurations, and access controls. It is precisely in this area that DORA compliance requirements come into play.

Concretely, a freshly provisioned Dataverse environment can present significant shortcomings depending on the configuration of your Azure tenant:

• MFA not always mandatory without security defaults or Conditional Access enabled
• Environments not segmented according to dev/test/prod best practices
• Log retention policy not configured to keep traces for as long as required
• Overly permissive access controls with widely distributed administrator roles
• No proactive monitoring by default to detect anomalies
• Workflows without robust error management and alert mechanisms

DORA compliance therefore requires significant technical tightening and expert configuration of your Dataverse environment.

Specific technical risks in a Dataverse environment

Access and identity management risks

Risks are multiple : too broad permissions granted out of convenience, absence of a strictly imposed MFA, poorly configured security roles that give access to sensitive data or even service accounts with administrator rights without real business justification.

In turn, these faults lead to Unauthorized access, data changes without traceability, the exfiltration of confidential information, or the escalation of privileges allowing an attacker to take control of the environment.

For example, an external consultant sets up your Dynamics 365 CRM with an administrator role. The mission is over, but no one is revoking their access. Six months later, this consultant is working for a competitor and maintains full access to your strategic business data.

The technical solution involves the establishment of a Granular RBAC with roles defined according to the principle of least privilege. Multi-factor authentication should be mandatory for all users through the activation of security defaults or Conditional Access policies in Entra ID. Finally, a regular and automated review of permissions ensures that no outdated access remains available for too long.

Workflow vulnerabilities and automations

Your critical business processes rely on Power Automate workflows and automations: validating credit applications, customer onboarding, complaint management, feeding reporting systems. The problem? These workflows can be fragile and fail “silently”.

Typical case: a bank automates mortgage validation in Dynamics 365. The workflow calls for an external scoring service. One day, this service changes its response format. The workflow fails without anyone noticing for three days, blocking all credit requests, until an unhappy customer escalates the problem.

The solution is through a continuous monitoring of workflows

with real-time dashboards showing the success rate and errors. Every automation must integrate error management with intelligent retry mechanisms, in addition to which automatic alerts must notify technical teams as soon as a critical workflow fails.

API performance and throttling risks

DORA requires the ability to maintain operations even in situations of intense stress.

Thus, Microsoft Dataverse imposes technical limitations on API calls to protect the platform and guarantee a fair quality of service. According to the official documentation, the standard limit is 6,000 requests per user in a sliding window of 5 minutes (variable depending on tenant, licenses and platform evolutions). Exceeding these limits triggers throttling: your requests are then rejected or slowed down, causing widespread slowdowns, critical operations failures and severe degradation of the user experience.

To avoid this scenario, you must optimize the architecture of your integrations : reduction in the number and complexity of requests, implementation of cache mechanisms to avoid repetitive calls, appropriate license sizing to increase quotas if necessary, and permanent monitoring of API quotas with alerts before exceeding them.

Lack of continuity and recovery strategy

A lot of organizations don't have a Tested Disaster Recovery Plan for Dataverse. Backups exist, but the actual recovery time is unknown because backup environments simply do not exist and of course the procedures are not documented either.

However, to comply with the DORA regulations, any organization must:

• Define its RTO (maximum time to put the service back online) and RPO (maximum acceptable age of lost data);
• prove through tests that it is in a position to meet these objectives.

The solution lies in the intersection of several paths, namely: a multi-level backup strategy with complete backups and incremental backups, the use of sandbox environments with geo-redundant replication, the conduct of regular tests.

Deficiencies in traceability and auditability

Without comprehensive traceability, you are blind. You can't neither demonstrate your compliance, nor effectively analyze an incident, nor detect anomalous behaviors before they cause damage.

The possible shortcomings are numerous:

• logs that don't capture critical events;
• lack of mechanisms for detecting anomalies in access patterns;
• no traceability of the progress of an incident (which compromises the compliance of all your EDM);
• logs kept for too short periods of time.

For example, a security incident is detected in your Dataverse environment. A table containing sensitive contract information has been changed in a suspicious manner. You start the investigation, but discover that the audit logs have not been set up to track changes on this specific table. Therefore, it is impossible to identify who made the changes, from which machine, at what precise moment and the investigation is at an impasse.

To overcome this problem, you must set up Dataverse auditing so as to be able to trace all relevant events on all critical entities. Let's look at all of this in more detail.

Technical approach to achieve DORA compliance on Dataverse

DORA technical diagnosis of your Dataverse environment

In concrete terms, according to our internal methodology, a comprehensive audit can cover more than 150 technical control points.

The first step to compliance is to complete a thorough technical audit of your current Dataverse configuration. This diagnosis reveals your invisible vulnerabilities and accurately quantifies your risk level.

The audit methodology covers all aspects of operational resilience: security and identity management, performance and robustness of workflows, resilience and recovery capabilities, completeness of monitoring and observability, maturity of your application life cycle.

Through this systematic analysis, you get a technical discrepancy report documenting all points of non-compliance with DORA requirements, accompanied by a risk matrix evaluating each vulnerability according to its criticality and its probability of occurrence. All that remains is to establish a roadmap to prioritize corrective actions in a logical order taking into account technical dependencies and business priorities.

Hardening and technical upgrading

Once the differences are identified, comes the technical remediation to transform your platform into a resilient infrastructure.

The approach is based on rigorous prioritization: actions are classified by criticality, the most urgent and most impacting projects are treated as a priority, and the implementation is done gradually in successive waves with validation at each stage.

• In Entra ID : MFA mandatory via security defaults or Conditional Access, risk-based policies, identity governance with periodic review.
• In Dataverse : RBAC as accurate as possible according to the least privilege, audit logs on critical entities, appropriate retention strategies, segmentation of dev/test/prod environments.
• In Azure : comprehensive monitoring with Azure Monitor and Application Insights, automatic alerts, multi-level backup strategy with geo-redundant replication, documented and tested recovery procedures.
• In Power Platform : strict workflow governance, automated deployment pipelines, rigorous version management.

Continuous monitoring and technical DORA run

DORA compliance is a permanent mode of operation which requires continuous monitoring and a rapid response capacity.

The continuous monitoring approach is based on real-time dashboards consolidating all the critical health indicators of your platform. Automatic alerts are triggered as soon as a threshold is exceeded or an anomaly is detected. Periodic reports document events, incidents, and changes in indicators. The indicators monitored cover all aspects of resilience: availability of each critical component, performance measured to detect degradations, API quotas monitored to anticipate overruns, correlated and analyzed security events, correlated and analyzed, incidents traced and documented.

Ideally, the organization of the run includes on-call duties to ensure a 24/7 response capacity on critical systems, as well as clearly defined escalation procedures so that each incident is handled with the appropriate level of expertise. Finally, it will also be necessary to constantly ensure that documentation is kept up to date.

‍

As you can see, achieving DORA compliance requires in-depth Microsoft expertise that most traditional compliance firms do not have. Indeed, it takes nothing less than mastering the intricacies of Dataverse, Entra ID, Azure, and Power Platform to diagnose vulnerabilities, implement hardening configurations, and establish a resilient operating mode.

Among the players capable of combining specialized technical expertise in the Microsoft ecosystem and understanding of DORA regulatory issues, Askware is distinguished by this combination. Thanks to our support on your long-term projects, you will be able to simultaneously meet the challenges of compliance, security, performance and return on investment.

Is your Dataverse environment really ready for DORA? Askware offers you an in-depth technical diagnosis to identify your vulnerabilities and establish your upgrade roadmap. Contact our Microsoft experts to technically secure your platform.