What an eighteen-month IAM modernization taught me about governance, sequence, and building controls that actually hold.

Most IAM programs fail the same way. The platform gets replaced. The role catalog gets rebuilt. The certification workflow gets automated. And two years later, the same findings show up in the next audit cycle.

The reason is almost always the same: the technology changed, but the governance did not.

I led an eighteen-month identity and access management modernization for a regional financial institution operating across multiple states and business lines. The engagement was triggered by a convergence of pressures familiar to anyone in financial services security: authentication-related production outages were climbing, an internal audit had surfaced entitlement drift and weak access certification practices, and the institution’s SOX testing cycle had identified IAM-related deficiencies in three areas. None had risen to the level of material weakness. But the trend line was clear, and the audit committee was paying attention.

What followed was a complete rebuild of authentication infrastructure, entitlement governance, access certification workflows, and privileged access controls. By the end, authentication-related Severity 1 and Severity 2 incidents had declined by more than fifty percent. Entitlement-to-role alignment exceeded ninety percent across reviewed applications. The subsequent SOX testing cycle closed all three prior findings with no new deficiencies identified.

This is what I learned.

The Problems Were Not Independent

The initial instinct in engagements like this is to divide the work into parallel workstreams. Authentication goes to one team. RBAC redesign goes to another. Certification workflow goes to a third. The prior attempts at modernization at this institution had taken exactly that approach, and they had failed.

The reason is that these problems are causally linked, not merely concurrent. Entitlement drift undermines certification quality. Weak certification obscures privileged account sprawl. Privileged account sprawl creates operational dependencies that destabilize authentication. Authentication instability erodes confidence in the entire access governance program. When each workstream operates in isolation, each team solves for its local problem and the systemic condition persists.

The first decision we made was to treat this as a single program with a defined sequence, not a portfolio of parallel projects. That sequence mattered more than almost any technical choice we made.

Stabilize Before You Transform

The first ninety days were dedicated entirely to authentication platform remediation. Federation certificates were inventoried and placed under automated expiration monitoring. Directory replication topology was revalidated against current load patterns. Session timeout policies were standardized across integrated applications. Authentication agents were consolidated to consistent patch levels. A single operational playbook governed federation onboarding, certificate renewal, and incident response.

We held every entitlement and governance workstream in planning mode until this work was complete.

This is counterintuitive to most security programs. Authentication infrastructure feels like plumbing. The visible work, the work that generates stakeholder interest, is the role catalog and the governance framework. But there is a practical reason to lead with stabilization: business tolerance for IAM change is gated by the reliability of the platform people interact with every day.

Application owners will not engage seriously with a role redesign exercise when the authentication platform is dropping Severity 1 incidents. Their attention is on the outages, not the governance conversation. Stabilization is not a detour from IAM modernization. It is the prerequisite.

Governance Has to Lead Technology

The prior modernization attempts had failed in part because technology changes had outpaced governance decisions. New role structures were implemented before the business had agreed on what the roles meant. Certification workflows were automated before the underlying entitlement data was trustworthy.

We inverted that sequence. Every technology change was preceded by a documented governance decision, approved by the relevant application owner or business stakeholder, with a clear statement of what the change was intended to accomplish and how success would be measured.

For the RBAC redesign, this meant convening application owners in facilitated working sessions to document actual business functions, the data and transactions accessed by each function, and the separation-of-duties boundaries that regulatory expectations or business practice required. The technology implementation followed the governance decision. Not the other way around.

This is slower in the early phases. It is substantially faster over the full program.

Access Decisions Are Business Decisions

The single most consequential governance design choice in this engagement was locating IAM ownership in the business rather than in IT.

Each in-scope application was assigned a designated IAM owner responsible for the integrity of role definitions, the accuracy of entitlement-to-role mappings, and the quality of certification reviews. That role sat in the business. Not in the IT organization. Not in the security team.

When IT owns the certification process, the business treats IAM as an IT compliance requirement. Something to be checked off. The reviews get done, but they do not get done with genuine judgment. Bulk-approval rates approaching ninety percent, which is what we found in some business lines at the outset of this engagement, are the natural result of a control that the business does not believe it owns.

Locating IAM ownership in the business changed the tone of every subsequent conversation. Application owners stopped asking when they could get access review off their calendars. They started asking whether their role definitions were actually right.

Sequence Privileged Access Last

There is a school of thought that privileged access governance should be the first priority in any IAM program because privileged accounts carry the highest risk. We took the opposite view, and the sequence proved correct.

Privileged access governance was Phase 4. It ran from month ten through month eighteen, after RBAC redesign and certification workflow reconstruction were complete.

The reason is structural. PAM expansion is technically complex, politically sensitive, and operationally disruptive. It touches vendor relationships, break-glass procedures, and administrative workflows that people have built dependencies around. To execute that work successfully, you need governance muscle, established stakeholder relationships, and documented evidence discipline.

We built all of that in Phases 2 and 3. By the time we reached PAM expansion, the steering committee trusted the program. Application owners understood the governance model. Evidence production was routine. The hardest workstream landed on the strongest foundation.

Starting with PAM would have attempted the opposite.

Produce Audit Evidence Continuously, Not at the End

Traditional audit preparation concentrates evidence production in the weeks before external testing. This pattern is predictable and almost universally wrong. It surfaces gaps at exactly the moment when the least time is available to remediate them. Audit stress is largely a self-inflicted condition.

From the outset of this engagement, every remediation step was designed to produce two artifacts: the operational change itself and the evidence that the change had been made. Evidence artifacts were collected in a standardized format, tagged to the relevant SOX control objective or GLBA safeguard expectation, and stored in a location accessible to Internal Audit throughout the program.

By the time the final SOX testing cycle arrived, the evidence package was already assembled. Audit conversations had been getting easier each quarter. The final cycle was routine.

This is achievable on any program. It requires discipline at the design level, not heroics at the end.

What Actually Held

Eighteen months later, the specific tools used in this engagement are less interesting than what survived them.

The steering committee governance model is still operating. Application IAM owners are still accountable for their role definitions and certification quality. Evidence production is still a standard output of every IAM change, not a scramble before testing.

The tools can be replaced. The governance model and the process discipline are what make the outcomes durable.

IAM modernization in financial services is rarely a technology problem. It is a governance problem expressed through technology. Institutions that approach it as a platform project tend to succeed at the platform work and fail at the governance work, and the same findings return within a few years.

The institutions that produce lasting improvement lead with governance and use technology as the instrument.

About The Author

Kimly Hong is a cybersecurity professional specializing in identity and access management, governance frameworks, and enterprise security program development. With hands-on experience implementing IAM solutions across complex regulated environments, Kimly works at the intersection of identity security, compliance, and business enablement. Connect on LinkedIn or www.kimlyhong.com to continue the conversation about identity governance modernization.