The advent of the Digital Operational Resilience Act (DORA) has introduced a new set of regulatory expectations that financial entities operating in the European Union need to be aware of. Additionally, organizations such as SaaS startups that provide services to financial entities, or plan to, must begin preparing to meet DORA’s requirements.
In a recent webinar hosted by Rhymetec and Vanta, we unpacked DORA requirements and discussed practical steps organizations can take now to align with DORA. Endri Domi, Infosec Manager at Rhymetec, moderated an insightful discussion between Faisal Khan, GRC Solutions Specialist at Vanta, and Metin Kortak, CISO at Rhymetec.
This blog post highlights the key points from their discussion, with a focus on what organizations need to understand and prioritize in the months ahead. You can check out the full webinar here.
What Are DORA Requirements, and Who Must Comply?
DORA requirements come from the EU’s Digital Operational Resilience Act, which is now in effect. The regulation applies to financial institutions operating in the EU, as well as certain types of service providers that support them.
According to Faisal Khan, GRC Solutions Specialist at Vanta, the purpose of DORA is to improve the resiliency of financial institutions:
“DORA is an EU regulation designed to improve the ability of financial institutions to weather and recover from any information or technology-related disruptions like cyber attacks, data breaches, and system failures. It’s really to build that tolerance for themselves so that they’re protected in the event some of those things would happen.” – Faisal Khan, Vanta
DORA covers both financial entities, such as banks, insurance companies, and investment firms, as well as their ICT third-party service providers. ICT (Information and Communication Technology) third-party service providers include cloud providers and other vendors that manage or support technology for other organizations.
The regulation introduces two types of regulatory documents that support its implementation:
Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS). RTS specifies what organizations must actually do to meet DORA’s requirements, while ITS focuses on how the information should be reported. How each of the 5 pillars of DORA is applied in practice, as shown in the next section, is shaped by the technical standards.
What Are The Five Pillars of DORA Requirements?
DORA requirements are structured around five pillars. Each pillar is designed to reduce ICT-related disruption risk in financial services and strengthen the resilience of the ecosystem. In our webinar, our experts honed in on explaining each pillar in detail, particularly those involving third-party risk and incident reporting:
1. ICT Risk Management
Mitigating ICT-related risks across your organization’s digital environment is a core part of DORA. Typically, this entails starting with a live, centralized asset inventory and linking each asset to a business function. This enables you to then align risk prioritization with actual operational impact, and helps keep future reporting manageable.
2. ICT-Related Incident Reporting
As highlighted by our experts, ICT-related incident reporting includes notifying both national competent authorities and any stakeholders who may be affected, such as customers or partners who rely on your platform:
“If you do have ICT-related incidents, those incidents will need to be communicated to the national authorities and other stakeholders who may be impacted by your platform, such as your customers.” – Metin Kortak, Rhymetec
If an incident meets the criteria for “major ICT-related incident”, you must notify your national competent authority (typically, your financial services or cybersecurity regulator) within 24 hours of detection. Follow-up reports are required as the situation evolves.
Incidents are classified based on metrics such as the number of users affected, duration of the disruption, and impact on data integrity or confidentiality. Your report should explain in detail what your response is and provide guidance for the recipient. The final report submitted to regulators must include a root cause analysis, detailing what happened and why it happened.
Bonus Tip: DORA goes further than GDPR by imposing stricter timelines, requiring a reporting process with multiple updates, and mandating the notification of any major ICT–related incidents (not just those involving personal data). In general, it covers a broader range of disruptions that impact operational continuity.
3. Digital Operational Resilience Testing
Under DORA requirements, operational resilience testing is addressed in Articles 24-27. Organizations must be able to demonstrate that their critical ICT systems can withstand disruption. Testing must be continuous and evidence-based:
“The point of this requirement is to ensure you have testing to verify that the resiliency of your application can be proved. This can be either third-party testing, or it can be internal testing.” – Metin Kortak, Rhymetec
This includes a mix of internal exercises (such as tabletop exercises) and, where applicable, advanced testing techniques like threat-led penetration testing (TLPT). The intent is to ensure that your organization is able to 1) recover from disruption and 2) continue delivering critical services under adverse conditions.
For most organizations, the following action items are good options to fulfill the requirements in this pillar:
Tabletop Exercises
Tabletop exercises are scenario-based discussions that mirror real-world scenarios. Undergoing a tabletop exercise allows your organization to test its response capabilities, validate roles and responsibilities, and improve communication without affecting live systems.
Technical Testing
For systems deemed critical, DORA encourages more rigorous validation, which can take the form of failover testing, load testing, and red team exercises. Third-party involvement is encouraged at this stage, particularly for high-risk or business-critical functions.
Testing must occur on a regular basis and must reflect the scale and risk profile of your organization. DORA does not prescribe a one-size-fits-all cadence, but regulators will expect to see a documented rationale for test frequency and scope.
Remediation and Continuous Improvement
Testing is only the first part of the requirement. DORA also expects organizations to conduct lessons learned from testing, remediate weaknesses accordingly, and feed results back into their risk management and ICT governance processes.
The overarching goal of this requirement is to encourage a shift from static, checklist-driven compliance to real-world resilience. Instead of simply having a plan, organizations have to prove it works.
Bonus Tip: Don’t forget about your critical third parties! We’ll get into that more in the next pillar, but it’s also relevant here. In areas where external service providers support your organization’s critical functions, you’ll need to evaluate their resilience as well. To do this, you can obtain assurance reports, risk assessments, validate their compliance with DORA if applicable, and/or coordinate joint exercises.
4. ICT Third-Party Risk
“If you do not understand your subprocessors, that’s probably the first thing you want to do. If you have to comply with GDPR, you probably already understand the subprocessors that you’re working with. For DORA, the next step would be to really understand how much data they process and how critical they are to your organization.” – Metin Kortak, Rhymetec
One of the foundational steps in meeting DORA requirements is gaining full visibility into your third-party relationships. While organizations that already comply with GDPR are required to maintain records of data subprocessors, DORA introduces an operational resilience component that extends beyond data protection. Under DORA, your organization has to consider not only who you’re working with, but how much risk those relationships introduce into your business.
Subprocessors often include cloud providers, SaaS tools, and outsourced IT or security vendors. DORA requires that financial entities mandate ICT third-party service providers that service those entities to map out these relationships and assess their criticality. Article 28 of DORA explicitly mandates risk assessments of ICT third-party service providers, with an emphasis on concentration risk.
“DORA also impacts the other third-party vendors and subprocessors that you are working with, because those vendors ultimately impact also the availability of your platform. For example, if you are hosted by a third-party hosting provider, they also impact the availability of your application. Therefore, you also need to conduct a risk assessment to ensure that the provider can actually support the resiliency of your application.” – Metin Kortak, Rhymetec
If you are a financial entity subject to DORA requirements, you must maintain a register of all contractual agreements with ICT third-party providers and identify those considered “critical or important”. This represents a broader industry shift from reactive vendor management to proactive operational resilience planning. Organizations that enact these changes will not only be positioned to comply with DORA, but also to build a more resilient overall business.
Other important considerations for the ICT-Third Party Risk Pillar include:
The Volume of Data Processed
How much sensitive or operational data flows through the vendor’s systems? The more data processed, the higher the impact of a service disruption or breach.
Criticality to Business Operations
If a subprocessor experiences downtime, how does that affect your ability to deliver services, meet SLAs, and maintain operational continuity?
Dependency Risk
Are there alternative providers or workarounds if a subprocessor fails? If not, that relationship may require additional safeguards in your contract or contingency planning.
Oversight and Exit Strategy
Ongoing monitoring and having the ability to disengage from a vendor if needed (without causing your organization to risk operational issues!) are essential under DORA.
5. Information Sharing
DORA encourages financial entities to participate in trusted information-sharing arrangements around cyber threat intelligence. While not mandatory, participation supports sector-wide resilience.
Bonus Tip: Join regional or sector-specific ISACs (Information Sharing and Analysis Centers) early. This gives your team early visibility into threats targeting similar organizations, often before they’ve hit public feeds or the news.
What Are Some Considerations When Becoming DORA Compliant, According to The Experts?
As you are working to achieve compliance with DORA requirements, here are several practical considerations to keep in mind, according to our experts at Rhymetec and Vanta:
Trade Reporting Integrity
If your organization is subject to transaction reporting requirements (such as under EMIR or MiFIR), DORA reinforces the need for accuracy and completeness of those reports. Insufficient reporting could raise compliance concerns.
Lack of An Official DORA Certification
This is a common misconception.
Unlike some regulatory frameworks, DORA does not offer a formal certification or audit program. Instead of a formal certification, organizations are expected to demonstrate compliance with DORA requirements through internal audits or third-party assessments.
However, it’s important to note that regulators still have the authority to request evidence and conduct inspections, so being “audit-ready” is still critical.
Framework Synergies
DORA is good at outlining what must be done, but often leaves the how to up to each organization and lacks specific implementation guidance. This opens the door to leverage existing security and compliance frameworks, such as ISO/IEC 27001 and 27002, SOC 2, or NIST, to guide implementation.
For example, DORA requires regular risk assessments but doesn’t prescribe a methodology. Therefore, ISO 27005 or NIST SP 800-30 can provide details on how to actually carry out risk assessments. Aligning DORA controls with these frameworks, if you already have them, helps avoid duplicating your efforts.
In Conclusion: How Organizations Leverage vCISO Services To Meet DORA Requirements
A virtual CISO (vCISO) can play a critical role in preparing your organization to meet DORA requirements. vCISOs provide technical guidance and control implementation, operational support, and oversight without the cost of a full-time executive hire.
For startups, a vCISO can help build foundational controls, align existing security processes to DORA’s requirements, and lead efforts like risk assessments, incident response planning, and third-party due diligence. For more mature organizations, a vCISO can support internal audit functions, map DORA requirements to existing frameworks (such as ISO 27001 or SOC 2), and create alignment between IT, legal, and compliance teams.
Regardless of organization size, a vCISO helps translate complex regulatory language into actionable plans that will hold up under regulatory scrutiny. vCISO services provide access at scale to top-tier cybersecurity and compliance services. vCISOs can also leverage the most cutting-edge tools, such as compliance automation platforms, to get you compliant in the fastest timeframe possible.
About Rhymetec
Our mission is to make cutting-edge cybersecurity available to SaaS companies and startups. We’ve worked with hundreds of companies to provide practical security solutions tailored to their needs, enabling them to be secure and compliant while balancing security with budget. We enable our clients to outsource the complexity of security and focus on what really matters – their business. Contact us today to get started.
Interested in reading more? Check out more content on our blog.