SecNumCloud Made Mandatory by the August 2026 Order: What France's SREN Law Changes for Cloud Trust — and What It Does Not Prove

Mid-August, the CISO of a French State operator receives a note from the legal department: the ministerial order approving the SecNumCloud framework has been published, and the cloud compliance clock has started. The same week, an auditor asks her something different: demonstrate that the processing records archived in 2024 have not been modified since. Two questions, two objects. The order answers the first. It does not answer the second.

This article covers what the French order of 12 August 2026 actually changes, for whom, and the distinction every DPO or CISO should keep in mind, in France and anywhere the "sovereign cloud" debate is playing out: trust in the infrastructure is not proof of a file's integrity.

What does the French order of 12 August 2026 say about SecNumCloud?

The order (arrêté) of 12 August 2026, published in France's Official Journal (JORF No. 0189 of 14 August 2026) and in force since 17 August 2026, approves the requirements framework applicable to cloud computing service providers. It implements Decree No. 2026-272 of 14 April 2026, itself derived from Article 31 of the SREN law of 21 May 2024, France's law on securing and regulating the digital space.

The text, available on Légifrance (in French), is titled "Arrêté du 12 août 2026 portant approbation du référentiel d'exigences relatif aux prestataires de services d'informatique en nuage". Its Article 2 sets out the attestation mechanism: a private provider's cloud service is deemed compliant when attested "by a qualification issued by the French national cybersecurity agency (ANSSI) or by a certification of the European Union or of a State party to the European Economic Area recognized as equivalent by that agency".

In practice: ANSSI's SecNumCloud qualification becomes the reference route for attesting compliance with the framework, with the door open to future equivalent European certifications.

Who must comply under the SREN law?

The scope of the obligation is precise, and it does not cover the private sector's own data. Decree No. 2026-272 targets French State administrations, State operators and six specifically designated public interest groupings, whenever their data of particular sensitivity is processed by a cloud service supplied by a private provider.

Three texts fit together:

• Article 31 of Law No. 2024-449 of 21 May 2024 (the SREN law) states the principle: the State's data of particular sensitivity entrusted to a private cloud must benefit from security criteria guaranteeing, among other things, protection "against any access by public authorities of third States" that has not been authorized.
• Decree No. 2026-272 of 14 April 2026 defines which entities are covered, refers to an ANSSI framework approved by ministerial order, and organizes a transitional regime: administrations already contractually committed may request a derogation, capped at eighteen months where a compliant offer exists, or one year renewable.
• The order of 12 August 2026 approves that framework and makes it enforceable.

Note what the text does not say. It imposes nothing on private companies for their own data, nor on public bodies outside the defined scope. An SME, a law firm or a mid-cap may choose a qualified cloud: that is a choice, not an obligation under this order.

What does ANSSI's SecNumCloud qualification cover?

SecNumCloud is an infrastructure and organizational qualification: it attests that a cloud service (IaaS, PaaS, SaaS) meets a high level of security and legal-protection requirements. It is issued by ANSSI for three years, with annual surveillance audits, based on version 3.2 of the framework.

According to ANSSI's FAQ (in French), the qualification notably covers:

• the organizational and technical security of the service (governance, segregation, incident management);
• the location where data is hosted;
• protection against non-European laws with extraterritorial reach: EU headquarters, majority-European capital, operational autonomy, independence from outside interference.

This is a real, demanding and audited guarantee. On its own ground (who hosts, under which jurisdiction, at which security level), SecNumCloud is currently the French reference. Nothing in this article calls that into question.

What the qualification proves, and what it does not

A hosting qualification attests properties of the service, not properties of your files. It sharply reduces the risk of unauthorized access and tampering, but it produces no third-party-verifiable evidence about the state of a specific document on a specific date. These are two distinct legal objects.

Concretely, SecNumCloud-qualified hosting lets you say: "my data is hosted by an audited provider, under European law, protected against access by non-EU authorities". It does not let you demonstrate, document in hand against an opposing party, that the audit report archived on 3 March already existed in that exact form on 3 March.

The last row deserves emphasis: timestamping has limits of its own. It proves that a file existed in a given form on a given date: existence and integrity at a point in time, hence anteriority. It says nothing about the author's identity or about who holds the rights.

Why integrity proof should live outside your hosting provider

A timestamp log kept by the hosting provider itself has a structural weakness: the party attesting is the party holding the data. If a document's integrity is challenged, an attestation produced by the provider hosting that document rests on trust in that provider, precisely what the opposing party will attack.

Integrity proof gains strength when it can be verified independently of the infrastructure storing the file. That is the principle of fingerprint anchoring: compute the document's SHA-256 hash, then anchor it on a public ledger controlled by neither the host, nor the timestamping service, nor the document's owner: the Bitcoin blockchain, via the open OpenTimestamps protocol. Changing a single byte of the file changes its fingerprint entirely: the match between the stored file and the anchored fingerprint can be checked by any third party, at any time.

On admissibility, the EU framework is set by the eIDAS Regulation: its Article 41.1 prohibits denying legal effect to an electronic timestamp solely on the grounds that it is not qualified. A non-qualified timestamp can therefore be admissible; its evidentiary weight remains for the court to assess, as serious supporting evidence within a broader body of proof.

Use cases for a DPO or CISO

Three situations where "the infrastructure is compliant" is not enough:

1. 1
   GDPR records and documentation

   Processing records, DPIAs and notification procedures evolve. Timestamping each version freezes a dated fingerprint: in a regulator's audit, you can document that a given version existed before the incident, whatever infrastructure hosts the record.
2. 2
   Incident and notification traces

   After a data breach, the timeline gets contested: when was the internal report written, when was the notification prepared? A fingerprint anchored before sending strengthens the body of evidence about the actual chronology.
3. 3
   Audit and compliance deliverables

   Audit reports, security policies, even the compliance evidence for regulations like SREN: timestamping the deliverable at production date lets you show, years later, that it was not rewritten after the fact.

In each case, migrating to a qualified cloud and timestamping documents answer two different requirements of the same compliance file.

Where does LegalStamp fit in?

LegalStamp is a non-qualified electronic timestamping service under eIDAS: we are neither a qualified trust service provider nor SecNumCloud-qualified, and we claim neither. Our ground is per-file integrity and anteriority proof, as a complement to your infrastructure, whatever it is.

The design assumes sensitive data: the SHA-256 fingerprint is computed in your browser, and the file never leaves your machine; only the fingerprint is transmitted. For a CISO, that means no new flow of sensitive data toward an additional provider. The fingerprint is then anchored on the Bitcoin blockchain via OpenTimestamps; the final attestation is available after a block is confirmed, not instantly. The .ots receipt can afterwards be verified by any third party, even if LegalStamp disappears. The mechanics are detailed on our how-it-works page.

The limits are real and stated: no legal presumption attached to a qualified timestamp, no proof of identity or ownership, and the proof only works if you keep the original file. Where a qualified timestamp is required, a provider from the EU Trusted Lists remains the right counterpart.

Conclusion

The order of 12 August 2026 closes the regulatory chapter opened by Article 31 of France's SREN law: the State's data of particular sensitivity will have to be hosted on services attested against the SecNumCloud framework, with explicit protection against non-European extraterritorial laws. It is a clear step forward for infrastructure trust. But trusted infrastructure does not produce documentary evidence: demonstrating that a file existed in a given form on a given date requires a dedicated mechanism, verifiable independently of any host. The two complement each other; neither replaces the other.

Disclaimer: this article is provided for informational and educational purposes only. It does not constitute legal advice. For a concrete situation (dispute, compliance, proceedings), have your evidence strategy validated by a legal professional.