Running an access audit before the regulator does

# Running an access audit before the regulator does

Three days before an examiner arrived at a mid-sized US bank in 2023, an internal audit found that 47 employees, including two branch tellers with no wealth management role, could pull up the full account history of a celebrity client. Nobody had approved that access in the past 18 months. The bank fixed it before the exam started. This lesson walks through exactly how that kind of review gets done.

Why this matters more than it used to

Banks hold data that is both financially sensitive and personally toxic if leaked: balances, transaction patterns, home addresses, sometimes health-related payments. Regulators no longer just ask "do you have a privacy policy." They ask "show me who accessed this record and why," and they expect you to have asked yourself first.

In the US, the relevant frameworks include the Gramm-Leach-Bliley Act (GLBA), which requires financial institutions to protect customer nonpublic personal information (NPI), enforced by the Federal Trade Commission (FTC) and prudential regulators like the OCC (Office of the Comptroller of the Currency) and FDIC (Federal Deposit Insurance Corporation). In the EU and UK, it's the GDPR (General Data Protection Regulation), which mandates "appropriate technical and organisational measures" and gives regulators like the UK's ICO (Information Commissioner's Office) power to fine based on inadequate access controls, not just breaches.

Both regimes converge on the same operational question: least privilege. Does every person with access actually need it, right now, for their job?

The entitlement review: what it actually is

An entitlement review (also called an access recertification) is a periodic audit where someone, usually a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → or information security team, pulls the list of every user with access to a system or dataset and checks it against what that person's role should allow.

For a VIP customer's account, that means reconstructing three things:

1. Who has access (the entitlement list, pulled from the identity and access management system, or IAM)

2. Who should have access (based on role, the "least privilege" baseline)

3. Who actually used that access, and when (from access logs, not permissions alone)

Permissions and usage are different questions. A person can be entitled to view an account and never touch it. Someone else can be entitled correctly but access it in a way that doesn't match their job that day. Auditors check both.

Reconstructing the review, step by step

Step 1: Pull the entitlement list

The reviewer exports every user, role, and permission tied to the customer's account record in the core banking system (e.g., FIS, Temenos, or similar platforms) and any downstream systems: CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète →, fraud monitoring, the call center's screen-pop tool, marketing databases.

A VIP account often shows up in more systems than a standard account because private banking and relationship managers have separate CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète → tiers. Each copy of the data is a separate access surface.

Step 2: MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → entitlement to role

Every access grant should mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → to a documented business reason. A typical mapping table:

| Role | Should have access? | Why |

|---|---|---|

| Assigned private banker | Yes | Direct servicing relationship |

| Branch teller (customer's home branch) | Yes, limited | Teller-line transactions only |

| Branch teller (other branch) | No | No servicing reason |

| Fraud analyst | Yes, case-triggered | Only during an open investigation |

| Marketing analyst | No (unless anonymized) | No servicing reason |

| IT database admin | Technically yes, flagged | Needs justification and monitoring |

Anyone in the "No" rows who shows up on the entitlement list is an over-permissioned account, the single most common finding in these reviews.

Step 3: Check for access creep

Access creep happens when someone changes roles (a teller promoted to loan officer, an analyst moved teams) but old permissions never get revoked. This is the single most common root cause auditors find, more common than malicious access.

A quick check: cross-reference the HR system's role-change log against the IAM system's permission-change log. If someone changed jobs eight months ago and their old system access is still active, that's a finding.

Step 4: Sample the access logs, not just the permission list

Having access isn't the violation; using it without cause is. Pull the actual query logs (who opened the record, when, from what device or branch) for a sample window, typically 90 days.

Flag:

• Access outside the employee's normal working hours or location
• Access with no linked service ticket, case number, or transaction
• Repeated "browsing" (opening the record without a subsequent action like a note, transaction, or callback)

This is the check that would have caught the 47-person case: several of those tellers had never once had a customer-initiated interaction logged against that VIP account, yet had opened it repeatedly.

Step 5: Verify segregation of duties

Segregation of duties (SoD) means no single person should have both the access and the authority to both view sensitive data and take an action that benefits from misusing it unchecked, like a call center rep who can both view the account and initiate a wire transfer without a second approver.

For VIP accounts specifically, banks often add a fourth-eyes rule: any data export or address change on a flagged high-profile account triggers a second reviewer, logged automatically.

A simple logic check you can script

Governance teams increasingly automate step 3 and 4 with basic queries. A simplified pseudo-SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Voir la définition complète → version:

SELECT user_id, access_time, action_taken
FROM access_log
WHERE account_id = 'VIP_00123'
  AND access_time NOT BETWEEN shift_start AND shift_end
  AND action_taken IS NULL

This flags any access to that account outside normal working hours with no follow-up action recorded, exactly the pattern that signals curiosity-driven snooping rather than legitimate servicing.

What examiners actually ask for

When the OCC, FDIC, or a state regulator (or, in Europe, the ICO or a national data protection authority) shows up, they typically request:

• The bank's data classification policy, showing that VIP or "high-profile" accounts are tagged as sensitive
• Evidence of periodic entitlement reviews (quarterly is common practice for high-risk systems)
• Logs proving that flagged over-access was remediated, with a timestamp showing how long it took
• A sample of access logs tied to a real record, to test whether the bank's monitoring actually works, not just exists on paper

Regulators increasingly favor testing over reading policy documents. If your policy says quarterly reviews happen but you can't produce evidence of the last one, that's a worse finding than having no policy and admitting the gap.

The US NIST (National Institute of Standards and Technology) access control framework, summarized in NIST SP 800-53, is a widely used reference for what "reasonable" access controls look like, even for banks not directly required to follow it.

Common findings, ranked by frequency

Based on patterns reported across bank internal audit functions (estimates, industry-consistent but not tied to a single published statistic):

1. Access creep from role changes (most common)

2. Shared or generic login credentials used by multiple staff, breaking the "who did it" trail

3. Vendor or contractor access never revoked after contract end