Your AWS security team just passed their audit. Your Azure estate meets compliance requirements. Your GCP workloads follow best practice. Yet your organisation still has critical gaps because nobody owns the spaces between clouds.
This is the multi-cloud security problem that ISO 27017:2015 was designed to address — and it's becoming urgent. The UK's National Cyber Security Centre has repeatedly warned that cloud misconfiguration remains one of the most common causes of data breaches. When you're running workloads across AWS, Azure, and GCP simultaneously, those misconfigurations multiply. Each provider uses different terminology, different default settings, and different security models. What's "secure by default" in one environment may be "exposed by default" in another.
For UK organisations subject to the Data Protection Act 2018 and UK GDPR, this isn't theoretical. The ICO expects you to demonstrate appropriate technical measures regardless of where your data sits. "We use multiple cloud providers" isn't a defence — it's an explanation of how you lost control. A unified multi-cloud security approach is the only way to maintain consistent governance across diverse infrastructure.
What ISO 27017 actually requires for multi-cloud environments
ISO 27017:2015 provides cloud-specific guidance that extends ISO 27001's controls. It addresses the shared responsibility model explicitly — something the base standard doesn't do well. The standard introduces seven additional controls specific to cloud computing, covering areas like virtual machine hardening, cloud service customer data removal, and segregation in virtual environments.
For multi-cloud architectures, three control areas matter most:
- CLD.6.3 (Segregation in virtual environments) — requires you to ensure adequate separation between your workloads and other customers'. Each provider implements this differently: AWS uses VPCs, Azure uses virtual networks, GCP uses VPCs with a different networking model. Your implementation must satisfy the same control intent across all three, even though the technical implementation differs.
- CLD.9.5 (Virtual machine hardening) — mandates consistent hardening standards. Your AWS AMIs, Azure VM images, and GCP machine images need equivalent security baselines. A configuration that meets hardening standards in one environment but not another creates an audit finding and, more importantly, an actual security gap.
- CLD.12.4 (Administrator's operational security) — demands privileged access controls that work consistently across all environments. This means just-in-time access, session recording, and approval workflows that operate regardless of which cloud console the administrator is using.
The challenge: AWS IAM, Azure Entra ID, and GCP IAM use fundamentally different permission models. A "read-only" role in one platform may grant capabilities that would be considered administrative in another. Organisations need to normalise these permission models into a single access governance framework rather than managing each cloud's permissions in isolation.
Why multi-cloud security gaps are growing
Azure security configurations don't translate to AWS. GCP security deployments in UK regions operate under different regional constraints, compliance boundaries, and service availability. And very few organisations have the internal depth to maintain expert knowledge across all three platforms simultaneously.
The practical result is drift. Your Azure team implements Defender for Cloud. Your AWS team uses Security Hub. Your GCP team relies on Security Command Center. Each tool reports compliance against its own benchmarks. None of them tell you whether your organisation meets ISO 27017 across the board — because none of them is designed to map findings to that standard natively.
This creates three specific problems:
Inconsistent identity boundaries. Most organisations federate identity from a single provider (usually Azure Entra ID) into AWS and GCP. But federation doesn't mean equivalence. Conditional access policies that block risky sign-ins in Azure may not trigger when that same identity accesses AWS via SAML assertion. The gap between what identity security looks like in each cloud creates blind spots.
Uneven encryption standards. AWS defaults to AES-256 for S3 server-side encryption. Azure Storage uses AES-256 by default. GCP Cloud Storage uses AES-256. Sounds consistent — until you realise key management differs entirely. Customer-managed keys in AWS KMS, Azure Key Vault, and GCP Cloud KMS have different rotation capabilities, access logging, and integration points. A key rotation policy that works in one cloud may fail in another.
Logging blind spots. CloudTrail, Azure Monitor, and Cloud Audit Logs each capture different event types with different retention defaults. If you're not normalising these into a unified detection capability with consistent correlation rules, you're missing attack patterns that span providers. An attacker who compromises credentials in Azure and pivots to AWS may leave evidence in both clouds, but neither cloud's native detection tool will connect the events.
Practical implementation: building a unified control framework
Stop trying to make each cloud's native tools do everything. Instead, build an abstraction layer that maps ISO 27017 controls to provider-specific implementations. This approach reduces the maintenance burden and ensures consistent audit evidence regardless of which cloud the auditor asks about.
Step one: Create a control mapping matrix. Take each ISO 27017 control and document how AWS, Azure, and GCP each address it. Where gaps exist, document compensating controls. This becomes your audit evidence and your engineering specification simultaneously. Update the matrix whenever a cloud provider changes its service offerings.
Step two: Centralise identity governance. Use a single identity provider with consistent conditional access policies. Implement just-in-time privileged access using tools that work across all three clouds. Azure PIM can govern Azure roles natively, but you'll need AWS IAM Identity Center and GCP's PAM capabilities configured to equivalent standards. Document the mapping between each cloud's privileged roles and your organisation's access governance policy.
Step three: Normalise security telemetry. Feed all three providers' security logs into a unified detection capability. Build detection rules that correlate activity across providers. An attacker who compromises credentials in Azure and pivots to AWS should trigger alerts based on the pattern, not just individual events. This requires consistent log schema and retention policies across all three clouds.
Step four: Automate configuration assessment. Manual reviews don't scale across multi-cloud environments. You need continuous scanning that checks all three environments against your unified control framework — not just each provider's native benchmarks. Automated assessment produces the evidence auditors need without the quarterly scramble to collect screenshots.
Common mistakes that fail audits
Treating each cloud as a separate compliance scope. Auditors increasingly expect unified evidence. If your AWS documentation looks completely different from your Azure documentation, they'll question whether you have genuine control or just checkbox compliance per platform.
Assuming provider certifications transfer to you. AWS, Azure, and GCP all hold ISO 27017 certifications for their infrastructure. That covers their responsibilities under the shared responsibility model. It says nothing about how you've configured your workloads. Your configuration choices are your compliance problem.
Ignoring inter-cloud data flows. Data moving between AWS and Azure may traverse the public internet unless you've explicitly configured private connectivity. That has encryption-in-transit implications under ISO 27017's data protection controls. Our consultants recommend private connectivity between clouds (Direct Connect, ExpressRoute, Dedicated Interconnect) for any data flows supporting regulated workloads.
Underinvesting in training. Multi-cloud security requires understanding of all three platforms. A team that knows AWS well but is weak on GCP will create gaps in the weakest link. Cross-train your team or supplement with expert support until internal capability catches up.
Frequently asked questions about multi-cloud security
Does an organisation need ISO 27017 certification for each cloud provider separately?
No. ISO 27017 certification is achieved at the organisational level, with the audit scope covering how you implement cloud security controls across all environments. The auditor will sample controls across your AWS, Azure, and GCP deployments to verify consistent implementation.
How should secrets be managed across multiple clouds?
Secrets management is one of the highest-risk areas in multi-cloud environments. Our consultants recommend a single secrets management platform that supports all three cloud providers, with consistent rotation policies, access auditing, and integration into CI/CD pipelines across all environments.
Can organisations use a single SIEM across AWS, Azure, and GCP?
Yes, and our team strongly recommends it for organisations running multi-cloud workloads. A unified SIEM with cloud-agnostic ingestion pipelines provides the correlation capability that native tools lack. Without it, you cannot detect cross-cloud attack patterns or produce consistent incident response evidence.
How Pyralink helps
Pyralink Innovation Ltd specialises in multi-cloud security architecture for UK organisations. Our CloudAuditX platform scans AWS, Azure, and GCP environments simultaneously, mapping findings against ISO 27017 controls rather than just provider-specific benchmarks. You get a unified view of your security posture across all three clouds.
For organisations needing deeper support, our vCISO service (from £497/month) provides ongoing governance across your multi-cloud estate. We help you build the control mapping matrices, implement the technical controls, and prepare the evidence packs that satisfy auditors. Pyralink holds £5M professional indemnity insurance — we stand behind our work.
Michael Adedeji, Pyralink's founder, holds CISM, CISA, and CC certifications with hands-on experience implementing ISO 27001 and 27017 controls across enterprise multi-cloud environments.