%201.svg)
HIPAA Compliance Checklist for 2025
DORA is no longer just a compliance exercise. For financial firms, the bigger challenge is keeping track of the SaaS, cloud services, and ICT providers their critical operations depend on.
The European Supervisory Authorities reported 3,383 major ICT incidents in the EU financial sector, with around one-third having a cross-border impact. System failures and external events were the main drivers.
That is why a DORA compliance checklist needs to go beyond policies and contracts. It should help teams see which applications matter, what they connect to, who has access, and where third-party dependencies could create risk.
This guide breaks DORA into practical checks for financial services and SaaS environments, with a focus on ICT risk, resilience, access, and third-party dependencies.
1. What Is DORA Compliance?
DORA compliance means meeting the requirements of the EU’s Digital Operational Resilience Act to manage technology-related risks in financial services.
It covers ICT risk management, incident response, resilience testing, and ICT third-party risk.
In simple terms: DORA compliance helps financial organizations prepare for technology disruptions and keep critical services running.
2. Who Needs to Comply With DORA?
DORA mainly applies to financial entities operating in the EU, including banks, insurers, investment firms, payment institutions, and crypto-asset service providers. It also brings the ICT providers they rely on into the risk management picture.
- Financial entities: Responsible for managing their ICT risk and third-party technology dependencies.
- ICT providers: SaaS, cloud, software, and other technology providers can become part of a financial entity’s DORA risk assessment.
- Critical ICT providers: Providers designated as critical can face additional EU-level oversight.
For SaaS companies, one distinction matters: serving a financial institution does not automatically mean the SaaS provider has the same DORA obligations as the financial entity. But the financial institution still needs to understand the provider’s service, data, access, dependencies, and resilience.
3. What Are the Five Pillars of DORA?
DORA organizes its requirements into five connected areas. Together, they cover how financial organizations manage technology risk, respond to disruptions, test resilience, govern ICT providers, and share relevant threat information.
- ICT Risk Management: Identify technology risks, assess their business impact, and put appropriate controls in place.
- ICT Incident Management: Detect, classify, respond to, and report ICT-related incidents while using lessons from incidents to improve controls.
- Digital Operational Resilience Testing: Test systems, recovery processes, and response plans to find weaknesses before a real disruption exposes them.
- ICT Third-Party Risk Management: Assess technology providers, including their security, resilience, subcontractors, contracts, dependencies, and exit arrangements.
- Information and Intelligence Sharing: Share relevant information about cyber threats and vulnerabilities with trusted financial-sector organizations and authorities where applicable.
For SaaS-heavy environments, these pillars often overlap. A single SaaS application can support a critical business function, process sensitive data, connect with other systems, and introduce third-party and access risks. This makes application-level visibility an important part of putting DORA into practice.
4. DORA Compliance Checklist
A useful DORA checklist should go beyond checking whether policies and contracts exist. It should connect each requirement to the technology, business function, data, identities, and third parties involved.
Use these checks to assess your DORA readiness:
A. Map Your ICT Environment and Critical Business Functions
Start with the actual technology environment, not just the vendor list.
Check:
- SaaS, cloud, and ICT services supporting critical or important functions
- Business processes dependent on them
- Data handled and where it is stored
- Application dependencies, APIs, and integrations
- Providers and subcontractors involved
Ask: If this application goes down today, which business process is affected?
B. Identify and Assess ICT Risks
Assess risk based on how the technology is actually used.
Look at:
- Business criticality and operational impact
- Data sensitivity
- Security posture
- User and privileged access
- Integrations and dependencies
- Recovery and replacement options
A provider may have strong security controls but still create significant operational risk if your business heavily depends on its service.
C. Control User and Privileged Access
Review access to critical applications regularly.
Check for:
- Admin and privileged accounts
- Excessive permissions
- Inactive or orphaned accounts
- Third-party access
- Access that no longer matches job roles
Access reviews should reflect current business needs, not just what was approved when the application was onboarded.
D. Govern Non-Human Identities
Service accounts, API keys, tokens, bots, and AI agents can have significant access without appearing in traditional user reviews.
Make sure each has:
- A clear owner and purpose
- Appropriate permissions
- Rotation or expiration controls
- Activity monitoring
- A defined revocation process
E. Monitor SaaS Integrations and Data Connections
An application's risk can change when it connects to another system or receives broader permissions.
Review:
- OAuth connections and APIs
- Connected applications
- Data-sharing relationships
- New integrations
- Permission changes
This is especially important when employees can connect applications without a central IT review.
F. Prepare for ICT Incidents
Your incident process should quickly show which applications, providers, and business functions are affected.
Check whether teams can:
- Detect and classify incidents
- Identify affected systems and providers
- Trace impact to business functions
- Coordinate with third parties
- Preserve evidence and support reporting
G. Test Business Continuity and Operational Resilience
Test whether critical operations can continue when technology fails.
Review:
- Business continuity and disaster recovery plans
- Backup and restoration
- Recovery objectives
- Critical SaaS dependencies
- Resilience testing and corrective actions
Ask: If a critical SaaS application is unavailable for a day, how will the affected business function continue?
H. Assess ICT Third-Party Risk
Evaluate providers based on the exposure they create for your organization.
Consider:
- Security and resilience
- Data locations
- Subcontractors
- Incident obligations
- Audit rights
- Business continuity
- Exit arrangements
- Concentration risk
The assessment should connect the provider to the application, users, data, access, and dependencies within your environment.
I. Review SaaS Contracts Against DORA
Check whether contracts address:
- Services and data locations
- Security requirements
- Incident assistance
- Business continuity
- Audit and access rights
- Subcontracting
- Termination and data portability
A contractual right is useful only when your organization can actually exercise it.
J. Maintain the DORA Register of Information
Keep the Register of Information aligned with the actual ICT environment.
Capture details such as:
- ICT provider and service
- Business function supported
- Contract information
- Provider and service locations
- Subcontractors
- Criticality and dependencies
The register should not become a static spreadsheet. New applications, providers, subcontractors, contracts, or changes in criticality should trigger a review and update.
K. Identify Concentration and Exit Risk
Look beyond whether an exit clause exists. Assess whether you could realistically leave the provider.
Check:
- Dependence on the same provider across critical functions
- Available alternatives
- Data portability
- Migration time
- Applications and workflows affected
- Ability to operate during transition
L. Monitor Material Changes
DORA compliance should continue after initial approval. Reassess when something materially changes, such as:
- New SaaS or ICT providers
- New integrations or broader API access
- New privileged users or NHIs
- Changes in data handling
- New subcontractors
- Security incidents
- Changes in business use or criticality
The goal is simple: make changes in the technology environment visible to the teams responsible for risk and compliance.
Bringing DORA Into Day-to-Day Operations:
A checklist is only useful when the information behind it stays current. Teams need visibility across applications, identities, integrations, vendors, security posture, and dependencies.
CloudEagle.ai can complement a broader DORA program by providing this operational context across SaaS, AI, identities, access, and integrations. It helps teams connect changes in the technology environment to risk reviews and remediation without replacing formal DORA governance or compliance processes.
5. How to Start Your DORA Compliance Program
DORA compliance is easier to manage when teams treat it as an ongoing process rather than a list of requirements to complete once.
A practical approach is: Scope → Map → Assess → Remediate → Test → Document → Monitor
- Scope: Identify covered entities, critical functions, and relevant ICT services.
- Map: Connect applications and providers to business functions, data, users, identities, and dependencies.
- Assess: Review ICT risk, access, security, resilience, contracts, and third-party exposure.
- Remediate: Prioritize gaps based on business impact and operational risk.
- Test: Test resilience, recovery, incident response, and critical dependencies.
- Document: Maintain assessments, evidence, contracts, and the Register of Information.
- Monitor: Reassess when applications, providers, access, integrations, or business use changes.
The objective is not simply to complete the checklist. It is to keep DORA controls aligned with the technology environment as it evolves.
Also Read: 7 Best Compliance Automation Tools Worth Trying
6. What Should SaaS Providers Prepare for DORA?
SaaS providers serving financial organizations should be ready to show how their services are secured, managed, and kept resilient. While DORA does not impose identical obligations on every SaaS provider, their services can become part of a customer’s ICT and third-party risk assessments.
Providers should be able to demonstrate:
- Security: How systems and customer data are protected.
- Resilience: Business continuity, recovery, and backup measures.
- Incident response: How incidents are detected, handled, and reported.
- Data handling: Where data is stored, processed, and transferred.
- Subcontractors: Which third parties support the service.
- Access controls: How privileged and customer access is managed.
- Audit support: What evidence customers can access for assessments.
- Exit readiness: How customers can retrieve their data and transition away.
The key is not having a DORA document ready for review. Providers need current evidence showing that these controls work in practice.
7. How Do You Build a DORA Evidence Trail?
DORA compliance requires more than having policies and controls in place. Teams need to show what was checked, who reviewed it, what evidence supports it, and what happened when a gap was found.
A practical evidence trail should connect:
For SaaS environments, evidence should also reflect changes in applications, access, integrations, identities, and third-party dependencies. This makes it easier to show that controls are not only documented but maintained as the technology environment changes.
8. How Can CloudEagle.ai Support DORA Compliance?
DORA risk does not stop at the vendor. It can extend across the application, users, identities, integrations, data, and business functions connected to that vendor.
CloudEagle.ai provides this operational context by bringing SaaS and AI discovery, access, identities, integrations, security posture, usage, and vendor information together.
Teams can use CloudEagle.ai to:
- Discover SaaS and AI applications across the environment.
- Connect applications with users and non-human identities, including service accounts, API tokens, and AI agents.
- Track integrations and dependencies that can change an application's risk.
- Monitor access and application changes that may require review.
- Connect vendors with applications, usage, access, and security context for stronger third-party risk assessments.
- Trigger remediation workflows and maintain an audit trail of actions.
This helps bridge the gap between a DORA requirement on paper and the technology environment that actually needs to meet it. CloudEagle.ai complements formal DORA governance, assessments, and reporting rather than replacing them.
Armorcode Case Study:
Armorcode used CloudEagle.ai to improve visibility into its non-human identities across its SaaS and cloud environment. CloudEagle.ai increased NHI visibility from 40% to 95%, helped remediate 480 unmanaged identities, and optimized 220+ over-privileged identities.
Stay DORA-Ready Every Day.
9. Conclusion
DORA compliance is not a one-time checklist exercise. Financial organizations need to keep track of their ICT environment, applications, access, third parties, and dependencies as they change.
The practical goal is simple: connect every requirement to the technology it affects, the evidence that supports it, and the action needed when something changes.
10. FAQs
1. What is a DORA compliance checklist?
A DORA compliance checklist is a practical way to assess whether an organization has addressed key DORA requirements, including ICT risk management, incident response, resilience testing, third-party risk, and information sharing.
2. Who needs to comply with DORA?
DORA primarily applies to financial entities operating in the EU, including banks, insurers, investment firms, payment institutions, and other covered entities. ICT third-party providers are also part of DORA's framework, with additional EU-level oversight applying to designated critical ICT providers.
3. What are the five pillars of DORA?
The five areas are ICT risk management, ICT-related incident management, digital operational resilience testing, ICT third-party risk management, and information and intelligence sharing.
4. What should a DORA checklist include for SaaS applications?
A SaaS-focused checklist should cover application criticality, data, user and privileged access, non-human identities, integrations, security posture, third-party dependencies, resilience, contractual requirements, and exit options.
5. How does DORA address ICT third-party risk?
DORA requires financial entities to manage risks from ICT providers, including assessing providers before entering contracts, maintaining a register of ICT arrangements, and addressing areas such as data locations, subcontractors, audit rights, security, termination, and exit strategies.
Turn DORA Compliance Into A Continuous Process.
.avif)
.avif)
.avif)
.png)
.avif)
.avif)
.avif)
