How to Choose a Cloud Security Assessment Provider in the UK
Most cloud security assessments sold in the UK are configuration scans with a report attached. A real assessment tests whether your cloud estate would hold up against someone actively trying to get in, judges the configuration against a named standard, and hands you findings a competent engineer can act on without a follow-up call. The difference shows up in the scope document, not the sales meeting.
If you are shortlisting providers, this is what to look at.
What you are actually buying
Four different things get sold under the same label, and the price difference between them is roughly tenfold.
A configuration scan. A tool is pointed at your subscription or account, and it reports drift from a benchmark. Useful, cheap, and something you can run yourself with the native tooling you may already be paying for: Microsoft Defender for Cloud, AWS Security Hub. If a proposal’s methodology is a tool name, this is what you are buying.
A cloud security assessment. Configuration review judged against a standard, plus identity and access analysis, network architecture review, logging and detection coverage, and a look at how the estate is actually built and deployed rather than only how it currently sits. Human-led, tool-assisted.
A cloud penetration test. Active exploitation within an agreed scope: privilege escalation paths, lateral movement between accounts or subscriptions, exposed services, data exfiltration routes. It answers a different question. Not “is this configured correctly” but “can someone get in from here”.
Certification or attestation. ISO 27001, Cyber Essentials Plus, or a customer’s own supplier assurance questionnaire. This is an audit against a defined scheme, and it is not an assessment. It tells you whether you meet a bar, not where your weaknesses are.
You may need more than one. What you should not accept is one of them priced and presented as another.
The questions worth asking
1. What standard are you assessing against, by name?
There should be a specific answer. In the UK the common ones are the NCSC cloud security principles, all fourteen of them, the CIS Benchmarks for the relevant platform, the Cloud Security Alliance Cloud Controls Matrix, and the platform vendors’ own baselines: the Microsoft Cloud Security Benchmark, the AWS Foundational Security Best Practices.
A provider who answers “industry best practice” is telling you they have no framework. Ask which controls they will assess and get the list before you sign, not in the report.
2. Who is doing the work, and what have they built?
Cloud security assessment is an engineering discipline. The person reviewing your landing zone should have built one. Ask for the named individuals, their certifications, and, more revealing, what they have deployed in the platform you run.
Accreditation is worth checking at the firm level too. CREST and The Cyber Scheme both assess UK testing providers on methodology and staff competence, and government and regulated buyers frequently require one or the other. Ask which the firm holds, for which services, and whether the people on your engagement are individually qualified or only working under the firm’s badge. The distinction matters more often than it should, and the registers are public, so verify rather than take the logo on the website at face value.
3. What is in scope, and what is explicitly out?
A good scope document names subscriptions, accounts, resource groups, regions and identity tenants. It states whether CI/CD pipelines and infrastructure-as-code repositories are included, and they usually should be, since that is where the misconfiguration originates. It says whether the assessment covers the platform only, or the workloads running on it.
Vague scope is the most reliable predictor of a disappointing report.
4. How do you handle identity?
Identity is where most cloud compromise actually happens, and it is the section that gets thinnest in weak reports. The assessment should cover privileged role assignments, standing versus just-in-time access, service principals and their credentials, cross-account or cross-tenant trust, conditional access or equivalent policy, and stale accounts.
If identity is one heading in the proposal rather than a workstream, ask why.
5. What does the deliverable look like, and can I see a redacted one?
Ask for a sample report. Any credible provider has one. What you want to see:
- Findings with evidence, the specific resource and the specific setting, not a generic control reference
- Severity that reflects your context, not a raw CVSS score copied out of a scanner
- Remediation a working engineer can follow, including the CLI command or portal path
- A prioritised order of work, because everything cannot be critical
- An executive summary that says something, rather than restating the finding count
If the sample is thirty pages of scanner output with a cover sheet, you now know what you would be buying.
6. What happens after the report?
A retest of remediated findings should be included, or at least priced up front. Ask how long the retest window runs, and whether it covers findings you fixed differently from the way they recommended.
7. Will you talk to my engineers?
The findings that matter most usually surface in conversation with the people who built the thing. A provider who wants read-only access and no contact until the readout is optimising for their own delivery cost, not for your result.
How Azure and AWS assessments differ in practice
The frameworks are similar. The work is not.
Azure assessments tend to centre on Entra ID, because in most Azure estates identity is the control plane and the blast radius of a role assignment is large. Expect real attention to management group and subscription hierarchy, Azure Policy assignment and whether it is actually enforcing or only auditing, privileged identity management, and whether the landing zone follows the cloud adoption framework or has grown organically. Guest accounts and cross-tenant access are a recurring finding.
AWS assessments centre on the account boundary and on IAM. Expect scrutiny of the organisation structure and service control policies, cross-account role assumption paths, resource-based policies, S3 bucket policies especially, and the difference between what IAM permits in theory and what is reachable in practice. Root account handling and region enablement come up more often than people expect.
Multi-cloud is not the sum of the two. The interesting findings sit in the joins: federated identity between platforms, shared secrets, CI/CD systems holding credentials for both, and networking that connects environments nobody intended to connect. If you run both, say so up front and ask specifically how the provider handles the boundary. Many assess each platform separately and never look at the seam, which is the part most likely to hurt you.
If the answer to a finding is that the architecture is wrong rather than the setting is wrong, you are into secure by design and secure cloud engineering territory, and it is worth knowing up front whether your provider can do that work or only report on it.
What drives the price
Cost tracks scope more than headcount:
- Number of subscriptions or accounts, and whether they are consistent or each built differently
- Identity complexity. A single tenant with clean role assignments is a fraction of the work of a federated estate carrying legacy service principals
- Whether infrastructure-as-code is in scope. Reviewing Terraform or Bicep is additional work, and usually the highest-value part
- Whether the workloads are included, or only the platform
- Retest inclusion
- Turnaround. Compressed timelines cost more, as they should
Ask for the price broken down against those. A single number with no structure behind it cannot be compared against another provider’s single number, and comparing them is the entire purpose of a shortlist.
Comparing providers
Run every shortlisted firm against the same criteria. This is the table worth building:
| Criterion | What good looks like |
|---|---|
| Named standard | Specific frameworks stated in the proposal, not “best practice” |
| Accreditation | CREST or Cyber Scheme, verified against the register, for the relevant service |
| Named consultants | Individuals identified, with platform experience you can check |
| Identity depth | A distinct workstream, not a heading |
| IaC and pipeline coverage | In scope by default, or priced clearly as an option |
| Sample report | Provided without hesitation, with evidence and actionable remediation |
| Retest | Included, with a stated window |
| Engineer access | Expected and scheduled |
| Scope precision | Subscriptions, accounts, regions and exclusions named |
| Price structure | Broken down against the scope drivers above |
Score them. The exercise usually separates the field faster than any reference call.
Red flags
- A fixed price quoted before scoping. It means the scope will be made to fit the price.
- The methodology is a product name. You are buying a licence with a person attached.
- No sample report available. There is a reason.
- Findings promised in a fixed severity distribution. Real assessments do not know what they will find.
- Certification and assessment sold as the same engagement, without a clear separation of what each covers.
- No UK presence or data handling position when your own obligations require one. Ask where the evidence and the report are stored, and for how long.
Where certification fits
Buyers frequently arrive asking for a cloud security assessment when what a customer has actually demanded is a certificate. They are different purchases, and buying the wrong one wastes a quarter.
If a customer contract or a framework requires Cyber Essentials Plus or ISO 27001, you need the certification, and the assessment is the thing that makes passing it straightforward. If what you need is to know where you are exposed, the assessment is the purchase, and certification may follow. A provider who can tell you which of the two you actually need, including when the answer is neither, is worth more than one who quotes for whichever you asked about.
How we approach it
Layer 7 has assessed and built cloud environments for UK government and regulated industry since 2010. Our cloud security assessments are judged against the NCSC cloud security principles, the CIS Benchmarks for the platform, and CSA and NIST controls where your compliance position calls for them. Our testers hold individual CREST and Cyber Scheme qualifications, and the same engineers who assess cloud estates also build and harden them, which is why the remediation guidance is something your team can act on rather than a generic checklist.
We also certify. Layer 7 became one of the first IASME-approved Certification Bodies in 2014, which means we can tell you honestly when what you need is a certificate rather than an assessment, and when it is neither.
If you are working through a shortlist and want a second opinion on what you are being quoted, we are happy to look at it. Start a conversation →