CADA Compliance Chain: How SaaS Developers Choose Cloud Infrastructure to Inherit Sovereignty

Post #1570 in the sota.io EU Cloud Compliance Series

The EU Cloud and AI Development Act (CADA) establishes a four-tier assurance framework for cloud services used by public-sector bodies and critical infrastructure operators. If you build SaaS products for government agencies, health authorities, or regulated industries, your clients will increasingly ask not just "where is the data stored?" but "what does your cloud sovereignty chain look like?"

This is the compliance chain question. And it changes how you source infrastructure.

The Compliance Chain Concept

Traditional cloud compliance thinking is binary: either your data is in the EU or it isn't. CADA introduces a richer model. Your SaaS product's sovereignty posture is determined by the weakest link in your infrastructure stack — not the strongest.

A SaaS application deployed on a CADA Level 3-qualified provider can still fail Level 3 requirements if it:

• Routes logs to a US-owned observability platform
• Stores secrets in a secrets manager operated by a company with a US parent
• Uses a CDN whose parent company is subject to CLOUD Act compulsion
• Sends transactional emails through a provider that stores message content in US jurisdiction

The compliance chain extends across every third-party service that processes, stores, or transmits data related to your application. Public-sector procurement increasingly evaluates the full stack, not just the primary compute layer.

The Three Tiers of a SaaS Compliance Chain

Understanding where sovereignty can break down requires mapping your stack into three tiers:

Tier 1: Primary Infrastructure

This is your compute, managed databases, and object storage — the primary CADA-evaluated layer. If you're on AWS Frankfurt, Azure Netherlands, or Google Cloud Belgium, you fail Level 3 regardless of GDPR DPA status. These providers have US parent companies subject to CLOUD Act compulsion. The data centre location is irrelevant to the jurisdictional exposure.

CADA Level 3 at Tier 1 requires:

• Cloud provider headquartered in an EU Member State
• No parent company or controlling shareholder in a third country
• Personnel with infrastructure access physically located in the EU
• No third-country law that could compel data access without EU court oversight

Providers like Hetzner (Germany), OVHcloud (France), and Scaleway (France) can satisfy Level 3 at Tier 1. US-headquartered hyperscalers cannot, regardless of their EU subsidiary structure.

Tier 2: Platform Services

This tier covers managed services you consume on top of primary infrastructure: message queues, managed Kubernetes, scheduled job runners, email delivery infrastructure, DNS, and similar platform-level components. Many SaaS developers underestimate this layer.

Common Tier 2 sovereignty breaks:

• Managed Redis or Kafka from a US-owned provider (even if deployed in EU regions)
• DNS through Cloudflare or Route 53 — both US-owned, potentially subject to compulsion orders
• Email delivery via SendGrid, Mailgun, or Postmark — US ownership, transactional data exposed
• Background job processing through Sidekiq Cloud or similar US-operated platforms

For CADA Level 3 procurement, procurement officers are beginning to ask for Tier 2 documentation. You need to be able to justify each platform service in your stack.

Tier 3: Application-Level Third Parties

This is the tier most developers overlook entirely. It covers every SDK, API integration, analytics tool, monitoring service, and log aggregator your application calls at runtime.

The compliance chain breaks at Tier 3 when:

• Error tracking goes to Sentry.io (US company) or Datadog (US company, NYSE-listed)
• Application metrics are shipped to New Relic or Grafana Cloud (US-owned)
• Log aggregation routes to Logtail (partially US-owned) or Papertrail (US company, SolarWinds subsidiary)
• Feature flags are managed via LaunchDarkly or Split.io (both US companies)
• Frontend analytics use Segment (US, Twilio subsidiary) or Amplitude (US, NASDAQ-listed)
• Web analytics use Google Analytics — directly CLOUD Act-exposed

For high-assurance Level 3 or Level 4 contexts, every API call from your application to a third-party service is a potential sovereignty break. Even a single telemetry ping to a US-controlled endpoint can disqualify a public-sector procurement bid.

Infrastructure Sourcing Decisions That Determine Your Level

The practical question for SaaS developers is not "which cloud am I on?" but "can I document a complete sovereignty chain from compute to application telemetry?"

Here is how each infrastructure sourcing decision maps to CADA levels:

Compute and primary storage: This determines your ceiling. If you're on AWS Frankfurt, you cannot claim Level 3 regardless of what else you do. If you're on Hetzner Cloud or a comparable EU-native provider, Level 3 is achievable.

Database: Managed databases from your primary cloud provider inherit its CADA level. If you're self-managing PostgreSQL on Hetzner VMs, the database sovereignty equals Hetzner's level. If you're using AWS RDS in eu-central-1, the database fails Level 3 for the same reason as the underlying compute.

Object storage: Same inheritance rule as databases. Hetzner Object Storage or OVH Object Storage = Level 3 eligible. AWS S3 (any region) = Level 3 fail.

DNS: Bunny DNS, Hetzner DNS, or OVH DNS are EU-native. Cloudflare and Route 53 are US-owned — DNS queries and zone data are subject to US law.

Email: EU-native email delivery providers include Brevo (formerly Sendinblue, French), Mailbox.org SMTP, or self-hosted Postfix on EU-native infrastructure. US email providers expose transactional message metadata.

Observability and monitoring: EU-native alternatives include Grafana Cloud on Hetzner regions (verify data residency per plan), Better Stack (Czech Republic), and self-hosted Prometheus/Grafana on your EU infrastructure. Datadog, New Relic, Dynatrace (Austrian HQ but US NYSE-listed with US operations) — check carefully.

Secrets management: HashiCorp Vault self-hosted on EU-native infra is CADA-clean. AWS Secrets Manager and Azure Key Vault inherit their provider's US-origin exposure.

Auditing Your Compliance Chain

The most reliable method for CADA compliance chain auditing is to map every network egress point from your application and classify each destination by its controlling legal entity.

A practical audit process:

Step 1 — Inventory all outbound network destinations. Use your existing application monitoring or a short-lived packet capture to enumerate every hostname or IP your application contacts. Include startup, steady-state, and error-path traffic.

Step 2 — For each destination, identify the controlling legal entity. Not the operating entity or the billing entity — the parent company with ultimate control. AWS, Google Cloud, and Microsoft Azure all have German or Dutch operating subsidiaries, but the controlling legal entity is a US corporation.

Step 3 — Classify each entity by CLOUD Act exposure. A company incorporated in the US, publicly traded in the US, or majority-controlled by US shareholders is exposed to CLOUD Act compulsion orders — regardless of where their data centres operate.

Step 4 — Map each CLOUD-Act-exposed dependency to a Level 3 alternative or document the business case for an exception. Some categories (payments, certain identity providers) may have no EU-native equivalent at sufficient scale. Document these as known exceptions in your procurement response.

Step 5 — Verify the alternatives. EU incorporation of an operating entity does not guarantee Level 3 eligibility. Check ultimate ownership structure. Several "EU cloud providers" are majority-owned by US private equity or listed on US exchanges.

Common Mistakes That Break the Chain

Mistake 1: Conflating GDPR DPA compliance with CADA Level 3. A GDPR-compliant Data Processing Agreement with AWS Frankfurt does not satisfy CADA Level 3. GDPR governs what data is processed and how consent is managed. CADA governs who controls the infrastructure and under whose law. These are orthogonal.

Mistake 2: Trusting EU data residency as sufficient. "My data never leaves Germany" is a Level 1 / Level 2 statement. Level 3 requires that no third-country law applies to the people operating the infrastructure, not just where the data sits.

Mistake 3: Ignoring development and staging environments. Public-sector procurement sometimes audits beyond production. If your staging environment ships telemetry to Datadog and your CI/CD pipeline runs on GitHub Actions (Microsoft, US), your compliance chain documentation needs to address this.

Mistake 4: Trusting provider marketing over legal structure. Several cloud providers market EU sovereignty credentials while being structured as US corporations with EU subsidiaries. Read the legal entity structure, not the marketing page.

Mistake 5: Assuming CADA only applies to your primary hosting. The compliance chain assessment covers every service that processes or stores data about your application's operation. This includes error tracking, feature flags, A/B test platforms, and customer success tools.

Practical Sourcing Decisions for a CADA Level 3 SaaS Stack

A reference stack for a CADA Level 3-eligible SaaS application:

The key insight: the default SaaS developer toolchain (AWS + GitHub + Datadog + Sentry.io + Segment) cannot achieve CADA Level 3. Every layer in that default stack has US-jurisdiction exposure.

What This Means for SaaS Developers Targeting Public Sector

If you're building for EU public-sector clients — municipalities, health authorities, federal agencies — CADA compliance chain documentation is becoming a procurement prerequisite rather than a nice-to-have.

The practical implication: you need to make infrastructure sourcing decisions now, before procurement processes begin, because retooling a deployed application's observability and secrets management mid-procurement is costly. SaaS developers who build on EU-native infrastructure from day one inherit CADA Level 3 eligibility at the Tier 1 layer and have a credible starting point for Tier 2 and Tier 3 audits.

Developers who build the default US-cloud-first stack and try to retrofit sovereignty face a migration cost that scales with application complexity — and a procurement documentation challenge that involves explaining away multiple CLOUD Act-exposed dependencies.

The compliance chain is an architectural decision that compounds. The earlier you make EU-native infrastructure choices, the cheaper and more credible your CADA Level 3 positioning becomes.

Next in the CADA series: a complete 25-step developer checklist for building CADA-compliant SaaS applications from scratch — covering infrastructure sourcing, vendor evaluation, procurement documentation, and ongoing compliance auditing.