Runbook 02 — IAM Security Review

Identity is one of the most important control planes in modern enterprise security.

A firewall may protect a network.

Encryption may protect data.

Endpoint security may protect devices.

But if an attacker controls a highly privileged identity, many of those protections can potentially be bypassed.

This runbook provides a repeatable process for answering:

Who has access?

Why do they have it?

How do they authenticate?

What can they do?

Is the access still required?

How is privileged access controlled?

Can suspicious identity activity be detected?

Runbook Purpose

Use this runbook to perform structured IAM security reviews across environments such as:

Enterprise Directory

Cloud IAM

SaaS Applications

Privileged Access Platforms

Application Identity

Workload Identity

Federated Environments

The objective is to move from:

Account List
    ↓
Identity Analysis
    ↓
Access Validation
    ↓
Risk Identification
    ↓
Remediation

Runbook Scope

This runbook covers:

Identity inventory
Identity ownership
Joiner-Mover-Leaver lifecycle
Authentication
MFA
Authorization
RBAC and ABAC
Least privilege
Separation of duties
Privileged access
Emergency access
Service accounts
Workload identities
Secrets and credentials
Federation and SSO
External identities
Access certification
Dormant accounts
IAM logging
Identity threat detection
Risk prioritization
Remediation planning

Runbook Inputs

Before starting, collect where available:

Identity Directory Export

User List

Group Memberships

Role Assignments

Privileged Account List

Service Account Inventory

Authentication Policies

MFA Configuration

Federation Configuration

Joiner-Mover-Leaver Procedures

Access Review Records

IAM Audit Logs

Previous IAM Assessments

Runbook Outputs

At completion, produce:

IAM Security Review Report

Identity Inventory

Privileged Access Register

Service Identity Register

Access Review Findings

IAM Risk Register

Remediation Roadmap

Executive Summary

IAM Review Workflow

Use this sequence:

01 Confirm Scope
      ↓
02 Identify Identity Sources
      ↓
03 Build Identity Inventory
      ↓
04 Validate Ownership
      ↓
05 Review Joiner Process
      ↓
06 Review Mover Process
      ↓
07 Review Leaver Process
      ↓
08 Assess Authentication
      ↓
09 Assess MFA
      ↓
10 Review Authorization
      ↓
11 Assess Privileged Access
      ↓
12 Review Service Identities
      ↓
13 Review Federation and SSO
      ↓
14 Review External Identities
      ↓
15 Perform Access Reviews
      ↓
16 Review IAM Logging
      ↓
17 Review Detection
      ↓
18 Identify Findings
      ↓
19 Rate Risk
      ↓
20 Build Remediation Plan

Step 01 — Confirm Review Scope

Define exactly which identity environments are included.

Document:

Identity Provider

Cloud Platforms

Corporate Directory

SaaS Applications

Privileged Access Systems

Application Identities

External Identities

Service Accounts

Scope Template

Assessment Name:

Business Unit:

Identity Platforms:

Cloud Environments:

Applications:

User Population:

Privileged Identities:

Service Identities:

External Identities:

Excluded Systems:

Assessment Date:

Scope Questions

Ask:

Are production identities included?

Are privileged identities included?

Are contractors included?

Are service accounts included?

Are cloud identities included?

Are SaaS identities included?

Assessment Limitation

If one identity source cannot be reviewed, document it.

Example:

Assessment Limitation:

Service identities used by the legacy ERP platform
were not available for review.

Step 02 — Identify Authoritative Identity Sources

Determine where identities originate.

Possible sources include:

Human Resources

Corporate Directory

Identity Provider

Cloud Directory

Application Database

Vendor Platform

Authoritative Source

For employees, a common model is:

HR System
   ↓
Identity Platform
   ↓
Applications

The authoritative source should determine:

Who Is Employed

Employment Status

Department

Role

Manager

Review Questions

Ask:

What creates an identity?

Which system confirms employment status?

How are changes propagated?

How are terminations propagated?

Red Flag

Accounts Created Manually
Without Authoritative Source

This can create inconsistent lifecycle management.

Step 03 — Build the Identity Inventory

Inventory all relevant identities.

Classify them into categories.

Employees

Contractors

Administrators

Service Accounts

Workload Identities

Application Identities

Guests

Emergency Accounts

Identity Inventory Template

Identity	Type	Owner	Department/System	Privilege	Status
user01	Employee	Finance	Finance	Standard	Active
admin01	Privileged	Cloud Team	Cloud	High	Active
api-service	Service	App Team	API	Medium	Active
contractor02	External	Vendor	Support	Standard	Review

Additional Fields

Where possible include:

Identity Name

Identity Type

Business Owner

Technical Owner

Created Date

Last Login

Authentication Method

MFA Status

Roles

Last Review

Current Status

Red Flags

Look for:

Unknown Owner

Unknown Purpose

No Recent Login

Excessive Privilege

Duplicate Identity

Former Employee

Shared Account

Step 04 — Validate Identity Ownership

Every active identity should have a valid purpose.

For human users:

Employee
Contractor
Partner
Vendor

For non-human identities:

Application Owner

System Owner

Workload Owner

should be known.

Ownership Questions

Ask:

Who requested this identity?

Who approves its access?

Who reviews it?

Who is responsible for disabling it?

High-Risk Pattern

Service Account
      +
No Owner
      +
High Privilege

This should receive immediate attention.

Step 05 — Review the Joiner Process

Assess how new users receive identities and access.

Expected process:

Employment Approved
      ↓
Identity Created
      ↓
Role Determined
      ↓
Access Approved
      ↓
Access Provisioned

Joiner Review Questions

Ask:

Who triggers account creation?

Is identity creation automated?

Who approves permissions?

Are roles based on job function?

Does the user receive unnecessary default access?

Joiner Checklist

Authoritative source exists
Identity creation is approved
Unique identity assigned
Role-based access used
Privileged access separately approved
MFA enrollment required where appropriate
Access recorded

Common Joiner Finding

Finding:
New employees receive broad default application access.

Risk:
Users may receive permissions unrelated
to their job responsibilities.

Recommendation:
Implement role-based provisioning aligned
to documented business functions.

Step 06 — Review the Mover Process

Movers are employees or contractors whose responsibilities change.

Examples:

Promotion

Department Transfer

Project Change

Temporary Assignment

Mover Risk

A common pattern is:

Old Access
   +
New Access
   ↓
Permission Accumulation

Mover Review Questions

Ask:

What happens when department changes?

Are old permissions removed?

Does manager approval occur?

Are privileged permissions reviewed?

Example

Before transfer:

Sales Access

After transfer:

Finance Access

Poor implementation:

Sales + Finance

Correct implementation:

Remove Sales
      ↓
Grant Finance

Red Flags

Permission Creep

Old Group Memberships

Legacy Administrative Roles

Temporary Access Never Removed

Step 07 — Review the Leaver Process

Leaver controls are critical.

The expected lifecycle is:

Employment Ends
      ↓
Identity Disabled
      ↓
Sessions Revoked
      ↓
Access Removed
      ↓
Credentials Invalidated

Leaver Questions

Ask:

How quickly is access disabled?

Are active sessions revoked?

Are VPN sessions terminated?

Are tokens revoked?

Are privileged accounts handled separately?

Termination Timing

Higher-risk departures may require immediate coordinated action.

Leaver Checklist

Critical Finding Example

Finding:
Former Employee Identity Remains Active

Risk:
A former employee may retain access
to enterprise applications and data.

Recommendation:
Disable the identity immediately,
revoke active sessions,
review post-termination activity,
and improve automated offboarding.

Step 08 — Assess Authentication

Authentication confirms:

Who are you?

Review authentication methods for:

Employees

Administrators

Contractors

External Users

Applications

Authentication Factors

Common categories:

Something You Know

Something You Have

Something You Are

Review Questions

Ask:

What authentication methods are allowed?

Is password-only authentication permitted?

Are legacy methods enabled?

How are credentials recovered?

How are failed logins monitored?

Password Review

Where passwords are used, review:

Storage practices
Reset process
Reuse risk
Exposure response

Avoid focusing only on complexity.

Account Recovery

Recovery processes can undermine strong authentication.

Example:

Strong MFA
   ↓
Weak Helpdesk Verification
   ↓
Account Takeover

Authentication Red Flags

Password-Only Privileged Access

Weak Password Recovery

Legacy Authentication

Shared Credentials

Unmonitored Login Failures

Step 09 — Assess Multi-Factor Authentication

Review MFA deployment based on risk.

Prioritize:

Privileged Accounts

Remote Access

Cloud Administration

Sensitive Applications

High-Risk Users

MFA Review Questions

Ask:

Who requires MFA?

Can users bypass it?

Can administrators disable their own MFA?

Are legacy protocols excluded?

What happens when a user loses a factor?

MFA Coverage Table

Identity Type	MFA Required	Status
Standard Employee	Yes	Review
Administrator	Yes	Required
Contractor	Yes	Review
Service Account	Not Human MFA	Separate Control

MFA Finding Example

Finding:
Privileged Accounts Without MFA

Risk:
Stolen credentials may allow unauthorized
administrative access to critical systems.

Recommendation:
Enforce approved strong authentication
for all privileged identities and validate
that alternate authentication paths
cannot bypass the requirement.

Step 10 — Review Authorization

Authorization answers:

What can this identity do?

Review:

Roles

Groups

Policies

Permissions

Resource-Level Access

Authorization Models

Common approaches:

RBAC

ABAC

Policy-Based Access

RBAC

User
 ↓
Role
 ↓
Permissions

ABAC

Identity Attributes
      +
Resource Attributes
      +
Context
      ↓
Access Decision

Least Privilege Review

For every sensitive role ask:

What exact permission is required?

Why?

Who approved it?

When was it last used?

Excessive Access Example

Developer
   ↓
Needs Deployment Permission
   ↓
Receives Full Administrator

Finding:

Excessive Privilege

Permission Sources

Access may be received through:

Direct Assignment

Group Membership

Nested Groups

Inherited Policies

Federated Role

Review the true source of privilege.

Hidden Privilege Example

User
 ↓
Group A
 ↓
Group B
 ↓
Administrator

Separation of Duties

Review whether one identity can perform conflicting actions.

Example:

Create Transaction
      +
Approve Transaction

Authorization Checklist

Step 11 — Assess Privileged Access

Privileged identities represent high-value targets.

Identify:

Global Administrators

Cloud Administrators

Domain Administrators

IAM Administrators

Security Administrators

Database Administrators

Privileged Access Register

Identity	Role	Owner	MFA	Standing?	Last Review
admin01	Cloud Admin	Cloud Team	Yes	Yes	Review
admin02	IAM Admin	IAM Team	No	Yes	Critical

Standing Privilege

Review whether users permanently hold access they only occasionally need.

Poor:

Administrator
24x7

Better:

Standard Identity
      ↓
Approved Elevation
      ↓
Temporary Privilege
      ↓
Privilege Removed

PAM / Privileged Workflow

A mature privileged-access model may include:

Strong Authentication
      ↓
Approval
      ↓
Temporary Elevation
      ↓
Administrative Session
      ↓
Logging
      ↓
Automatic Expiration

Dedicated Admin Identities

Where appropriate:

Employee Standard Account

should be separate from:

Administrative Account

Shared Privileged Accounts

Avoid:

Username:
admin

Used By:
Multiple People

because individual accountability is lost.

Break-Glass Accounts

Emergency accounts should have:

Defined purpose
Strong protection
Restricted use
Monitoring
Periodic testing

Privileged Access Red Flags

Missing MFA

Shared Admin Accounts

Permanent High Privilege

Unknown Administrator

Dormant Administrator

No Privileged Activity Logging

Step 12 — Review Service and Workload Identities

Non-human identities can have substantial privilege.

Review:

Service Accounts

Application Accounts

API Identities

Automation Accounts

Workload Identities

CI/CD Identities

Service Identity Questions

Ask:

What workload uses the identity?

Who owns it?

What permissions are required?

How does it authenticate?

When was it last reviewed?

Static Credential Risk

Poor model:

Application
   ↓
Static Password / API Key
   ↓
Resource

Risk:

Credential Copied
      ↓
Credential Forgotten
      ↓
Credential Remains Valid

Preferred Pattern

Where supported:

Workload
   ↓
Identity Platform
   ↓
Short-Lived Credential
   ↓
Resource

Service Identity Inventory

Identity	Owner	Workload	Privilege	Credential
app-prod	App Team	API	Medium	Managed
backup-sa	Infra	Backup	High	Static
old-api	Unknown	Unknown	Medium	Key

Critical Pattern

Unknown Owner
      +
Static Credential
      +
High Privilege

CI/CD Identity Review

Deployment pipelines may have production privileges.

Repository
   ↓
Pipeline
   ↓
Deployment Identity
   ↓
Production

Assess:

Repository access
Pipeline approvals
Secrets
Deployment privilege
Production scope

Step 13 — Review Federation and SSO

Modern enterprises commonly use federation.

User
 ↓
Identity Provider
 ↓
Trust Relationship
 ↓
Application

Federation Review Questions

Ask:

Which identity providers are trusted?

Which applications trust them?

What attributes are accepted?

Which roles can federated users obtain?

Are old federation relationships still required?

SSO Benefits

SSO can improve:

Centralized Authentication

Lifecycle Management

MFA Enforcement

Logging

Concentration Risk

However:

Identity Provider Compromise
          ↓
Many Applications

The IdP becomes a critical security asset.

Federation Red Flags

Old Trust Relationships

Excessive Federated Roles

Weak IdP Protection

External Users Receiving Internal Admin Access

Poor Federation Logging

Step 14 — Review External Identities

Review:

Contractors

Guests

Vendors

Partners

Consultants

External Access Questions

Ask:

Who sponsors the external identity?

What does it access?

When does access expire?

Is MFA required?

When is access reviewed?

Expiration

Temporary users should ideally have:

Start Date
   +
End Date

rather than indefinite access.

Red Flag

Vendor Project Completed
      ↓
Vendor Account Still Active

External Identity Register

Identity	Sponsor	Purpose	Expiry	Access
Vendor01	IT	Support	30 Sep	Limited
Contractor02	Engineering	Project	None	Review

Step 15 — Perform Access Reviews

Access should be periodically recertified.

The goal is to answer:

Does this person or workload
still require this access?

Prioritize Reviews

Start with:

Privileged Access

Sensitive Applications

External Users

Service Accounts

Critical Data

Access Review Workflow

Collect Access
      ↓
Identify Reviewer
      ↓
Provide Context
      ↓
Approve / Remove
      ↓
Record Evidence

Reviewer Context

The reviewer should understand:

Who Is the User?

What Role Do They Have?

What Permissions?

When Was Access Last Used?

Why Was It Granted?

Poor Review

500 Accounts
      ↓
Approve All

This provides limited assurance.

Access Review Template

Identity	Access	Last Used	Owner	Decision
User01	Finance Read	Recent	Finance	Keep
User02	Admin	180 Days	IT	Remove
Vendor01	Support	90 Days	Vendor Mgmt	Review

Dormant Accounts

Review identities that have not been used for an established period.

Unused access still creates risk.

Orphaned Accounts

An orphan account has no valid associated owner or employment relationship.

These should be prioritized.

Step 16 — Review IAM Logging

IAM activity must be observable.

Important events include:

Successful Authentication

Failed Authentication

Password Reset

MFA Change

User Creation

User Disablement

Role Assignment

Privilege Change

Federation Change

Service Credential Creation

Logging Questions

Ask:

Are authentication events logged?

Are IAM changes logged?

Are logs centralized?

How long are logs retained?

Who can delete them?

IAM Logging Architecture

Identity Provider ─────┐
Cloud IAM ─────────────┤
SaaS IAM ──────────────┼──→ Central Logging
PAM ───────────────────┤
Application IAM ───────┘
                              ↓
                           SIEM / SOC

High-Risk IAM Events

Prioritize:

New Administrator

MFA Disabled

Break-Glass Account Used

New Service Credential

Federation Changed

Privileged Group Modified

Red Flags

IAM Audit Logs Disabled

No Privileged Activity Logs

Short Retention

Logs Not Centralized

Administrators Can Remove Evidence

Step 17 — Review Identity Threat Detection

Logging should support detections.

Potential identity detections include:

Unusual Authentication

Repeated Failed Logins

Dormant Account Used

New Administrator Assigned

MFA Disabled

Service Credential Created

Unexpected Federation Change

Detection Mapping

Threat	Detection
Credential attack	Repeated login failures
Account takeover	Unusual successful login
Privilege escalation	Admin role added
Defense evasion	MFA disabled
Persistence	New privileged identity
Service compromise	New credential created

Detection Context

A single login may not be suspicious.

But:

Failed Authentication
      ↓
Successful Login
      ↓
Privilege Change
      ↓
Sensitive Data Access

creates a stronger signal.

Detection Review Questions

Ask:

Which identity attack scenarios can we detect?

Are privileged changes alerted?

Are dormant accounts monitored?

Are service identity changes monitored?

Step 18 — Build Identity Attack Paths

Review how one identity weakness could lead to broader compromise.

Attack Path 1

Phishing
  ↓
Employee Compromise
  ↓
Inherited Group Access
  ↓
Cloud Access
  ↓
Sensitive Data

Attack Path 2

Leaked API Key
   ↓
Service Identity
   ↓
Application Resources
   ↓
Database

Attack Path 3

Dormant Contractor Account
      ↓
Valid Login
      ↓
Internal Application
      ↓
Sensitive Data

Attack Path 4

Admin Account
Without MFA
      ↓
Credential Theft
      ↓
IAM Modification
      ↓
Persistent Access

Key Review Question

Ask:

If this identity is compromised,
what can the attacker reach next?

Step 19 — Identify IAM Findings

Every IAM finding should be evidence-based.

Use:

Finding

Affected Identity

Risk

Evidence

Recommendation

Priority

Finding Template

Finding:
[IAM security weakness]

Affected Identity / System:
[Identity or IAM platform]

Risk:
[Potential business impact]

Evidence:
[Validated observation]

Recommendation:
[Remediation]

Priority:
[Critical / High / Medium / Low]

Example — Dormant Administrator

Finding:
Dormant Privileged Account Remains Enabled

Affected Identity:
Admin-Legacy

Risk:
An unused privileged identity could be
compromised without rapid detection
and provide administrative access.

Evidence:
The account retains administrator privileges
but has no valid documented operational purpose.

Recommendation:
Validate ownership and purpose.
Disable the account if no longer required.

Priority:
High

Example — Long-Lived Service Credential

Finding:
Long-Lived Credential Used by Production Service

Affected Identity:
payment-service

Risk:
Credential exposure could allow unauthorized
access to production resources.

Evidence:
A static credential remains active
for a production workload.

Recommendation:
Evaluate migration to workload identity
or short-lived credentials and rotate
the current credential.

Priority:
High

Example — Weak Offboarding

Finding:
Former Contractor Account Still Active

Affected Identity:
contractor-legacy

Risk:
A former contractor may retain access
to internal enterprise systems.

Recommendation:
Disable the identity,
review historical activity,
and strengthen contractor offboarding.

Priority:
Critical

Step 20 — Rate IAM Risk

Consider:

Privilege

Asset Criticality

Authentication Strength

Credential Exposure

External Exposure

Account Activity

Business Impact

Risk Scale

Use:

Low

Medium

High

Critical

Example IAM Risk Register

ID	Finding	Likelihood	Impact	Risk
IAM-001	Admin without MFA	4	5	Critical
IAM-002	Former user active	4	5	Critical
IAM-003	Excessive privilege	3	5	High
IAM-004	Long-lived key	3	4	High

Prioritization Order

A practical sequence is:

Compromised Identities

Former Users

Privileged Authentication

Excessive Privilege

Service Credentials

External Accounts

Lifecycle Weakness

Governance Improvements

Always validate against actual business risk.

Step 21 — Build the Remediation Roadmap

Group remediation into time horizons.

Immediate

Examples:

Disable Former Accounts

Contain Compromised Identities

Enforce Privileged MFA

Remove Unauthorized Roles

Rotate Exposed Credentials

Short Term

Examples:

Review Privileged Membership

Remove Dormant Accounts

Assign Service Identity Owners

Review External Users

Medium Term

Examples:

Automate Joiner-Mover-Leaver

Implement Periodic Access Reviews

Reduce Standing Privilege

Centralize IAM Logging

Strategic

Examples:

Identity Governance

Privileged Access Management

Workload Identity

Zero Trust

Continuous Identity Risk Monitoring

Remediation Tracker

Finding	Priority	Owner	Action	Status
Admin MFA	Critical	IAM	Enforce MFA	Open
Former account	Critical	HR/IAM	Disable	Immediate
Service key	High	App Team	Replace	Planned
Access review	Medium	IAM Governance	Implement	Planned

Step 22 — Produce the IAM Security Review Report

The final report should contain:

01 Executive Summary

02 Assessment Scope

03 Identity Architecture

04 Identity Inventory

05 Joiner-Mover-Leaver Review

06 Authentication Assessment

07 MFA Assessment

08 Authorization Assessment

09 Privileged Access Review

10 Service Identity Review

11 Federation and SSO Review

12 External Identity Review

13 Access Certification Review

14 IAM Logging and Detection

15 Identity Attack Paths

16 Findings

17 IAM Risk Register

18 Remediation Roadmap

19 Assessment Limitations

Executive Summary Template

Assessment Objective:

Evaluate enterprise Identity and Access
Management security controls.

Overall IAM Risk:

[Low / Moderate / High / Critical]

Highest-Risk Issues:

1. [Finding]
2. [Finding]
3. [Finding]

Business Impact:

[Identity-related business risk]

Immediate Actions:

1. [Action]
2. [Action]
3. [Action]

Strategic Recommendation:

[Long-term IAM program improvement]

IAM Security Scorecard

Domain	Rating
Identity Inventory	Moderate
Joiner Process	Defined
Mover Process	High Risk
Leaver Process	High Risk
Authentication	Moderate
MFA	High Risk
Authorization	Moderate
Privileged Access	High Risk
Service Identities	Moderate
Federation	Moderate
Access Reviews	High Risk
Logging	Moderate
Detection	Developing

Quick IAM Review Checklist

Identity Inventory

Employee identities reviewed
Contractor identities reviewed
Privileged identities reviewed
Service identities reviewed
External identities reviewed
Unknown identities investigated

Lifecycle

Authentication

Authentication methods reviewed
MFA coverage reviewed
Legacy authentication reviewed
Recovery procedures reviewed
Privileged authentication reviewed

Authorization

Privileged Access

Service Identities

Federation

Trust relationships identified
Old federation removed
External role mappings reviewed
SSO security reviewed

Access Reviews

Monitoring

IAM Decision Framework

For every identity ask:

Who is it?

Who owns it?

Why does it exist?

How does it authenticate?

What can it access?

How did it receive access?

When was access last used?

Is access still required?

What happens if it is compromised?

Would we detect misuse?

Common IAM Review Mistakes

Mistake 1 — Reviewing Only User Accounts

IAM also includes:

Service Accounts

Workload Identities

Applications

Federation

Privileged Accounts

Mistake 2 — Looking Only at Assigned Roles

Permissions may come from nested or inherited access.

Mistake 3 — Checking MFA Without Checking Bypass Paths

Strong MFA provides limited value if legacy authentication bypasses it.

Mistake 4 — Ignoring Employee Role Changes

Mover processes are a major source of permission accumulation.

Mistake 5 — Ignoring Non-Human Credentials

Service credentials can remain active for years.

Mistake 6 — Treating Access Review as a Checkbox

Reviews must produce meaningful decisions.

Mistake 7 — Ignoring Identity Monitoring

Access controls should be observable.

Runbook Completion Criteria

The IAM security review is complete when:

Professional Outcome

This runbook gives you a repeatable process for moving from:

Identity Inventory
      ↓
Lifecycle Review
      ↓
Authentication
      ↓
Authorization
      ↓
Privileged Access
      ↓
Service Identity
      ↓
Monitoring
      ↓
Risk
      ↓
Remediation

A professional IAM security review should not end with:

We Found 200 Accounts.

It should answer:

Which identities matter?

Which access is excessive?

Which accounts should not exist?

Which authentication controls are weak?

Which identities create attack paths?

Which risks require immediate action?

That is the foundation of enterprise identity security.

What’s Next?

➡️ Runbook 03 — Risk Assessment

In the next runbook, you will turn security observations into a standardized enterprise risk-management workflow covering:

Assets
  ↓
Threats
  ↓
Vulnerabilities
  ↓
Existing Controls
  ↓
Likelihood
  ↓
Impact
  ↓
Inherent Risk
  ↓
Residual Risk
  ↓
Treatment
  ↓
Risk Ownership
  ↓
Risk Register

The progression is:

Cloud Security Assessment
        ↓
IAM Security Review
        ↓
Identify Security Exposure
        ↓
Translate Exposure Into
Enterprise Risk