Analytics Access Control: Safe Executive Reporting

The problem: everyone needs reports, not everyone should see the data

Executives need numbers to make decisions: where sales are growing, where quality is dropping, which projects are stuck, how much support costs, how many people are involved. For such questions aggregates and trends are usually enough. Details about specific employees, patients, clients or salaries rarely help at the board level but significantly increase risk.

The problem begins when the same report is made "for everyone." It's convenient to distribute, display on a big screen, or grant access to contractors or branches. But if the report contains personal or sensitive fields (full names, national IDs, contacts, addresses, diagnoses, payment amounts, contract numbers), broad access turns ordinary analytics into a potential leak.

The danger isn't only malicious intent. More often it’s mundane scenarios: a dashboard link forwarded in a chat, a report opened on a shared computer, an Excel export saved to a disk, rights not revoked after a project ends. Any "universal" table with details about people or deals eventually gains a life of its own.

Common conflicts that arise include:

• branches see each other's metrics and argue about access rather than the numbers;
• sales ask for client-level detail while security and legal demand restrictions;
• contractors and interns get "one-week" access that is never closed;
• an executive wants a single consolidated report, while divisions must follow a "need to know" principle.

Success looks simple: executives get clear, consistent KPIs and trends, while detail is visible only to those who need it by role and division. Everyone understands the rules: what is visible, to whom, and why that is safer.

First, decide which data must not be shown

Access control for analytics starts not with BI roles, but with a simple question: which fields and rows must not be exposed to anyone except a narrow group. "Forbidden" data often hides inside ordinary reports: in drill-throughs, tooltips, Excel exports, notes and even file names.

Personal data is not just full names and national IDs. It also includes phone numbers, emails, addresses, photos, birthdates, and sometimes indirect identifiers: employee IDs, pass numbers, contract numbers, bank details. Even when you show only KPIs, filters or a "Top 10 employees" table can accidentally reveal too much.

Separate data levels. Raw records (transactions, HR entries, tickets) are almost always the most sensitive. Marts and aggregates are safer, but not automatically: if a mart contains identifiers or too-fine detail (for example, "sales by manager by day") it also becomes personal. KPIs are usually easier to agree on, but they too shouldn’t be shown broken down by individuals in many cases.

A simple classification to start:

• Public: can be shown to all employees.
• Internal: for most people inside the company, not for external publication.
• Confidential: only on a need-to-know basis (finance, procurement, projects).
• Personal: strictly limited access, often requires masking or aggregation.

Mark dangerous fields and tables in advance so a dashboard designer doesn't pull them into visuals by accident. Practical minimum steps:

• add a data-class label to the data dictionary or at least table descriptions;
• keep a list of forbidden fields (e.g., national ID, phone, address);
• mark tables with personal data as "limited roles only";
• check hidden places: drill-through, tooltip, export.

Example: executives need a turnover/attrition report. The KPI "attrition by division" can be internal, while the list of dismissed employees with names and reasons is personal and must not appear on any screen accessible to a broad group.

Access model: roles, divisions and simple rules

To make reports useful, access must be predictable: a person opens a dashboard and sees exactly what they need for work. Most often this is achieved by combining roles and division-based restrictions.

RBAC: roles as a clear foundation

RBAC (role-based access control) is easiest to explain and agree with the business. You define roles and typical scenarios in advance, then attach a set of reports and a level of detail to each role.

For example:

• an executive sees summary metrics and trends;
• an analyst sees detail down to transactions but without personal data;
• HR sees personnel slices and personal fields but not finance;
• accounting sees financial documents and postings;
• a branch sees only its own branch metrics.

Keep roles few. When there are dozens, they become hard to manage and users will start requesting "temporary access" that is later forgotten.

Division- and region-based access: "each sees their own"

Roles answer "what can be seen" but not "which portion of the data." For that you add limits by division, branch or region. Then a manager in Almaty sees only their region while central office sees aggregates across all regions.

For this to work the data must contain anchors for filtering: division, branch, region, sometimes the manager's employee ID. These fields must be populated consistently across sources, otherwise restrictions will leak through exceptions and dirty records.

ABAC in simple terms: rules by attributes

When roles are few but situations many, ABAC (attribute-based access control) helps. Logic: access depends on attributes of the user and attributes of the data.

A simple rule: an employee sees rows where the branch matches their branch. More advanced: a project manager sees only their project even if it sits in another division. Or a "regional director" role gets access to a group of regions rather than just one.

ABAC is convenient when the company structure changes (new branches, matrix projects). You update attributes in the employee directory rather than rewriting dozens of permissions.

Principle of least privilege saves time

Least privilege is not "deny everything." It's an agreement that access is limited by default, and expansions happen through a clear request process with a time limit.

In practice this saves time: fewer debates during approvals, fewer manual exceptions, fewer incidents to investigate later. Executives are also more likely to trust reports when it's clear why different people see different detail levels.

How to produce management reports without leaks

A management report should answer executives' questions: what's happening with revenue, costs, deadlines, quality and risk. The closer you get to raw data (rows about employees, clients, patients, tickets), the higher the chance of accidentally exposing too much. So build analytics access control so executives get a coherent picture while details open only for those who need them for work.

A practical technique is to keep two "depths" of the same report. First: a common mart for executives—aggregates, trends, plan-vs-actual comparisons, deviations. Second: a detailed version for process owners—reasons for deviations, raw records, statuses, comments. Ideally it's one dashboard with different detail levels depending on the role.

Aggregation and controlled drill-down

To preserve usefulness while reducing leak risk, start with aggregation: show totals, shares, trends and distributions. Rows by person and personal attributes should not be the first screen.

Make drill-down governed by rules, not ad hoc. For example:

• executives see company and division-level figures but no employee lists or personal fields;
• a division head drills down to teams and projects inside their block;
• HR, security or a process owner sees personal rows but only within their responsibilities and with audit logging;
• access to details for sensitive metrics is granted on request and for a limited time.

Masking, pseudonymization and pragmatic choices

Not everything must be hidden. Sometimes replacing values is better.

Masking suits phone numbers, national IDs and emails: show partially or not at all. Pseudonymization helps when you need repeatable identifiers (for example, "Employee A" across periods) but cannot reveal the name.

The main risk is over-masking so the report stops being useful. If you hide too much you may miss concentration of problems: e.g., defects rising on one shift or overload on a particular line. A compromise: keep useful breakdowns without personal fields (shift, shop floor, role, task type) and restrict access to personal reasons to a detailed layer for a small group.

Example: a production company shows executives order fulfillment trends and downtime by site and shop. Drilling into a single shift is allowed for the production director, but access to employee cards and personal comments is only for site managers and HR within their division.

Step-by-step plan to implement access control

Start by recording the goal: management reports should be available quickly, but analytics access must not let people see more than needed. If you don't document this, the project turns into a debate about exceptions.

Step 1. Inventory where the data actually "lives"

List all places where people get numbers. Leaks often happen not in BI but through "temporary" exports.

• data sources (CRM, ERP, HR, finance)
• BI reports and dashboards
• regular Excel exports and files on shared drives
• email distributions and presentations with metrics
• marts and tables used by analysts

Then assign data owners for each dataset: who can approve access and who is responsible for quality. Without an owner any rule becomes "nobody's".

Step 2. One-page access matrix

Create a simple table: roles (for example, executive, manager, analyst, HR) in rows and data types and divisions in columns. In each cell write briefly: "sees aggregates", "sees only own division", "sees only own deals", "no personal data". This matrix quickly aligns expectations with security and legal.

Step 3. Pilot, tests and rollout

Choose one report and one division for the pilot. In companies with branches and different functions it’s easier to start with a sales dashboard where boundaries are clear.

Important for the pilot:

• set access rules and assign an owner;
• test scenarios "under another role": check what each user type sees;
• control exports (who can download details);
• provide short training: what can be published and where to request access;
• introduce periodic reviews of rights (for example quarterly and on transfers).

Agree the change process: who submits a request, who approves and where it is recorded. That prevents access from growing unnoticed and relying on specific individuals.

Technical mechanisms: RLS, masking and logs

Technical measures are needed so access rules work in every report and export. Most BI platforms and warehouses support this out of the box; the key is to assemble the scheme correctly.

RLS and CLS: what the user can see

RLS (row-level security) answers which records end up in a report. A typical case: a branch manager sees only their branch, while a department head sees only their portfolio.

CLS (column-level security) answers which fields are shown even if the row is available. This is useful when the same report serves many people but national IDs, phones, addresses or salaries must be hidden.

In practice use a combination:

• RLS by division, region or project to cut off irrelevant rows;
• CLS or masking for sensitive fields (e.g., show only the last 4 digits of a phone number);
• separate roles for viewing and exporting, because export is often riskier than viewing.

Marts and views: separate analytics from production systems

Don't connect BI directly to production databases that contain personal data. It's safer to create an analytical layer: marts, views, prepared tables. There you can implement RLS/CLS, anonymization and unified division directories.

Example: a sales mart stores amount, client category and branch, while national IDs and addresses live in a separate locked table accessible only to a narrow group. Executives see trends and deviations while personal details remain locked.

SSO, MFA and logs: reduce risk and keep a trail

Even perfect roles won't help if an account is compromised. Enforce single sign-on (SSO) and multi-factor authentication (MFA) for users with access to sensitive data.

And always collect access logs. Minimum useful items to record:

• who opened the report and under which role;
• which datasets were accessed;
• whether exports occurred and their size;
• time and source of access (device, network).

Logs are useful not only for investigations but also to find unused rights: if a role exists but nobody uses a section, that access can be removed without pain.

Processes and responsibility: make rules work daily

BI settings alone won't save you if there are no simple rules around them. Access control works when rights are granted consciously, reviewed regularly and revoked quickly when needed.

Access requests: a clear path instead of "add me to the report"

A unified process that applies to all dashboards and marts works best. Then an executive doesn't have to "pull strings" to get access and admins don't have to guess what a user needs.

A request should include:

• what to open (report, section, dataset) and for how long;
• purpose of access (task, project, audit);
• user's role and division (and branch if relevant);
• confirmation from the data owner about legitimacy;
• note about export rights (allowed and in what form).

Expiry dates are important: temporary access is easier to control than permanent. In organizations with many moves, this reduces the risk that a former sales employee still sees client metrics.

Separation of duties: no one should "request, grant and check"

Minimum process roles: data owner (approves), BI admin (configures), security/internal control (audits and maintains rules). This lowers the chance of mistakes and prevents access granted "by favor."

Review rights regularly: quarterly or immediately on personnel changes (transfer, dismissal, role change). A practical method is to send data owners a list of who has access to their data and ask to confirm or revoke.

Incident response and export policy

If a leak is suspected, follow a short clear scenario:

• temporarily block access and exports for the account;
• preserve action logs and prior rights versions;
• assess scope (which reports, which data, which period);
• notify responsible parties (security, data owner, manager);
• restore access only after checks and rule corrections.

Define an export policy: who can export, in what format and when an anonymized extract is required. For many organizations this is a key protection: a branch head may only need aggregates, while exporting client- or employee-level details requires approval and is time-limited.

Common mistakes and traps when separating access

Access control is often implemented "by eye": it seems closed, but a single bypass breaks protection.

Mistake 1: "Make it easy for executives"

Sometimes top managers get admin rights to avoid bothering them with requests. Admin rights usually grant access to raw datasets, settings and unrestricted export. An executive ends up seeing more than needed and responsibility blurs.

Rule: grant rights by role, not by person. Executives typically need aggregates, KPIs and division breakdowns without row-level data.

Mistake 2: "We removed names and that's enough"

Anonymization is often superficial: names are removed but employee IDs, unique phones, rare job titles or combinations remain. In small teams these markers quickly re-identify someone.

Ensure management marts have no persistent identifiers or rare attributes that reveal identity. If unavoidable, use grouping (grades, teams, ranges) and the minimum necessary detail.

Mistake 3: One dataset for everyone without row restrictions

A classic trap: data from different divisions is mixed in one model while restrictions only apply on report pages. A user changes a filter, exports or accesses another visualization and sees foreign rows.

If your organization has branches, departments or project teams, rules must be enforced at the row level, not only at the UI level.

Mistake 4: Rights not updated after personnel changes

A transfer, a new role or a departure often leaves old access in place. This creates silent leaks that are hard to spot.

Mistake 5: "We closed everything" but forgot copies

Even perfect BI rules don't help if data lives in exported files, screenshots and shared folders.

Minimum pre-publication checks:

• can exports to Excel/PDF be made and who can do it;
• where exports are stored and who can access those folders;
• can a report be forwarded externally;
• are access logs enabled and regularly reviewed;
• do temporary accesses have an expiry and who controls it.

Short checklist before publishing a dashboard

Before you click "Publish" go through this brief list. It takes 10–15 minutes but can prevent a report that looks tidy from exposing too much.

• Make sure personal fields are not present in default visuals. If a name, national ID, phone, exact address or client ID is not needed for the task, replace them with aggregates or anonymized labels.
• Test role and division filters practically. Open the dashboard with test accounts from different departments and levels (e.g., executive, analyst, branch employee) to confirm each sees only their portion.
• Check "edge" scenarios: empty divisions, employee transfers, role overlap, new branch. This is where access logic often breaks.

Export is usually the main bypass. Even when the screen is protected, an export can carry extra rows.

• Decide if export is necessary. If so, limit format and volume, add clear confidentiality warnings, and use watermarks for sensitive reports.
• Verify hidden fields in tooltips, drill-downs, tables with drill-down or "details" tabs. Personal data often hides there.

Also prepare post-publication controls. Access control works only if someone monitors it.

• Ensure access logs are enabled and record what exactly is captured: who opened a report, what was exported, which filters were used.
• Appoint a report owner (not an abstract "admin") who reviews logs weekly or monthly and reacts to suspicious actions.

Finally: temporary access almost always becomes permanent if not limited.

• Issue temporary rights with an expiration date that actually expires.
• Set a simple renewal flow: who approves, for how long and what is the justification for renewal.

If you build a single executive dashboard for multiple divisions, run this checklist precisely at the boundaries between divisions — that's where leaks most often hide.

Example: a branch-based company and one executive dashboard

Imagine a holding with 12 branches. The CEO needs a single screen: revenue, margin, overdue, plan fulfillment and monthly dynamics. Branch heads and their teams need detail: by managers, clients, contracts, causes of overdue. Some of these data points are personal and must not be visible to everyone.

The working scheme: one dashboard with different visibility levels. Top-level shows aggregates for the holding and a comparison of branches without unnecessary details. Lower-level drill-downs open only within the user's branch and only to roles that need them. This keeps a single KPI view while avoiding dozens of report copies.

To protect personal data, teams often implement two data layers. The first layer contains anonymized metrics (revenue by segment, number of requests, share of overdue) without names and contacts. The second layer is a detailed mart with masking (partial hiding of phone, email, document) and strict role rules. Specific roles (HR or security) may get full-field access but only within their responsibilities.

After rollout measure not just dashboard convenience but rule quality:

• number of incidents and requests about excessive access;
• average time to grant or change rights;
• count of exceptions (manual allowances) and how long they remain;
• share of users who get enough from aggregates without detail;
• frequency of role review after personnel changes.

Next step: assess current data architecture and pick one report for a pilot that contains both management overview and sensitive fields. If you need turnkey infrastructure and implementation, it can be useful to work with a partner who covers hardware and integration — for example, GSE.kz (gse.kz) supplies servers and workstations and offers system integration and 24/7 support for corporate IT systems.