Skip to main content

Data Sovereignty Compliance in 2026 - DORA, AI Act, and Why Your SaaS Platform is a Liability

· 22 min read
Aytan Jalilova
Aytan Jalilova
Developer Advocate @ IOMETE

January 17, 2025 wasn't just another regulatory deadline. It was the day the Digital Operational Resilience Act went into full force across the EU, fundamentally changing what it means to operate a data platform in the financial sector.

Banks, insurance companies, payment processors, investment firms—every financial institution in the EU now operates under a framework that doesn't just ask "where is your data stored?" It demands proof that you can maintain operational continuity even when third-party ICT providers fail. That you control failover procedures, backup strategies, and incident response without depending on vendor support tickets. That your critical functions aren't concentrated with a single provider who can be compelled by foreign governments to hand over data.

SaaS platforms—Snowflake, Databricks, any vendor where you don't control the infrastructure—can't provide that level of operational independence. And in August 2026, when the EU AI Act reaches full application, the compliance gap widens further.

This isn't a future problem. Financial institutions are being audited right now. Fines are being levied. And the organizations that waited to act are discovering that migrating off SaaS platforms takes months, not weeks.

DORA: Operational Resilience Isn't Optional Anymore​

Before DORA, financial institutions managed operational risk primarily through capital allocation. Set aside enough money to cover potential losses, and regulators were satisfied. That model ignored a critical reality: when your data platform goes down, having capital reserves doesn't help you process transactions, serve customers, or maintain regulatory reporting.

DORA flipped the framework. It's no longer about absorbing losses after an incident. It's about proving you can prevent incidents, detect them immediately when they occur, contain the damage, recover operations, and repair systems—all without relying on third-party vendors to save you.

The five pillars of DORA map directly to infrastructure control:

1. ICT Risk Management​

Financial entities must establish internal governance and control frameworks for ICT risk management. This includes identifying risks, protecting systems, detecting threats, responding to incidents, and recovering operations.

Here's the problem: if your data lakehouse runs on Snowflake or Databricks, you don't control the infrastructure. You can't implement your own threat detection systems. You can't configure custom failover procedures. You're dependent on the vendor's risk management framework, which is designed for their operational needs, not yours.

DORA requires ongoing monitoring of ICT risks, including risks from third-party providers. But SaaS platforms don't expose the level of infrastructure visibility needed for real-time risk assessment. You can't see resource utilization across their clusters. You can't monitor network traffic for anomalies. You can't audit patch cycles or configuration changes.

In self-hosted environments running platforms like IOMETE, you deploy your own monitoring stack—Prometheus, Grafana, custom dashboards tracking every metric that matters. You integrate with your existing SIEM systems. You control alerting thresholds and incident escalation procedures. That's what operational independence looks like.

2. Incident Reporting​

DORA mandates structured processes for reporting significant ICT-related incidents. Financial entities must classify incidents by severity, provide details on impact and response actions, and notify competent authorities without undue delay.

When a SaaS platform experiences an outage, you're a passenger. You get status page updates hours after the incident started. You have no visibility into root cause analysis. You can't independently verify the scope of impact or validate the vendor's timeline. And when regulators ask for incident reports, you're relying on whatever the vendor chooses to disclose.

This isn't theoretical. Snowflake experienced credential-stuffing incidents in mid-2024 that exposed customer data. Organizations using Snowflake had to report incidents they didn't detect, couldn't investigate, and couldn't remediate independently. That's a DORA violation waiting to happen.

In self-hosted deployments, you detect incidents through your own monitoring. You investigate using your own logs. You control the timeline for reporting because you control the infrastructure. When an auditor asks for proof of incident detection capabilities, you show them your alerting rules, your runbooks, your post-incident reviews—all internal, all under your control.

3. Digital Operational Resilience Testing​

DORA requires regular testing of resilience capabilities. This includes vulnerability assessments, penetration tests, and scenario-based testing that simulates real-world cyber threats. Critical financial entities must conduct Threat-Led Penetration Testing (TLPT), where external teams simulate advanced persistent threats against production systems.

You cannot conduct meaningful resilience testing on a SaaS platform. You don't control the attack surface. You can't simulate infrastructure failures. You can't test failover procedures because you don't control the failover mechanisms. The vendor might run their own tests, but those results aren't yours to present to regulators.

Self-hosted platforms let you test everything. Simulate node failures in your Kubernetes cluster. Kill pods mid-query and verify that jobs recover gracefully. Introduce network latency and measure query degradation. Run chaos engineering experiments that would be impossible on shared SaaS infrastructure.

Organizations running IOMETE conduct regular DR drills where entire data centers fail over to backup regions. They document recovery time objectives (RTO) and recovery point objectives (RPO) based on actual test results, not vendor SLAs. That's what resilience testing means under DORA.

4. Third-Party ICT Risk Management​

This is where SaaS platforms become fundamentally incompatible with DORA.

The regulation requires financial entities to assess and continuously monitor risks associated with third-party ICT service providers. Contractual agreements must include provisions for security, incident reporting, and operational resilience. Regular vendor risk assessments and continuous monitoring are mandatory.

But here's the clause that breaks SaaS models: financial entities must ensure that their critical and important functions are not too heavily concentrated with a single provider or small group of providers.

If your entire data lakehouse runs on Snowflake, you've violated this requirement. If all your analytics queries, all your ML pipelines, all your regulatory reporting depends on one vendor's infrastructure, you have unacceptable concentration risk.

DORA explicitly states that financial entities cannot contract with ICT providers who cannot meet resilience requirements. Competent authorities are empowered to suspend or terminate contracts that don't comply.

Self-hosted platforms eliminate concentration risk by design. You own the infrastructure. You can deploy across multiple cloud providers. You can run on-premise for critical workloads and use cloud for burst capacity. You're not locked into a single vendor's operational decisions or geographic footprint.

5. Information Sharing​

DORA encourages (but doesn't require) sharing of cyber threat intelligence among financial entities. This fosters sector-wide collaboration to strengthen defenses.

SaaS vendors don't share threat intelligence with customers. They might publish generic security advisories, but detailed indicators of compromise, attack vectors, and mitigation strategies are proprietary. You're blind to threats that might be targeting your specific deployment because you don't control the infrastructure layer.

In self-hosted environments, you participate in threat intelligence sharing directly. Your security team receives IOCs from industry groups, applies them to your infrastructure, and contributes findings back. That collaborative defense model only works when you control the systems being defended.

The EU AI Act: Why AI Models Make Sovereignty Urgent​

The EU AI Act reaches full application on August 2, 2026. While DORA targets operational resilience, the AI Act targets AI system governance—and the two regulations overlap in ways that make SaaS platforms even more problematic.

High-risk AI systems—those used in recruitment, law enforcement, credit scoring, critical infrastructure management—must demonstrate:

  • Adequate risk assessments documented before deployment
  • Activity logs showing exactly what data was used for training and inference
  • Human oversight with the ability to intervene in automated decisions
  • Transparency about how models make predictions

The penalties for non-compliance go up to 7% of global annual turnover—higher than GDPR violations.

Now consider how AI workloads run on SaaS platforms:

You train a fraud detection model using customer transaction data in Snowflake. The training happens on vendor infrastructure. The feature engineering uses vendor compute. The model artifacts are stored in vendor-managed object storage.

When a regulator asks to see your AI risk assessment, can you prove that the vendor's infrastructure meets AI Act requirements? Can you demonstrate that training data was handled according to GDPR data minimization principles? Can you show activity logs proving that no unauthorized personnel accessed training datasets?

You can't. Because you don't control the infrastructure where the AI workload ran.

The AI Act requires that organizations using high-risk AI systems maintain complete audit trails. For AI systems trained on sensitive data, that means proving:

  • Where the training data originated
  • Who accessed it during the training process
  • What transformations were applied
  • How the model was validated
  • Where inference happens and under what controls

SaaS platforms don't provide that level of audit transparency. They give you query logs and usage metrics, but not infrastructure-level provenance showing exactly where compute happened, which storage buckets were accessed, and what network paths data traversed.

Self-hosted platforms running on infrastructure you control give you direct access to every layer of the stack. You can trace data lineage from source systems through transformations to model training. You can prove that training data never left your VPC. You can show that only authorized data scientists had access to sensitive features. That's what AI Act compliance requires.

Data Sovereignty Laws: The Global Patchwork​

DORA and the AI Act are EU regulations, but data sovereignty is a global concern. Organizations operating internationally face a patchwork of conflicting requirements:

India's Digital Personal Data Protection Act empowers the government to mandate that certain data categories remain in India. Cross-border transfers require government approval.

Saudi Arabia's data protection law requires prior approval for cross-border transfers, with strong expectations for local data storage.

China's PIPL (Personal Information Protection Law) requires local storage for personal data, with cross-border transfers only allowed to government-approved jurisdictions.

The US CLOUD Act allows American authorities to compel disclosure of data held by US-based providers, regardless of where that data is physically stored.

These laws create irreconcilable conflicts for SaaS platforms. Snowflake and Databricks are US-based companies. If EU regulators demand proof that US authorities cannot access EU citizen data, SaaS vendors cannot provide it. The CLOUD Act explicitly gives US law enforcement the power to demand data from US companies, even data stored in EU data centers.

This isn't hypothetical. GDPR's Schrems II ruling invalidated data transfers to the US precisely because of inadequate protection against government surveillance. Organizations using US-based SaaS platforms to process EU data are in violation the moment that data crosses a border or becomes accessible to a US-based vendor.

Self-hosted platforms solve this by keeping data under local jurisdiction. Deploy in the EU, and data stays in the EU. Deploy in India, and data stays in India. No vendor can be compelled to hand over data because there's no vendor with access to it. You control encryption keys, access policies, and audit logs. That's what data sovereignty actually means.

The SaaS Liability: Operational Independence vs. Vendor Dependency​

The fundamental incompatibility between DORA/AI Act requirements and SaaS platforms boils down to one principle: operational independence.

DORA requires that financial entities can maintain critical functions even when third-party ICT providers fail. The AI Act requires complete audit trails and governance controls over AI systems. Data sovereignty laws require that data remains under local jurisdiction and control.

SaaS platforms cannot provide operational independence. Their business model depends on centralized control, shared infrastructure, and the ability to push updates across all customers simultaneously. When a SaaS platform experiences an outage, you're offline until the vendor fixes it. When a foreign government demands access to data, the vendor must comply with local laws. When regulators audit your AI systems, you can only show what the vendor chooses to expose.

Self-hosted platforms provide operational independence by design:

  • Failover is under your control – You define RTO/RPO targets, implement backup strategies, and test recovery procedures on your schedule. IOMETE deployments support multi-region failover with automated snapshot replication across availability zones.
  • Incident response is yours to manage – You detect threats, investigate incidents, and remediate vulnerabilities without waiting for vendor support. IOMETE integrates with your existing SIEM systems and alerting infrastructure.
  • Audit trails are complete and accessible – You log every query, every data access, every system change at infrastructure level. IOMETE provides built-in audit logging for compliance reporting without third-party dependencies.
  • Data sovereignty is guaranteed – Data stays where you deploy it, under the jurisdiction you choose. IOMETE runs entirely within your infrastructure boundaries—on-premise, in your VPC, or air-gapped.
  • AI governance is enforceable – You control where models train, what data they access, and how they're validated. IOMETE's Apache Iceberg tables maintain complete lineage from raw data through transformations to model artifacts.

Organizations running IOMETE demonstrate DORA compliance by showing their own monitoring dashboards, their own incident runbooks, their own DR test results. They demonstrate AI Act compliance by providing complete data lineage from source systems through model training to production inference. They demonstrate data sovereignty by deploying in their own VPCs, data centers, or air-gapped networks.

This isn't just better compliance. It's the only viable path to compliance for regulated industries.

Who's Already Migrated (And Why)​

The migration from SaaS to self-hosted isn't future planning. It's happening right now:

European banks are repatriating data from US-based SaaS platforms to meet DORA operational resilience requirements. They can't afford vendor concentration risk, and they can't accept that a single outage at Snowflake or Databricks takes down their entire analytics infrastructure.

Insurance companies subject to DORA are moving ML pipelines to self-hosted platforms because they need complete audit trails for AI risk assessments. They can't demonstrate AI Act compliance when model training happens on vendor infrastructure they don't control.

Payment processors are adopting self-hosted lakehouses to eliminate third-party dependency risk. DORA's requirement for operational continuity during vendor failures means they need infrastructure they can operate independently.

Healthcare organizations handling patient data under GDPR and HIPAA are choosing self-hosted platforms to avoid third-party processor agreements and ensure data never leaves their controlled environments.

Government agencies requiring air-gapped deployments for classified workloads cannot use SaaS platforms by definition. They're adopting self-hosted lakehouses for data sovereignty and zero-trust architecture compliance.

The pattern is consistent: organizations with serious regulatory obligations are choosing infrastructure control over vendor convenience. They're willing to invest in operational capability because the alternative—regulatory fines, data breaches, operational disruptions—is far more expensive.

What Compliance Actually Costs (And What It Saves)​

The question isn't whether to comply. DORA is enforceable now. The AI Act becomes enforceable in August 2026. The question is: what's the cost of compliance, and what's the cost of non-compliance?

Cost of Non-Compliance​

DORA fines are determined by individual EU member states but can be substantial. Financial entities that cannot demonstrate operational resilience face not just fines, but potential suspension of operations until compliance is achieved.

AI Act penalties go up to 7% of global annual turnover. For a financial institution processing billions in transactions, that's hundreds of millions in potential fines.

Data breach costs in the financial sector average $5.9 million per incident, with 223 days to identify and contain breaches. DORA's focus on operational resilience is explicitly designed to reduce this exposure.

Operational disruptions from vendor outages cost more than money—they erode customer trust, damage reputation, and trigger regulatory scrutiny that persists long after the incident is resolved.

Cost of Compliance (Self-Hosted Path)​

Infrastructure costs for self-hosted platforms are predictable and transparent. IOMETE charges $500/vCPU/year for licensing with no hidden fees or compute markups. Underlying compute and storage are billed directly by your cloud provider or run on your own hardware. For a typical financial institution running 500 vCPUs, that's $250K/year in licensing plus direct infrastructure costs—no vendor lock-in, no usage-based pricing surprises.

Operational overhead is minimal if you're already running Kubernetes. IOMETE deploys as a containerized application—define resource requirements, deploy via Helm charts, monitor through standard observability tools like Prometheus and Grafana. Organizations already operating Kubernetes infrastructure find incremental management overhead negligible.

Migration effort takes 3-6 months depending on table count and complexity. Export data from SaaS platforms to object storage (S3, Azure Blob, GCS), convert to Apache Iceberg tables using IOMETE's migration tools, validate queries against production workloads, run dual environments during transition, then cut over when confidence is established.

Ongoing compliance is automated through IOMETE's built-in table maintenance. Automated compaction handles small files, snapshot expiration manages metadata growth, orphan file cleanup prevents storage bloat. Monitoring dashboards surface table health metrics for regulatory audits. Audit logs capture every data access event for compliance reporting.

The total cost of ownership for a self-hosted lakehouse is 40-60% lower than equivalent SaaS workloads, while providing the operational independence required for DORA and AI Act compliance.

The Timeline: How Fast Can You Actually Migrate?​

DORA is enforceable now. The AI Act becomes enforceable in August 2026. If you're still running critical workloads on SaaS platforms, the timeline is tight.

Month 1-2: Assessment and Planning

  • Inventory current SaaS dependencies and data volumes
  • Map critical functions and identify DORA/AI Act compliance gaps
  • Define target architecture (on-premise, cloud, hybrid)
  • Estimate migration effort and resource requirements

Month 3-4: Infrastructure Deployment

  • Deploy self-hosted lakehouse platform (IOMETE on Kubernetes)
  • Configure monitoring, alerting, and incident response integrations
  • Set up development and staging environments with IOMETE's built-in SQL editor and job orchestration
  • Validate connectivity to source systems and existing data catalogs

Month 5-6: Data Migration and Validation

  • Export tables from SaaS platform to object storage
  • Convert to Apache Iceberg format
  • Migrate queries and validate results
  • Run dual environments (SaaS + self-hosted) for critical workloads

Month 7: Cutover and Decommission

  • Switch production traffic to self-hosted platform
  • Monitor performance and stability
  • Decommission SaaS contracts once validation is complete

Organizations running IOMETE typically complete migration in 4-6 months with minimal disruption to ongoing operations. The key is running dual environments during transition—SaaS for production stability, self-hosted for validation—then cutting over once confidence is established.

What Happens If You Don't Act​

Regulatory enforcement isn't theoretical anymore. DORA audits are happening. Financial institutions that cannot demonstrate operational resilience are being flagged for remediation. And when the AI Act reaches full enforcement in August 2026, regulators will have even more grounds to challenge SaaS dependencies.

The organizations that waited are discovering that migration takes longer than they expected. SaaS platforms don't make it easy to export data. Query optimization that worked on vendor infrastructure doesn't translate directly. Governance frameworks need to be rebuilt for self-hosted environments.

The longer you wait, the more expensive and disruptive the migration becomes. And the compliance deadline doesn't move.

If you're operating in financial services, healthcare, or any regulated industry, the question isn't whether to move to self-hosted infrastructure. The question is how fast you can execute the migration before the next audit cycle catches you in violation.

Frequently Asked Questions​

Frequently Asked Questions

What exactly does DORA require for third-party ICT providers?

DORA requires financial entities to assess and continuously monitor risks from third-party ICT providers, ensure contracts include security provisions, and avoid excessive concentration risk with any single provider.

Financial institutions must conduct due diligence before contracting with ICT providers, implement ongoing monitoring, and ensure that critical functions are not too heavily concentrated with one vendor.

Organizations running self-hosted platforms like IOMETE eliminate third-party dependency by owning the infrastructure, making them directly responsible for operational resilience without relying on vendor SLAs.

Can SaaS platforms ever be DORA-compliant?

SaaS platforms can meet some DORA requirements through contractual commitments and security controls, but they cannot provide the operational independence required for true resilience.

DORA requires that financial entities can maintain critical functions even when third-party providers fail. By definition, SaaS platforms create vendor dependency that prevents independent operation during outages.

Organizations using IOMETE demonstrate operational independence by controlling failover procedures, incident response, and infrastructure recovery without vendor dependencies.

How does the AI Act change data platform requirements?

The AI Act requires complete audit trails for high-risk AI systems, including proof of where training data originated, who accessed it, and how models were validated. This level of infrastructure-level provenance is impossible on SaaS platforms.

High-risk AI systems face penalties up to 7% of global annual turnover for non-compliance, making audit transparency critical.

In IOMETE deployments, organizations maintain complete data lineage from source systems through model training, with infrastructure-level logs proving that training data never left controlled environments.

What's the timeline for DORA and AI Act enforcement?

DORA entered full enforcement on January 17, 2025. The EU AI Act reaches full application on August 2, 2026. Organizations still using SaaS platforms for critical workloads have less than a year to migrate before AI Act enforcement begins.

Financial institutions are being audited now for DORA compliance. Waiting until AI Act enforcement starts means migrating under regulatory pressure, which is far more expensive and disruptive.

Organizations running IOMETE typically complete migration in 4-6 months, making early 2026 the deadline for starting migration if you want to be ready before August enforcement.

How do you demonstrate operational resilience testing under DORA?

DORA requires regular vulnerability assessments, penetration tests, and scenario-based testing simulating real-world threats. Critical entities must conduct Threat-Led Penetration Testing (TLPT) where external teams simulate advanced attacks.

You cannot conduct meaningful resilience testing on SaaS infrastructure you don't control. Testing requires simulating infrastructure failures, which is impossible when the vendor manages the infrastructure.

Organizations running IOMETE conduct DR drills simulating node failures, network partitions, and data center outages, documenting actual RTO/RPO based on test results rather than vendor SLAs.

What happens if your SaaS provider has an outage during a DORA audit?

If you cannot maintain critical functions during a vendor outage, you fail DORA operational resilience requirements. Regulators can require remediation, impose fines, or suspend operations until compliance is achieved.

DORA explicitly requires that financial entities demonstrate continuity even when third-party providers fail. Vendor SLAs are not sufficient—you must prove independent operational capability.

Organizations running IOMETE demonstrate failover to backup clusters, restore from snapshots, and maintain query processing during infrastructure failures—all without vendor dependency.

Can you run IOMETE in multiple jurisdictions to meet data sovereignty laws?

Yes. IOMETE deploys wherever you need it—EU data centers for GDPR compliance, India for DPDP Act requirements, on-premise for air-gapped government workloads. Data stays under the jurisdiction you choose.

Multi-jurisdictional organizations run separate IOMETE instances per region, ensuring data sovereignty without vendor intermediaries who might be subject to conflicting legal requirements.

This eliminates the CLOUD Act conflict where US-based SaaS vendors can be compelled to hand over EU data despite physical storage location.

What's the cost difference between SaaS and self-hosted for DORA compliance?

Self-hosted platforms like IOMETE cost 40-60% less than SaaS alternatives while providing the operational independence DORA requires.

A typical deployment costs $250K/year in IOMETE licensing (500 vCPUs at $500/year) plus direct infrastructure costs, compared to $2M+ for equivalent SaaS consumption.

Organizations already operating Kubernetes find incremental operational overhead minimal, while gaining complete control over failover, incident response, and audit capabilities required for DORA compliance.

About IOMETE​

IOMETE is a self-hosted data lakehouse platform built on Apache Iceberg, Apache Spark, and Kubernetes. It runs entirely within your infrastructure—on-premise, in your VPC, or in air-gapped environments—giving you complete control over data sovereignty, operational resilience, and compliance. With DORA-ready monitoring, AI Act-compliant audit trails, and complete operational independence from vendor dependencies, IOMETE is designed for financial services, healthcare, and government organizations that cannot compromise on regulatory compliance.

Learn more at iomete.com or schedule a demo to see how self-hosted lakehouse architecture meets DORA and AI Act requirements.