The Disconnect
When a bank or financial institution is talking with a regulator about their IAM Prorgram, the conversation usually starts like this:
Examiner: "Walk me through how you manage user access to your financial systems."
Institution: "We use [SailPoint / Okta / Saviynt / CyberArk]. It handles all our provisioning and access reviews."
Examiner: "Good. Show me your access review records for the past year."
Institution: "We run reports quarterly and send them to managers for review."
Examiner: "Show me the attestations. Who reviewed what? What conflicts were identified? What remediation occurred?"
Institution: "We have the reports we sent. We don't have signed attestations."
Finding: "The institution lacks adequate evidence of access review execution and exception management."
This isn't a tool failure. The IAM platform generated the reports. Users got provisioned. MFA enforced authentication.
This is a governance failure. The institution never designed the mechanisms that translate tool outputs into examiner-acceptable evidence.
What IAM Tools Do vs. What Governance Requires
IAM platforms are excellent at:
- Automating user provisioning workflows
- Enforcing authentication policies
- Integrating with authoritative data sources
- Generating access reports
- Aggregating entitlements across systems
- Detecting orphaned or dormant accounts
But IAM platforms cannot:
- Design your role model
- Define what constitutes a segregation of duties conflict
- Determine appropriate approval workflows
- Establish access review criteria
- Define privileged access boundaries
- Create the governance mechanisms that produce defensible evidence
The tool is the accelerator. The governance design is the control.
When institutions deploy IAM tools without governance design, they get:
- Role models that don't align with job functions or control requirements
- Access reviews that generate reports no one acts on
- Provisioning workflows that bypass systematic approval
- Segregation of duties "detection" with no enforcement mechanism
- Privileged access granted without documented business justification
- Evidence that looks like governance but doesn't withstand examination
The Five Governance Design Failures That Break IAM Programs
Failure 1: No Authoritative Role Model
What we see:
- Roles created ad-hoc based on access requests
- Role-to-entitlement mappings incomplete or undocumented
- Roles don't align with organizational structure or job functions
- No segregation of duties analysis during role design
- Users accumulate entitlements outside their role definitions
What examiners conclude: You have an access management tool, not a role-based access control system. If roles don't drive provisioning decisions and don't prevent segregation of duties conflicts — they're not controls.
What defensible looks like:
- Roles designed by analyzing job functions, process responsibilities, and control requirements
- Each role mapped to specific entitlements with documented justification
- Roles reviewed quarterly for continued appropriateness
- Segregation of duties conflicts identified during role design and prevented at assignment
- Role assignments drive all access provisioning (no ad-hoc entitlement grants)
Failure 2: Access Reviews Without Governance
What we see:
- Access reports generated quarterly and emailed to managers
- No formal attestation workflow
- No documented criteria for what constitutes appropriate access
- Managers don't understand what they're reviewing or why
- Exceptions identified but not tracked to remediation
- Evidence consists of "we sent the reports" — no record of review execution
What examiners conclude: You generate reports. You don't execute access reviews. There's no evidence that anyone validated access appropriateness, identified conflicts, or remediated exceptions.
What defensible looks like:
- Quarterly access review with formal attestation workflow
- Managers receive role-level and entitlement-level visibility
- Clear criteria: Does this access align with job function? Are there segregation of duties conflicts? Is this user still in this role?
- Exception workflows for access that doesn't match expectations
- Remediation tracking for identified issues
- Evidence: signed attestations, identified exceptions, remediation completion records
Failure 3: Provisioning Without Approval Governance
What we see:
- IAM platform automates provisioning based on submitted requests
- Requests submitted via ticket system or email
- Approval workflows inconsistently followed
- No segregation of duties validation before access granted
- No documented business justification retained
- Evidence: request tickets exist, but approval records incomplete
What examiners conclude: Your provisioning is automated, but ungoverned. There's no systematic approval process, no segregation of duties enforcement, no retained evidence of who authorized what access.
What defensible looks like:
- Formal access request with documented business justification
- Manager approval required before provisioning
- Automated segregation of duties conflict detection
- Role-based provisioning (request role assignment, not individual entitlements)
- All requests, approvals, and role assignments timestamped and retained
- Evidence: request record, approval timestamp, SoD validation result, provisioning log
Failure 4: Privileged Access Without Boundaries
What we see:
- Privileged access granted based on job title (all DBAs get admin rights)
- No separate administrative accounts (users have one account with elevated privileges)
- No executive approval required for privileged assignments
- No just-in-time provisioning for temporary admin needs
- Privileged sessions not logged or monitored
- No quarterly recertification of privileged users
What examiners conclude: You have privileged users, but no privileged access governance. There's no boundary between regular and administrative access, no approval process, no monitoring, no evidence that privileged access is appropriate and reviewed.
What defensible looks like:
- Separate administrative accounts for users with privileged access needs
- IT Director or CFO approval required for privileged access assignments
- Documented business justification for each privileged assignment
- Just-in-time access provisioning for temporary admin needs
- Privileged session logging and monitoring
- Quarterly privileged user recertification with executive sign-off
- Evidence: privileged user inventory, approval records, session logs, quarterly attestations
Failure 5: Segregation of Duties "Detection" Without Enforcement
What we see:
- IAM tool has SoD conflict detection capabilities
- No documented SoD conflict matrix
- Conflicts detected after access granted (not prevented during provisioning)
- Identified conflicts not systematically remediated
- Compensating controls for approved exceptions not documented
- Evidence: conflict reports exist, but no governance process around them
What examiners conclude: You detect conflicts, but you don't prevent them or manage them. There's no SoD governance — just a tool generating alerts no one acts on systematically.
What defensible looks like:
- SoD conflict matrix documented and approved by Risk Committee
- Conflicts automatically detected during provisioning workflow
- System prevents conflicting role assignments (or requires explicit exception approval)
- Compensating controls documented for approved exceptions
- Quarterly SoD conflict reviews to identify drift
- Evidence: conflict matrix, detection logs, exception approvals, compensating controls, quarterly review attestations
Why This Happens
IAM implementations are typically led by IT teams focused on technical deployment, not governance design.
The project succeeds when:
- The platform is installed
- Users can authenticate
- Provisioning workflows are automated
- Reports can be generated
But examiners don't evaluate technical functionality. They evaluate governance effectiveness.
The questions examiners ask require governance design:
- "How did you determine appropriate roles?"
- "What approval process governs privileged access?"
- "How do you validate access appropriateness?"
- "How do you enforce segregation of duties?"
- "What happens when conflicts are identified?"
These aren't technical questions. They're governance questions.
And if the governance mechanisms weren't designed during implementation — the tool can't compensate.
What does success look like? Institutions that pass IAM examinations have:
1. Governance-driven role models Roles designed by analyzing job functions, process responsibilities, and control requirements — not by replicating existing access patterns.
2. Formal access review governance Quarterly attestations with clear criteria, exception workflows, and remediation tracking — not reports sent to managers with no follow-up.
3. Approval workflows with evidence retention Every access decision traceable to a request, an approval, and a business justification — not tickets that someone might have approved.
4. Privileged access boundaries Clear separation between regular and administrative access, executive approval for privileged assignments, just-in-time provisioning, session logging — not standing admin rights for everyone who asks.
5. Segregation of duties enforcement Conflicts prevented during provisioning, compensating controls documented for exceptions, quarterly reviews to detect drift — not alerts generated after access granted with no systematic remediation.
The IAM tool enables all of this. But only if the governance mechanisms were designed first.
The Path Forward
If you've already deployed an IAM platform but failed an examination — you don't have a tool problem. You have a governance design problem.
The remediation isn't "implement a different IAM tool."
The remediation is:
- Design the role model properly
- Establish formal access review governance
- Define approval workflows and evidence requirements
- Establish privileged access boundaries
- Build segregation of duties enforcement mechanisms
