ISO 27001, G-Cloud and SOC 2: How to vet a sovereign cloud provider

A procurement officer at a mid-sized financial services firm spent six months last year negotiating with a cloud provider that turned out not to hold the certification it had implied in its sales deck. The contract collapsed during legal review. The firm lost the time, the provider lost the deal, and somewhere in the middle, a senior engineer learned the difference between "compliant with the principles of" and "audited to the standard of."

This is the unglamorous reality of cloud procurement. Certifications matter, but they only matter if you can read them properly. A logo on a website is not evidence. A signed audit report is. The gap between the two is where most procurement mistakes live, and it's worth understanding which certifications carry weight, what they actually attest to, and how to verify them before you sign anything.

Sovereign cloud, in particular, raises the stakes. If you're choosing a provider partly because your data needs to live in a specific jurisdiction under a specific legal framework, the assurance you need from certifications goes beyond generic security claims. You need evidence that the provider's controls are tested, current, and applicable to the regions where your data will sit.

The three certifications that matter most

There are dozens of relevant frameworks, but three carry disproportionate weight in serious procurement decisions: ISO 27001, SOC 2, and G-Cloud. Each does a different job, and confusing them is a common mistake.

ISO 27001

ISO 27001 is an international standard for information security management systems. It's a process certification, and what it really attests to is that the provider has a working ISMS, that the ISMS has been audited by an accredited body, and that the controls listed in Annex A are being implemented and reviewed. It's not a product certification, and it doesn't tell you anything specific about how a particular service is engineered. What it does tell you is that the company has the organizational discipline to run security as a managed system rather than a series of fire drills.

When you see ISO 27001 on a provider's site, ask for the certificate. It will name the certification body, the scope (which parts of the business are in scope), and the expiry date. All three matter. A certificate that covers the corporate office but excludes the data centers is not what you think it is.

SOC 2 Type II

SOC 2 is an American framework, developed by the AICPA, and it's particularly common among providers serving US enterprise buyers. SOC 2 Type II reports describe the design and operating effectiveness of controls over a period of time, typically six to twelve months, against the Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy).

The Type II distinction matters. A Type I report is a snapshot. A Type II report is the audit of how the controls actually behaved over a sustained period. For any production workload, Type II is the one to ask for.

SOC 2 reports are not public documents. A serious provider will share them under NDA. A provider that won't share the report under NDA is asking you to take their word for it, and you shouldn't.

G-Cloud

G-Cloud is the UK government's procurement framework for cloud services, currently on iteration 14 (the framework refreshes regularly). Inclusion on G-Cloud means a provider has been accepted onto a vetted supplier list that UK public sector buyers can purchase from without running a full procurement process. It's both a sales channel and a credibility marker.

For a UK buyer in financial services, healthcare, or critical national infrastructure, G-Cloud listing matters because it signals the provider has gone through Crown Commercial Service due diligence. For non-UK buyers, it's a useful indicator that the provider has reached a level of operational maturity.

What certifications does Civo hold?

Civo holds all three: ISO 27001, SOC 2 Type II, and a listing on G-Cloud 14, alongside Cyber Essentials. 

That combination is increasingly the baseline for sovereign cloud procurement, particularly for buyers in regulated industries who want feature parity between public and private environments without the certification gaps that often come with smaller providers. The Civo pitch of "built for more" reads, in this context, as the operational discipline that backs the certifications, not just a tagline.

What else belongs on the vetting checklist

Certifications are necessary but not sufficient. A few other questions deserve answers before you commit:

Reading a certificate properly

A few practical tips for actually verifying what's in front of you:

• Check the certificate body: ISO 27001 certificates are issued by accredited certification bodies. The certificate will name the body. Cross-reference it against the relevant national accreditation register (UKAS in the UK, ANAB in the US).
• Check the scope: A certificate scope statement will describe what's covered. Read it. "Information security management system supporting the design, development and operation of cloud infrastructure services" is what you want. "Information security management system supporting administrative office operations" is not.
• Check the date: Certificates expire. ISO 27001 runs in three-year cycles with annual surveillance audits. A certificate dated four years ago is either lapsed or has been re-issued under a more recent date that the provider hasn't updated.
• Ask for the audit report, not just the certificate: For SOC 2, the report is the substantive document. For ISO 27001, the Statement of Applicability tells you which controls the provider has implemented and which it has excluded.

The unfashionable conclusion

Vetting a cloud provider properly is mostly paperwork, and the firms that do it well treat it as a discipline rather than a chore. The companies that get burned tend to be the ones that took logos at face value, didn't ask for the underlying reports, and didn't read the scope statements when they did receive them.

For sovereign cloud specifically, the bar should be higher, not lower. If a provider is telling you that data will stay in your jurisdiction, you want that backed by audited controls, contractual language, and a certification posture that's genuinely current. Anything less is a story, not a guarantee.

FAQs