IAM Control Checklist

This appendix is a practical review tool for a real IAM environment. It is not a certification checklist and not a vendor comparison sheet. Use it as an operating checklist for finding weak trust boundaries, ownership gaps, lifecycle drift, and poor auditability before those weaknesses turn into an incident.

The strongest way to use the checklist is as a recurring review loop:

• mark each item as yes, partial, no, or unknown
• attach evidence, not only opinion
• identify which no or partial items create the highest blast radius
• turn the highest-risk gaps into named remediation actions with owners

    flowchart LR
	    A["Review current controls"] --> B["Mark yes, partial, no, or unknown"]
	    B --> C["Attach evidence and identify risk"]
	    C --> D["Prioritize remediation"]
	    D --> E["Recheck on the next review cycle"]

What to notice:

• a checklist is only useful when it leads to action
• unknown is an important result, because hidden IAM state is often a real risk signal
• evidence matters more than a confident guess

How to Use This Checklist

Use the checklist as a working baseline, not as a one-time audit worksheet. The goal is to confirm that identities have clear ownership, access has understandable meaning, exceptions are controlled, and security teams can reconstruct what happened when something goes wrong.

Good evidence can include:

• authoritative system records
• exported role or group data
• policy documents
• access review output
• logs for recent privileged or lifecycle events
• proof that a control was tested rather than only described

If a control exists only in tribal knowledge, mark it as weak even if experienced staff believe it usually works.

Rating Guidance

Use the following meaning consistently:

• Yes: The control exists, is documented or observable, and works in normal operations.
• Partial: The control exists in some systems, environments, or teams but is inconsistent or weak.
• No: The control is missing or known to be ineffective.
• Unknown: The organization cannot confidently determine whether the control is present or working.

Unknown should not be treated as harmless. In IAM, uncertainty about ownership, privilege, or logging often means the environment is already hard to secure.

Identity Inventory

• Every human identity class is defined clearly: employee, contractor, partner, customer, admin. Evidence to look for: workforce source definitions, joiner and offboarding rules, separate identity types in the directory or identity platform.
• Every non-human identity has an owner, purpose, environment, and review path. Evidence to look for: service-account registry, automation inventory, workload ownership mapping.
• Shared accounts are eliminated or tightly contained with compensating controls. Evidence to look for: named exceptions, recorded emergency use, clear actor attribution around unavoidable shared identities.
• Duplicate accounts across systems are understood and justified, not accidental leftovers. Evidence to look for: identity correlation rules, migration exception register, documented legacy-system dependencies.
• Directories, HR systems, and local application stores have clear source-of-truth boundaries. Evidence to look for: architecture documentation or workflow rules that state which system owns lifecycle facts, roles, and profile data.

Priority note: Identity inventory is one of the highest-leverage areas. If the organization cannot explain who or what exists, later controls such as least privilege and review become much weaker.

Authentication Baseline

• MFA is enforced for privileged access and internet-reachable access paths. Evidence to look for: policy settings, coverage reports, exception list, proof of enforcement rather than only guidance.
• Password reset and recovery flows are at least as strong as the initial sign-in flow. Evidence to look for: help-desk procedures, recovery policy, identity-proofing steps, logging of reset events.
• Session lifetimes, refresh behavior, and reauthentication triggers are documented. Evidence to look for: session policy, token TTL settings, admin-session controls, zero-trust or conditional-access rules.
• High-risk sign-ins can be blocked, stepped up, or reviewed through conditional access. Evidence to look for: policies for high user risk, impossible travel, unmanaged device, or privileged application sensitivity.
• Break-glass accounts are protected, monitored, and excluded from routine use. Evidence to look for: named break-glass accounts, stronger controls, alerting, post-use review records.

Priority note: If privileged and externally reachable access still depend on weak or inconsistent authentication, the rest of the IAM program is carrying unnecessary exposure.

Authorization and Least Privilege

• Roles and groups reflect stable business meaning rather than one-off convenience. Evidence to look for: role catalog, group ownership, clear descriptions that managers and reviewers can explain.
• Sensitive actions are separated so one identity cannot complete every control step alone. Evidence to look for: approval workflows, separation of duties for finance, security, production changes, or data export.
• Standing privilege is minimized, especially in production and control-plane environments. Evidence to look for: JIT or time-bound elevation, smaller admin population, differentiated production roles.
• Resource ownership is explicit wherever delegation or sharing is allowed. Evidence to look for: documented owners for datasets, projects, workspaces, environments, or delegated admin scopes.
• Exception access is time-bound, approved, and visible to reviewers. Evidence to look for: expiry fields, approval records, exception register, automated expiration where possible.

Priority note: If reviewers cannot explain what a role or group actually grants, mark the control as weak even if a formal role model exists.

Lifecycle and Reviews

• Joiner, mover, and leaver events flow from authoritative source data. Evidence to look for: HR-driven or approved vendor-driven workflow, mover logic, contractor end-date handling.
• Access removal happens promptly during offboarding and role changes. Evidence to look for: measured deprovisioning time, incident drills, audit samples of terminated or transferred users.
• Managers or resource owners can explain what reviewed access actually means. Evidence to look for: review screen quality, role descriptions, removal actions taken from review findings.
• Orphaned accounts, stale groups, and inactive identities are measured and cleaned up. Evidence to look for: metrics, cleanup reports, dashboards, recurring ownership checks.
• Temporary access expires automatically unless it is renewed deliberately. Evidence to look for: expiration metadata, renewal workflow, logs showing access ended on schedule.

Priority note: Slow or inconsistent deprovisioning is often one of the most important IAM weaknesses to fix first because it leaves access behind after business need ends.

Privileged Access

• Administrators use separate admin identities for elevated work. Evidence to look for: distinct admin accounts, separate login paths, different policies for privileged use.
• Privileged sessions are logged, and sensitive changes are attributable to a person or workload. Evidence to look for: request IDs, session records, admin action logs, policy change history.
• JIT elevation is preferred over broad standing admin rights. Evidence to look for: approval workflows, expiring grants, small standing admin population, measured privileged-session durations.
• Emergency access is tested, auditable, and reviewed after use. Evidence to look for: break-glass exercise records, post-use investigation notes, emergency-access runbooks.
• Support, billing, platform, security, and database privileges are scoped independently where practical. Evidence to look for: differentiated high-risk roles rather than one generic super-admin role.

Priority note: Any privileged path that lacks attribution, fast revocation, or meaningful scope separation should be treated as a high-priority control gap.

Workload Identity and Secrets

• Service accounts are inventoried and tied to an owner and system purpose. Evidence to look for: machine-identity register, purpose fields, environment separation, owner assignment.
• Secrets are stored centrally rather than embedded in source code or ad hoc scripts. Evidence to look for: secret references in deployment config, code scanning results, repo cleanup status.
• Keys, certificates, and client secrets rotate on a known schedule. Evidence to look for: rotation jobs, max-age settings, alerts on stale credentials, rotation runbooks.
• Workload identity or short-lived credentials are used where the platform supports them. Evidence to look for: token exchange, workload assertion flows, platform-issued machine credentials.
• CI/CD and automation identities are scoped narrowly and reviewed like human privilege. Evidence to look for: separate deployment identities by environment, reduced pipeline permissions, audit records for automation actions.

Priority note: Unowned machine identities and long-lived secrets in CI or production are often among the most serious hidden IAM risks in modern environments.

Logging and Governance

• Login success, failure, MFA events, role changes, policy changes, and lifecycle events are logged. Evidence to look for: event catalog, centralized log pipelines, sample retained events from each category.
• Audit records include timestamps, actor identity, target, action, and enough context for investigation. Evidence to look for: request IDs, session IDs, policy versions, stable actor mapping, target-resource identifiers.
• IAM standards, approval paths, and exception rules are documented and owned. Evidence to look for: policy owners, review dates, exception process, approval model.
• Metrics exist for orphaned accounts, privileged account counts, MFA coverage, and deprovisioning speed. Evidence to look for: dashboards, trend reports, alert thresholds, ownership for remediation.
• Review results lead to remediation, not only report completion. Evidence to look for: tracked follow-up actions, closed findings, measurable reduction in stale privilege or identity drift.

Priority note: If logging exists but cannot explain privilege changes or sensitive access paths, the environment is still difficult to investigate and govern.

Fast Triage Questions

Use these questions when the checklist finds too many gaps at once:

• Which identities would create the largest blast radius if compromised today?
• Which manual IAM workflows would fail silently during rapid growth or an incident?
• Where does access meaning depend too heavily on tribal knowledge rather than naming and documentation?
• Which systems still rely on static secrets when short-lived workload identity is possible?
• Which privileged actions cannot be tied back confidently to an accountable actor?

Review Cadence Suggestions

• Monthly: orphaned accounts, stale temporary access, privileged-account inventory, break-glass changes.
• Quarterly: role and group meaning review, access recertification quality, machine-identity owner coverage, control exceptions.
• After major incidents or platform changes: privileged logging checks, conditional-access tuning, service-account and secret review.

Quiz Time