What breaks when access reviews still rely on spreadsheet workflows in AWS environments?

Why Spreadsheet Reviews Break Down in AWS

Spreadsheet access reviews assume identities, permissions, and ownership are stable enough to be checked in batches. AWS does not behave that way. Accounts multiply, IAM roles shift, permission sets change, and delegated administration spreads responsibility across teams and environments. That means a static workbook quickly becomes a snapshot of a moving target, not evidence of control.

For security teams, the real problem is not the spreadsheet itself but the mismatch between manual review cadence and cloud-native identity sprawl. AWS access often includes service roles, cross-account trust, temporary sessions, and inherited permissions that are easy to miss when reviewers are working from exports. NIST control guidance for access review and least privilege is clear in principle, but enforcement becomes fragile when the review process is not tied to live identity data and revocation workflows. See the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls for the underlying governance expectations.

NHIMG research shows why stale governance is so dangerous: in the Ultimate Guide to NHIs, 71% of NHIs are not rotated within recommended time frames, and 97% carry excessive privileges. In practice, many security teams discover review failures only after access has already drifted past approved boundaries, rather than through intentional control design.

How It Works in Practice

Effective AWS access reviews need to move from spreadsheet choreography to source-of-truth governance. That means pulling identity and entitlement data directly from AWS Organizations, IAM, IAM Identity Center, and any external identity provider, then validating that data against business ownership and approved access intent. Reviews should be driven by live exports or API-fed workflows, not emailed sheets that age the moment they are opened.

The operational goal is to make review, attestation, and remediation part of one controlled loop. Reviewers should see the actual principals, attached policies, permission sets, trust relationships, and last-used signals. When something is out of policy, revocation should flow into the same workflow so that the decision is not just recorded but enforced. Current guidance suggests pairing access certification with least-privilege testing, because some AWS permissions are only dangerous in combination, especially across accounts and roles.

• Use authoritative inventory from AWS rather than manually maintained tabs.
• Segment reviews by account, application, and business owner so scope stays understandable.
• Include non-human identities such as roles, keys, and automation accounts, not just named users.
• Capture evidence of who approved, what changed, and when revocation completed.

NHIMG’s NHI Lifecycle Management Guide is relevant here because access review is only one checkpoint in a broader lifecycle that includes onboarding, rotation, monitoring, and offboarding. For AWS-specific attack patterns, the Codefinger AWS S3 ransomware attack illustrates how quickly exposed cloud access can become an operational incident. These controls tend to break down when organisations rely on exported spreadsheets for cross-account roles because the data is already stale by the time reviewers finish the first pass.

Common Variations and Edge Cases

Tighter access review process often increases operational overhead, requiring organisations to balance auditability against reviewer fatigue and change velocity. That tradeoff becomes sharper in AWS environments with ephemeral workloads, federated access, and heavy use of automation. Best practice is evolving, but there is no universal standard for treating service roles, break-glass access, and short-lived sessions exactly the same way as human accounts.

One common edge case is access that is technically valid but operationally misleading. A role may appear broad in a spreadsheet even though it is only assumable under narrow conditions, or a temporary permission set may be approved for a task that has already ended. Another issue is reviewer context: if the workbook does not show last-used data, trust policy, or account ownership, approvers are forced to guess. That is how stale attestations survive intact.

Spreadsheet workflows also struggle with scale in organisations that separate security administration, account ownership, and application ownership. The more handoffs involved, the more likely it is that a revocation request gets recorded but never executed. The better pattern is to treat reviews as evidence generation for a living control, not as a yearly compliance exercise. For a broader view of recurring NHI failure modes, the 52 NHI Breaches Analysis is a useful reference point, especially when access review gaps combine with excessive privilege and slow remediation.

Related resources from NHI Mgmt Group

• What breaks when access reviews rely on reviewer memory instead of evidence?
• What breaks when user access reviews are still manual in hybrid environments?
• What breaks when financial institutions rely on manual access reviews instead of governed workflows?
• What breaks when access reviews rely on manual cleanup in Elastic environments?