Email infrastructure for public-sector bodies that need to answer "no" to the third-country-law question

The honest answer: we are aligned with the controls but not blanket-certified on all three. SecNumCloud 3.2 is a French national qualification process tied to specific service offerings; we pursue it on a per-engagement basis when the procuring authority requires it, with typical preparation timeline of 4-6 months. C5 is closer to a control-area audit framework; we maintain documentation aligned with the C5 control areas and can offer a C5 audit at the procuring authority's request, typically completing within 3 months. ENS Medium is our baseline alignment for Spanish public-sector engagements; ENS High is achievable with additional contractual controls.

The pattern we recommend for procurement teams: include the certification as a contract-condition rather than a tender-precondition. This lets you select the best-fit provider on technical and sovereignty grounds, then condition the contract award on certification completion within a defined timeline. The alternative — requiring certification as a tender precondition — typically narrows the field to providers who already have the certification for a specific service variant, and those service variants may not match your operational requirements.

Honest: every cloud provider operating in Europe today depends on US-origin or East-Asian-origin CPUs at the silicon layer. Intel Xeon and AMD EPYC for server compute; the network and storage controllers similarly originate outside the EU. The European Chips Act adopted in 2023 is on a 5-10 year horizon to establish indigenous European silicon manufacturing capacity at scale; until that horizon arrives, all of us share this dependency.

What this means for sovereignty framework alignment: Objective 5 (supply-chain sovereignty) is the one objective where no current EU cloud provider can claim full compliance. The Framework acknowledges this implicitly by treating supply-chain sovereignty as a graduated objective rather than a bright-line test. Our position with procurement teams is to disclose the dependency clearly, document the mitigations (hardware lifecycle management, supply-chain diversification, secure boot and firmware verification), and treat the CPU question as a sector-wide architectural concern rather than a provider-specific risk.

Schrems II and the EDPB Recommendations 01/2020 require any data exporter using SCCs to a third-country provider to run a TIA and add supplementary measures if needed. For our customer base this question typically inverts: our customers are EU controllers, we are EU processors, no third-country transfer occurs in normal operation, so the TIA question doesn't fire at all.

We include a pre-completed TIA template in our DPA package documenting the EU-only baseline, the operational data flows, the sub-processor jurisdictional analysis, and the technical and contractual measures in place. For the rare case of any cross-border processing (typically only when a customer explicitly opts in to a non-EU sub-processor for a specific use case), the TIA is updated with the additional supplementary measures from EDPB Recommendations 01/2020 — pseudonymization, encryption with customer-controlled keys, data splitting — to satisfy the proportionality test the EDPB requires.

90-120 days end-to-end for a typical national-ministry-scale migration. The breakdown: 30 days for procurement readiness and contract execution; 30 days for technical onboarding including DNS preparation, DKIM key generation, DMARC progression to p=quarantine, IP warmup; 30 days for parallel-run validation where a portion of traffic flows through both providers; 30 days for full cutover, decommissioning of the legacy provider, and final DMARC progression to p=reject.

For larger cross-ministry deployments (multi-agency, multi-domain) the timeline extends to 6-9 months. The procurement side typically takes longer than the technical side: EU public-sector contracts above the threshold require formal tender procedures with mandatory standstill periods, which set the minimum elapsed time regardless of how fast both sides can move technically.

NIS2 (Directive EU 2022/2555) requires "essential" and "important" entities to report significant incidents to their national competent authority within 24 hours (early warning), 72 hours (incident notification), and one month (final report). As a cloud provider serving public-sector customers, we are in scope as an important entity in most national transpositions; our customers, depending on their sector, may be in scope as essential entities.

The interaction model: when an incident occurs on our infrastructure that may affect your operations, we notify your named operational contact within an hour during EU business hours (2-3 hours off-hours), with the technical evidence package structured for your internal classification team to determine whether the incident meets your NIS2 threshold. If it does, you proceed with your own notification under your sector's competent authority; we provide additional evidence on request through the standard NIS2 information-sharing channels.

For most public-sector workloads — citizen-facing email, tax notifications, healthcare communications, judicial notifications, educational communications — our standard infrastructure with the procurement-ready documentation package is sufficient. For classified or formally restricted-handling workloads (EU RESTRICTED, EU CONFIDENTIAL, member-state national classification equivalents like Bundesregierung NfD, Restreint UE), the requirements escalate substantially and the appropriate model is dedicated deployment with member-state-specific certifications.

Practically: for EU RESTRICTED and below, our infrastructure can be configured with additional controls (dedicated IP allocation, segregated DNS, enhanced operational segregation, classified-handling-trained personnel) to support the use case. For EU CONFIDENTIAL and above, the standard answer is to direct the procuring authority to the relevant member-state national cloud (Bundescloud in Germany, Cloud Souverain in France) rather than attempt to fit a sovereignty-aligned commercial cloud into a classification level it wasn't designed for. We're honest about where our infrastructure fits and where it doesn't.

LATAM public-sector procurement increasingly mirrors the EU sovereignty framing but with different jurisdictional anchors. Mexico's MAAGTICSI sets ICT security requirements for federal agencies; the SAT (tax authority) and IMSS (social security) have explicit data-residency and provider-sovereignty expectations. Brazil's LGPD plus the Marco Civil da Internet establishes citizen-data sovereignty principles; the ANPD has issued specific guidance on cross-border processing of public-sector data. Colombia under Ley 1581 plus the Plan TIC 2026 emphasizes Colombian operational sovereignty. Chile under Ley 19.628 (reformed 2024) and Argentina under Ley 25.326 have similar profiles.

The procurement model that works for LATAM public-sector buyers engaging us: data routing remains in our EU infrastructure (which satisfies most LATAM cross-border-processing requirements with appropriate contractual safeguards), the contractual chain includes a local LATAM legal entity for VAT and procurement compliance, and the sovereignty framing is documented in the equivalent of the EU's 8 objectives translated to the LATAM jurisdictional context. We have engagements with public-sector buyers in Mexico, Colombia, and Brazil structured this way.