Data Access Control: The PII Blind Spot in Your BI Tool

Executive Summary

---

The difficulty of knowing who sees sensitive data

A request comes in from the legal team. It seems simple enough: "Can you give us a list of everyone who has accessed customer PII on our analytics platform in the last six months?"

In my experience, for a Data Protection Officer at a growing company, this is a tricky question to answer. You've done the right thing: you've encouraged a data-driven culture and got people using the new BI tool. The side effect is that you now have over a hundred dashboards, built by many different people, with no central record of what data is in them or who has access.

You might have moved to the cloud and hired good engineers, but often this just means the old problems now happen faster. What was meant to be a push for Self-serve Analytics has created a situation that's difficult to manage, and you can't easily answer legal's question.

The cause: A missing security layer in your BI tool

This isn't a problem with your people. The analysts are doing their jobs, not trying to cause trouble. The issue, usually, is with the initial setup. In the rush to get insights, most BI platforms (like Looker, Tableau, or Power BI) are configured with access rights that are too open by default. The priority is getting things done quickly, not locking them down.

I've seen this happen quite a lot, particularly with scale-ups in sensitive areas like health or financial tech. They invest a great deal in their data stack, but tend to see governance as something to sort out later. The result is often a system where:

Permissions are given out one by one: Access is managed per person, not by their role, which creates a complicated web of permissions that's hard to track.

Data isn't classified: There's no distinction between a dashboard with sensitive PII and one showing website clicks. No tags, no labels, no warnings.

There's no clear audit trail: The BI tool might log that someone looked at a dashboard, but it can't tell you precisely which data they saw, particularly if that data changes every day.

This situation is a common outcome of Dashboard Sprawl. As the number of reports grows, control tends to decrease, and the data that is so valuable to the business also becomes a source of risk.

A structured approach to managing access

The problem isn't the tool itself, but the lack of a considered security design within the tool. The fix is to move from a reactive, manual process to a planned, managed one. It's about putting a system in place that helps protect the business.

This doesn't mean writing a long policy document that no one reads. It's about building sensible, automated limits directly into your reporting.

1. Auditing and classifying reports

The first step is usually a thorough clear-out. We'd look at all the dashboards to find the ones that haven't been used for months and, more importantly, the ones that contain high-risk PII. Each key dashboard is then given a sensitivity level. This simple step immediately reduces the number of places where things could go wrong.

2. Using Role-Based Access Control (RBAC)

The idea here is to stop managing permissions for each individual. Instead, you define roles (like 'Finance_User', 'Marketing_Manager_UK', 'Operations_Lead_DE') and give permissions to that role. When someone changes jobs, you just change their role group, rather than updating dozens of individual dashboard permissions.

3. Using Row-Level Security (RLS)

This is often the most important part. RLS lets you have a single dashboard that shows different data to different people. For example, a UK manager sees only UK data, while a German manager sees only German data from the same report. It's a core part of a sensible Data Governance framework, as it lets you give people the access they need without showing them the entire dataset.

Getting people on board

To be clear, making this change can meet with some resistance. Teams that are used to having open access to data might feel that you're slowing them down. Taking away access, even to data they probably shouldn't have had, can feel like a step backwards for them.

This part of the work is as much about people as it is about technology. It usually helps to get department heads on board by explaining it not as a restriction, but as a safeguard. You're helping them make decisions safely and protecting the company from significant risk. It might mean moving a little more slowly for a few weeks, to be able to move much more quickly and safely for years to come.

The outcome: An auditable system

Once this kind of structure is in place, the situation changes. When the legal team asks for that audit log, it's not a cause for panic. You can simply query a system that was designed for this sort of request and produce an accurate report in a few minutes.

Perhaps more importantly, your role shifts from being a gatekeeper to being the designer of a system that lets people work freely but safely. The business can move quickly, but within sensible limits that you've helped to build. You've fixed the foundations, so the rest of the building is on solid ground.