# Put a service role's purpose next to its owner

Identities outlive deployments unless someone owns their lifecycle. Keep the permission rationale and recovery procedure available to the team operating the workload.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Maintain an identity record

Record the workload, owner, environment, trust mechanism and policy location. Link the normal and recovery operations that justify its access.

Include any long-lived credential exception and its management procedure without storing the secret value in the documentation. The record should explain where authority comes from, not expose it.

Use naming that distinguishes runtime, deployment and administrative identities. Similar names with different authority create avoidable confusion during incidents.

## Preserve the permission evidence

Keep the allowed and denied test cases with the relevant policy version. Include uncommon schedules and recovery operations that a new maintainer might otherwise remove as unused.

Document the limits of activity-based analysis. A quiet observation period is evidence about that period, not proof that every unobserved permission is unnecessary.

Record why broader scopes remain where provider semantics require them and what other restrictions apply.

## Rehearse a denial investigation

Give the incoming team a synthetic failure involving the wrong output resource. They should identify the actual principal, requested action and effective policy context before proposing a change.

Verify that they can distinguish an application targeting error from a legitimate missing permission. The default response should not be attaching an administrator policy.

Document the approved emergency access path and how temporary grants are removed after recovery.

## Retire access with the workload

Include identity review in service decommissioning, account changes and ownership transfers. Remove unused roles, trust relationships and resource grants through the supported process.

Confirm that deployment automation no longer recreates retired access. Deleting a role manually while leaving its infrastructure definition active produces confusing drift rather than a lasting retirement.

A useful handover lets another operator explain every important permission and find the person authorised to change it. That makes future maintenance safer and faster than relying on a role whose only history is that it once fixed an outage.

## Sources

- [AWS: IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)