Identity & Access Management Risk Checklist

Identity failures are still among the most common ways systems — including AI products — are abused: leftover admin accounts, shared API keys, missing MFA on cloud consoles, and contractors who never lost access after a project ended.

This checklist is a practical lens for technology and risk partners. It is educational and does not constitute an audit programme or certification.

How to use it

• Scope one environment first (e.g. production cloud + SSO + AI vendor consoles).
• Evidence beats intention: screenshots, IdP policies, ticket IDs, last review dates.
• Re-run after org changes, M&A, or major vendor onboarding.
• Connect findings to your AI risk and vendor assessments when the same identities unlock model keys or customer data.

Joiners

New access should be role-based and approved, not cloned from a teammate’s over-privileged account.

• Standard role catalogue for engineering, support, finance, etc.
• Time-bound exceptions
• Separated identities for humans vs automation

Movers

Internal moves silently accumulate entitlements (“access creep”).

• Triggered add/remove on role change
• Expiring project access
• Manager attestation for sensitive apps

Leavers

Last-day disablement must cover more than the laptop SSO session.

• IdP / email / chat
• Cloud consoles and AI vendor seats
• PATs, API keys, deploy tokens, shared inboxes
• Device trust and VPN

Privileged access

Treat production admin, billing owners, and break-glass accounts as high-risk assets.

• Inventory and ownership
• Just-in-time elevation where possible
• Dual control for destructive actions when feasible
• Regular review of standing privileges

MFA

MFA is necessary but not sufficient; quality matters.

• Enforce for workforce and remote access
• Prefer phishing-resistant methods for admins
• Control recovery paths (SIM swap and backup-code abuse are real)

Service accounts

Machine identities often outlive the humans who created them.

• Named owner and purpose
• Least privilege and environment separation
• Rotation, scanning for leaked keys, emergency revoke
• No long-lived keys in git or client apps

Access reviews

Periodic reviews catch what joiner/mover automation misses.

• Cadence by sensitivity
• Reviewer accountability
• Documented keep/revoke outcomes
• Focus on admins, data stores, and AI/vendor consoles

Segregation of duties

Prevent one person from requesting, approving, and concealing sensitive changes.

• Define conflicts for your critical processes (deploy + prod data; finance + admin)
• Compensating monitoring when small teams cannot fully split roles

Authentication

Centralise where you can; exception-manage where you cannot.

• SSO coverage for critical apps
• Strong password and anti-stuffing baselines for residual local accounts
• Risk-appropriate sessions and step-up authentication

Logging

You cannot investigate what you never recorded.

• Authn success/failure and privilege use
• Retention aligned to incident needs
• Alerting on anomalous admin behaviour
• Protect logs from tampering by the same admins they monitor (as far as practical)

Third-party access

Vendors, contractors, and “temporary” integrators need the same discipline.

• Distinct identities
• Time bounds and tickets
• No shared generic logins
• Offboarding checklist that includes AI and cloud vendor seats

Closing note

Strong IAM will not make an unsafe AI use case safe — but weak IAM will undermine every other control. Use this checklist alongside the AI Risk Assessment Checklist and the educational DORA primer when identity underpins critical digital services.