CADA Developer Checklist: 25 Steps to Sovereignty-Compliant SaaS Infrastructure

Post #1571 in the sota.io EU Cloud Compliance Series — CADA-CLOUD-SOVEREIGNTY-LEVELS-2026 #5/5 Finale

This is the finale of the CADA Cloud Sovereignty Series. Over the previous four posts, we covered the EU Tech Sovereignty Package's four assurance levels and which providers qualify, the technical requirements for Level 3, how CADA compares to EUCS, and how the compliance chain flows from cloud provider through SaaS application to end customer. This post consolidates everything into a single, executable 25-step checklist.

The checklist is organised into five phases that mirror a typical SaaS development lifecycle: provider selection, architecture review, third-party dependencies, operational controls, and procurement readiness. Each step is actionable — it either passes, fails, or requires remediation. Work through them in sequence; the later phases assume the earlier ones have been completed.

How to Use This Checklist

Target audience: SaaS developers and technical leads building products for EU public-sector customers, critical infrastructure operators, or regulated industries where CADA Level 3 compliance will be required in procurement requirements.

CADA Level 3 recap: Requires EU-owned cloud provider, EU-based personnel with data access, EU jurisdiction throughout the operational stack, and no non-EU extraterritorial legal access vector (no CLOUD Act exposure). AWS, Azure, and GCP fail Level 3 on ownership and jurisdiction grounds regardless of EU data centres.

Scoring: Each step is binary (✅ Pass / ❌ Fail / ⚠️ Needs Review). Aim for 25/25 Pass. Items marked ❌ are blockers for CADA Level 3 procurement. Items marked ⚠️ are risks that require documented mitigation.

Phase 1: Cloud Provider Selection (Steps 1–5)

The foundation of CADA compliance is your primary cloud provider. Get this wrong and no amount of downstream architecture work can compensate.

Step 1 — Verify EU Incorporation of Your Cloud Provider

What to check: Your cloud provider's legal entity is incorporated in an EU member state, not merely operating an EU subsidiary of a non-EU parent.

How to verify:

• Check the provider's company registry entry (Handelsregister for German providers, RCS for French, etc.)
• Confirm that the entity you contract with is the EU-incorporated entity, not an EMEA subsidiary
• Review whether the parent company is incorporated outside the EU/EEA

Passes: Hetzner Online GmbH (Germany), OVHcloud SAS (France), Scaleway SAS (France, Iliad Group), IONOS SE (Germany, United Internet AG), Exoscale (Switzerland, A1 Digital — note: CH is not EU but EEA-adjacent, verify for your procurement context)

Fails: AWS EMEA SARL (parent: Amazon.com Inc., Delaware USA), Microsoft Ireland Operations Ltd (parent: Microsoft Corporation, Washington USA), Google Cloud EMEA Ltd (parent: Google LLC, Delaware USA)

Remediation if fail: Migrate to an EU-incorporated provider. The compliance chain cannot be repaired at the architecture level if the provider fails Level 3.

Step 2 — Confirm No CLOUD Act Exposure

What to check: The provider cannot be compelled by US law enforcement to disclose your data without an EU court order.

How to verify:

• Check whether the provider's parent company is incorporated in the United States (CLOUD Act applies to all US-incorporated entities regardless of data location)
• Review the provider's legal documentation for CLOUD Act disclosure policies
• Verify the provider has no US entities in its corporate structure that could be compelled

Key principle: CLOUD Act exposure is a function of corporate structure, not data location. AWS storing your data in Frankfurt does not remove CLOUD Act exposure because Amazon.com Inc. (Delaware) remains subject to US law globally.

Remediation if fail: This is a Level 2/3 blocker. Only structural change — migrating to a provider without US parent — resolves this.

Step 3 — Verify EU-Only Operational Personnel Access

What to check: Administrative access to your infrastructure — including emergency access, support access, and maintenance access — is performed exclusively by EU-resident personnel.

How to verify:

• Request the provider's access control policy document
• Confirm whether on-call or support staff based outside the EU can access customer environments
• Check whether management tooling used for your infrastructure is operated from non-EU locations

Passes: Providers like Hetzner maintain EU-only operations centres. Verify for your specific provider through their DPA annexes.

Needs Review: Providers with global support teams who may have technical access from non-EU locations for incident response. Even with EU-incorporated parent, this creates Level 3 risk if non-EU staff can access production systems.

Step 4 — Obtain the Provider's CADA Compliance Declaration

What to check: Your provider has issued a formal CADA compliance declaration or is in the process of obtaining CADA conformity assessment body (CAB) certification.

How to verify:

• Check the provider's compliance documentation page
• Request a written declaration of CADA Level 3 conformity
• If CAB certification is pending, request the expected certification timeline

Note: As of June 2026, CADA conformity assessment bodies are newly operational. Full third-party CADA certifications are in process. Providers with existing EUCS High or equivalent certifications and EU-native corporate structures are generally in strong position — document this with a written declaration.

Remediation if fail: Proceed with a self-declaration based on verified corporate structure and operational controls, documented in your compliance dossier.

Step 5 — Review the Data Processing Agreement for CADA Alignment

What to check: Your DPA with the provider reflects CADA Level 3 requirements: EU jurisdiction governing clause, no third-country data access, EU-only personnel clause, and incident notification under EU jurisdiction.

How to verify:

• Review DPA Section on governing law: must specify EU member state law, not Delaware or other non-EU jurisdiction
• Check for explicit exclusion of third-country data access
• Verify that the provider's standard DPA does not include clauses permitting non-EU parent access

Remediation if fail: Request a DPA amendment. CADA-compliant providers should be willing to add EU jurisdiction governing clauses and third-country access exclusions.

Phase 2: Architecture Review (Steps 6–10)

With the right provider selected, the next phase reviews your application architecture for sovereignty risks introduced by design choices.

Step 6 — Audit All Managed Services for CADA Compliance

What to check: Every managed service from your provider (managed databases, object storage, CDN, email relay, managed Kubernetes, etc.) is included in your CADA compliance chain.

How to verify:

• List every managed service you consume from your cloud provider
• Verify that each service is operated by the same EU-incorporated entity and under the same CADA controls as your primary compute
• Check whether managed service operations are handled by the same EU-only personnel pool or whether some managed services use a different operational team

Common pitfall: Developers ensure their Kubernetes nodes are on a CADA Level 3 provider but use a managed Redis or database service that is operated by a different team with different personnel access policies.

Step 7 — Review Multi-Cloud and Hybrid Footprint

What to check: If you run multi-cloud or hybrid, every component handling public-sector customer data satisfies CADA Level 3.

How to verify:

• Map all workloads handling regulated data
• For each workload, identify which cloud provider runs it
• Verify that workloads handling public-sector data do not have compute or storage on non-CADA-Level-3 providers

Exception handling: Development and CI/CD environments that never touch production data can remain on other providers. Document this separation explicitly. The CADA compliance requirement applies to data handling, not to development tooling.

Step 8 — Verify Data Flow Does Not Leave CADA-Compliant Infrastructure

What to check: Data from public-sector customers does not flow through any component running on non-CADA-compliant infrastructure, even transiently.

How to verify:

• Trace request flows from user input through to database write and response
• Identify any intermediate processing that occurs on infrastructure outside your CADA-compliant provider
• Check background job queues, webhook processors, and async workers — these often run on different infrastructure than the primary application

Common pitfall: The main application runs on Hetzner, but background jobs for data exports run on a legacy AWS Lambda function "temporarily."

Step 9 — Confirm No US-Routed DNS or CDN

What to check: DNS resolution and content delivery do not route through US-operated infrastructure that could expose metadata to CLOUD Act jurisdiction.

How to verify:

• Check your DNS provider's corporate structure and operational jurisdiction
• If using a CDN, verify the CDN operator is EU-incorporated or that your usage is limited to non-sensitive static assets
• Review whether CDN edge nodes in EU locations are operated by the EU entity or by a US parent

Context: CDN and DNS are sometimes overlooked because they are seen as "just routing." However, DNS queries and CDN access logs constitute metadata about your users and can be subject to CLOUD Act requests if the provider is US-incorporated.

Pragmatic approach: For CDN, separating static assets (images, CSS, JS) from API traffic and using a CADA-compliant provider for the API tier satisfies the spirit of Level 3 for most procurement requirements.

Step 10 — Review Backup and Disaster Recovery Infrastructure

What to check: Backup storage and disaster recovery infrastructure meets the same CADA Level 3 requirements as primary infrastructure.

How to verify:

• Identify where backups are stored
• Verify that backup storage uses a CADA-compliant provider
• Check whether disaster recovery runbooks call for failover to non-CADA-compliant providers

Common pitfall: Primary application runs on Hetzner, but database backups are shipped to AWS S3 "for reliability." The backup creates a CLOUD Act exposure for all backed-up data.

Remediation: Use Hetzner Object Storage or another CADA-compliant object storage provider for all backup data.

Phase 3: Third-Party Dependencies (Steps 11–15)

Third-party integrations are where CADA compliance most commonly breaks down. Developers carefully select a CADA-compliant primary provider and then introduce a dozen third-party SaaS tools that route data through US-operated infrastructure.

Step 11 — Inventory All Third-Party SaaS Integrations That Handle Customer Data

What to check: A complete list of every third-party service that receives, processes, or stores data from your public-sector customers.

How to verify:

• List all external API integrations
• Include analytics, error tracking, logging, email delivery, payment processing, support ticketing, feature flagging, and communication tools
• Map which integrations receive personally identifiable information versus which receive only aggregate or non-customer-specific data

Output: A third-party data flow map documenting which services handle which categories of customer data.

Step 12 — Classify Third-Party Integrations by CADA Risk

What to check: Each third-party integration is classified by its CADA risk level based on what data it receives and whether it is CADA Level 3 compliant.

Classification tiers:

• Tier A — CADA-compliant: EU-incorporated provider handling customer data. No risk.
• Tier B — Non-compliant but non-sensitive: US-operated service handling only non-customer-specific data (e.g., aggregate error counts, system metrics without user context). Low risk with documentation.
• Tier C — Non-compliant handling sensitive data: US-operated service receiving PII, API keys, user behaviour data, or other customer-sensitive information. Blocker for CADA Level 3.

Common Tier C findings:

• Error tracking (Sentry with US-hosted plan)
• APM / observability (Datadog US endpoints)
• Email delivery (SendGrid, Mailgun with US infrastructure)
• Authentication providers (Auth0 with US-operated tenants)
• Analytics (Mixpanel, Amplitude with US data storage)

Step 13 — Replace or Isolate Tier C Integrations

What to check: Every Tier C integration has been either replaced with a CADA-compliant alternative or isolated so that it no longer receives customer-sensitive data.

Replacement options for common Tier C tools:

Isolation approach: Where replacement is not immediately feasible, strip all customer-identifiable data from events sent to Tier C tools. Error tracking can receive stack traces without user IDs. Analytics can receive page views without session fingerprinting.

Step 14 — Review Open Source Dependencies for Telemetry and Phone-Home Behaviour

What to check: Open source libraries and frameworks in your stack do not have built-in telemetry that phones home to US-operated infrastructure.

How to verify:

• Check the documentation of major frameworks for opt-in/opt-out telemetry
• Review network traffic from your application in a controlled environment for unexpected outbound connections
• Check CI/CD tooling for telemetry that might send build data or dependency information to US services

Common findings:

• Next.js telemetry (opt-out via NEXT_TELEMETRY_DISABLED=1)
• Kubernetes metrics exporters with default remote endpoints
• npm / package manager analytics
• Docker build telemetry

Remediation: Disable all opt-in telemetry via environment variables. Document disabled telemetry in your compliance dossier.

Step 15 — Verify Supply Chain: CI/CD Does Not Send Build Artefacts to Non-CADA Infrastructure

What to check: Your CI/CD pipeline does not send built artefacts, secrets, or source code to non-CADA-compliant infrastructure.

How to verify:

• Review where build artefacts are stored (container registries, artefact repositories)
• Check whether CI runners have access to production secrets and whether those runners are on CADA-compliant infrastructure
• Verify that container images are pulled from CADA-compliant registries, not DockerHub (US-operated)

Pragmatic boundary: CI/CD infrastructure that builds code but never handles production customer data is typically excluded from CADA Level 3 scope in procurement discussions. However, document this exclusion explicitly — procurement teams increasingly ask about build pipeline access to production secrets.

Phase 4: Operational Controls (Steps 16–20)

Operational controls ensure that your day-to-day operations do not inadvertently break the CADA compliance you've built into the architecture.

Step 16 — Implement EU-Only Access Policy for Production Systems

What to check: Access to production systems — including SSH, Kubernetes API, database consoles, and admin panels — is restricted to team members in EU member states.

How to implement:

• Document the list of team members with production access and their locations
• Implement IP-based access restrictions to limit production access to EU IP ranges where feasible
• Review on-call rotations to ensure non-EU team members are not in the rotation for production access

For globally distributed teams: Create a documented exception process for non-EU team members. Access should require EU-based approval, be logged, and be limited to read-only or break-glass scenarios with full audit trail.

Step 17 — Establish Audit Logging for All Data Access

What to check: All access to customer data is logged with sufficient detail to demonstrate EU-only access to CADA auditors.

What logs must capture:

• Identity of the accessor (user ID, service account)
• Timestamp and source IP
• Nature of access (read, write, delete)
• Data classification of accessed resource

Log storage: Access logs must themselves be stored on CADA-compliant infrastructure. Shipping access logs to a US-operated SIEM creates the same CLOUD Act exposure as the data access itself.

Step 18 — Implement Incident Response Procedure for Data Access Requests

What to check: Your incident response procedure includes a documented process for handling data access requests from law enforcement or government bodies.

Key elements:

• All requests must be directed to your EU legal entity
• No voluntary disclosure of customer data to non-EU authorities without an EU court order
• Any request from a non-EU authority must be escalated to EU legal counsel before any response
• Customer notification procedure for law enforcement access requests (where legally permitted)

Note: CADA Level 3 certification will likely require documented procedures in this area. Procurement questionnaires increasingly ask for this documentation.

Step 19 — Conduct Quarterly CADA Compliance Reviews

What to check: You have a documented process for reviewing your CADA compliance posture on a regular cadence.

Review agenda:

• New third-party integrations added since last review (classify against CADA risk tiers)
• Personnel changes affecting EU-only access policy
• Cloud provider changes or new managed service adoptions
• Upstream provider compliance updates (new CADA CAB certifications, corporate structure changes)
• Any incidents or near-misses that touched the CADA compliance boundary

Documentation output: A dated compliance review record that can be provided to procurement teams as evidence of ongoing compliance management.

Step 20 — Implement Data Residency Enforcement at the Application Layer

What to check: Your application enforces EU data residency at the code level, not just through provider configuration.

How to implement:

• Use explicit region/zone configuration in all infrastructure-as-code templates (no "auto" region selection)
• Implement application-level guards that reject configuration changes that would move data outside the EU
• Add infrastructure tests that verify data storage endpoints resolve to EU regions

Purpose: Provider configuration can be changed accidentally or by a misconfigured IaC pipeline. Application-layer enforcement provides a second line of defence and creates an audit trail.

Phase 5: Documentation and Procurement Readiness (Steps 21–25)

The final phase ensures you can demonstrate CADA compliance to procurement teams and auditors — transforming technical controls into auditable evidence.

Step 21 — Create the CADA Compliance Dossier

What to check: You have a single, versioned document that records your CADA Level 3 compliance posture with evidence.

Dossier sections:

1. Provider selection rationale with legal entity verification
2. Architecture overview with data flow diagram
3. Third-party integration inventory with CADA risk classifications
4. Personnel access policy with EU-only access documentation
5. DPA and legal documentation
6. Audit log configuration
7. Incident response procedure
8. Quarterly review records

Versioning: The dossier should be version-controlled (git or equivalent) so that changes can be audited over time. Procurement teams may ask for the compliance posture at a specific historical date.

Step 22 — Map Your CADA Compliance to Common Procurement Questions

What to check: You have pre-prepared answers to the standard CADA questions that appear in public-sector procurement questionnaires.

Common questionnaire questions and your prepared answers:

Tip: Most EU public procurement portals use a questionnaire format based on EUCS or CADA standard question sets. Prepare answers in a reusable document that can be adapted per tender.

Step 23 — Obtain Written CADA Declarations from Critical Sub-Processors

What to check: Your key sub-processors (cloud provider, managed database provider, email delivery provider) have provided written CADA compliance declarations.

What to request:

• Written confirmation of EU corporate incorporation
• Confirmation of no CLOUD Act exposure
• Confirmation of EU-only personnel access for customer environments
• Commitment to notify you of any change in corporate structure that would affect CADA Level 3 compliance

Practical note: Larger EU-native providers (Hetzner, OVHcloud, Scaleway) have standard CADA declaration documents available. Request the most recent version and include it in your compliance dossier.

Step 24 — Establish a CADA Change Management Process

What to check: You have a documented process that ensures future infrastructure or tooling changes are reviewed against CADA compliance before implementation.

Process elements:

• CADA impact assessment for all infrastructure changes
• Sign-off requirement from technical lead before introducing new third-party integrations
• Automated checks in CI/CD that flag new external endpoints for CADA review
• Change log entries referencing CADA compliance review for all infrastructure changes

Purpose: CADA compliance is not a one-time audit. Your posture changes every time you add a new tool, expand the team, or change providers. The change management process ensures compliance drift is caught before it becomes a procurement blocker.

Step 25 — Conduct a Pre-Procurement Mock Audit

What to check: Before submitting a response to a public-sector procurement tender, you have conducted an internal mock audit against the CADA checklist.

Mock audit scope:

• Walk through all 25 steps of this checklist
• For each step, verify that documentary evidence is current (not more than 6 months old)
• Identify any gaps and remediate before the procurement response deadline
• Have a team member who was not involved in building the compliance controls conduct the review

Timing: Conduct the mock audit at least 4 weeks before a procurement response deadline. Remediation of findings — particularly replacing Tier C third-party tools — can take 2–4 weeks.

Summary Checklist

Phase 1: Provider Selection

• Step 1: Cloud provider is EU-incorporated
• Step 2: No CLOUD Act exposure
• Step 3: EU-only operational personnel access
• Step 4: Provider CADA compliance declaration obtained
• Step 5: DPA reviewed for CADA alignment

Phase 2: Architecture Review

• Step 6: All managed services in CADA compliance chain
• Step 7: Multi-cloud/hybrid footprint reviewed
• Step 8: Data flow verified — no non-CADA transit
• Step 9: DNS/CDN reviewed for US-routing
• Step 10: Backup/DR infrastructure CADA-compliant

Phase 3: Third-Party Dependencies

• Step 11: Third-party integration inventory complete
• Step 12: Integrations classified by CADA risk tier
• Step 13: Tier C integrations replaced or isolated
• Step 14: OSS telemetry and phone-home behaviour reviewed
• Step 15: CI/CD supply chain reviewed

Phase 4: Operational Controls

• Step 16: EU-only access policy implemented
• Step 17: Audit logging for all data access
• Step 18: Incident response procedure documented
• Step 19: Quarterly compliance review process established
• Step 20: Data residency enforcement at application layer

Phase 5: Documentation and Procurement Readiness

• Step 21: CADA compliance dossier created
• Step 22: Procurement question answers prepared
• Step 23: Written CADA declarations from sub-processors
• Step 24: CADA change management process established
• Step 25: Pre-procurement mock audit process documented

The sota.io Position in This Checklist

SaaS developers building on sota.io can pre-check several items in this list. sota.io is an EU-native managed PaaS running on Hetzner Germany infrastructure — EU-incorporated provider, no CLOUD Act exposure, EU-only operations. Deploying on sota.io means Steps 1, 2, 3, and 10 are addressed at the platform level, with Step 4 and 5 supported through sota.io's standard compliance documentation.

The remaining steps — architecture review, third-party dependencies, operational controls, and procurement documentation — are the developer's responsibility, but the foundation is clean.

CADA Series Wrap-Up

This post closes the CADA-CLOUD-SOVEREIGNTY-LEVELS-2026 series:

1. [CADA #1/5] — The four assurance levels and which providers qualify
2. [CADA #2/5] — Level 3 Technical Requirements for EU Cloud Sovereignty
3. [CADA #3/5] — CADA vs EUCS: which certification matters when
4. [CADA #4/5] — Compliance chain: how SaaS developers inherit sovereignty
5. [CADA #5/5] — This checklist: 25 steps to CADA-compliant SaaS

The EU Tech Sovereignty Package is now law. Public-sector procurement requirements will reference CADA Level 3 within 12–18 months across most EU member states. Developers who build CADA compliance into their architecture now will have a structural procurement advantage over those who retrofit it later.