Teams should split the authority to grant access from the authority to validate it, and apply that split consistently across AWS, Azure, and GCP. The practical test is simple: no single role should be able to assign privileged access and then certify that same access as acceptable.
Why Separation Matters in Cloud Administration
Cloud administration and audit oversight solve different problems, and they should live with different people or functions. Administration creates or changes access, while audit oversight checks whether those changes were justified and approved. In practice, that means the same person should not be able to both grant privileged access and later sign off that the access was appropriate.
The control objective is not bureaucracy for its own sake, it is preserving independent review. When grant and review sit together, access creep becomes harder to see, exceptions become normalized, and recertification loses value. This separation should hold across AWS, Azure, and GCP, even if the implementation details differ by platform.
Where teams struggle is usually not the policy statement, but the operating model. Cloud roles often bundle provisioning, policy changes, and reporting into one admin path. The safer pattern is to design access so that the person who approves or certifies entitlement cannot also be the person who makes the entitlement true.
What Good Separation Looks Like Across AWS, Azure, and GCP
A practical design uses distinct roles for access administration, audit review, and evidence collection. Administrative roles can create, modify, or revoke access, but they should not own the certification workflow or its evidence trail. Audit or governance roles should be able to inspect assignments, approval history, and usage patterns without having the ability to alter the underlying access they are reviewing.
That separation is easiest to sustain when it is enforced at the platform layer, not just documented in a policy. Use native cloud permission boundaries, delegated administration, and read-only review paths so reviewers can verify access without becoming part of the provisioning chain. If a reviewer needs temporary admin rights for an exception, treat that as a controlled exception with a defined expiry and recorded rationale.
Independent review also works better when the evidence source is stable. Teams should be able to show who approved access, what changed, when it changed, and who later reviewed it. For cloud environments, that usually means combining change logs, access assignment records, and periodic recertification evidence so audit oversight does not depend on memory or spreadsheets.
Where the Control Usually Breaks Down
The main failure mode is role concentration. If one cloud operator can both assign privileged access and validate that assignment later, the review becomes self-certification in practice. That creates blind spots around emergency access, inherited permissions, and standing privileges that remain in place long after the original need has passed.
The issue gets worse when teams use broad platform admin roles as a convenience layer. In that model, the same account may have rights to change IAM settings, manipulate group membership, and view or approve the resulting access report. Audit and access governance guidance is useful here because it reinforces the need to separate assignment, review, and recertification responsibilities rather than collapsing them into a single operator path.
This is also where cloud platform differences matter less than the governance outcome. Whether the control is implemented through AWS IAM, Azure Entra, or GCP IAM, the question is the same: can one role change privileged access and then certify that the change was acceptable? If the answer is yes, the control is not strong enough.
Risk and Threat Considerations
When administration and oversight are combined, the organisation loses independent challenge. That creates avoidable exposure to excessive privilege, undiscovered exceptions, and weak audit evidence, especially in environments where access changes happen frequently and at scale.
Failure mechanism: The same operator can authorise access, implement the change, and later attest that the change met policy, which removes meaningful separation of duties and weakens the integrity of the review process.
Impact: Incorrect or unjustified privileged access can persist longer, detection of access drift becomes harder, and audit conclusions become less trustworthy because the reviewer is effectively validating their own work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly governs splitting access grant and review authority. |
| AC-6 — Least Privilege | Limits how much cloud administration power any one role can hold. | |
| AU-6 — Audit Review, Analysis, and Reporting | Supports independent inspection of access changes and certification evidence. | |
| Recommendation — Separate provisioning and certification duties so no one role can both assign and approve privileged access. Constrain cloud admin roles to the minimum access needed for their operational tasks. Route access evidence to a separate review function and retain records for independent analysis. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | Requires dividing conflicting access and oversight responsibilities. |
| Recommendation — Assign approval, implementation, and review of privileged access to different roles. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Cloud access governance depends on controlled assignment and oversight of access rights. |
| Recommendation — Design cloud access workflows so privilege assignment and review remain independently controlled. | ||
Practitioner Guidance
What to verify: Check whether the review path is truly independent of the provisioning path. If the same cloud role can both modify privileged access and approve recertification evidence, the model needs redesign, not just more documentation.
What good looks like: The admin who makes the change cannot be the final reviewer, and the reviewer can inspect evidence without being able to alter the entitlement under review. That separation should be visible in role design, workflow design, and audit logs.
Common mistake: Treating “read-only” as sufficient when the reviewer still has indirect control over the same access process through another role, automation path, or emergency override.
Practitioner takeaway: The control succeeds only when oversight can challenge administration without depending on the same trust chain, otherwise the review becomes a confirmation step instead of an independent check.