Running an access audit before the regulator does

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.View full definition → 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.View full definition →, 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.View full definition → 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.View full definition → 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.View full definition → 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.View full definition → version:

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

4. Overly broad default roles (e.g., "branch staff" role granting system-wide account visibility rather than home-branch-only)

5. Curiosity access to celebrity, executive, or coworker accounts with no legitimate reason

Key Takeaways

• An entitlement review compares who has access, who should have access, and who actually used it. All three checks are necessary; permissions alone don't show misuse.
• Access creep from role changes, not malicious insiders, is the most common root cause of over-permissioned accounts.
• Log-based checks (unusual hours, no linked action, no case ticket) catch curiosity-driven snooping that a static permissions list will miss.
• GLBA (US) and GDPR (EU) both push toward the same practical standard: least privilege, documented business justification, and provable periodic review.
• Regulators test evidence, not policy documents. Being able to produce the last review, its findings, and proof of remediation matters more than having a well-written policy nobody can point to.