The 8 digital sovereignty criteria to put in an IT RFP

A sovereignty requirement only changes a decision when it is broken down into verifiable evidence and weighted above the typical price gap between two comparable bids. The eight dimensions to cover are the eight sovereignty objectives of the European Commission's Cloud Sovereignty Framework: strategic control, legal exposure, data and AI, operational independence, software supply chain, technology portability, security and compliance, and environmental impact. Each one turns into a question you ask the vendor and a document you require in return.

In France, where the most recent figure is available, 91 % of decision-makers surveyed now see digital sovereignty as a major strategic issue,  according to the survey run by Infopro Digital Études for L'Argus de l'assurance and Efficy among 412 respondents in March and April 2026.

Julian Maurel, CEO of Jahia, observes in an op-ed published by IT for Business on 30 June 2026 that the requirement nonetheless stays "confined to a criterion weighted at around 10 %, when price carries 50 or 60 %". That is a practitioner's observation from French tenders, not a survey finding, and we give it as such.

A requirement that appears everywhere and almost never changes an outcome. Here is how to make it count, using the framework the European Commission now applies to its own procurement.

Key takeaways

• Writing the requirement is the easy part. The decision that matters is whether sovereignty is a weighted criterion, a pass or fail condition, or a contract clause. The three produce different results.
• The precedent that changes the conversation: for its own EUR 180 million sovereign cloud contract, the European Commission made a sovereignty level an eligibility condition rather than a weighted criterion.
• A weight only bites above the usual price gap between two comparable bids. At 10 % against price at 60 %, it will not move a single ranking.
• Under the UK Procurement Act 2023, award criteria must be clear, measurable and proportionate, with a published assessment methodology. A vague sovereignty criterion is now harder to defend, not easier.
• Exit cost is the most revealing test. A vendor who cannot put a number and a timeline on your exit has already answered the dependency question.
• Build the scorecard before you look at the market, have the business teams validate it, and rank vendor reputation last.

Why put sovereignty criteria in an IT RFP

Because a dependency you do not evaluate at purchase becomes a cost you absorb for the life of the contract. A digital experience platform commits an organisation for several years, during which the legal framework, the vendor's ownership structure and the pricing model can all change without your consent.

The ground has firmed up, and it is now citable.

In the UK, the Procurement Act 2023 gives you the language. Award criteria must be measurable and proportionate, and the assessment methodology has to be published with the tender. A sovereignty requirement expressed as a list of documents to produce meets that test. One expressed as a preference for European vendors does not.

In the EU, the Commission has gone further than setting rules for others: it has applied a sovereignty scale to its own buying, and the detail is worth knowing before you draft. It is covered in its own section below.

Two forces work against the intent, and ignoring them explains most decorative requirements.

The first is personal risk. A public buyer is asked to commit for three, five or eight years, and whoever signs carries that choice. The industry adage says it plainly: nobody ever got fired for buying IBM. If the decision is made on sovereignty grounds at the expense of everything else, it produces a backlash against sovereignty itself.

The second plays out before the RFP is published, in how the requirement is written. When an organisation looks for an alternative to a dominant product and describes its needs by listing that product's features, the RFP is already pointing back at it. Starting from what users actually need, rather than from the installed product, is what makes sovereignty criteria worth writing at all.

What makes a solution genuinely sovereign

A sovereign solution is one where the buyer can determine, at any point, who can access their data, under which jurisdiction, and on what terms they can leave. Vendor nationality alone does not establish that. A European company can host with a provider subject to extraterritorial law, be owned by a non-European shareholder, or run support from outside the region.

The reverse is equally true. Hosting inside a country does not shield data from an order aimed at a vendor's parent company, where the parent's home jurisdiction allows it. That is why recent frameworks evaluate a chain of dependencies rather than a hosting location.

The reference framework: the European Commission's Cloud Sovereignty Framework

The eight criteria below are not a house invention. They follow the structure of the Cloud Sovereignty Framework published by the European Commission in October 2025, version 1.2.1. This is the part most articles on the subject leave out, and it is the part that gives a scorecard authority in front of a procurement board.

The framework sets out eight sovereignty objectives: strategic, legal, operational, environmental, supply chain transparency, technological openness, security, and compliance with EU law. It adds a scoring scale, the Sovereignty Effectiveness Assurance Levels or SEAL, running from SEAL-0, which describes a complete absence of sovereignty, to SEAL-4, which requires a full EU supply chain from chips to software.

This is not a theoretical document. The Commission applied it to its own purchase. For its sovereign cloud contract worth up to EUR 180 million over six years, awarded on 17 April 2026, it states plainly that "for the providers to be considered eligible, they needed to reach SEAL-2 level". A sovereignty level was therefore an eligibility condition, not a weighted criterion. The four contracts went to European providers.

For a buyer, that precedent is an argument. When the European Commission itself turns a sovereignty level into an admissibility condition for a EUR 180 million contract, the question of whether you are allowed to do it stops being theoretical.

The 8 digital sovereignty criteria to evaluate

1. Strategic control over the product

Strategic control measures your ability to influence where the product goes. You test it by asking whether the roadmap can be contractually committed, whether feature continuity can be written into the agreement, and what notice period applies if a component is discontinued.

A vendor who refuses any written commitment on product direction is asking you to accept a risk you cannot budget for. Ask for the product evolution process, the role customers play in prioritisation, and the end-of-life policy for versions.

2. Legal exposure and jurisdiction

Legal exposure covers governing law and the reach of foreign legislation. It comes down to three things: the ownership chain of the vendor and its hosting providers, the law and venue governing the contract, and whether a documented process exists for responding to foreign authority requests.

The question is specific. Which legal entity signs the contract, what is its full ownership chain, and does that chain include an entity subject to extraterritorial legislation. An evasive answer here is itself an answer.

3. Data and AI

Data control covers residency, encryption, key custody, and whether your content is used to train models. For organisations it covers, the GDPR already provides the documentation backbone: records of processing, impact assessments, residency, and processor commitments under Article 28 of Regulation (EU) 2016/679. UK organisations request the same documents under their own regime, and Swiss organisations under their federal act.

AI adds a question many RFPs still miss. Ask explicitly where content submitted to a model is processed, whether customer data can be used for training, whether the model can run inside your environment, and whether you can choose or replace the model. A vendor who cannot answer is moving your content into a chain you do not control.

4. Operational independence

Operational independence is your ability to run the platform without depending exclusively on the vendor. It shows up in where support and managed services teams sit, which administrator rights you are actually granted, and how much your internal teams can do unassisted.

One point deserves particular attention: whether business teams can create and change content without a development cycle. A platform that requires a ticket for every page change creates an operational dependency that appears in no technical scorecard, and that you pay for every month.

5. Software supply chain

Supply chain transparency is the most frequently skipped criterion and one of the most decisive. It is also one of the eight objectives of the European framework. A solution presented as sovereign whose components come largely from third-party building blocks nobody controls is sovereign in name only.

Ask for the software bill of materials, the dependency update policy, the remediation window for critical vulnerabilities, and the list of subcontractors with access to the environment or the data. These are documentable. Their absence is information in itself.

6. Technology portability

Technological openness is your freedom to choose and change your technical foundation. It rests on three verifiable elements: whether the code is open or closed, whether documented APIs allow the export of content and structures, and whether any undocumented proprietary format stands in the way.

Open source makes auditing easier and reduces dependency without eliminating it. The useful question is not whether the solution is open source, but whether you could take technical and legal control of your platform if your vendor disappeared.

7. Security and compliance

In the most regulated sectors, insurance among them, security and compliance are the easiest criteria to make objective, because they rest on verifiable certifications. Depending on data sensitivity, a buyer can require or weight recognised certifications, and should name which ones in the tender documents rather than leaving it open. In France, SecNumCloud, issued by the national cybersecurity agency, is the reference example: not a general obligation, but required by state policy for particularly sensitive data. Check what the equivalent is in your own jurisdiction before naming it.

Ask for current attestations, with their exact scope and certifying body, rather than a statement of compliance in the response. A certification that does not cover the environment you will actually be given does not protect you.

8. Environmental impact

Environmental impact is the eighth objective of the European framework, and it connects to sovereignty through infrastructure location. Ask for the PUE of the data centres involved, the energy mix at the hosting site, and the hardware lifecycle policy.

Most European hosting providers publish these figures. Their absence from a response deserves to be scored the same way a missing certification would be.

Weighted criterion, pass or fail condition, or contract clause

You now know the eight criteria. What remains is deciding how to use them, because the same criterion does not produce the same effect depending on the place you give it. So settle one question before writing the scorecard: will sovereignty be a weighted scoring criterion, a mandatory condition that disqualifies a bid, or a contractual commitment backed by penalties. All three are legitimate, they do not produce the same result, and confusing them is the leading cause of decorative requirements.

As a weighted criterion, sovereignty enters the score alongside price and features. This is the more common route for public buyers in the Union, bound by Article 67 of Directive 2014/24/EU to use criteria linked to the subject matter and proportionate to it, and it is equally available under the UK Procurement Act 2023 provided the criterion is measurable. It has real effect on one condition: the weight has to exceed the typical price gap between two comparable bids. At 10 % against price at 60 %, it will not move a single ranking.

As a mandatory condition, the RFP rules out bidders that fail a stated requirement, for example a minimum level on the SEAL scale, or a named national cloud qualification where your jurisdiction recognises one. The effect is immediate and unambiguous. In exchange, the condition has to be proportionate to the need, justified by data sensitivity, and verifiable from documents. It also assumes a real market of compliant vendors exists, otherwise the RFP returns no usable bid.

As a contract clause, often forgotten and cumulative with the other two: restrict data access by the supplier, back the commitment with penalties, and require a costed exit plan. This route works where exclusion would be disproportionate or unrealistic, which is usually the case when no mature alternative exists yet in the segment.

A sample scorecard for an IT RFP

The table below covers the sovereignty block only. It sits alongside your functional, technical and price criteria: the percentages in the third column are shares within whatever envelope you assign to sovereignty, and the fourth shows what each one is worth if that block carries 30 % of the overall score.

Treat this split as a starting point and adjust it to the sensitivity of the data involved. What matters is that the envelope assigned to sovereignty stays above the usual price gap between two comparable bids, otherwise the criterion will never discriminate. For the most sensitive workloads, the question is whether it should be a mandatory condition rather than a weighted one.

Neutralise brand reflex before you write the scorecard

The first obstacle to an honest evaluation is not legal, it is psychological. A familiar vendor reassures. An unfamiliar one exposes whoever picks it. Until that reflex is neutralised, sovereignty criteria stay decorative no matter how well they are written.

The counter-move is methodological, and it comes down to three steps. Build the scorecard from what your users need, before you look at what the market offers. Have the business teams validate it rather than IT alone. And rank vendor reputation explicitly at the bottom of the weighting, so that nobody has to defend that choice in the room.

The order matters. A scorecard written after surveying the market borrows the vocabulary of the offers it has just read, and closes around them. One written beforehand describes a need, which leaves a chance to the vendors the team had never heard of.

Questions to ask vendors

These questions have the advantage of requiring documents in response rather than assurances.

1. Which legal entity signs the contract, and what is its complete ownership chain?
2. Which subcontractors have technical access to the data, and from which countries?
3. Can our content be used to train a model, and can we choose which model is used?
4. What is the costed price and timeline for a full exit, including export of content and structures?
5. Which certifications cover the exact environment we will be given, and through what date?
6. What contractual notice applies if a capability we rely on is discontinued?
7. Where do you place your offering on the SEAL scale of the Cloud Sovereignty Framework, and on what evidence?

Mistakes to avoid

The most common mistake is writing a criterion without weighting it. Sovereignty at 5 % in an RFP where price carries 60 % will not change a ranking, and the signal it sends to the market is that the requirement is for show.

Three other traps come up regularly. Treating hosting location as sovereignty leads to approving a vendor whose parent remains exposed to foreign legislation. Accepting a statement instead of evidence makes the criterion unverifiable if it is ever disputed. And skipping the exit plan recreates the exact dependency the exercise was meant to avoid, since switching cost becomes the incumbent's strongest renewal argument.

A fourth trap is rarer and more expensive: writing a requirement so strict that no bid in the market can meet it. Both the EU framework and the UK Procurement Act point the same way. A sovereignty requirement is only worth having if it leaves real competition standing.

Where Jahia stands on these criteria

Jahia is a European vendor of enterprise CMS and digital experience platform software, built on an open source foundation. Against the criteria above, that translates into inspectable code and a choice of hosting infrastructure, including with a European sovereign provider.

On compliance, the platform holds an ISO/IEC 27001:2022 certification issued by AFNOR and PCI DSS SAQ-D SP compliance. The exact scope of those certifications, and their validity dates, are published on our security and compliance page.

On everything else, apply your own scorecard to us: this article is written by a vendor, and that is one more reason to require the documents rather than believe the declarations, including ours. No platform scores identically on all eight criteria, and the weighting you choose will determine the answer.

If your tender is specifically about a CMS, GDPR and sovereignty: why your choice of CMS matters applies the same requirements to that category of solution.

FAQ

Is a European vendor automatically sovereign?

No. Vendor nationality guarantees nothing on its own. A European company can host with a provider subject to extraterritorial law, be owned by a non-European shareholder, or run support from outside the region. What determines the actual level of control is the ownership chain, the law governing the contract, and where technical access to the data physically sits.

Does the CLOUD Act reach data stored in Europe?

The US CLOUD Act of 2018 allows United States authorities to compel data held by a provider subject to their jurisdiction, whatever the country of storage. Storing data in Ireland, the UK or Switzerland does not by itself put it out of reach. The Act provides routes to challenge a request, but the deciding factor remains which legal entity controls access to the data, not the address of the data centre.

What is the difference between sovereign cloud and trusted cloud?

A sovereign cloud is an offering whose entire chain, ownership, operations and hosting, sits under European law. A trusted cloud is an offering operated in Europe under licence from non-European technology, with contractual and technical separation guarantees. The second reduces exposure without removing it, which can be enough depending on data sensitivity.

Which certifications should we actually require?

Name them in the tender documents rather than asking for compliance in general. ISO/IEC 27001 is the baseline recognised across Europe, and PCI DSS applies where payment data is involved. Add the national cloud or security qualification your own jurisdiction recognises, and whatever your sector supervisor requires. In every case, require the attestation itself, its exact scope and its expiry date.

How do you evaluate a vendor's sovereignty?

By requiring documents rather than declarations. Ask for the ownership chain of the signing entity, the list of subcontractors with technical access and their countries, certification attestations with their exact scope, the software bill of materials, and a costed exit plan. The Commission's Cloud Sovereignty Framework provides a ready-made scoring scale to structure the exercise.

Which criteria belong in an IT RFP?

The eight dimensions described here: strategic control, legal exposure, data and AI, operational independence, software supply chain, technology portability, security and compliance, environmental impact. Each needs required evidence and a weight. A criterion written without a weight or an expected proof will not discriminate between bids. These sit alongside the usual functional criteria, covered in our guide on how to choose a digital experience platform.

Sources

1. European Commission,Cloud Sovereignty Framework, version 1.2.1, implementation guidance, October 2025.
2. European Commission,Commission advances cloud sovereignty through strategic procurement, 17 April 2026.
3. Procurement Act 2023, in force 24 February 2025, andsection 19on award criteria.
4. Directive 2014/24/EUon public procurement, Article 67.
5. Regulation (EU) 2016/679 (GDPR), Article 28.
6. European Commission, renewal of the UK adequacy decisions, 19 December 2025, valid to 27 December 2031.
7. Federal Data Protection and Information Commissioner,EU adequacy decision regarding Switzerland, 15 January 2024.
8. US CLOUD Act resources, US Department of Justice.
9. Julian Maurel,"Souveraineté numérique : si elle est stratégique, pourquoi ne pèse-t-elle que 10 % ?", IT for Business, 30 June 2026 (in French).
10. Online survey run by Infopro Digital Études for L'Argus de l'assurance and Efficy, 23 March to 10 April 2026, among 412 respondents in France, of whom 211 in insurance, 101 in industry and 100 in public organisations.