Identity Governance in Financial Services, for Every Identity Type
Introduction
Identity governance for financial services means proving that each human, machine, and AI agent identity holds only the access its role needs. You review that access on the terms PCI DSS, DORA, SOX and NYDFS set, and you keep evidence an examiner accepts.
Many programs still split the work. People sit in the IGA, while service accounts and AI agents live in spreadsheets, vaults or nowhere.
Oak, the AI-native identity operating system, governs human, machine, and AI agent identities on one live graph, beside the IGA you run. Oak remediates from the source the moment an identity deviates.
This guide maps what each regime asks of access. It then shows how to hold segregation of duties, third parties and evidence to that standard.
Key takeaways
- Oak runs identity governance for financial services beside the IGA you already run.
- PCI DSS Requirement 7.2.4 sets access reviews at least once every six months.
- Payment approval rights can survive a team move and break segregation of duties.
- Contractors and vendor accounts need an internal owner and the same reviews.
Why identity governance for financial services carries a heavier burden
Banks, insurers and payments firms hold regulated customer and payment data. An access error there is often a control failure as well as a security gap.
The IBM Cost of a Data Breach Report 2026 puts the global average breach at a record $4.99 million, up 12%.
Third parties can hold deep access into core systems, including processors and outsourced operations teams. Payment flows add segregation of duties, where the person who creates a payment should not be the one who approves it.
Machine identities now outnumber people by a wide margin. The 2026 Identity Security Landscape found 109 machine identities per human.
At that scale, non-human identity governance in financial services becomes its own discipline. Each machine identity needs an owner, a reviewer and an approver.
Oak starts with the part your IGA has never seen, the machine identities it cannot tie to a person.
What PCI DSS, DORA, SOX and NYDFS expect of access
Each regime sets its own access expectation, and many financial firms answer to more than one. Below, each text speaks in its own wording, then one table lines them up.
PCI DSS v4.0 Requirement 7.2.4
PCI DSS v4.0 Requirement 7.2.4, published in the PCI SSC document library, requires that all user accounts and related access privileges are reviewed at least once every six months. That scope includes third-party and vendor accounts.
Each review ensures access remains appropriate based on job function, and any inappropriate access is addressed. Management then acknowledges that access remains appropriate.
DORA for EU financial entities
Under DORA Article 9(4)(c), financial entities implement policies that limit physical or logical access to information assets and ICT assets. That access is limited to what is required for legitimate and approved functions and activities only.
Financial entities also establish policies, procedures and controls that address access rights and ensure a sound administration thereof. DORA applies to entities including credit institutions, payment institutions and investment firms.
SOX IT general controls
Audits of internal control over financial reporting under SOX follow PCAOB AS 2201, the standard for the integrated audit. It lets the auditor benchmark an automated application control in later years.
That reliance holds only where general controls over program changes, access to programs and computer operations are effective and continue to be tested. Access to programs is therefore a control your auditor keeps returning to.
NYDFS Part 500 for New York regulated entities
Under 23 NYCRR 500.7, covered entities limit user access privileges to information systems that provide access to nonpublic information. Privileges stay limited to only those necessary to perform the user's job, and privileged accounts are limited too.
Covered entities periodically, but at a minimum annually, review all user access privileges and remove or disable accounts and access no longer necessary. They also promptly terminate access following departures.
Access expectations and review cadence by regime
| Regime | Who it covers | Access expectation | Review cadence as stated |
|---|---|---|---|
| PCI DSS v4.0 Requirement 7.2.4 | User accounts in PCI DSS scope, including third-party and vendor accounts | Access remains appropriate to job function; inappropriate access addressed; management acknowledgment | At least once every six months |
| DORA Article 9(4)(c) | Financial entities, including credit institutions, payment institutions and investment firms | Access limited to legitimate and approved functions and activities; sound administration of access rights | Not stated in Article 9(4)(c) |
| SOX, under PCAOB AS 2201 | Integrated audits of internal control over financial reporting | Effective general controls over access to programs | Tested by the auditor |
| NYDFS, 23 NYCRR 500.7 | Covered entities under Part 500 | Access limited to what the job requires; privileged accounts limited; prompt termination after departures | At a minimum annually |
The cadences are floors from different texts. Where several apply to one system, firms usually schedule reviews to the strictest cadence. Each text's other obligations still stand on their own.
Oak runs continuous, risk-driven access reviews in place of quarterly campaigns, so each regime's review draws on decisions already on record.
Governing human, machine and AI agent identities on one model
Split inventories leave gaps. The IGA holds people, a vault holds some service accounts, and AI agents often sit with the teams that built them.
Each list answers a different question, so nobody can say who or what has access right now.
Every identity needs certifying: service accounts, contractors, RPA bots, and AI agents, each tied to an accountable human owner.
Oak's Identity Risk Visibility & Intelligence (Identity Intelligence Layer) holds all of them on one live graph with one data model. It continuously correlates what every identity can access with what it actually uses, then routes risk-prioritized decisions to the right reviewers.
For AI agent identity governance, the platform runs continuous reviews driven by each agent's own risk profile, not a fixed calendar. It checks each agent's access against actual usage and removes excessive permissions at the source.
People change roles, and that is where stale access often starts. Joiner-mover-leaver (JML) events trigger event-driven micro-certifications.
A move prompts a review of the access the old role no longer justifies, instead of waiting for the next campaign.
Segregation of duties on payment approval
Effective access is what an identity can actually reach once nested groups, inherited admin rights and impersonation chains are resolved.
Segregation of duties breaks at the level of effective access. A toxic combination often spans systems that no single entitlement list shows.
Take an illustrative scenario, not a customer: a finance analyst moves teams but still holds approve-payment rights from the old role. If the new role can initiate payments, one person now holds both sides of the control.
Neither entitlement looks wrong on its own, so a reviewer looking at one list can approve both.
Oak surfaces toxic combinations and SoD conflicts, then replaces standing approve rights with just-in-time grants whose expiry is written into the target system.
Keep break-glass access for emergencies, with an audit trail of each use.
Third-party and contractor access
The Verizon 2026 DBIR found a third party was involved in 48% of breaches, a 60% increase on the previous year.
Contractors are human identities. Govern each one with an internal owner who answers for that access.
Integrations with standing tokens deserve the same scrutiny, because each token is access with no person behind it. PCI DSS Requirement 7.2.4 already places third-party and vendor accounts inside its six-month review.
The harder problem is reach. Vendor access often lands in systems your IGA never connected.
Oak's ConnectAny reaches on-prem, homegrown and custom systems, so vendor accounts there join the same graph and the same review.
Evidence an examiner accepts
An examiner typically wants proof that a review covered the full population, that decisions were informed, and that revocations happened. Build your evidence package around these items:
- Population completeness across human, machine, and AI agent identities
- Reviewer context for each decision, such as last use and sensitivity
- Revocations executed in the target system, not only ticketed
- Management acknowledgment that access remains appropriate
- Proof that no reviewer certified their own access
- Timestamps on each decision, revocation and acknowledgment
Standing evidence holds up better than a package assembled before each exam. Reviewers and auditors should read from the same record.
Oak produces auditor-ready exports from the graph your reviewers decide on, with last use, peer comparison, sensitivity and an AI recommendation on every row.
Conclusion
Identity governance for financial services holds up when one record answers who and what has access, on each regime's terms.
For you as CISO or IAM lead, examiner requests become exports, and segregation of duties conflicts on payments get fixed before money moves.
Already running an IGA? Oak connects to the IGA you already run and covers the identities and systems it cannot reach. Oak offers a free white-glove implementation program for qualifying large enterprises.
For your own vendor due diligence, Oak's platform is SOC 2 Type II certified and ISO 27001 aligned (Oak's privacy policy).
Get a demo to see Oak govern human, machine, and AI agent identities beside the IGA you run.
Frequently asked questions
Does identity governance for financial services cover AI agents?
Yes, identity governance for financial services covers AI agents as identities in their own right. An agent running on its builder's credentials can reach everything that builder can, which can include payment and customer data. Oak discovers SaaS, homegrown, shadow and custom agents, maps an accountable human owner to each, and records who each agent acts on behalf of.
How often should a bank review access for identity governance in financial services?
A bank should treat each regime's review cadence as the minimum for its access reviews, then review sooner where risk rises. Oak flags orphaned and dormant accounts, standing privileged access and peer anomalies as they appear, so a risky identity gets a decision when it changes. The scheduled review then confirms decisions instead of discovering problems for the first time.
Can identity governance for financial services work alongside an existing IGA?
Yes, Oak's identity governance works alongside the IGA your bank, insurer or payments firm already runs. Oak connects to the IGA itself as a source and sends findings to your ticketing tools. Oak's White Glove team can also read policies and roles out of the incumbent IGA, so you start from the model you already have.
Which systems are hardest to bring into identity governance for financial services?
On-prem, homegrown and custom systems are among the hardest to bring into identity governance at a financial firm. Applications in those systems can grant out-of-band entitlements, so that access never reaches the IGA. Oak connects to these systems through pre-built and custom connectors, file upload, direct API and database connections, or an on-prem agent.
Who should own identity governance for financial services in a bank?
A bank's program has three stakeholders to satisfy: the CISO for posture and board risk, the IAM team for architecture, and compliance for audit evidence. Oak resolves a named human or team owner for each machine and AI agent identity, and attributes every action to a person, script or agent. Oak rolls its findings into an identity risk score your board can follow.
Discover related posts
