Cloud IAM Role Design Standard Template

Most cloud IAM sprawl starts at design time, when each team invents its own role names, scopes and trust rules and nobody can later tell which role is safe to remove. This template is a design standard that [Organisation] can adopt as written: it sets the rules every new IAM role, role assignment and service account must meet before it is created, covering naming, permission scope, maximum-permission boundaries, trust and assumption, session limits, ownership and periodic review. It applies to AWS, Microsoft Azure with Entra ID, and Google Cloud; platforms are listed alphabetically. It is for cloud platform engineers, identity architects and security reviewers. It complements the Cloud IAM Review Checklist, which audits roles that already exist; this standard governs how they are designed.

How to use this template

Adopt sections 1 to 11 as policy text. Replace bracketed values such as [Organisation], [prefix] and [90 days] with your own, and delete platform rows you do not use.
Turn each "must" into an automated check in your infrastructure as code pipeline (policy-as-code on Terraform plans, AWS IAM Access Analyzer policy validation, Azure Policy, Google Organization Policy). A standard that is only reviewed by hand drifts within months.
Apply it to new roles first, then bring existing roles into line when they are next changed or reviewed, starting with privileged ones.
Record exceptions in the register in section 10, with an owner and expiry date.

1. Purpose

This standard ensures that every cloud IAM role at [Organisation] has a predictable name, a single purpose, the least privilege it needs, a bounded maximum, a trust relationship limited to known principals, a named owner and a review date, so that access can be understood, audited and removed safely.

2. Scope

AWS: IAM roles, customer managed policies, permissions boundaries, and permission sets in IAM Identity Center.
Azure and Entra ID: Azure RBAC custom role definitions and role assignments, Entra directory role assignments, application permissions and managed identities.
Google Cloud: custom roles, IAM allow and deny policies, and service accounts.
Identities covered: workforce users through federation, workloads, CI/CD pipelines, third parties and AI agents. Long-lived IAM users and service account keys are covered by section 7.

3. Definitions

Role: a named set of permissions (AWS IAM role or permission set, Azure role definition, Google role).
Binding: the attachment of a role to a principal at a scope (AWS policy attachment, Azure role assignment, Google allow policy binding).
Boundary: a control that sets the maximum permissions regardless of what a role grants (AWS permissions boundaries and service control policies, Google deny policies, Azure role assignment conditions and assignable scopes).
Trust: the rule stating which principals may use a role (AWS trust policy, Entra federated credentials and managed identity assignment, Google service account impersonation grants).
Privileged role: any role that can change IAM, read secrets, change logging, or administer an account, subscription, project or above.

4. Naming convention

Names must let a reviewer tell purpose, owner, environment and privilege from the name alone. Use the pattern [prefix]-[env]-[app or team]-[function]-[access level], lower case, hyphen separated.

Element	Allowed values	Example
prefix (identity type)	hum (people), wl (workload), ci (pipeline), ext (third party), agt (AI agent), bg (break-glass)	wl
env	prd, stg, dev, sbx, shared	prd
app or team	Short name from the [CMDB / service catalogue]	payments
function	What the role does, one or two words	s3-export
access level	ro (read only), rw (read and write), admin, iam (can change access)	rw

Must: keep names within platform limits (AWS role names are limited to 64 characters) and never include secrets, customer names or data classifications in a name. Google advises against sensitive terms in service account emails because anyone who can view an allow policy can see them.
Must: record owner contact, ticket reference and review date in the description field and as tags or labels: [owner], [cost-centre], [data-classification], [review-by].
Should: use the AWS role path (for example /workload/payments/) to group roles for policy conditions and reporting.
Must (automation): reference Azure roles by role definition ID, not name, in scripts; Microsoft notes that names can change while IDs do not.

5. Permission design

One purpose per role. A role serves one application, pipeline or job function. Google recommends single-purpose service accounts because shared accounts make audit trails hard to attribute and access grows over time.
No wildcard actions in custom roles. List actions explicitly. Microsoft advises against * in Actions and DataActions because new operations added later are granted automatically. In AWS, Action "*" or "iam:*" is allowed only in break-glass roles.
Scope resources and add conditions. Name resource ARNs, resource groups or projects; add conditions such as source VPC, organisation ID, tags or TLS where the platform supports them.
No basic or broad built-in roles for workloads. Google Owner and Editor, and Azure Owner and Contributor at subscription scope, must not be bound to workloads. Set the Google Organization Policy constraint iam.automaticIamGrantsForDefaultServiceAccounts so default service accounts are not given Editor automatically; it does not remove existing grants, so review those separately.
Generate, then tighten. Start from a provider managed role in development only, then replace it with a custom least-privilege role, for example one generated by AWS IAM Access Analyzer from CloudTrail activity, before production.
Bind to groups, not individuals, for workforce access. Microsoft recommends assigning roles to groups to reduce assignment count and simplify review.

5.1 Role specification record

Every role request must include this record, stored with the code that creates the role.

Field	What to record	Check before approval
Name	Per section 4	Pattern check passes in the pipeline
Purpose	One sentence: which job or workload, which data	Not shared with another application
Owner and deputy	Named people or team mailbox	Both exist in the HR or directory record
Principals	Exact users, groups, workloads or accounts that may use it	No wildcard principals; external accounts carry an external ID
Permissions	Actions and resources, with conditions	No wildcard actions; policy validation has no errors or security warnings
Boundary	Boundary, SCP, deny policy or condition that caps it	Cannot be edited by the requesting team
Privilege class	ro, rw, admin or iam	admin and iam require security architecture approval and just-in-time access
Session and review	Maximum session and review-by date from section 8	Dates set as tags or labels
Data classification	Highest classification the role can read or change	Matches the data owner's register

5.2 Worked example

A payments service needs to write nightly export files to one storage bucket in production. Under this standard it gets a role named wl-prd-payments-s3-export-rw, with permission to put objects only under the export prefix of that bucket, trusted only by the payments workload's federated identity, capped by the workload permissions boundary, tagged with the payments team as owner, and given a six-monthly review date. It does not get read access to other buckets, list access across the account, or any IAM permission. If the team later asks for read access to reconcile files, that is a second, separately named read-only role rather than a widening of the first, which keeps each role's purpose and blast radius easy to explain in a review.

For technique depth, see the Least Privilege Techniques Guide and How to find AWS IAM policies with wildcard actions.

6. Boundaries and guardrails

Every role sits inside at least one maximum-permission control that the role's own team cannot change.

Control	Platform	Rule in this standard
Permissions boundary	AWS	Must be attached to every role created by a delegated team. Delegated creators may call iam:CreateRole only with the iam:PermissionsBoundary condition set to [approved boundary ARN]. A boundary grants nothing; effective permissions are the intersection of boundary and identity policy.
Service control policies and resource control policies	AWS	Organisation-wide denies for leaving the organisation, disabling CloudTrail and using unapproved regions. SCPs do not apply to the management account, so no workload roles may live there.
Assignable scopes and role assignment conditions	Azure	Custom roles must list the narrowest assignable scopes. Any role that can create role assignments must carry a condition limiting which roles it may assign, as Microsoft recommends.
Deny policies	Google Cloud	Organisation or folder deny policies block IAM policy changes and service account key creation except for [platform admin group]. Deny is evaluated before allow.
Privileged Identity Management	Entra ID and Azure	Privileged roles must be eligible, not active, with MFA, justification and approval on activation.

Choosing the guardrail. Use an organisation-level control (AWS SCP or RCP, Google deny policy at organisation or folder) for rules that hold for everyone, such as never disabling audit logging or never creating service account keys. Use a per-role control (AWS permissions boundary, Azure role assignment condition) when you delegate role creation to product teams and need to cap what those teams can grant. Use just-in-time elevation (Entra PIM, or an equivalent approval flow for AWS and Google Cloud) for people who need privileged roles occasionally rather than daily. Most estates need all three: the organisation layer stops the worst actions, the per-role layer contains delegated teams, and just-in-time access removes standing privilege. AI agents and automation that act for users must get their own workload roles under this standard, never a copy of a human's role.

7. Trust and assumption

Named principals only. Trust policies must name specific account, role or service principals. AWS does not accept a wildcard inside an ARN in a trust policy's Principal element; "Principal": "*" with weak conditions is prohibited. See Wildcard Trust Check.
Third parties: cross-account roles for vendors must require sts:ExternalId, with a value unique to [Organisation] and controlled by the vendor, as AWS's confused deputy guidance describes.
Service principals: resource policies that trust an AWS service must constrain aws:SourceArn or aws:SourceAccount (or aws:SourceOrgID).
Federation for workloads: CI/CD and external workloads must use OIDC workload identity federation, scoped by subject claims to a specific repository and branch or environment, instead of stored keys. See the Cloud Workload Identity Guide.
Impersonation in Google Cloud: Service Account User and Service Account Token Creator must be granted on the individual service account, never at project or folder level, where they would cover every account beneath.
No long-lived keys unless an exception is approved: no new AWS IAM users with access keys for workloads, and the Google constraint iam.disableServiceAccountKeyCreation enforced with narrow exceptions.

8. Session and lifecycle rules

Role class	Maximum session	Elevation	Review cadence
Workforce read only	[8 hours]	Standing via group	[Annual]
Workforce read and write	[4 hours]	Standing via group, production by request	[Six-monthly]
Privileged (admin, iam)	[1 hour]	Just in time with approval	[Quarterly]
Workload and pipeline	Platform default for federated tokens	None	[Six-monthly] plus unused-access check
Third party	[1 hour]	None	[Quarterly] and at contract change
Break-glass	[1 hour]	Sealed credentials, alert on use	[Quarterly] test

AWS allows role sessions of up to 12 hours where the role's maximum session duration permits, and limits chained role sessions to one hour. On retirement, disable before deleting: Google notes that a recreated service account with the same name is a new identity and old bindings will not apply to it.

9. Review and evidence

Design review: every new privileged role, trust to an external account, or exception is approved by [Cloud Security Architecture] before merge.
Unused access: roles and permissions unused for [90 days] are flagged using AWS last accessed information, Google role recommendations or Azure access reviews, and removed after owner confirmation.
Ownership: roles with a departed or missing owner are reassigned within [30 days] or disabled.
Evidence: the pipeline stores the policy check results, approval and change ticket for each role change, for [audit retention period].

Metrics to report: percentage of roles meeting the naming standard; percentage of workload roles with a boundary or equivalent guardrail; number of trust policies naming external accounts without an external ID (target zero); number of standing privileged assignments; percentage of roles reviewed on schedule.

10. Exceptions

Exceptions are requested through [ticket queue], approved by [CISO or delegate], recorded with the role, the rule breached, the compensating control, the owner and an expiry no later than [180 days]. Expired exceptions are treated as findings.

11. Framework mapping

Framework	Reference	Section
NIST SP 800-53 Rev. 5	AC-2 Account Management, AC-3 Access Enforcement, AC-6 Least Privilege, AC-6(5) Privileged Accounts, AC-6(7) Review of User Privileges	4 to 9
NIST CSF 2.0	PR.AA-05 access permissions defined, managed, enforced and reviewed	5 to 9
ISO/IEC 27001:2022 Annex A	5.15 Access control, 5.18 Access rights, 8.2 Privileged access rights	5 to 9

Implementation guidance

Order of work: publish the naming convention and tags first (cheap, immediate reporting value), then boundaries and trust rules for new roles, then the review cycle, then remediation of existing privileged roles.
Test in audit mode: run policy-as-code checks as warnings for [two sprints], measure failures, then switch to blocking. Keep a documented bypass for incidents so a failing check never blocks a fix. Rolling back a rule means returning it to warning mode, not deleting it.
Small organisations with a single account, subscription or project can rely on naming, no-wildcard rules and PIM or just-in-time access, and add boundaries when they delegate role creation. Large estates need boundaries and organisation-level guardrails from day one, because central review cannot keep up with delegated teams.
Common failure patterns: boundaries that the delegated team can itself edit; roles named after people rather than purpose; one CI role shared across all repositories; trust policies left open after a vendor contract ends; and default service accounts still holding Editor. The Capital One breach shows the cost of a workload role with more storage access than its function needed.
Response: if a role is abused despite the standard, follow the Cloud Incident Response Guide.

Cloud IAM Role Design Standard Template: Naming, Boundaries, Trust and Review Rules