DORA Compliance Guide: Digital Operational Resilience Act For Financial Entities And ICT Providers

The EU Digital Operational Resilience Act, usually called DORA, is now one of the most important cybersecurity and ICT risk regulations for the European financial sector. It applies from 17 January 2025 and changes how financial entities manage ICT risk, incidents, resilience testing, third-party providers and operational continuity.

DORA is different from many older cybersecurity rules because it treats digital resilience as a core part of financial stability. A bank, insurer, payment institution, investment firm, crypto-asset service provider or other financial entity does not only need good technical controls. It must also be able to prove that it can identify ICT risks, protect critical functions, detect and report major incidents, recover from disruption, test resilience, manage third-party dependencies and keep evidence for supervisors.

For ICT third-party providers, DORA is equally important even when the provider is not itself a regulated financial entity. Financial customers increasingly need contractual evidence, audit rights, incident cooperation, security documentation, testing results, vulnerability handling and exit support from their ICT suppliers. In practice, DORA has become a major procurement and vendor-risk requirement across the European financial technology ecosystem.

SecPoint products such as the Penetrator vulnerability scanner and Protector security appliance can support DORA readiness activities by helping organizations discover vulnerabilities, document technical risk, prepare testing evidence and strengthen network security. They do not replace the financial entity's DORA governance duties and they do not constitute DORA certification.

What Is DORA?

DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. It entered into force on 16 January 2023 and applies from 17 January 2025. The regulation aims to harmonize ICT risk management and digital operational resilience requirements across the EU financial sector.

Before DORA, ICT risk requirements were spread across different EU and national rules for banking, insurance, investment services, payments, securities markets and other financial activities. DORA creates a common framework for digital operational resilience. It is not only about preventing cyberattacks. It is about ensuring that financial entities can continue critical services, recover from disruption and manage ICT dependencies in a controlled way.

DORA is built around several practical themes: ICT risk management, incident management and reporting, digital operational resilience testing, ICT third-party risk management, information sharing and oversight of critical ICT third-party providers. These themes are connected. An organization cannot report major ICT incidents quickly if it cannot detect and classify them. It cannot manage third-party risk if it does not know which providers support critical or important functions. It cannot test resilience if it has not defined what needs to remain available, authentic, intact and confidential.

Who Must Care About DORA?

DORA primarily applies to financial entities in the EU financial sector. It also creates a framework for ICT third-party service providers, including contractual expectations for providers used by financial entities and EU-level oversight for providers designated as critical. Article 2 lists many categories of financial entities and also refers to ICT third-party service providers. Regulatory summaries often describe DORA as applying to around 20 categories of financial entities, plus the ICT third-party provider framework.

DORA includes proportionality. The way a large systemic bank implements DORA will not be identical to the way a smaller regulated financial entity implements it. However, proportionality is not an exemption from having controls, policies, evidence and governance. It means the design and depth of controls should reflect the entity's size, risk profile, complexity, services and dependencies.

DORA Is Not A Product Certification

DORA should not be confused with a product certification regime. It is not the same as CE marking, CRA conformity assessment or an official cybersecurity certificate for a firewall, scanner or cloud platform. DORA is mainly a financial-sector operational resilience regulation. It tells financial entities how to govern ICT risk, manage third-party dependencies, test resilience and report major incidents.

This distinction matters for cybersecurity vendors. A vendor should be careful with marketing language. It is safer and more accurate to say that a product or service can support DORA readiness, DORA evidence, DORA testing, DORA ICT risk management or DORA third-party risk documentation. It is usually not accurate to say that a product is "DORA certified" unless a specific recognized certification or supervisory mechanism actually exists for that claim.

The Five Practical Pillars Of DORA

DORA is often explained through five practical pillars. These pillars are useful because they translate a complex legal text into operational workstreams.

Governance And Management Responsibility

DORA makes ICT risk a management responsibility. Article 5 requires financial entities to have an internal governance and control framework that ensures effective and prudent management of ICT risk. The management body is responsible for defining, approving, overseeing and implementing arrangements related to the ICT risk management framework.

In practical terms, DORA is not something that can be delegated entirely to an IT administrator or outsourced to a vendor. The board or management body must understand the risk, approve the framework, allocate resources, define roles and ensure that the organization can maintain high standards of availability, authenticity, integrity and confidentiality of data.

Governance Checklist

• Define management responsibility for ICT risk and digital operational resilience.
• Document roles and responsibilities across management, IT, security, compliance, risk, procurement and business owners.
• Maintain an ICT risk management framework approved at the appropriate level.
• Link ICT risk decisions to critical or important business functions.
• Review ICT risk reporting regularly, not only after incidents.
• Ensure outsourced ICT services remain under internal oversight.
• Keep evidence of decisions, reviews, risk acceptance and remediation tracking.

ICT Risk Management Under DORA

DORA expects financial entities to manage ICT risk throughout the lifecycle of systems and services. This includes identifying assets and dependencies, protecting systems, detecting anomalous activity, responding to incidents, recovering services and learning from events.

A useful DORA readiness question is: can the organization prove which ICT assets support which critical or important functions, which vulnerabilities affect them, which controls protect them, which providers operate them, and how quickly they can be recovered?

DORA Incident Reporting

DORA requires financial entities to manage, classify and report major ICT-related incidents. The reporting regime is designed to harmonize how serious ICT incidents are notified to competent authorities across the EU financial sector.

Current DORA reporting rules are generally described as a three-step process for major ICT-related incidents: an initial notification, an intermediate report and a final report. Regulatory materials describe the initial notification as due as early as possible, within four hours from classification as major and no later than 24 hours from becoming aware of the incident; the intermediate report within 72 hours; and the final report within one month according to the applicable reporting rules.

Incident Reporting Readiness Checklist

• Define what counts as an ICT-related incident and how incidents are classified.
• Define when an incident becomes major and who can make that decision.
• Maintain 24/7 or appropriate escalation paths for critical signals.
• Prepare initial, intermediate and final report templates.
• Assign responsibility for regulator communication.
• Keep evidence of detection time, classification time, impact assessment and decisions.
• Run incident simulations to test whether reporting deadlines can be met.
• Include third-party incident notification duties in vendor contracts.

Digital Operational Resilience Testing

DORA requires financial entities to test digital operational resilience. Testing should not be treated as a one-time penetration test. It should be a structured program that gives management evidence that ICT systems, controls, continuity arrangements and recovery capabilities are working.

Testing can include vulnerability assessments, vulnerability scans, open-source analysis, network security assessments, gap assessments, scenario-based tests, compatibility testing, performance testing, end-to-end testing, penetration testing, physical security reviews, source-code reviews where relevant, and business continuity or disaster recovery exercises.

DORA also includes threat-led penetration testing, often called TLPT, for certain financial entities. TLPT is not necessarily required for every financial entity. It is a more advanced form of testing for entities that meet the relevant criteria and are instructed or required under the applicable DORA framework.

How SecPoint Penetrator Can Support Testing Evidence

SecPoint Penetrator can help prepare vulnerability scanning and security testing profiles that support DORA readiness. This can include external network scanning, internal vulnerability assessment, authenticated scanning, web application checks, reporting and remediation evidence.

The important word is support. A Penetrator scan report can be useful evidence for ICT risk management and resilience testing, but it is not a DORA certification. DORA compliance depends on the financial entity's full governance, risk management, incident reporting, testing, third-party risk and supervisory obligations.

ICT Third-Party Risk Under DORA

ICT third-party risk is one of the most operationally important parts of DORA. Financial entities increasingly depend on cloud platforms, SaaS systems, managed service providers, cybersecurity vendors, payment technology providers, data processors, software suppliers and infrastructure operators. DORA requires this dependency to be governed, documented and controlled.

Article 28 states that financial entities remain fully responsible for compliance even when they use ICT third-party service providers. This is a core DORA principle: outsourcing work does not outsource accountability.

Before entering into contractual arrangements for ICT services, financial entities need to assess whether the service supports a critical or important function, assess relevant risks, consider concentration risk, perform due diligence and ensure the provider is suitable. Article 30 sets out key contractual provisions for ICT services, including clear service descriptions, locations where services and data processing are provided, subcontracting conditions, security requirements, access and audit rights, termination rights and exit arrangements.

Third-Party Provider Checklist

• Maintain a register of ICT third-party service providers and contractual arrangements.
• Identify which providers support critical or important functions.
• Document service descriptions, SLAs, data locations and subcontracting rules.
• Assess concentration risk and substitutability for important providers.
• Include incident notification duties and cooperation timelines in contracts.
• Include access, audit and information rights where required.
• Define exit strategies for providers supporting critical or important functions.
• Review provider security evidence regularly, not only at contract signature.

Register Of Information

DORA requires financial entities to maintain a register of information for contractual arrangements with ICT third-party service providers. The register helps financial entities monitor ICT third-party risk and helps competent authorities and the European Supervisory Authorities understand dependencies and identify critical ICT third-party providers.

For many organizations, the register is one of the first places where DORA becomes operationally painful. A company may discover that it has dozens or hundreds of ICT services spread across cloud accounts, SaaS subscriptions, security tools, outsourced support, development platforms, data providers and business applications.

Critical ICT Third-Party Providers

DORA creates an EU-level oversight framework for critical ICT third-party service providers, often called CTPPs. These are providers whose services are considered critical for the financial sector. The European Supervisory Authorities can designate critical providers and assign a Lead Overseer.

This does not mean every software vendor to a bank automatically becomes a critical ICT third-party provider under direct EU oversight. However, even non-critical providers can be deeply affected by DORA because financial customers must manage their ICT provider risk and often pass requirements into contracts.

DORA, NIS2, CRA And GDPR: How They Differ

DORA sits alongside other EU digital and cybersecurity rules. It is useful to understand what each regulation is trying to do.

A single organization or service can touch several regimes. A financial entity may be under DORA for ICT risk. A software product sold to that financial entity may be under CRA. Personal data processed during the service may be under GDPR. A provider or customer may also have NIS2 obligations depending on sector and national implementation.

DORA Readiness For ICT Providers

ICT providers serving financial customers should expect more questions from procurement, compliance, security and vendor-risk teams. Even when the provider is not directly supervised under DORA, the customer may need evidence from the provider to meet its own obligations.

What Financial Customers May Ask For

• Security overview and control documentation.
• Vulnerability management and patching process.
• Incident notification process and contact details.
• Service availability commitments and operational resilience evidence.
• Penetration test or vulnerability assessment summaries.
• Data processing and service location information.
• Subcontractor list and subcontracting change process.
• Business continuity, disaster recovery and backup approach.
• Exit support and data return or deletion process.
• Audit rights, customer assurance reports or independent assessment evidence.

A provider that can answer these questions clearly will be easier for financial customers to approve. A provider that cannot answer them may become a procurement risk, even if the product is technically strong.

How SecPoint Can Support DORA Readiness

SecPoint can support DORA readiness by helping organizations build technical evidence around vulnerability exposure, security testing and network protection. This support is most useful when it is integrated into the customer's governance and evidence process.

Practical DORA Checklist

The checklist below is a practical starting point for organizations that need to structure DORA readiness work. It is not a complete legal checklist, but it can help teams move from general awareness to evidence.

Common DORA Mistakes

• Treating DORA as a one-time policy project instead of an operational evidence program.
• Assuming the IT department can own DORA alone without management, risk, compliance and procurement.
• Keeping vendor information in scattered spreadsheets without a controlled register.
• Running vulnerability scans without remediation ownership or evidence of closure.
• Having incident response plans that do not match regulatory reporting deadlines.
• Signing ICT provider contracts without audit rights, subcontractor visibility or exit support.
• Confusing a security product report with DORA certification.
• Waiting for a major incident before testing communication and escalation paths.

DORA Article-To-Action Mapping

DORA is a legal regulation, but implementation must become operational. The table below translates several important DORA areas into practical actions that security, compliance, procurement and management teams can understand. It is not a complete legal mapping, but it is useful for planning a readiness project and for explaining why technical evidence matters.

Penetrator DORA Scan Profiles

A practical way to support DORA readiness is to create repeatable scan profiles. The goal is not to run random scans. The goal is to create predictable, documented testing evidence that can be repeated, compared and used for remediation tracking.

SecPoint Penetrator profiles can be prepared around the way financial entities think about ICT risk: external exposure, internal infrastructure, web applications, authenticated checks, critical systems, third-party connections and remediation validation. This makes the scan output easier to connect to DORA governance and risk reporting.

The strongest scan program is one where each profile has a purpose, schedule, owner, approval process, evidence folder and remediation workflow. For example, an external exposure profile may run monthly, while remediation validation may run after every critical fix. Critical systems may require a different scanning window and stronger change control.

Protector And Network Resilience

DORA does not require a specific firewall brand or one named technical architecture. It requires financial entities to manage ICT risk and maintain digital operational resilience. Network protection is one practical part of that wider control environment.

A security appliance such as SecPoint Protector can support network protection by helping enforce traffic rules, filtering, segmentation, VPN access, gateway security and other controls depending on configuration and deployment. For DORA purposes, the evidence is not merely that a firewall exists. The evidence should show why the control is needed, how it is configured, who approved the rules, how changes are reviewed and how logs or alerts are used.

Network Control Evidence

• Network diagram showing protected zones and critical systems.
• Firewall rule review records and change approvals.
• VPN and remote access configuration evidence.
• Segmentation test results for critical or important functions.
• Logs showing blocked or monitored activity where relevant.
• Backup and restore procedure for gateway configuration.
• Update and patching records for the security appliance.
• Incident response steps for suspected gateway compromise or misconfiguration.

This is also where DORA and CRA can meet in practice. DORA is about the financial entity's operational resilience. CRA is about cybersecurity requirements for products with digital elements placed on the EU market. A financial entity may ask a firewall vendor for both DORA-supporting evidence and product-security evidence under other regimes. The vendor should answer accurately and avoid mixing the regimes into one unclear claim.

DORA Evidence Folder Model

DORA readiness becomes much easier when evidence is organized by topic and date. A common problem is that organizations do many good security activities but cannot prove them quickly during an audit, supervisory review, vendor assessment or incident investigation. A structured evidence folder helps turn daily work into defensible proof.

The evidence folder does not need to be complicated at the beginning. It can start as a controlled document repository with owners and naming rules. Over time it can become part of a GRC platform, ticketing system or compliance evidence tool.

Vendor Questionnaire: How To Answer Safely

ICT providers selling to financial entities may receive DORA questionnaires. These questionnaires can ask whether the provider is DORA compliant, whether the product is DORA certified, whether the provider supports incident reporting, whether subcontractors are used and whether the customer can audit the provider.

The safest approach is to answer clearly without overclaiming. If a vendor is not itself a regulated financial entity or designated critical ICT third-party provider, it should avoid pretending to have the same DORA obligations as a bank. At the same time, it should show that it understands customer requirements and can provide security evidence.

DORA Metrics Management Should Track

DORA readiness should be measurable. Management needs more than long policy documents. It needs a small set of indicators that show whether ICT risk is improving or getting worse.

• Number of critical or high vulnerabilities open on critical systems.
• Average time to remediate critical and high vulnerabilities.
• Percentage of critical systems scanned within the required schedule.
• Number of overdue remediation actions.
• Percentage of ICT providers classified and entered in the register.
• Number of providers supporting critical or important functions without complete contract evidence.
• Backup restore success rate for critical systems.
• Incident detection-to-classification time during exercises.
• Incident classification-to-notification readiness during simulations.
• Number of open audit findings related to ICT risk or third-party providers.

These metrics should be reviewed by the right governance forum. DORA is not only about having controls; it is about knowing whether those controls are operating and whether risk is within the organization's tolerance.

30-Day DORA Readiness Start Plan

A full DORA program can be large, but the first steps should be practical and evidence-oriented.

Frequently Asked Questions

Is DORA already active?

Yes. DORA applies from 17 January 2025. Financial entities in scope should already be operating under DORA requirements.

Is DORA only for banks?

No. DORA covers a broad range of financial entities, including banking, payments, investment services, insurance, market infrastructure, crypto-asset service providers and other financial-sector entities listed in the regulation.

Does DORA apply directly to all ICT vendors?

DORA includes ICT third-party service providers in its framework and creates direct EU-level oversight for providers designated as critical. Many non-critical ICT providers are affected mainly through their financial customers' contractual, audit, incident and assurance requirements.

Can a product be DORA certified?

DORA is not generally a product certification regime. A product can support DORA readiness, but the financial entity remains responsible for its DORA compliance. Vendors should avoid unsupported claims that a product is "DORA certified."

How can vulnerability scanning support DORA?

Vulnerability scanning helps identify ICT weaknesses, prioritize remediation, document technical risk and show evidence of recurring testing. This supports DORA ICT risk management and resilience testing, but it does not replace the full DORA governance framework.

Does DORA require penetration testing?

DORA requires digital operational resilience testing. This can include several types of testing. Threat-led penetration testing applies to selected entities under the relevant criteria and supervisory framework, not automatically to every organization in the same way.

What is the biggest practical DORA challenge?

For many organizations, the hardest parts are evidence, third-party dependency mapping, incident reporting readiness and proving that controls are not just written in policies but actually operating.

Conclusion

DORA turns digital operational resilience into a formal supervisory requirement for the EU financial sector. It is not enough to have cybersecurity tools. Financial entities must show governance, risk management, testing, reporting, third-party control and recovery capability. ICT providers must be ready to support customers with clear evidence, security documentation, incident cooperation and contractual transparency.

SecPoint can support DORA readiness through vulnerability scanning, network security controls, dark web exposure checks and practical reporting evidence. The right approach is honest and evidence-based: use technical controls to support the DORA program, document what they prove, remediate what they find and avoid unsupported certification claims.