Choosing an infrastructure or platform cloud provider is the largest security decision most organisations make about a single supplier, yet the security part of the evaluation is often a questionnaire returned after the commercial choice is already made. The provider runs the hypervisors, the identity plane, the key management service and the administrative systems that every one of your workloads depends on, and its own failures become your incidents. This vendor-neutral guide sets out the security requirements to write into an IaaS or PaaS selection: assurance evidence, tenant separation, identity and administration, key custody, provider operator access, logging, resilience, data location and exit. It is for security architects, cloud platform teams and procurement leads running a first selection, a second-provider decision or a renewal. It covers selection only; for running a cloud estate securely once chosen, see the Cloud Security Guide.
Key takeaways
- Assurance evidence comes first. Ask for independent reports (ISO/IEC 27001 with 27017, SOC 2 Type II, a CSA STAR Level 2 entry) and read their scope: which services, regions and control plane components are actually covered.
- Key custody decides who can read your data. Compare provider-managed keys, customer-managed keys in the provider's KMS, and keys held outside the provider, and accept that each step towards your own custody moves availability risk to you.
- Provider operator access must be visible and controllable. Require documented just-in-time access for support staff, customer approval where data is touched, and logs of every such access.
- Logging must be in the base price. CISA's Secure by Demand Guide asks for security logs retained for at least six months at no extra charge; control plane, identity and data access logs are what every investigation needs.
- Plan the exit before you sign. Data export formats, key portability, identity federation and contractual exit assistance are far cheaper to negotiate during selection than during a crisis.
Define requirements
Write the requirements from the workloads and data you will place in the cloud, then test each provider against them. The NCSC's 14 Cloud Security Principles make a good skeleton because they were written for exactly this purpose: data in transit protection (principle 1), asset protection and resilience (2), separation between customers (3), operational security (5), personnel security (6), supply chain security (8), identity and authentication (10), secure service administration (12), audit information and alerting for customers (13) and secure use of the service (14). Record:
- Service models: IaaS, PaaS, managed databases, serverless, managed Kubernetes and AI services each shift a different share of the work to the provider. Map them with the Shared Responsibility Models Guide and the Shared Responsibility Matrix Template.
- Data classes: personal data, payment data, health data, export-controlled data, secrets and keys. Each class carries its own location, encryption and access rules.
- Location and sovereignty: the regions you may use, whether support staff in other countries may access data, and whether you need a sovereign or government region. See the Data Sovereignty and Residency Guide and the EU Sovereign Cloud Options Compared Guide.
- Regulatory drivers: financial entities in the EU must manage ICT third-party risk and keep a register of information under DORA (see the DORA ICT Third-Party Risk and Register of Information Guide); public sector buyers may need a national authorisation such as FedRAMP.
- Key custody stance: which data may be encrypted with provider-managed keys and which must use customer-managed or externally held keys.
- Resilience targets: recovery time and recovery point objectives per workload, and whether a single region, multi-region or second provider is required.
- Operating model: who will hold the root or organisation-level accounts, and whether all change will flow through infrastructure as code.
Capability areas
Score each provider on the areas below. The minimum requirement column is what to write into the RFP; the right-hand column is the reason it matters when something goes wrong.
| Capability area | Minimum requirement | Why it matters |
|---|---|---|
| Independent assurance | ISO/IEC 27001 certificate with ISO/IEC 27017 cloud controls, SOC 2 Type II report, CSA STAR entry; scope lists services and regions you will use | A certificate that excludes the service you buy proves nothing about it |
| Tenant separation | Documented isolation for compute, storage and network; published approach to hypervisor and side-channel issues; confidential computing options where needed | NCSC principle 3: a malicious customer must not reach yours |
| Identity and administration | Federation with your IdP (SAML or OIDC), enforced MFA for every human, organisation-wide guardrail policies, root or owner account protection, short-lived workload credentials | The control plane is reachable from the internet and is the main target |
| Key management | Customer-managed keys across the services you will use, HSM-backed options, FIPS 140-3 validated modules where required, key usage logged | Key custody sets who can decrypt data (SP 800-53 SC-12, SC-28) |
| Provider operator access | Just-in-time access for support staff, customer approval workflow for data access, logs of every approval and access | NCSC principles 6 and 12: provider admin systems are high-value targets |
| Logging and alerting | Control plane, identity and data access logs; export to your SIEM; at least six months retained at no extra cost | Without logs you cannot scope an incident (AU-2, AU-11) |
| Network security | Private connectivity, private endpoints for platform services, default-deny security groups, flow logs | Keeps data paths off the internet (SC-7, SC-8) |
| Resilience | Multiple availability zones, documented regional failure behaviour, immutable or locked backup options, SLA with service credits | Outages and ransomware are availability risks you share (CP-9, CP-10) |
| Vulnerability handling | Public vulnerability disclosure policy, customer security bulletins, notice of platform changes that affect security | You need to know when the platform itself is affected |
| Exit and portability | Bulk export in open formats, documented egress costs, contractual exit assistance, data deletion confirmation | Concentration and lock-in are regulated risks for many sectors |
Key custody options compared
Every major provider now offers a version of the same three models. The trade-off is consistent: more customer control means more customer responsibility for availability.
| Model | Where the key lives | Strength | Cost to you |
|---|---|---|---|
| Provider-managed keys | Provider KMS, provider controls lifecycle | No effort, encryption on by default | You cannot revoke the provider's ability to decrypt, and key usage is often not visible to you |
| Customer-managed keys (CMK, BYOK) | Provider KMS or provider HSM, you control policy, rotation and deletion | Key policy is yours; key use is logged; disabling the key stops decryption | You manage key policies and rotation; a deleted key can destroy data |
| Externally held keys (HYOK) | Your own HSM or key manager outside the provider, reached through a proxy | Provider cannot decrypt without calling your key service | You own availability, latency and durability; AWS documents this as a major departure from the standard shared responsibility model and recommends it only for regulated workloads that require it |
Ask which services support each model, because coverage is uneven: AWS documents that its external key store supports symmetric keys only, with no automatic rotation or multi-Region keys, and recommends a round trip of 35 ms or less to your key manager. For the decision itself see the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.
Evaluation criteria
Weights are an NHI Mgmt Group suggestion; adjust them to your data classes and regulators. Score 0 to 3 on evidence seen, not on the provider's marketing pages.
| Criterion | Weight | Evidence to request | Maps to |
|---|---|---|---|
| Assurance and transparency | 15% | Audit reports and their scope, CCM v4.1 or CAIQ responses, bridge letters, pen test summaries | SA-9, SR-6, CA-2; CSF GV.SC-06 |
| Identity and control plane | 20% | Federation, MFA enforcement, guardrail policies, workload identity federation, break-glass design | AC-2, IA-2, IA-5; CSF PR.AA-05 |
| Data protection and keys | 15% | Key models per service, HSM validation level, key access logging, default encryption | SC-12, SC-28; CSF PR.DS-01, PR.DS-02 |
| Provider access controls | 10% | Operator access process, approval workflow, personnel screening, access logs | PS-3, SA-9 |
| Logging and detection | 15% | Log types, default retention, cost, export latency, native threat detection | AU-2, AU-11 |
| Resilience | 10% | Zone and region design, backup immutability, SLA, incident history and post-incident reports | CP-9, CP-10; CSF PR.IR-04 |
| Contract, location and exit | 15% | Incident notification terms, sub-processor list, data location commitments, exit assistance, deletion evidence | SA-4, SR-5; CSF GV.SC-05, GV.SC-07 |
The CSA Cloud Controls Matrix v4.1, which now combines the CCM and the CAIQ question set, has 197 control objectives across 17 domains and is the most widely used structured questionnaire for cloud providers. A STAR Level 1 entry is a self-assessment; Level 2 pairs the CAIQ with a third-party ISO/IEC 27001 certification or SOC 2 attestation, so weight Level 2 evidence more heavily. See How to Read a SOC 2 Report Guide for what to check in the report itself.
Where identity fits
Most cloud breaches run through identities rather than through the provider's infrastructure. Two questions matter at selection. First, how strong are the defaults: can you enforce MFA for every human account and federate everything to your IdP, as the Cloud Provider Mandatory MFA guide describes? The Snowflake Breach 2024 showed what happens when a cloud platform lets customers run accounts without MFA. Second, how good is non-human identity support: workload identity federation instead of long-lived access keys, scoped service accounts, key age reporting and organisation-wide policies that block key creation. The Capital One Breach 2019 turned on an over-privileged role reachable from a workload. The provider's own key hygiene matters too: in the Microsoft Storm-0558 Key Breach 2023 a stolen provider signing key was used to forge access to customer mailboxes, which is why the transparency and incident reporting criteria above carry real weight. See the Cloud Workload Identity Buyer's Guide.
Provider operator access
Ask how provider staff reach customer environments. Microsoft documents Customer Lockbox for Azure as an example of the pattern to look for: a support engineer requests just-in-time access, a customer approver with a named role approves or denies it, unanswered requests expire after four days, and approvals are written to the Activity Log or the Entra audit log. Note the stated exclusions as well: emergency break-glass scenarios, incidental exposure during troubleshooting and external legal demands do not trigger a request. Every provider has equivalent exclusions; get them in writing. The Cloud Provider Support and Operator Access Controls Guide covers the controls in more depth.
Decision guidance by organisation size
- Small organisations: choose the provider whose secure defaults you will actually keep: MFA enforced, encryption on, logging on, public access to storage blocked by default. Use provider-managed or customer-managed keys in the provider KMS; externally held keys are rarely worth the operational load.
- Large or regulated estates: expect to need organisation-level guardrails, customer-managed keys for regulated data, operator access approval, regional restrictions, long log retention and a tested exit plan. The Cloud Concentration Risk and Exit Strategy Guide covers what regulators expect.
- Second provider: a second cloud reduces concentration risk but doubles identity planes, logging pipelines and policy sets. The NSA's Top Ten Cloud Security Mitigation Strategies (March 2024) include a dedicated sheet on the complexity of hybrid and multi-cloud environments for that reason.
- Sovereign offerings: sovereign regions or partner-operated clouds can meet location and staff-access rules, but often lag on service coverage. Check the services you need exist there before you rely on it.
Questions to ask vendors
- Which of the services and regions we plan to use are inside the scope of your ISO/IEC 27001, ISO/IEC 27017 and SOC 2 reports, and when did each period end?
- Can we enforce MFA and federation for every human identity, including the root or owner account, with no local password fallback?
- How do workloads authenticate to your APIs without long-lived keys, and can we block creation of long-lived keys organisation wide?
- Which services support customer-managed keys and which support externally held keys, and is every use of a key logged in a log we can export?
- How do your support and engineering staff gain access to customer data, can we approve each access, and what are the exclusions?
- Which logs are on by default, how long are they kept at no extra charge, and which data access logs cost extra?
- How quickly will you notify us of a security incident affecting our tenancy, and is that a contractual commitment?
- How did you handle your last significant security incident, and was a public post-incident report published?
- Where is our data stored and processed, including backups, logs, telemetry and support tickets, and can we restrict it to named regions?
- Which sub-processors can access our data, and how will we be told of changes?
- What exit assistance do you provide, in which formats can we export data and configuration, and what are the egress charges?
- How will you confirm deletion of our data and keys at the end of the contract?
Red flags
- Audit reports whose scope excludes the services, regions or control plane components you plan to use, or no recent report at all.
- MFA, federation, organisation guardrails or audit logs only available on a premium support plan or a separate product.
- Logs retained for days by default, with data access logging priced so high that customers routinely leave it off.
- No way to see or approve provider staff access to your data, or refusal to document the exceptions.
- Customer-managed keys missing for the core storage and database services you need.
- No public vulnerability disclosure policy and no record of publishing post-incident reports.
- Exit terms that offer data export only in proprietary formats, or no contractual exit assistance.
Proof of concept
Run the POC in a sandbox organisation or account structure that mirrors your intended landing zone, with one representative workload and synthetic data. See the Cloud Landing Zone Security Guide for the baseline to build.
- Federate the sandbox to your IdP, enforce MFA, lock the root or owner account behind break-glass credentials, and confirm a user removed from the IdP loses access.
- Apply organisation guardrails: deny public storage, deny long-lived access key creation, restrict regions. Try to break each one and confirm it is blocked and logged.
- Deploy the workload through infrastructure as code using workload identity federation from your pipeline, with no stored cloud keys.
- Encrypt a storage bucket and a database with a customer-managed key, disable the key, and confirm reads fail and the attempt is logged. Re-enable and confirm recovery.
- Export control plane, identity and data access logs to your SIEM; measure delivery delay and confirm the retention and cost in writing.
- Raise a support case that would need data access and observe the operator access approval flow end to end.
- Restore a backup into a different zone or region and time it against your recovery objectives.
- Export the workload's data and configuration as if exiting, and record the steps, formats and egress cost in your Cloud Exit Plan Template.
- Agree go-live metrics: share of human identities federated with MFA, count of long-lived keys, share of regulated data under customer-managed keys, log delivery delay and backup restore time.
Primary sources used here: NCSC: The Cloud Security Principles, CISA: Secure by Demand Guide, Cloud Security Alliance: Cloud Controls Matrix, Cloud Security Alliance: STAR Registry, ISO: ISO/IEC 27017, NSA: Top Ten Cloud Security Mitigation Strategies, NIST: SP 800-53 Rev. 5, AWS: External key stores and Microsoft Learn: Customer Lockbox for Microsoft Azure. Products are named only to illustrate documented features; this is not a recommendation.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: Cloud Security Guide · Shared Responsibility Models Guide · Cloud Concentration Risk and Exit Strategy Guide · Security Requirements for Selecting a Colocation or Data Centre Provider · Security Requirements for Selecting a Managed Kubernetes Service