Banks Have the Most Mature IGA Programs in Any Industry, and They Still Can’t Produce a Complete Account List
Banks run some of the most mature identity governance deployments. Hundreds of applications onboarded with certification campaigns on a schedule for a decade or more. They have several dedicated IAM teams and a governance platform that cost seven figures.
Those same banks are the ones now failing audit tests on completeness. An examiner asks for every account that can reach a financially relevant system, and the bank can produce a long list of accounts without being able to show that the list covers everything.
The cause is architectural because a governance platform reports on the applications it’s connected to. And in a bank there’s a specific set of systems that never get reliably connected and are also incredibly difficult to monitor.
What examiners ask a bank now
Four sets of regulations address this, and each one presses on a different part of the same completeness question.
SOX 404 hasn’t changed as a statute. But the auditor’s procedure and requests to meet the statute have increased. The list of users with access to financially relevant systems has to be generated by a system rather than assembled by hand, and it has to reconcile against HR. For each access decision the auditor wants the reviewer, the timestamp, the rationale, and evidence that the revocation actually reached the system holding the account.
NYDFS Part 500 has been fully in force since November 2025. It requires multi-factor authentication for every access to every system rather than only for remote access, an annual review of all privileges, and a privileged access management solution at the largest firms. Evidence is retained five years, and the CISO plus a senior officer certify annually. Enforcement actions under Part 500 have repeatedly cited access privilege failures.
DORA has applied since January 2025. It requires a unique identity for every person including vendor staff, privileged and emergency access issued on a need-to-use basis and logged, service and generic accounts with named owners and regular reviews, and logs protected from tampering. In practice, regulators ask for the privileged account inventory with an owner and a last-review date against every entry.
PCI DSS 4.0 requires every account in the card environment to be reviewed at least every six months, and it says explicitly that this includes application and system accounts.
A US-listed bank with European operations that takes card payments sits under all four at once. Its own corporate customers won’t sign a contract without seeing a SOC 2 report, and many require ISO 27001 certification as well, so the bank gets audited as a vendor on top of being examined as a bank. That means your governance platform has to respond to six different auditors, each of whom wants the evidence in its own format.
The connector catalog sets the boundary
An identity governance platform reports on the applications it has connectors for. That report is complete and accurate about everything the platform knows about. The problem is what the report can’t say. If an application has no connector or doesn't log identity changes, nothing in the output says “here are the forty systems nobody pointed me at.”
In a bank, the critical applications our customers always need more identity monitoring on are the mainframes with security managers holding RACF or ACF2, older Unix estates, and SQL-backed identity stores inside core banking, payments and trading platforms. In those platforms, users and entitlements live in application tables rather than in a directory. Systems and devices like payment switches, branch and ATM systems, legacy LDAP directories that were meant to be decommissioned years ago, and whatever arrived with the last three acquisitions and hasn’t been merged.
There’s a pattern in that list. These are the oldest systems in the bank, and they’re also where the money moves. So the accounts nobody is certifying sit on the most consequential access in the institution. When a SOX auditor asks how the list of users was produced, that’s what they’re probing for. They want to know whether the systems that matter most were included or quietly left out.
There’s a second problem with those systems. Most of them have never written an identity audit trail that anyone kept. There’s no log to forward to a SIEM, so no amount of retention budget produces a history for them.
Why the campaign model can’t close it
Coverage isn’t the only issue. Even on the applications that are connected, the data in the governance platform answers a narrower question than the one being asked.
A certification is a decision about one day The campaign closes, and the artifact is a set of approvals attached to what each account held on the date it was reviewed. An examiner sampling across the whole audit period wants to know what happened between campaigns. A temporary elevation granted for quarter-end close and removed before the next review appears in neither snapshot.
Proof of execution stops where the connector stops For a connected application, a revocation can be pushed and confirmed. For everything else, the decision becomes a ticket to a platform administrator, and the evidence is that the ticket got closed. A closed ticket doesn’t prove the entitlement is gone from the mainframe.
The governance platform records its own actions inside itself Examiners now ask whether the evidence could have been altered by the people it describes. The administrator of the governance platform can change its configuration, edit its data, and adjust who sees what, including the records of their own activity. So the proof that an access review happened correctly is held by someone with the ability to change that proof. There’s no setting inside the platform that answers the question, because the question is about where the record lives.
Identity governance is a moving target where the goal posts keep changing. But major IGA platforms were designed between 2005 and 2015 to run a certification workflow over connected applications. In 2026 they’re being asked for a complete account list across the whole estate, a change history covering the audit period, confirmation that revocations executed in the source system, and a record kept somewhere the people it describes can’t reach. Those weren’t requirements when the architecture was set.
The newest requirement has a date on it
Regulators moved again in 2026, this time on automation. The European Central Bank directed significant institutions to file action plans by October 31, 2026 covering identity and access controls for AI tooling and agents. Guidance from the UK NCSC and its Five Eyes partners asks for distinct identities for agents, short-lived least-privilege credentials, and logging of every action and tool call.
An agent authenticates through a service principal, an API key or a workload identity, and it can reach whatever that account can reach. Agent credentials are often short-lived by design, which means a governance platform that polls on a schedule may never see one exist at all. The link between an agent and the human accountable for it has to be recorded, and the record has to outlive a credential that existed for four minutes. The practical version of the requirement is that every AI agent runs as an account somebody has to own.
What would actually close these gaps
The account list has to be built independently of the platform being certified. That means going to each system and monitoring every account continuously, instead of waiting for a connector to be written so you can collect a snapshot of data.
Change has to be captured as it happens, including in systems that write no logs of their own. For those systems, you need a mechanism to essentially generate that history for you by getting the full account list and comparing each read against the one before it. If an account gained admin rights between Tuesday and Wednesday, that difference becomes a dated change event, even though the system itself never wrote anything down. Execution has to be recorded as a confirmation rather than a ticket request. When an account gets disabled, the evidence is the answer that came back from the system holding the account. A closed ticket is not enough to show that the account is gone.
The record has to live outside the systems it describes, in a store where entries can be added but never edited or deleted. If an administrator grants themselves privileged access on Friday and removes it on Monday, both changes are already recorded somewhere they can’t reach. That’s a system of record. It’s the object auditors have been describing in their requests for several years without using the term.
Where Hydden fits
Hydden is the Identity System of Record. It discovers identities across the systems a bank actually runs, including the mainframe tier, SQL-backed identity stores and acquired environments that no governance connector reaches. It correlates every account to a person or a workload and keeps the provenance of how that link was made. Every change becomes a typed event on an append-only record held outside the systems it describes. Where a system writes no log, Hydden derives the change events by comparing one full read of that system against the next, so a platform that has never produced an audit trail still yields an attributable history.
Hydden runs on what the bank already has, and enforcement executes through existing systems rather than around them. The governance platform keeps running the campaigns and holding the certification decisions, now against a feed that covers the estate instead of the catalog. The vault covers the privileged accounts the record finds. When an account has to go, Hydden asks the authoritative system to disable it and records that system’s answer beside the evidence that justified the decision.
For the completeness argument in general terms, IGA, PAM and IdP Are Not the System of Record makes the architectural case, and Banks Are Scaling Faster Than Their Privileged Access Controls covers the privileged side.
To see the gap between what your governance platform covers and what your estate actually contains, schedule a 1 on 1 risk review.
Frequently asked questions
Why do banks with mature IGA deployments still fail audit testing on completeness?
Because the report is bounded by connector coverage, and in a bank the unconnected systems aren’t a random sample. Mainframe security managers, SQL-backed identity stores inside core banking and payments platforms, older Unix estates, legacy directories and unmerged acquisitions rarely have connectors, and they hold some of the most consequential access in the institution. The governance platform reports accurately on what it governs, and it has no way to report the size of what it was never pointed at.
What does DORA require for privileged and service accounts?
A unique identity for every person including vendor staff, privileged and emergency access granted on a need-to-use basis and logged, service and generic accounts with named owners and regular reviews, and logs protected from tampering. In practice, supervisors ask for the privileged account inventory with an owner and a last-review date against each entry. That requires attribution for accounts that frequently have neither.
How does NYDFS Part 500 differ from what banks were already doing?
Three requirements do most of the work. Multi-factor authentication applies to every access to every system rather than only to remote access. All privileges get reviewed annually, which requires knowing which accounts are privileged across the whole estate. And the largest firms have to run a privileged access management solution and monitor privileged activity. Evidence is retained five years, and the CISO plus a senior officer certify annually, which puts the consequence of a gap onto named individuals.
Can one identity program serve SOX, DORA, NYDFS and PCI at the same time?
The evidence can be shared even though the reports can’t. All four need a complete set of accounts, named owners, review decisions with reviewers and dates, proof that revocations executed, and history across the period. They differ on frequency, retention length and scope boundaries, and those differences can be expressed as filters and schedules over one underlying record. Building a separate account inventory per regulation is what causes trouble, because the totals won’t reconcile when an examiner compares two of them.
What is the ECB deadline on AI agents?
The European Central Bank directed significant institutions to file action plans by 31 October 2026 covering identity and access controls for AI tooling and agents. Related NCSC and Five Eyes guidance asks for distinct agent identities, short-lived least-privilege credentials, and logging of every action and tool call. Since agents act through accounts, the inventory and ownership questions are the ones already being asked about service accounts, on a faster clock.