Database Reporting Security: A UK Business Guide to Who Can See What When You Build Internal Dashboards in 2026

Row-level security reporting means building dashboards that show each person only the rows of data they are entitled to see — their own region, their own team, their own customers — rather than giving everyone the same company-wide view. Most UK businesses that build internal dashboards skip it. The first version of a sales or operations dashboard is usually built quickly, shared with everyone who asks, and left open because restricting access looks like extra engineering work that can wait.

It rarely waits harmlessly. A sales rep opens the pipeline dashboard and finds company-wide margin by customer, including the discounts given to accounts their colleagues manage. A regional manager filters the operations report and sees headcount costs, overtime and absence for every other region. A finance export containing salary bands is forwarded to a project manager who needed one column from it. None of these people went looking for sensitive data; the dashboard simply showed it to them.

This guide starts with the real risk of flat dashboard access, then covers practical implementation: row-level security at the data layer versus filtering in the BI tool, role design that matches the organisation without becoming unmaintainable, masking sensitive columns for different audiences, closing the routes by which data leaks out of dashboards, and auditing who actually accessed what. It is written for business owners, finance and operations leaders, and the people who build or commission internal reporting, and it applies whether you use Power BI, another BI tool or a custom dashboard.

What controlling who sees what actually means

Dashboard access control works at several levels, and it helps to separate them, because each answers a different question.

• Report-level access decides who can open a dashboard at all. It is the most common control and the least precise: everyone who can open the report sees everything in it.
• Row-level security decides which records a person sees within a report. The same dashboard shows a regional manager their region and a director every region.
• Column-level security and masking decide which fields a person sees. A team leader might see staff names and hours but not salaries; an analyst might see customer postcodes but not names.
• Action-level permissions decide what a person can do with what they see: export, share, subscribe, edit or build new reports on the same data.
• Auditing records who accessed what and when, so that access can be reviewed and incidents investigated.

Good reporting data governance uses all five together. Report-level access on its own forces an unhappy choice: either build many near-identical reports for different audiences, or give broad audiences access to more than they need. Row-level and column-level controls remove that choice, letting one well-maintained dashboard serve everyone appropriately.

The real risk of flat dashboard access

Flat access — everyone with access to a report sees all of it — feels harmless while the dashboard is new and the audience is small. The risks grow as dashboards become central to how the business runs.

Commercial information reaches the wrong people

Margins, discounts, customer profitability and supplier pricing are among the most commercially sensitive data a business holds. When sales and account teams can see all of it, the information can influence negotiations, internal disputes and, when people leave, competitors. Staff moving to a competitor with a mental picture of every customer’s margin is a real and common concern.

Pay and HR data causes internal harm

Headcount cost, salary, overtime, absence and performance data shown too widely can damage trust, create grievances and expose the business to complaints. Regional or departmental managers seeing each other’s staff costs in detail is a frequent example.

Personal data is processed beyond its purpose

Dashboards often contain personal data about customers or staff. Showing it to people who do not need it for their role sits uncomfortably with the data protection principles of data minimisation and purpose limitation, and increases the impact of any breach.

Exposure multiplies through exports and sharing

Anything visible in a dashboard can usually be exported, screenshotted, subscribed to or shared. Flat access does not just mean many people can see sensitive data; it means many people can copy it somewhere you no longer control.

Trust in the dashboard erodes

Paradoxically, flat access can reduce use. When managers know everyone can see everything, sensitive figures are kept out of dashboards and managed in spreadsheets instead, undermining the single source of truth the dashboard was meant to provide.

What flat dashboards expose

The chart shows how often each type of sensitive data was visible to all users of at least one widely shared internal dashboard, across the UK business reporting environments we review. Figures are indicative.

The top two are the most common because they arise naturally. A sales dashboard built for directors includes margin by customer; it is then shared with the sales team for pipeline tracking, and the margin comes with it. A performance dashboard shows every region because the person who built it needed to compare them. The data was appropriate for the original audience and became inappropriate as the audience grew. Our earlier overview of database reporting security covers the wider security picture, including encryption and connection security; this guide focuses on controlling visibility within reports.

Dashboard access in UK businesses — the numbers

The figures below are indicative, drawn from reporting environment reviews we carry out for UK businesses of 20 to 500 staff. They are not a formal survey.

The third figure illustrates the hidden cost of avoiding row-level security. Where businesses do separate audiences, they often do it by copying a report for each region or team. Each copy then needs maintaining, and they drift apart: a fix applied to one is forgotten in another, and figures that should match no longer do. Row-level security replaces many copies with one report that shows each person the right slice.

Scoring three ways to separate audiences

Businesses that recognise the problem usually choose between three approaches. The score grid compares them; a high badge means the approach performs well on that dimension, except for the last row, where high means high ongoing effort.

Separate reports are quick to create and become a maintenance burden. Row filters defined in the BI tool give consistent figures from a single report and are often the right first step, but they protect data only within that tool. Security defined at the data layer takes more thought up front and pays off over time, because it applies to every report, export and tool that reads the data, and it is defined once rather than in each report.

Filtering in the BI tool versus security at the data layer

The comparison sets out the two main ways to implement row-level security.

In practice, many businesses use both: data-layer security for the most sensitive data and the rules that must hold everywhere, and BI-tool roles for convenience features and for data where the BI tool is the only access route. The important thing is to know which layer is protecting each piece of sensitive data, and what could bypass it.

Row-level security at the data layer versus in the BI tool

The choice of where to enforce row-level security has more consequences than it first appears.

How BI-tool row filters work

Most BI tools let you define roles in the reporting model, each with a filter that limits which rows members can see. In Power BI, for example, roles are defined in the semantic model with filter expressions, and dynamic security can use the signed-in user’s identity to look up what they may see from a mapping table. Other tools offer equivalent features. This is quick to set up and works well when the BI tool is the only route to the data.

The limitations matter, though. The rules protect only reports built on that model, so each additional model needs its own rules. In some tools, row filters apply only to people consuming reports, not to people with rights to edit the underlying model or workspace; in Power BI, for example, row-level security applies to viewers but not to workspace members with edit permissions. Anyone with direct access to the source database or another tool sees everything.

How data-layer security works

Modern databases and warehouses can enforce row-level security themselves. SQL Server and Azure SQL support security policies that filter rows based on the user or session context; PostgreSQL supports row security policies on tables; cloud warehouses offer similar features through row access policies or secure views. Every query, from any tool, returns only the rows the rule allows for that identity.

For this to work, the database needs to know who is asking. That means either passing the user’s identity through from the BI tool to the database, which some tools support with appropriate configuration, or setting session context that identifies the user on each connection. Where the BI tool connects using a single shared service account and imports data, data-layer rules see only that account, and row-level security has to be enforced in the BI model instead.

Choosing

Data-layer security is worth the extra design when several tools or teams query the same data, when the data is particularly sensitive, or when the organisation is growing and the number of reports will multiply. BI-tool roles are often enough for a single main dataset used through one tool, provided edit rights are tightly controlled. Our guide to data warehouses versus reporting databases covers the underlying architecture choices that affect where security can live.

Role design that matches the organisation without becoming unmaintainable

Role-based report permissions are where many implementations go wrong. The first version creates a role per region or team; the second adds roles for people who need two regions; within a year there are dozens of roles, each with hand-written filters, and nobody is sure who is in which or why.

Separate the rules from the people

The approach that scales is to write a small number of rules that look up each person’s entitlements from a mapping table, rather than writing a role for every combination. A mapping table lists each user against the regions, teams, cost centres or customers they may see. The security rule then says, in effect, “show rows where the region is in this user’s list”. Changing someone’s access becomes a change to a row in a table, not a change to the security model.

Derive entitlements from systems of record

Where possible, populate the mapping table from systems that already know the answer: the HR system for reporting lines and departments, the CRM for account ownership, the finance system for cost centre responsibility. Then entitlements update automatically when someone changes role, joins or leaves, rather than depending on someone remembering to update the reporting permissions.

Handle hierarchies deliberately

Managers usually need to see everything below them. Hierarchy-aware rules — a director sees all regions, a regional manager sees their region, an area manager sees their areas — are best driven from the organisational structure rather than listed by hand. Plan how to handle people with responsibilities in more than one part of the structure, and temporary cover arrangements.

Keep a small number of broad roles

Alongside the mapping-driven rules, a handful of broad roles — for example, all-data access for finance and directors, and no access to sensitive columns for general staff — covers most needs. Resist creating roles for individual exceptions; handle those through the mapping table.

Document who decides

Every entitlement should have an owner who decides who may see what: typically the head of the function whose data it is. Access requests go to them, not to whoever maintains the reports.

Designing the data model with security in mind

Row-level security is far easier to implement and far more reliable when the reporting data model has been designed with it in mind. Retrofitting security onto a model built without it is where many subtle leaks originate.

Give every sensitive row a security key

Each row that needs protecting should carry the attribute that security will filter on: region, branch, cost centre, account owner, client. If margin data sits in a table with no branch column, there is nothing for a branch-based rule to filter by, and developers resort to workarounds that are easy to get wrong.

Use dimension tables as security anchors

In a typical reporting model, security rules are applied to dimension tables such as branch, region or customer, and flow through relationships to the fact tables holding sales, costs and other figures. This is efficient and keeps rules in one place, but it depends on relationships being defined correctly. A fact table that is not related to the secured dimension, or is related in a way that does not pass the filter, will show all its rows to everyone.

Separate highly sensitive data

Salary, individual performance and similar data are often best held in separate tables or even separate datasets, with their own stricter security, rather than mixed into general operational tables. That makes it easier to give broad audiences access to operational reporting without any route to the most sensitive figures.

Be careful with pre-calculated totals

Tables of pre-aggregated figures, such as company totals or league tables by region, can bypass row filters if they are not themselves secured. Decide deliberately whether each audience should see company-wide comparisons, and secure or remove aggregate tables accordingly.

Implementing controlled access in eight weeks

The timeline sets out a practical sequence for introducing row-level and column-level security into an existing reporting environment.

Weeks one and two often deliver the quickest risk reduction, because reviewing current access usually uncovers people with edit rights, export permissions or direct database access they do not need. Removing those takes minutes and closes some of the most significant bypass routes before any new security is built.

What controlled access costs

The table compares indicative costs of implementing access controls in a typical UK SME reporting environment with the costs of continuing without them. Figures are broad ranges and depend on the number of reports, data sources and tools involved.

The last row often makes the business case on its own. Businesses that separate audiences by copying reports typically spend more each year maintaining the copies than a one-off row-level security implementation would cost, and still suffer from figures that drift between versions. The other costs of going without are harder to put a number on but more serious: a commercially damaging leak, an internal grievance over pay data or a personal data breach.

Masking sensitive columns for different audiences

Row-level security decides which records people see. Many sensitive data in dashboards problems are about columns instead: the right people seeing the right rows, but with fields they should not see. A team leader needs their staff’s hours but not their salaries; a customer service analyst needs order history but not full payment details; a marketing analyst needs postcodes and purchase patterns but not names.

Remove columns that nobody needs

The simplest and strongest control is not bringing sensitive columns into the reporting model at all unless a report genuinely needs them. Many dashboards contain fields such as dates of birth, home addresses or full account numbers simply because they were in the source table. If no report uses them, remove them from the model.

Hide columns from audiences that do not need them

Where some audiences need a column and others do not, column-level or object-level security can hide it from those who should not see it. In Power BI, for example, object-level security can restrict access to specific tables or columns for particular roles; databases offer column permissions and secure views. Hidden columns should be genuinely inaccessible, not just left off a visual, because anyone who can explore the data model or export underlying data may otherwise find them.

Mask or generalise where partial information is enough

Masking shows a partial or altered value: the last four digits of an account number, an email address with most characters obscured, an age band instead of a date of birth, a salary band instead of an exact figure. Some databases offer dynamic data masking, which alters what non-privileged users see when they query a column. It is useful for reducing casual exposure, but it is not a strong security boundary on its own, because determined users with query access can sometimes infer masked values. Treat it as one layer alongside proper permissions.

Aggregate for wide audiences

For company-wide dashboards, showing aggregated figures — totals by department rather than by person, averages rather than individual values — often meets the business need without exposing individual data. Be careful with very small groups, where an aggregate can effectively reveal an individual’s figure.

Pseudonymise for analysis

For analysts who need to study patterns rather than identify people, replacing names and identifiers with consistent codes lets them work with the data while reducing the risk if it is exposed. Pseudonymised data is still personal data under UK data protection law if it can be re-identified, so it still needs protection.

How often edit rights bypass the filters

One of the most common gaps in BI-tool row-level security is that it does not apply to everyone. Across the BI environments we review where row filters are in use, the proportion in which more people hold edit or contributor rights than need them — and can therefore see unfiltered data in tools where those rights bypass row filters — is substantial.

The figure is indicative rather than a formal survey. It usually arises innocently: people are given workspace member or contributor rights so they can build their own reports or share content, without anyone realising that this also exempts them from row-level security. The fix is to separate building from consuming: give most people viewer rights to secured content, provide build access through datasets that enforce security for the builder, and keep edit rights on sensitive models to the small group who maintain them.

Access control practices in place

The progress bars show how often each practice is in place across the UK business reporting environments we review. Figures are indicative.

The practices most often in place are those that come with the platform: company sign-in and sharing with groups. Everything that requires a deliberate decision about what each person should see — removing columns, limiting edit rights, restricting exports, row and column security, ownership, automated entitlements and log review — is in place in a minority of environments. Most of the gap is about decisions and design rather than technology the business does not have.

Reporting access control maturity — where most UK businesses sit

Combining report-level, row-level and column-level controls, edit and export rights, entitlement management and auditing gives an indication of overall maturity. The gauge reflects a typical UK business of 20 to 500 staff with an established internal dashboard estate.

A score in the high twenties usually reflects an environment where people sign in and reports are shared with groups, but where everyone who can open a report sees all of it, many people have edit or export rights, sensitive columns sit in models unused, and nobody reviews who looked at what. Audiences are separated, if at all, by copying reports.

Working through the eight-week programme above typically lifts the score into the sixties or seventies. The largest early gains come from the access review and from row-level security on the most sensitive dataset; the later ones from column controls, automated entitlements and regular review.

Closing the routes data takes out of dashboards

Row and column security protect what people see on screen. Data also leaves dashboards in other ways, and each route needs checking.

• Exports. Export to Excel or CSV is often enabled by default. Decide for each sensitive report whether export is needed, and whether it should include underlying data or only summarised data. Exports from secured reports should respect row-level security, but check that they do in your tool.
• Subscriptions and scheduled emails. Report snapshots emailed on a schedule may be rendered under one person’s permissions and sent to others, or forwarded freely once in inboxes. Review who receives scheduled reports and what they contain.
• Sharing and links. Links that work for anyone with the link, or public publishing features, bypass identity-based security entirely. Disable public publishing for internal data and prefer sharing with named groups.
• Build and analysis access. Permission to build new reports or analyse a dataset in a spreadsheet can expose data that existing reports do not show. Make sure security applies to these routes as well.
• Direct database access. Analysts and developers with direct access to the reporting database or warehouse bypass BI-tool security. Limit direct access and apply data-layer security where it is needed.
• Natural language and AI features. Question-and-answer or AI assistant features in BI tools should respect the same security as the underlying model. Check this before enabling them on sensitive data.
• Embedded reports. Reports embedded in other applications or portals need security configured for that context, particularly if external users are involved.

A useful exercise is to pick one sensitive figure — say, margin for a particular customer — and trace every route by which someone not entitled to it could obtain it. The answers usually reveal one or two routes nobody had considered.

Auditing who actually accessed what

Access controls define who can see what. Auditing shows who did, which matters for investigating incidents, reviewing whether access is still appropriate and demonstrating good governance.

What to capture

Most BI platforms and databases can log who opened which report, when, and what they did: viewed, exported, shared, subscribed or changed security settings. For sensitive datasets, also capture changes to roles, mapping tables and permissions, since these determine everyone else’s access. Check how long logs are retained by default, as it may be shorter than you need, and export them to longer-term storage if required.

How to use it

Logs that nobody reads protect nobody. Agree a light routine: a quarterly review with data owners of who has access to their sensitive reports and who has actually used them; alerts for unusual activity such as large exports of sensitive data or access outside normal patterns; and a check of access for leavers and people who have changed role. Unused access is a good candidate for removal.

Data protection considerations

Access logs themselves contain personal data about your staff, so they need appropriate protection and retention. More broadly, controlling and evidencing who can access personal data in reports supports obligations under UK data protection law, including security and data minimisation. This is a general point rather than legal advice; take advice on your specific obligations.

Joiners, movers and leavers

Access that was right on the day it was granted becomes wrong as people change roles. Movers are the most frequently mishandled: a regional manager who moves to a different region often keeps access to the old one as well as gaining the new, and over a few years a long-serving employee can accumulate access to most of the business.

The most reliable fix is the one described earlier: drive entitlements from systems of record, so that a change in the HR system or CRM updates reporting access automatically. Where that is not yet possible, tie reporting access changes into the existing joiner, mover and leaver process, so that the reporting team is notified as part of the same workflow that changes email groups and system accounts.

Leavers deserve particular attention. Disabling a person’s company account usually removes their access to cloud BI tools, but check for other routes: personal subscriptions to scheduled reports, shared links, exported files and any direct database credentials. For staff leaving to join a competitor, a review of recent exports and access to sensitive reports is a sensible precaution, handled in line with your HR policies and with appropriate advice.

Quarterly access reviews with data owners catch what automated processes miss. Ask each owner to confirm, for their sensitive datasets, that everyone with access still needs it. Unused access is the easiest to remove and the least likely to be missed.

Testing that security actually works

Row-level security that has not been tested should not be trusted. Errors are easy to make and silent when made: a rule that returns all rows when a user is missing from the mapping table, a relationship that lets filtered data leak through an unfiltered table, a measure that calculates company totals regardless of the filter.

Test deliberately, ideally before each release that changes security or the data model. Most BI tools let developers view a report as a particular role or user; use it to check what typical users in each role see. Include edge cases: someone with two regions, someone with none, a leaver, a manager in the hierarchy, a new starter not yet in the mapping table. Decide what should happen when someone has no mapping entry — usually they should see nothing, not everything. Check totals and calculated measures as well as row counts, since some calculations can reveal information from outside the user’s permitted rows. And check the other routes: exports, subscriptions and analysis in spreadsheets under the same identity.

Writing these checks down as a short test plan, and repeating it after changes, turns security from something believed to something verified.

Performance and usability with security in place

Security has practical side effects that are worth planning for, so that it does not undermine confidence in the dashboard.

Query performance. Row-level rules add work to every query, particularly complex dynamic rules that look up hierarchies. Well-designed rules on indexed security keys usually have little noticeable impact, but poorly designed ones can slow reports considerably. Test performance with security applied, not just as an administrator who bypasses it.

Caching and refresh. Some caching and pre-computation features behave differently when row-level security is in use, because each user sees different results. Check how your tool handles caching for secured reports, especially for large audiences.

Explaining different numbers. Once security is in place, two people looking at the same dashboard see different totals. That is the point, but it can cause confusion if it is not explained. A clear indication on the report of what the viewer is seeing — “showing data for the North region” — prevents people comparing figures that were never meant to match.

Comparisons and benchmarks. Managers often want to compare their area against others or against the company average. Decide whether that is appropriate and, if so, provide it deliberately through secured aggregate measures, rather than leaving gaps that encourage people to ask for broader access.

Common dashboard access control mistakes

The mistakes below account for most of the exposure we find in internal reporting environments.

• Giving everyone the full view because it is easier. Sensitive data spreads with the audience.
• Copying reports per audience. Maintenance multiplies and figures drift.
• A role for every combination. Roles become unmaintainable; use mapping tables instead.
• Maintaining entitlements by hand. Access lags behind joiners, movers and leavers.
• Assuming row filters apply to everyone. Edit rights can bypass them in some tools.
• Leaving sensitive columns in models unused. They can surface through exploration and export.
• Relying on masking alone. Useful for casual exposure, not a strong boundary.
• Ignoring exports, subscriptions and links. Data leaves through routes the security does not cover.
• Defaulting to all rows when a mapping is missing. New or unmapped users should see nothing.
• Never reviewing access logs. Excess access and unusual activity go unnoticed.

Case study: one dashboard, many regions

A UK building supplies distributor with around 280 staff across fourteen branches in four regions had a well-used sales and operations dashboard. It had started as a directors’ report and grown over two years to more than 120 users, including branch managers, sales reps and regional managers. Everyone saw everything: sales and margin by customer for every branch, staff costs and overtime for every region, and discounts agreed with every key account.

The issue surfaced when a branch manager raised a grievance after seeing overtime and staffing costs for a neighbouring branch, and shortly afterwards a sales rep who had resigned was found to have exported a customer margin list before leaving. To manage sensitivity, the reporting team had already created seven regional copies of parts of the dashboard, which no longer reconciled with each other or with the main report.

The distributor mapped sensitivity with each data owner. Branch managers would see their branch, regional managers their region, sales reps their own accounts plus branch totals, and directors and finance everything. Staff cost detail would be visible only to the manager responsible and to HR and finance; margin by customer only to account owners, their managers and directors. A mapping table driven from the HR system and CRM replaced hand-maintained roles. Row-level security was implemented in the reporting database for margin and staff cost data, with BI-model roles for convenience features. Staff names and individual costs were hidden from audiences that saw only totals. Export of customer-level margin was restricted, edit rights were reduced from twenty-three people to four, and access logging with a quarterly review was introduced.

The seven regional copies were retired. Over the following months, the single secured dashboard became more widely used rather than less, because regional managers trusted that their figures were visible only to the right people and stopped keeping parallel spreadsheets. A test plan run before each release caught one rule change that would have shown all branches to a new starter not yet in the mapping table.

“We thought locking it down would make the dashboard less useful. The opposite happened. People put more into it because they know who can see it, and we went from eight versions of the truth to one.” — Finance Director, UK building supplies distributor

The lesson is not that the original dashboard was badly built. It served its first audience well. The problem was that access grew without the security growing with it, which is the natural path for any successful internal dashboard.

The 12-point dashboard access control checklist

The checklist covers the essentials for controlling who sees what in internal reporting.

1. Map sensitive data and audiences. For each main dashboard, who should see which rows and columns.
2. Name a data owner for each sensitive dataset. They decide who may see it.
3. Review current access. Remove unnecessary report, edit, export and direct database rights.
4. Decide which layer enforces each rule. Data layer for sensitive, widely used data; BI tool where it is the only route.
5. Use mapping tables, not role sprawl. A few rules that look up each person’s entitlements.
6. Drive entitlements from HR, CRM or finance data. So access follows joiners, movers and leavers.
7. Default to no data when a mapping is missing. Never to all data.
8. Remove, hide or mask sensitive columns. According to each audience’s need.
9. Separate building from consuming. Keep edit rights on sensitive models to maintainers.
10. Control exports, subscriptions and sharing. Disable public links for internal data.
11. Test as real users before each release. Including edge cases and other access routes.
12. Log access and review it quarterly. With data owners, and alert on unusual activity.

When spreadsheets are the real leak

In many businesses, the dashboard is not the main route by which sensitive reporting data spreads. Spreadsheets are. A monthly management pack built in Excel, a margin analysis emailed to the sales team, a headcount file saved to a shared drive: each carries the full dataset with no row-level or column-level control, and once sent it cannot be recalled.

Moving recurring reports from emailed spreadsheets into a secured dashboard is often the single biggest improvement in reporting data governance a business can make, because it replaces many uncontrolled copies with one controlled source. Our guides to moving from spreadsheets to dashboards and Power BI versus Excel for reporting cover the transition in more detail.

Where spreadsheets remain necessary, a few habits help: produce audience-specific extracts rather than sending the full dataset, remove columns the recipient does not need, store files in locations with appropriate permissions rather than emailing them, apply sensitivity labels where your platform supports them, and prefer live connections to a secured dataset over static exports, so that security continues to apply when someone opens the file.

External users, client portals and partners

Some businesses share reporting outside the organisation: clients who see their own account performance, franchisees who see their own outlet, partners who see shared pipeline. External sharing raises the stakes for row-level security, because a mistake shows one client another client’s data, which is both a commercial and a data protection problem.

The same principles apply with less margin for error. Each external user should be identified individually, not through a shared login. Row-level security should be enforced at the data layer or in an embedding layer designed for the purpose, rather than relying on filters that a user could change. Default behaviour for an unrecognised or unmapped user must be no data. Exports and sharing should be restricted more tightly than for internal users. And testing should include deliberately trying to see another client’s data, since that is the failure that matters most.

For embedded analytics in a client portal, the application typically identifies the user and passes their entitlements to the reporting layer, which then enforces them. The design of that handover — how identity and entitlements are passed, and how they are verified — deserves careful review, ideally including security testing before launch.

At a glance: controlling who sees what in internal dashboards

How Cloudswitched approaches reporting security

We build internal reporting so that one well-maintained dashboard can serve every audience appropriately. Engagements usually start with a sensitivity map agreed with your data owners and a review of current access, which often removes the most significant exposure — excess edit, export and database rights — within days.

We then design row-level security at the layer that suits your data and tools: in the database or warehouse where data is sensitive and used by several tools, in the BI model where that is the only route, and often both. Entitlements are driven by mapping tables populated from your HR, CRM or finance systems, so access follows joiners, movers and leavers without manual updates. Sensitive columns are removed, hidden or masked by audience, exports and subscriptions are controlled, and a test plan checks what each type of user sees before every release.

Finally, we turn on auditing and set up a light review routine with data owners, and we consolidate the duplicate per-audience reports that security makes unnecessary. No configuration can remove every risk, but layered controls with clear ownership mean your dashboards show each person what they need, and nothing they should not see.

Frequently Asked Questions

What is row-level security in reporting?

A control that limits which records each user can see within a report or dataset, so the same dashboard shows a regional manager their region and a director every region, based on who is signed in.

Should row-level security be in the database or the BI tool?

Data-layer security applies to every tool and query and suits sensitive or widely used data. BI-tool roles are quicker to set up and suit data accessed only through that tool. Many businesses use both, with clear understanding of which protects what.

How do we stop role-based permissions becoming unmanageable?

Use a small number of rules that look up each person’s entitlements from a mapping table, populated from HR, CRM or finance systems, rather than creating a separate role for every region, team or combination.

What is column masking?

Showing a partial or generalised version of a sensitive value, such as the last four digits of an account number or a salary band instead of an exact figure. It reduces casual exposure but should be combined with proper permissions rather than relied on alone.

Does row-level security apply to everyone?

Not always. In some BI tools, people with edit or workspace member rights are not subject to row-level security. Administrators and exempted accounts also bypass data-layer rules. Keep these rights to a small group.

Can users bypass dashboard security by exporting data?

Exports from properly secured reports should respect row-level security, but exports still move data outside the tool. Restrict export on sensitive reports, review scheduled subscriptions, and check how your tool handles security in exports and spreadsheet analysis.

What should happen if a user is not in the mapping table?

They should see no data. A rule that shows everything when a user cannot be found is one of the most common and serious row-level security errors.

How do we test row-level security?

Use the tool’s ability to view reports as a particular role or user, check typical users and edge cases such as multiple roles, leavers and unmapped users, and verify totals, exports and other access routes as well as visible rows.

Do we need to audit dashboard access?

It is good practice, particularly for sensitive data. Logs help investigate incidents, show whether access is still appropriate and demonstrate governance. Review them periodically with data owners rather than just collecting them.

How does UK GDPR affect internal dashboards?

Dashboards often contain personal data, and principles such as data minimisation and security apply. Limiting who can see personal data in reports, removing unnecessary fields and controlling exports all support compliance. Take advice on your specific obligations.

Will restricting access make our dashboards less useful?

Usually the opposite. When people trust that sensitive figures are only visible to the right audience, they are more willing to put data into the dashboard, and duplicate spreadsheets and copied reports can be retired.

How long does it take to implement?

For a typical SME reporting environment, an access review can be done in days, and row-level and column-level security for the main datasets in around six to eight weeks, depending on the number of sources and tools.

Related reading

More guidance for UK businesses from the Cloudswitched blog:

• AI integration architecture: connecting LLMs without a maintenance nightmare
• Cyber Essentials scope: deciding what is in and out of your certification
• IT governance for UK SMEs: board reporting and risk registers
• Website security hardening: protecting your site from common attacks
• Network change management: making changes without outages