Onboarding a cloud provider without a proper security review exposes your organisation to uncontrolled third-party risk, potential regulatory violations, and data breaches that could have been prevented. The cloud provider gains access to your systems, data, and processes from the moment the contract is signed, yet without a structured review, you have no verified basis for trusting their security posture. The questions below unpack exactly what that risk looks like, how it affects your compliance obligations, and what you can do to prevent it becoming a permanent liability. If you want to talk through your current vendor landscape, feel free to get in touch with us and we will be happy to help.
What risks does an unreviewed cloud provider introduce?
An unreviewed cloud provider introduces a range of uncontrolled risks: data exposure, supply chain vulnerabilities, unclear incident response responsibilities, and the absence of any contractual security baseline. Because you have not assessed their controls, you are effectively extending trust without evidence, which is one of the most common root causes of third-party breaches.
The risk profile breaks down across several dimensions. From a data perspective, any provider handling personal or confidential data becomes a processing extension of your organisation. If their environment is misconfigured or under-protected, that exposure is yours to answer for. From an operational perspective, a provider with weak availability or recovery controls can take your critical services offline without warning. From a reputational perspective, incidents originating in a vendor environment are rarely perceived as “their fault” by customers or regulators.
Supply chain attacks have become a preferred vector for threat actors precisely because organisations tend to scrutinise their own perimeter while leaving vendor access under-governed. A cloud provider with broad access to your infrastructure, APIs, or customer data and no verified security baseline is a structural gap, not just a theoretical one.
How does skipping a security review affect compliance obligations?
Skipping a security review of a cloud provider directly undermines your compliance obligations under frameworks including GDPR, NIS2, ISO 27001, and DORA. Each of these frameworks places explicit responsibility on the organisation to assess, select, and monitor third-party suppliers who handle data or provide critical services. Ignorance of a vendor’s security posture is not a valid defence.
Under GDPR, engaging a processor without verifying their technical and organisational measures violates Article 28, which requires a documented assessment before any processing agreement is formalised. Under NIS2, organisations in scope must manage supply chain security as part of their broader risk management obligations, and cloud providers are squarely within that scope. Under ISO 27001, supplier security is a named control domain, and auditors will look for evidence of supplier assessments as part of certification.
The practical consequence is that a compliance gap in your vendor selection process does not stay isolated. It surfaces during audits, due diligence reviews, and incident investigations. Organisations that onboard cloud providers reactively, without documented security reviews, frequently discover that the gap affects not just one vendor relationship but their entire third-party governance posture. That is a much larger remediation problem than a single review would have been.
What should a cloud provider security review actually include?
A cloud provider security review should cover, at minimum: the provider’s security certifications and audit reports, their data processing and sub-processor arrangements, access control and encryption standards, incident response and breach notification procedures, business continuity and disaster recovery capabilities, and the contractual terms that govern all of the above.
Documentation and certification checks
Start with what the provider can evidence. ISO 27001 certification, SOC 2 Type II reports, or equivalent third-party audit outcomes give you an independently verified baseline. These are not a substitute for your own assessment, but they confirm that a structured security programme exists and has been tested. Where certifications are absent, request a completed security questionnaire aligned to a recognised standard such as the Cloud Security Alliance CAIQ.
Contractual and operational controls
Review the Data Processing Agreement carefully, including sub-processor lists and the conditions under which sub-processors can be added or changed. Confirm that breach notification timelines meet your regulatory obligations, that data residency commitments align with your jurisdiction requirements, and that exit and data deletion provisions are clearly defined. Operational controls such as logging, monitoring, and vulnerability management practices should also be part of the conversation before you sign.
Who is responsible for reviewing a cloud provider’s security posture?
Responsibility for reviewing a cloud provider’s security posture sits with the organisation onboarding the provider, not the provider itself. Regardless of how robust a vendor’s own security programme is, the obligation to verify and document that assessment belongs to the organisation that will rely on the provider’s services and be accountable to regulators and customers.
In practice, this responsibility needs to be owned by a named function within your organisation. In larger organisations, this typically falls to the Information Security or Procurement function, often in collaboration with Legal for contractual review. In scale-ups and mid-market companies, this ownership is frequently unclear, which is exactly where governance gaps emerge.
The key principle is that ownership must be role-based, not individual-dependent. If the review only happens when a specific person remembers to initiate it, the process is fragile. Continuous governance requires that vendor review is embedded into a repeatable, accountable process with defined triggers, owners, and outcomes, not left to informal judgment. Management must actively sponsor this, because vendor decisions are ultimately business decisions with security consequences.
When is it too late to fix a cloud provider security gap?
It is never entirely too late to address a cloud provider security gap, but the cost and complexity of fixing it increase significantly once the provider is embedded in your operations. The longer a gap persists, the more it becomes entangled with live data, active integrations, and contractual dependencies that make remediation disruptive.
There are moments when the gap becomes genuinely difficult to close. If an incident has already occurred and the provider’s environment was the entry point, you are now in a reactive position where remediation happens under regulatory scrutiny and reputational pressure simultaneously. If a certification audit is imminent and the vendor relationship cannot be evidenced, you face a finding that delays or jeopardises the audit outcome. If the provider holds data that cannot easily be migrated, dependency has already accumulated to the point where negotiating better contractual terms is difficult.
The practical answer is that the right moment to address a cloud provider security gap is before the contract is signed, the second-best moment is during the first contract renewal, and any moment after that still has value but carries increasing remediation cost. Governance drift, where an initially acceptable vendor relationship gradually moves out of alignment with your risk appetite, is one of the most common patterns we see in organisations that lack a structured vendor review cycle.
How can organisations build a repeatable cloud vendor review process?
A repeatable cloud vendor review process requires four components: a defined trigger set for when reviews occur, a standardised assessment framework, clear ownership and escalation paths, and a record-keeping mechanism that creates an audit trail. Without all four, the process will be inconsistent and difficult to evidence during audits or incidents.
Define your triggers and scope
Reviews should be triggered by onboarding a new provider, renewing an existing contract, a material change in the provider’s services or sub-processors, a security incident at the provider, and on a periodic basis aligned to your risk classification. Not all vendors carry the same risk, so a tiered approach makes sense: providers with access to personal data or critical systems warrant more frequent and deeper reviews than low-risk tooling.
Standardise the assessment and maintain continuity
Use a consistent questionnaire or assessment template so that reviews are comparable over time and across vendors. Map your assessment criteria to the regulatory frameworks you operate under, whether that is GDPR, NIS2, ISO 27001, or others, so that the output of each review is directly useful for compliance purposes. Assign a named owner for each vendor relationship who is responsible for initiating reviews, chasing outstanding responses, and escalating unresolved gaps. Store all review outputs in a central register that is accessible to your security, legal, and management teams.
Building this kind of structured, continuous process is at the core of what governance as a permanent capability looks like in practice. It is not a one-off project or an annual checkbox; it is an ongoing operational discipline that keeps your organisation in control of its vendor risk posture across the full lifecycle of every cloud relationship.
If your organisation is working through how to structure cloud vendor reviews or wants to strengthen its third-party governance more broadly, contact us and we can help you build a process that works for your size, sector, and regulatory obligations.
Frequently Asked Questions
How long does a cloud provider security review typically take?
The timeline depends on the provider's responsiveness and the depth of review required, but a structured assessment for a high-risk cloud provider typically takes two to four weeks from initial questionnaire to documented outcome. Lower-risk providers with existing certifications like ISO 27001 or SOC 2 Type II can often be reviewed more quickly, since third-party audit reports reduce the volume of direct questioning required. Building this timeline into your procurement process from the start prevents the review from being rushed or skipped under commercial pressure.
What if a cloud provider refuses to share their security documentation?
A refusal to share security documentation is itself a significant risk signal and should factor directly into your onboarding decision. Most reputable providers will share SOC 2 Type II reports, ISO 27001 certificates, or completed CAIQ questionnaires under a non-disclosure agreement, so outright refusal is unusual and warrants scrutiny. If a provider cannot evidence their security posture, you have no verified basis for trust, and onboarding them for any processing involving personal data or critical systems would likely place you in breach of your own compliance obligations under GDPR Article 28 or equivalent frameworks.
Does using a major cloud provider like AWS, Azure, or Google Cloud mean we can skip the security review?
No — using a hyperscale provider does not eliminate the need for a security review, though it does change its focus. The shared responsibility model means that while the provider secures the underlying infrastructure, your organisation remains responsible for how you configure, access, and govern your environment on top of it. A review for a hyperscale provider should focus on your configuration choices, IAM policies, data residency settings, and the contractual terms in their Data Processing Agreement, rather than questioning the provider's core infrastructure security.
How should we handle cloud providers that are onboarded by individual teams without going through a central review process?
Shadow IT procurement — where teams onboard cloud tools independently — is one of the most common sources of unreviewed vendor risk, and addressing it requires both a policy control and a cultural shift. The policy layer means establishing a clear rule that no cloud provider handling company data or systems can be onboarded without a completed security review and sign-off from the responsible function. The cultural layer means making the review process fast and low-friction enough that teams do not bypass it out of convenience, which often requires a tiered approach where lightweight tools face a lighter-touch assessment than high-risk providers.
What is the difference between a one-time vendor assessment and continuous vendor monitoring?
A one-time assessment gives you a point-in-time snapshot of a provider's security posture, which becomes outdated as the provider's environment, sub-processors, and your own usage of their services evolve. Continuous monitoring means maintaining visibility over that relationship throughout its lifecycle — tracking certification renewals, reviewing sub-processor changes, responding to provider-side incidents, and conducting periodic reassessments aligned to your risk tier. For providers with access to personal data or critical systems, a one-time review at onboarding is a starting point, not a complete governance answer.
How do we prioritise which cloud providers to review first if we have a large existing vendor estate with no prior assessments?
Start by mapping your existing vendor estate against two dimensions: the sensitivity of the data or systems each provider can access, and the criticality of the services they deliver to your operations. Providers that score high on both — for example, those handling personal data and supporting business-critical processes — should be reviewed first. From there, work through providers with high data sensitivity but lower operational criticality, then those with operational criticality but lower data risk. Documenting this prioritisation rationale also demonstrates a risk-based approach to auditors, which has compliance value in itself.
Can we rely on a cloud provider's self-reported security questionnaire, or do we need independent verification?
Self-reported questionnaires are a useful starting point but should not be treated as sufficient evidence on their own, particularly for high-risk providers. Where independent verification is available — such as a current ISO 27001 certificate or a SOC 2 Type II report from a recognised auditor — you should request and review it alongside the questionnaire, as it provides a tested rather than declared view of the provider's controls. For providers without third-party audit reports, a more detailed questionnaire combined with contractual commitments and, where proportionate, a right-to-audit clause provides a stronger governance basis than self-attestation alone.
Related Articles
- Why does your sales team keep losing deals over compliance?
- What do you prioritize when your compliance budget gets cut?
- What governance structure works best for mid-market companies?
- What happens when governance gets one agenda item and is never discussed properly?
- What happens when your entire compliance program depends on one person?