They Had Access, They Had No Reason: Why Access Management Is Not Enough

At a bank in Europe, an employee looked at customer accounts for more than two years: 3,573 customers and over 6,600 queries. None had a business reason and none was flagged by the bank's internal monitoring. The regulator issued a EUR 31.8 million fine in March 2026. Nobody broke into the system. The employee had access.

The Same Story in Different Countries

This is not one bank's misfortune. The pattern repeats.

• A financial cooperative in Canada: an employee extracted the data of about 9.7 million people over at least 26 months. Their access to the data warehouse was limited, but other employees had copied the same data to a shared drive. The privacy commissioner found access control and data separation inadequate.
• In Turkey: in a summary of a decision by the Personal Data Protection Board, a bank employee used the right to view assigned customer information for a purpose beyond its scope, photographed a customer's ID image and shared it with a third party. The decision ended in an administrative fine of TRY 100,000.

What the cases share: no outside attacker, no firewall breached, no password cracked.

Access and Justification Are Not the Same Thing

Access answers one question: what can this person do? Justification answers another: why did this person do it?

Access management is very good at the first: role, group, table permission, column permission. Very few organisations have a system for the second. When an authorised person runs a query within their permissions, whether it had a business reason is recorded nowhere. That is why you cannot fix this by cleaning up permissions, improving the role matrix or even reducing headcount: the problem is someone with access looking without a reason.

Four Things These Cases Share

• The duration is long. Two years, 26 months. Not a one off mistake but repeated behaviour.
• The volume is not small. Thousands of customers, millions of records.
• Nobody asked. There were records and monitoring, but nobody asked "what was the reason for this query".
• The penalty is disproportionate. One employee's behaviour left the organisation with a bill of millions of euros and dollars.

What Is the Ceiling in Turkey?

Under Turkish data protection law the 2026 upper limit of the administrative fine for breaching the data security obligation is TRY 17,092,242. The law also requires a breach to be notified to the person concerned and to the Board as soon as possible. To notify, you first have to know which data left, through whose hands, and when. So the answer to "who looked, and why" is a matter not only for internal audit but for a legal obligation at the moment of a breach.

The Outline of a Fix: One Channel and a Required Reason

Let a request be the only way to take data out of production. That request should:

• require a reason (free text, mandatory),
• show which columns will be returned by asking the target server before the query runs, before anyone sees data,
• mask sensitive columns automatically (ID number, card, IBAN, phone),
• ask for a separate approval with a reason for any unmasked column,
• deliver the file encrypted, with the download password shown in the portal against a reason,
• record who downloaded it, from which address and for what reason.

These records are gathered in the "Data Access and Export Log" report. When an auditor asks "who took which customer data last quarter and for what reason", the answer is on one page.

What This Does Not Do

• It does not see viewing done through an application screen. As in the bank above, if the employee looked through the banking application's screens, the trace lives in the application itself. The product covers requests to take data out of the database.
• It does not prevent connecting directly to the database. A DBA can run a SELECT with their own account. Catching that is the job of database activity monitoring and SIEM. The right design is one channel, the request, and an alarm for every access outside it.
• It does not track the file after download. If the downloaded file is copied somewhere, that copy is outside the product. That is why masking and a short retention period matter.

Stating these limits is not a weakness. Someone describing a solution with no limits either does not know or is not saying.

Frequently Asked Questions

Why is unjustified access by someone with permissions not noticed?

Access management answers "what can this person do". The answer to "why did they do it" is recorded nowhere in most organisations. When an authorised person runs a query within their permissions, the system sees a normal operation.

Does cleaning up permissions not solve this?

Not on its own. Improving the role matrix and reducing headcount lowers risk but does not stop someone who keeps access from looking without a reason. The fix is to tie the only way of taking data out to a request with a mandatory reason.

Does this approach prevent connecting directly to the database?

No. The product is not a proxy. A DBA can run a SELECT directly with their own account. Catching that is the job of database activity monitoring and SIEM; the right design is a single channel, the request, with an alarm for any access outside it.