Keeping auditors calm, admins sane, and privileges on a short leash across AWS, Azure, and GCP

ISO 27001 is often described as “technology-agnostic,” which is a polite way of saying the standard doesn’t care how complex your environment is. If you’re running AWS, Azure, and GCP in parallel, that distinction stops being comforting very quickly.

From an auditor’s point of view, multi-cloud is not “advanced.” It’s risky. Multiple control planes. Multiple identity and access management (IAM) models. Multiple places for access creep to quietly sprawl while everyone assumes someone else is looking after privilege escalation.

ISO 27001 is just one of the many international cybersecurity standards, from EU Cybersecurity Laws to NYDFS, but they all want organizations to address access control standards. Not policies. Not diagrams. Actual control over who can do what, where, and for how long, across all your environments.

What ISO 27001 Really Expects From Access Control

ISO 27001:2022 doesn’t ask for perfection. It asks for evidence of intent, implementation, and review.

Specifically, access control controls (Annex A.5.15–A.5.18) boil down to four expectations:

1. Access is risk-based, not convenience-based
2. Identities are managed across their lifecycle
3. Authentication is strong and protected
4. Access rights are granted sparingly and reviewed regularly

If any of those break down in one cloud, auditors’ll (quite reasonably) assume they break down everywhere.

The Multi-Cloud Access Control Problem, Unvarnished

AWS, Azure, and GCP each do IAM ok, in isolation. ISO 27001 issues arise from the gaps between them.

Common patterns auditors recognize instantly:

• Standing admin roles “just in case”
• Cloud engineers holding privileges they last needed six months ago
• IAM roles that grew organically and are now vaguely terrifying
• Service accounts and access keys no one remembers creating
• Access reviews that exist as rubber stamp emails, not analysis

The standard doesn’t ban multi-cloud. It does require you to control it coherently.

What “Good” Looks Like Across AWS, Azure, and GCP

1. Centralized identity, decentralized enforcement

Humans should not exist unfettered inside cloud IAM.

In a compliant design:

• Users authenticate via a central identity provider
• AWS, Azure, and GCP trust that identity
• Cloud access is role-based or group-based, not user-based

This allows identity lifecycle events (joiners, movers, leavers) to propagate cleanly across all three clouds. Disable the identity, and access disappears everywhere.

Auditors like this because it reduces ambiguity. Engineers like it because it stops account archaeology.

2. Just-in-time access instead of permanent privilege

ISO 27001 never says “zero standing privilege,” but it clearly prefers temporary, purpose-bound access over permanent elevation.

In practice:

• Engineers operate without admin access by default
• Elevated cloud permissions are requested when needed
• Access is time-boxed and is revoked automatically
• Every elevation has a reason and an approver

Across AWS, Azure, and GCP, this avoids the slow creep of over-privilege that turns annual access reviews into existential crises.

It also produces lovely audit evidence: timestamps, approvals, expiry logs, and clean revocation.

3. Precision beats predefined roles

Cloud-native permissions are blunt instruments. ISO 27001 does not require you to use them blindly.

A more mature approach:

• Access is minted dynamically
• Permissions are scoped to specific actions on specific resources
• Nothing reusable lingers after the task completes

If an engineer needs to list S3 buckets, they get exactly that. If they need to restart a VM, they get that operation precisely. No wildcard privileges, no future surprises.

Auditors see this as strong risk treatment. Attackers see it as frustrating. Both reactions are desirable.

4. Continuous visibility across clouds

ISO 27001 expects you to know what access exists, not just what you intended to grant.

In multi-cloud environments, that means:

• A unified view of AWS, Azure, and GCP entitlements
• Clear ownership of every role, policy, and service account
• Identification of unused, excessive, or orphaned privileges

This is where many organizations struggle. Native tools show slices of the picture. ISO expects the whole thing.

Visibility isn’t about complex visualizations for their own sake. It’s about being able to answer one simple audit question without sweating:

“Who can access production right now, and why?”

5. Reviews that result in change

ISO 27001 (℅ the International Organization for Standardization) doesn’t just require access reviews. It requires effective ones.

That means:

• Regular reviews of cloud roles and other entitlements
• Clear reviewers (not “the security team”)
• Evidence that access was removed when it shouldn’t exist

In mature environments, reviews aren’t annual panic events. They’re continuous, lightweight, and targeted at high-risk access: admins, sensitive resources, third-party roles, and service accounts.

Auditors don’t expect zero findings, just like no one really believes a five-star rating on Amazon. They expect you to find them yourself.

Where Many Multi-Cloud Programs Quietly Fail

The biggest ISO 27001 access control failures aren’t technical. They’re organizational.

• Engineers self-approve access because production is on fire
• Access tickets pile up and get rubber-stamped
• Emergency access becomes permanent access
• “We’ll fix it after the audit” becomes a lifestyle choice

Standards don’t collapse because people are careless. They collapse because processes don’t scale to reality.

A More Practical Operating Model

Modern access control programs increasingly treat cloud permissions as ephemeral infrastructure, not static configuration.

In this model:

• Access is requested and approved in existing workflows (Slack, Teams)
• Risk-based rules auto-approve low-risk requests
• High-risk access requires explicit approval
• Permissions are created dynamically and destroyed automatically
• All activity is logged, reviewed, and attributable

This aligns surprisingly well with ISO 27001 because it turns policy into behavior, and behavior into evidence.

What Auditors Actually Want to See

When ISO auditors review access control in multi-cloud environments, they’re looking for consistency more than cleverness.

If you can show:

• Central identity governance
• Controlled, time-bound cloud access
• Clear visibility of entitlements
• Regular reviews with remediation
• Evidence that humans don’t live permanently as admins

They tend to relax.

If you can’t, they don’t.

Final Thoughts

ISO 27001 access control isn’t about proving you trust your engineers less. It’s about proving you don’t rely on memory, goodwill, or heroics to protect your cloud estate.

In multi-cloud environments, access control either becomes deliberate and automated, or it becomes accidental and indefensible.

Auditors can tell the difference. So can attackers.

Design accordingly.

‍