Understanding DORA: How Acsense Ensures Financial Sector Resilience

What does DORA require for identity infrastructure?

DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), became enforceable across the EU on January 17, 2025. It requires EU financial entities to run identity infrastructure as resilient ICT systems under Articles 7, 11, 24, and 25, with tested RTO and RPO, continuous risk management, and scenario-based resilience testing on demand.

DORA Enforcement Status in 2026

DORA is no longer a deadline. It is an active enforcement regime. The Digital Operational Resilience Act became applicable across the EU on January 17, 2025, and national competent authorities have been conducting supervisory dialogues, on-site inspections, and resilience test reviews ever since. For financial entities running Okta, Microsoft Entra ID, or both, the question has shifted from "are we ready for DORA?" to "can we prove our identity infrastructure meets DORA today, on demand, in the format an EU regulator expects?"

Most cannot. The regulation caught up. The tooling has not.

Sixteen months into enforcement, the picture is sharper than it was at go-live. Competent authorities are no longer asking whether financial entities have read the regulation. They are requesting incident reports, ICT risk management framework documentation, third-party register entries, and the outputs of the first round of resilience testing programs. The European Banking Authority published its ICT and security risk management guidelines as the operational baseline supervisors anchor on, and EIOPA and ESMA have followed with parallel guidance for insurance and capital markets.

Three patterns are emerging from the first inspection cycles. First, identity is being treated as critical ICT infrastructure, not as a security control. When supervisors ask which systems support critical or important functions under Article 8, identity providers consistently make the list, and the follow-up question is always the same: how do you test and prove the recoverability of those systems? Second, third-party ICT risk is in scope, and so is your IDP. Okta and Microsoft Entra ID fall under DORA's third-party ICT services regime, and the customer's ability to recover their tenant configuration is the half of the answer that sits with the financial entity. Third, annual point-in-time attestations no longer pass. Supervisors want to see how drift is detected between formal tests, not just the test report itself.

For financial services teams running Okta, Microsoft Entra ID, or both under one regulated entity, the gap between current tooling and current expectations is widening every quarter. The rest of this post walks through which DORA articles apply, how each maps to a specific Acsense capability, and what the evidence pack a national competent authority expects actually looks like.

Which DORA Articles Apply to Identity Infrastructure

DORA is structured into chapters covering ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Identity infrastructure is touched by ten of the regulation's articles, but four of them define the standard for what a financial entity must be able to prove.

Article 7 sets the baseline for the tools and systems themselves. Financial entities must use ICT systems, protocols, and tools that are appropriate to the magnitude of operations supporting their activities, reliable, equipped with sufficient capacity to handle peak loads and stress, technologically resilient, and able to securely process data and provide accurate and consistent outputs. Identity infrastructure must meet every one of those criteria, because every other critical ICT function authenticates through it.

Article 11 sets the standard for business continuity. It requires a documented ICT business continuity policy with defined RTO and RPO for critical or important functions, backed by tested recovery procedures. Identity is in scope by virtue of underpinning those functions.

Article 24 sets the scope of the testing program. Financial entities must run a digital operational resilience testing program that covers all ICT systems supporting critical or important functions, with testing performed at least annually by independent parties.

Article 25 defines what testing actually means. Vulnerability assessments, network security assessments, gap analyses, physical security reviews, and scenario-based testing. Significant entities also conduct Threat-Led Penetration Testing under Article 26 every three years.

Read together, these four articles require a financial entity to maintain an identity infrastructure that is appropriate and reliable (Article 7), has a documented business continuity policy with tested RTO and RPO (Article 11), and is exercised through a scenario-based resilience testing program (Articles 24 and 25). The standard is no longer "we use a major IDP, so identity is handled." The standard is "we can demonstrate, with evidence, that our tenant configurations, recovery procedures, and continuity controls meet the framework today." Read the regulation directly on EUR-Lex: Regulation (EU) 2022/2554 (DORA full text).

DORA Article-to-Capability Mapping Table

Below is the article-by-article view of how Acsense covers the specific DORA obligations that apply to Okta and Microsoft Entra ID. Use this table when scoping the controls a national competent authority will ask about during a supervisory dialogue.

DORA Article	What the Article Requires	Acsense Capability	Evidence Generated
Article 5 (Governance and organization)	Management body sets, approves, and oversees the ICT risk management framework, including identity controls.	Compliance & Assurance	Compliance Framework Scoring reports for board-level review, drift detection summaries, recoverability posture briefings
Article 6 (ICT risk management framework)	Comprehensive, documented framework with continuous risk monitoring across all ICT systems, including identity.	Compliance & Assurance + Configuration Management	Continuous risk posture against the DORA control set, configuration change history with actor attribution
Article 7 (ICT systems, protocols, and tools)	Identity ICT systems must be appropriate, reliable, resilient, with capacity for peak loads and accurate output integrity.	Backup & Recovery + Configuration Management	Immutable backup of Okta and Entra ID tenant state, point-in-time configuration snapshots, baseline alignment reports
Article 8 (Identification of critical functions)	Register and classify ICT systems supporting critical or important functions, including identity providers.	Configuration Management	Multi-tenant inventory across Okta and Entra ID, dependency-aware object mapping, critical function tagging
Article 9 (Protection and prevention)	Continuous monitoring and control of ICT system integrity, with automated detection of configuration anomalies.	Compliance & Assurance	Continuous Drift Detection logs (10 minutes or less), alert routing through Slack, Teams, SIEM, and email
Article 11 (Response and recovery)	Documented ICT business continuity policy with defined and tested RTO and RPO for identity infrastructure.	Disaster Recovery + Backup & Recovery	Tested ~10 minute RTO and RPO measurements, Hot Standby Tenant readiness, Continuous Resilience Validation runs
Article 13 (Reporting and review)	Reports on the testing program and post-incident reviews available to the competent authority on request.	Compliance & Assurance	Audit-ready evidence packs, historical configuration logs, Recoverability Health Reports, regulator-formatted submissions
Article 24 (General requirements for testing)	Annual testing program covering all ICT systems supporting critical or important functions, by independent parties.	Disaster Recovery	Continuous Resilience Validation drill outputs, recovery runbook validation evidence, test cadence records
Article 25 (Testing of ICT tools and systems)	Scenario-based testing, vulnerability assessments, gap analyses for ICT systems including identity.	Disaster Recovery + Compliance & Assurance	Scenario-based failover test results, configuration gap analyses, dependency-aware recovery validation
Article 28 (Third-party ICT risk)	Manage the ICT third-party risk associated with IDP providers under shared responsibility.	Backup & Recovery + Disaster Recovery	Tenant-side backup independent of IDP availability, cross-IDP recovery runbook, third-party register evidence

Three points jump out of the table. The first is that evidence is continuous, not periodic. The compliance baseline reflects the live state of Okta and Entra ID configurations at any moment, not a quarterly screenshot. The second is that recovery is tested, not assumed. Continuous Resilience Validation runs recovery drills automatically and produces the auditable evidence that DORA Articles 11, 24, and 25 require. The third is that both Okta and Microsoft Entra ID sit under one baseline, so the financial entity does not need to stitch evidence from two platforms into one DORA submission. The IDP-agnostic architecture extends to additional providers as financial entities consolidate or expand.

Detect, Enforce, Prove: How Acsense Operates Against DORA

Not evidence collection. Enforcement. The standard DORA sets is operational, not paperwork. Acsense Compliance & Assurance and Configuration Management detect both accidental and adversarial misconfigurations, the drift that creates supervisory findings, and the drift that creates incidents, before either becomes a problem. The platform operates against DORA through three connected capabilities.

Detect: Configuration Drift in 10 Minutes or Less

Incremental synchronization monitors Okta and Entra ID configurations and detects when they move out of alignment with the approved DORA-mapped baseline in as little as 10 minutes. When Conditional Access policies weaken, admin privileges expand, OAuth apps appear, MFA enforcement scopes shift, or service principal permissions change, alerts fire through Slack, Teams, SIEM, and email. This is the cadence DORA's continuous risk management language anchors on. Nobody else in cloud IAM detects drift this fast.

Enforce: Baseline Capture and One-Click Rollback

Detection without enforcement is just monitoring. Configuration Management captures the approved baseline and gives the IAM team one-click rollback to the last known-good state when drift is detected. Acsense restores configurations to approved compliant states, rolling policies back to prior versions, killing unauthorized OAuth registrations, reverting privilege escalations. Other tools document. Acsense enforces. This is the capability that turns continuous monitoring into a continuous compliance control under Article 6, and moves the financial entity toward fully autonomous identity governance.

Prove: Article-Mapped Evidence on Demand

Compliance & Assurance maps live configuration state against DORA Articles 5, 6, 7, 9, 11, and 13 in real time, and against SOC 2, ISO 27001, NIST SP 800-53, HIPAA, GDPR, NIS2, and APRA CPS 230/234 alongside. Automated compliance scores, historical configuration logs, and audit-ready evidence reports replace weeks of manual spreadsheet collection before every supervisory dialogue. Not threat indicators. Not security scores. The actual controls a national competent authority assesses, mapped to the configurations running in production right now.

The Five Questions DORA Inspectors Are Asking About Identity

These are the five questions financial entities must be able to answer, on demand, when a national competent authority opens a DORA file on identity infrastructure. Each maps to a specific platform capability.

1. Can you recover your IAM system if it breaks, and can you prove it before a crisis? Article 11 expects a tested recovery procedure, not an untested plan. Supervisors want evidence of completed recovery exercises, not a runbook in a folder.
2. How fast can you restore working authentication to meet your RTO and RPO commitments? If you cannot demonstrate the actual recovery time of your identity infrastructure under controlled conditions, your stated RTO is an assumption.
3. What exactly changed in your identity environment, when, and by whom? Article 6 expects continuous risk management. That requires a complete configuration change history with actor attribution, not a 90-day system log retention window.
4. Are your IAM configurations continuously aligned to your DORA control set? Periodic attestations cannot detect drift between tests. Article 9 expects continuous monitoring. The first question after any inspection finding is "when did this drift start?"
5. Can you prove DORA compliance posture and recovery readiness to a regulator on demand? Article 13 requires reports on the testing program and post-incident reviews to be available to the competent authority. Manual evidence collection over weeks does not meet the spirit of the regulation.

Most financial entities can answer one or two of these. The honest answer to the rest is "we are working on it." That gap is what an active inspection cycle exposes.

DORA Audit Readiness Checklist for Identity

This checklist is the action spine for any financial entity preparing for or responding to DORA supervision on identity infrastructure. The Quick Wins close the gaps that surface first. The Core Program builds the evidence engine. The Advanced track operationalizes continuous resilience against the testing program lifecycle.

How Acsense Closes the DORA Identity Gap

Periodic testing assumes the identity environment stays stable between exercises. It does not. Conditional Access policies change. App registrations come and go. Service principals proliferate. AI agent bindings appear weekly. The bank that passed its last annual test can fail Article 7 expectations within a quarter and have no way to detect it before a supervisor does.

Acsense closes this gap by treating IAM as continuous infrastructure with continuous evidence. The IAM Resilience Platform protects Okta and Entra ID tenant state continuously, manages every configuration change with full audit trails, recovers identity infrastructure within tested ~10 minute RTO and RPO targets, and validates the live state against DORA controls in real time. The result is one compliance baseline, one recovery runbook, and one evidence pack that meets supervisor expectations across both identity providers, with the architecture built to extend to additional IDPs as financial entities consolidate or expand.

Four things separate Acsense from every other approach to DORA identity compliance. Drift detection in 10 minutes or less. Tested recovery readiness with auditable proof. Direct mapping to the DORA control set rather than to threat indicators or security scores. Coverage of Okta and Microsoft Entra ID under one baseline, with the architecture built to extend to more.

Supervisors will not wait for the next annual test. Configurations will not stay still. Audit-ready evidence cannot be assembled retroactively. DORA expects a financial entity to operate with continuous evidence of identity resilience, and Acsense is the platform that delivers it.

---

Frequently Asked Questions

What does DORA require for identity systems?

DORA requires EU financial entities to manage identity infrastructure as part of their ICT risk management framework. Under Article 7, identity systems must use appropriate, reliable, and resilient ICT tools that minimize risk and support continuity. Articles 11, 24, and 25 add business continuity obligations, scenario-based resilience testing, and Threat-Led Penetration Testing for significant entities. Identity is in scope because authentication is the access layer for every other critical ICT function.

When did DORA become enforceable?

DORA (Regulation (EU) 2022/2554) became enforceable on January 17, 2025. It applies directly across all EU member states without national transposition. National competent authorities, coordinated by the European Supervisory Authorities (EBA, ESMA, EIOPA), are conducting active supervision and inspections. Financial entities, ICT third-party providers, and critical service providers are all in scope.

How does Acsense map to DORA Article 7?

Acsense maps to DORA Article 7 through three platform capabilities. Configuration Management gives every Okta and Microsoft Entra ID change a full audit trail. Disaster Recovery delivers a tested ~10 minute RTO and ~10 minute RPO for identity infrastructure. Compliance & Assurance detects configuration drift in 10 minutes or less and produces audit-ready evidence mapped to the specific DORA controls regulators assess.

What is the DORA ICT business continuity testing requirement?

Articles 24 and 25 require financial entities to run a digital operational resilience testing program at least annually, with scenario-based testing of all ICT systems supporting critical or important functions. Identity systems are in scope because they underpin every critical function. Significant entities must also conduct Threat-Led Penetration Testing every three years. Test results, gaps, and remediation evidence must be provided to the competent authority on request.

Do my Okta and Microsoft Entra ID configurations need to be tested separately for DORA?

No. DORA evaluates whether the financial entity can recover and prove resilience for the identity infrastructure as a whole, regardless of how many providers sit underneath. Acsense delivers a single compliance baseline across both Okta and Microsoft Entra ID, so one tested recovery runbook, one drift detection threshold, and one set of audit evidence covers both IDPs under one DORA submission.

What are the penalties for DORA non-compliance?

DORA penalties are set by national competent authorities and can include administrative fines, public statements identifying the entity, cease-and-desist orders, and personal liability for senior management. For ICT third-party providers designated as critical, the European Supervisory Authorities can impose periodic penalty payments. Beyond fines, supervisory findings typically trigger formal remediation plans with strict deadlines and follow-up inspections.

How does Acsense enforce DORA Article 7 baselines in real time?

Acsense Compliance & Assurance captures the approved Okta and Entra ID configuration baseline and detects every deviation from it in 10 minutes or less, with full actor attribution and a remediation path back to compliance. Configuration Management supports one-click rollback to the last known-good state, while Disaster Recovery validates ~10 minute RTO and RPO continuously. Other tools document. Acsense enforces.