How Continuous Control Assurance (CCA) Supports DORA
DigitalXForce wrote this page.
Continuous Control Assurance (CCA) supports DORA by testing the controls in a financial entity’s ICT risk management framework against live evidence, so the entity can show its supervisor how each control performed over time. DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), has applied since 17 January 2025 to 20 types of EU financial entities. It requires an ICT risk management framework, incident management and reporting, resilience testing and control of ICT third-party risk. DigitalXForce tests the controls, keeps the evidence, classifies incidents and builds the register of information, and the entity keeps every filing with its regulator.
What DORA changes is the standard of proof. The same rules now apply across the EU, third-party arrangements are recorded in a register of information kept in standard templates, and major ICT-related incidents are reported to the competent authority. The work that grows is evidence.
What does DORA require of financial entities?
ESMA summarizes DORA in 5 areas. The obligations sit in the regulation itself, in technical standards and delegated regulations, and in supervisory guidance, and the European Supervisory Authorities list each instrument on their DORA pages.
ICT risk management
DORA sets principles and requirements for an ICT risk management framework. Regulatory technical standards under Articles 15 and 16 fill in the detail, including a simplified framework for the entities that qualify for it.
ICT-related incidents
Entities manage ICT-related incidents and classify them against criteria set in technical standards under Article 18(3). Major incidents are reported to the competent authority, and the standard forms and procedures under Article 20 cover that reporting and the notification of significant cyber threats. The ESAs published their 2025 report on major ICT-related incidents on 3 June 2026.
Digital operational resilience testing
Entities run a digital operational resilience testing program that covers a range of tests, including advanced testing.
ICT third-party risk
Entities manage the risk that comes from their ICT third-party service providers and put key provisions into their contracts. They keep a register of information in the standard templates set under Article 28(9). Technical standards under Article 28(10) set out the contract policy for ICT services that support critical or important functions.
What goes into the register of information?
The register lists every contractual arrangement the financial entity has for ICT services, at entity level and at sub-consolidated and consolidated level. For each arrangement it records the ICT third-party service provider, the functions of the entity the service supports and whether each is critical or important, where the service is provided and the data is kept, the subcontractors in the chain, and the contract’s dates and termination terms. The implementing technical standards under Article 28(9) set the templates.
Oversight of critical ICT providers
The ESAs oversee the ICT third-party providers designated as critical for the financial sector, to address the systemic and concentration risk that comes from relying on a small number of providers. That oversight falls on the providers. It matters to a financial entity because some of its own providers may be among them.
On 31 July 2026 the ESAs issued a statement on a consistent, risk-based approach to ICT risks from frontier AI models. The rules for AI systems themselves sit in the EU AI Act.
How does Continuous Control Assurance (CCA) support DORA?
Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. Continuous Control Monitoring (CCM) monitors conditions, evidence and signals associated with controls. CCM is a capability within CCA. Under DORA, CCM watches the evidence behind each ICT control, and CCA decides whether the control still works and keeps the result for the supervisor.
DORA asks for an ICT risk management framework that works in practice, and regulatory technical standards under Articles 15 and 16 fill in its detail. A dated test result for each control shows a supervisor how that framework performed over time. The same results reach DORA’s other areas as well: a failed control reaches X-ROC, where it is alerted, triaged, escalated and reported, and a material change in an ICT provider’s posture triggers a reassessment of that provider.
The table shows example controls, how DigitalXForce reads the evidence for each and how often. The frequencies come from DigitalXForce’s example evidence plan, and each organization sets its own, since each control is tested on a schedule set by how quickly its evidence can change.
| DORA area | What is tested | How DigitalXForce reads the evidence | How often, in the example plan |
|---|---|---|---|
| ICT risk management | Multi-factor authentication is enforced. | The platform reads MFA status from the identity tool that enforces it. | It is read daily. |
| ICT risk management | Privileged accounts are known and limited. | The platform reads the privileged account inventory from the identity tools. | It is read daily. |
| ICT risk management | Access rights are reviewed. | The platform reads the access review logs from the identity tools. | They are read weekly. |
| ICT risk management | Data is encrypted. | The platform reads encryption status from the systems that enforce it. | It is read continuously. |
| ICT risk management | Backups are made and verified. | The platform reads the backup verification results. | They are read daily. |
| ICT risk management | Systems are configured to the organization’s standard. | ESRPM runs configuration checks across network security, cloud and identity tools. | Configuration hygiene is read continuously. |
| ICT risk management | Software is patched, and critical vulnerabilities are fixed. | Patch currency and critical CVE status come from scanners such as Qualys and Tenable. | They are read daily. |
| ICT risk management | Logs are kept and reach the SIEM. | The platform checks log retention and the health of the SIEM feed. | They are read hourly. |
| ICT third-party risk | A critical ICT provider keeps its controls in place. | External Risk View watches each provider from outside, and a critical provider can share connector evidence from its own systems with its logged consent. | A material change in its posture triggers a reassessment. |
A test result does not approve the framework, set risk tolerance or decide which functions are critical or important, and the entity’s leadership keeps those decisions. Advanced resilience testing still needs qualified testers, and the entity files every report with its competent authority.
What DigitalXForce does for DORA
DigitalXForce reads evidence through 250+ technology integrations across cloud, identity, endpoint, SIEM, vulnerability management, ITSM and enterprise applications. Each piece of evidence tests a control from a normalized control library, and each control is mapped once to every requirement it satisfies across 50+ compliance frameworks, DORA among them. The X-BCOR module brings DORA’s resilience requirements into the same control and evidence model as everything else, so an entity that also reports on ISO/IEC 27001 or NIS2 does not collect the same evidence twice.
For the ICT risk management framework, each control is tested on its own schedule, and every result is kept with the evidence it read and a timestamp. A failed test becomes a finding that raises the related risk in the enterprise risk register, which holds inherent and residual risk, likelihood, impact and treatment. AI JedAI scores and prioritizes that risk, and X-SPM, Extended Security Posture Management, rolls the results into posture by domain. Attack Surface Manager keeps the inventory of ICT assets current without agents.
For incidents, X-ROC, the XForce Risk Operations Center, is the operations layer of the DigitalXForce TRiSCM platform, where control failures, risk changes and vendor events are alerted, triaged, escalated and reported. The incident team starts from the control history behind the event. DigitalXForce also classifies each ICT-related incident against DORA’s classification criteria, and the report to the competent authority stays with the entity.
For resilience testing, X-BCOR runs scenario-based resilience planning and ties continuity and recovery plans to live control coverage. Vulnerability findings arrive from scanners such as Qualys and Tenable. Each finding is worked and retested like any other failed control.
For ICT third-party risk, the third-party risk management module runs the supplier lifecycle in 6 stages: intake and screening, due diligence and tiering, onboarding, continuous monitoring with fourth-party visibility, issue management, and offboarding or recertification. It places each supplier in Tier 1 Critical, Tier 2 High or Tier 3 Commodity. Critical suppliers can share connector evidence from their own systems under the customer’s right-to-audit clause and with the supplier’s logged consent. Connectors read configuration and compliance signals only, never business records or customer data. AI JedAI reads each supplier’s SOC 2 and ISO reports, maps them to the entity’s controls and flags the gaps for an analyst to approve.
External Risk View watches each supplier from outside and maps fourth-party and nth-party dependencies. A material change in a supplier’s posture triggers a reassessment. When a supplier reports a breach, AI JedAI maps it to the services and data that depend on that supplier, and offboarding tracks data return and access revocation to a closure record.
XForce GPT writes the narratives and board reports from AI JedAI’s analysis, and an analyst reviews AI output before anyone relies on it. Dashboards serve the CISO, the board and audit committee, and the compliance and audit teams.
X-BCOR is aligned with DORA, and the third-party risk module covers the ICT third-party side, while the entity still makes every filing with its regulator.
What stays with the financial entity
DORA puts its obligations on the financial entity, and the platform does not move them.
- The entity’s leadership owns the ICT risk management framework, sets its risk tolerance and decides which functions are critical or important.
- The entity reports major ICT-related incidents to its competent authority.
- The entity designs and runs its resilience testing program, including any advanced testing, with qualified testers.
- The entity negotiates contract terms with its ICT providers and is accountable for its register of information.
- The entity accepts or rejects each risk. DigitalXForce records an accepted exception as a named person’s decision with a reason and an expiry date.
How DORA maps to the platform
| DORA area | What DigitalXForce does | What the entity still does |
|---|---|---|
| ICT risk management framework, with technical standards under Articles 15 and 16 | Controls are tested on their own schedules and every result is kept with its evidence. Failures raise risks in the register, AI JedAI scores them and X-SPM shows posture by domain. Attack Surface Manager keeps the asset inventory current. | Leadership approves the framework, the risk tolerance and each treatment decision. |
| ICT-related incident management and reporting, with standards under Articles 18(3) and 20 | X-ROC alerts, triages, escalates and reports failed controls and posture changes. DigitalXForce classifies each incident against DORA’s criteria. | The entity notifies its competent authority of major incidents. |
| Digital operational resilience testing | X-BCOR runs scenario-based planning against live control coverage, and vulnerability findings are worked and retested. | The entity runs the testing program and any advanced testing. |
| ICT third-party risk and contracts, with standards under Articles 28(9) and 28(10) | The TPRM module tiers suppliers, reads their reports with AI JedAI, takes consented connector evidence from critical suppliers and monitors them from outside. DigitalXForce produces the register of information in the standard templates set under Article 28(9). | The entity sets contract terms and is accountable for its register of information. |
| Oversight of critical ICT third-party providers | External Risk View maps fourth-party and nth-party dependencies, so the entity can see which providers it relies on. | The ESAs oversee the providers, and the entity tracks whether its own providers are designated. |
Where DigitalXForce is not the answer
DigitalXForce does not file reports with a competent authority or run advanced resilience tests. An entity that qualifies for DORA’s simplified ICT risk management framework, with a small estate and few ICT providers, may find its existing tools and a well-kept register enough. DigitalXForce fits an entity with many ICT providers, several frameworks beside DORA, and a supervisor who wants to see how controls performed over time.
What is tested from live data and what still needs a person
Which controls DigitalXForce tests directly from live tool data depends on the tools you connect through X-Connect and E-Connect. Controls that rest on a document, such as a signed policy, are reviewed by AI JedAI against the requirement and kept with their evidence. The demo shows that split for your own stack.
The evidence the auditor receives
For each control, the auditor receives the test result, the evidence it read, the time it was read and the history of earlier results. A-Assess prepares the evidence and findings in the form auditors review.
Other frameworks the same controls report to
A DORA control on ICT risk management, incident handling or third-party oversight often also answers requirements in NIS 2, ISO/IEC 27001 and NIST CSF 2.0. DigitalXForce maps such a control once, so one test result reports to each framework it belongs to. The article on the common control framework explains the method.
The financial services page shows how banks and other financial institutions use DigitalXForce.
DigitalXForce is not a certification, assessment or authorization body for DORA. It tests and documents the controls the framework requires.
Questions about DORA
How does Continuous Control Assurance (CCA) support DORA?
It tests the controls in the ICT risk management framework against live evidence and keeps each result with a timestamp, so a financial entity can show its supervisor how each control performed over time. Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. A failed control reaches X-ROC, the XForce Risk Operations Center, where it is alerted, triaged, escalated and reported.
How can DORA ICT controls be continuously monitored?
Connect the systems that enforce each ICT control and read their state on a schedule set by how quickly the evidence can change. Continuous Control Monitoring (CCM) monitors conditions, evidence and signals associated with controls, and it is a capability within Continuous Control Assurance, which decides whether each control still works. In DigitalXForce’s example evidence plan, encryption status is read continuously, MFA status daily and SIEM feed health hourly.
When did DORA start to apply?
DORA entered into force on 16 January 2023 and has applied since 17 January 2025. Its technical standards were adopted in batches, and ESMA, EIOPA and the EBA each list them on their DORA pages.
Who does DORA apply to?
It applies to 20 types of financial entities, including banks, insurers and investment firms, and to ICT third-party service providers. Providers designated as critical come under direct oversight by the European Supervisory Authorities.
Does DigitalXForce report major ICT incidents to the regulator?
It does not file the report. X-ROC alerts, triages, escalates and reports failed controls and posture changes, and DigitalXForce classifies each incident against DORA’s criteria. The financial entity notifies the competent authority.
How does DigitalXForce help with ICT third-party risk under DORA?
The third-party risk management module tiers each supplier, reads its SOC 2 and ISO reports with AI JedAI for an analyst to approve, and monitors it from outside with External Risk View. External Risk View also maps fourth-party and nth-party dependencies.
Does using DigitalXForce make a financial entity DORA compliant?
It does not. Compliance is the entity’s obligation and its supervisor’s judgment. DigitalXForce tests the controls behind DORA’s requirements and keeps timestamped evidence of each result, including the failures.
DigitalXForce terms used on this page
DigitalXForce gives each of its terms one definition and uses it everywhere, including in its glossary.
- Enterprise Security Risk and Posture Management (ESRPM) is the DigitalXForce module that runs configuration checks, operational insights and deployment benchmarking across IAM, SIEM, cloud, OT and IoT, SecOps and enterprise systems through 250+ technology integrations.
- X-SPM is Extended Security Posture Management, the DigitalXForce capability that scores security posture across the enterprise and its vendors from the same control data.
- A risk operations center is an operating model for continuously measuring, prioritizing and reducing risk, in the way a security operations center handles threats; DigitalXForce’s implementation is X-ROC, the XForce Risk Operations Center. X-ROC is the operations layer of the DigitalXForce TRiSCM platform, where control failures, risk changes and vendor events are alerted, triaged, escalated and reported.
- AI JedAI is the DigitalXForce AI engine that analyzes: it reasons over control evidence and live telemetry, maps documents to controls and frameworks, scores and prioritizes risk, and recommends remediation mapped to framework requirements.
- XForce GPT is the DigitalXForce generative AI engine that writes: it produces the plain-language risk narratives and board-ready reports, generates policies, standards and plans, and runs the embedded assistant.
Related pages
- What Is Continuous Control Assurance (CCA)? explains the strategic level of control assurance, which validates whether controls continue to operate as expected.
- What Is Continuous Control Monitoring (CCM)? explains the capability within Continuous Control Assurance that monitors the evidence behind each control between tests.
- X-BCOR is the business continuity and operational resilience module.
- Third-party risk management runs the supplier lifecycle, and External Risk View adds the view from outside.
- X-ROC, the XForce Risk Operations Center, is where failed controls and incidents are worked.
- The Automated GRC module maps each control once across 50+ compliance frameworks.
- What is a common control framework? explains how one control, written and tested once, serves every framework it maps to.
- How automated control testing decides whether a control still works explains the test behind each result.
- How to continuously validate third-party controls covers supplier evidence between assessments.
- What is fourth-party risk? explains the subcontractors behind each ICT provider and what DORA expects of them.
- The frameworks page lists the most requested frameworks.
Sources
- ESMA’s DORA page summarizes the 5 areas and lists the technical standards with their article numbers, including the 2025 report on major ICT-related incidents of 3 June 2026 and the statement on frontier AI models of 31 July 2026, at https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora.
- EIOPA’s DORA page gives the application date of 17 January 2025, the 20 types of financial entities and the oversight of critical ICT providers, at https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en.
- Regulation (EU) 2022/2554 of 14 December 2022 is published on EUR-Lex at https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng.
- The ESMA and EIOPA pages were read on 25 September 2026.
Do this once instead of every audit.
Every step above can be done by hand. DigitalXForce does them continuously, maps the result to 50+ frameworks once, and keeps the evidence current between audits. A 30 minute walkthrough on your own framework set shows what that removes from your calendar.
