Updated: 22 October 2026.
A dashboard can show only headcount, totals and trends while the account behind it can still read individual records. I would check both before describing the data as protected.
The visual tells me what a particular screen displays. It does not tell me everything a user, dataset author or service account can retrieve.
This matters when a reporting system combines useful business information with names, employee identifiers, compensation or other personal data. Removing those fields from a chart does not automatically remove access elsewhere.
Trace the identity that reaches the database
Imagine a fictional reporting system where managers see monthly headcount by department. The warehouse also contains individual employment records.
I would trace a request from the dashboard to the dataset and then to the database connection. Does the database receive the viewer’s identity, or does it see a shared service account? Who can edit the dataset? Can an author add fields, create a new analysis or export a different result?
These questions determine where access restrictions must be enforced. A database policy cannot distinguish two dashboard viewers if both arrive as the same identity and no trusted user context reaches it.
Redshift supports row-level security, and supported QuickSight configurations can propagate user identity. Those capabilities need deliberate configuration; I would verify which identity actually executes the query rather than infer it from the sign-in screen.
Illustrative access paths: the dashboard connection reaches approved aggregates, while individual records require a separately authorised route.
flowchart TD V["Dashboard viewer"] --> Q["Reporting connection"] Q --> A["Approved aggregate relation"] A --> T["Totals and trends"] Q --> X["Direct raw-record access denied"] U["Authorised detail user"] --> P["Identity and permission checks"] P --> R["Permitted individual records"] T --> S["Review small groups and exports"]
Give aggregate reporting an appropriate data source
Where a dashboard needs only approved totals, I would consider giving its connection access to a dedicated aggregate relation instead of the underlying personal records. The owner, grants and query behaviour of that relation still need review.
For an illustrative headcount dataset, the approved output might contain reporting month, business unit and count. It would not include a hidden employee identifier merely because the source table contains one.
This approach also makes the intended contract easier to inspect: these are the fields and level of detail this reporting use case needs. A separate, controlled workflow can serve authorised users who genuinely require individual records.
Aggregation needs a privacy review too
An aggregate is not automatically anonymous. Suppose a filter reduces a department to one person. A total can then reveal information about that person. Comparing overlapping groups can also disclose more than either chart appears to show on its own.
I would review small groups, combinations of filters, drill-downs and exports. Depending on the data and audience, the design may need broader groupings, suppression or limits on available breakdowns. There is no universal group-size threshold that makes every dataset safe.
Test with accounts that should be refused
My review would include a viewer from another department, an ordinary author and the service identity itself. I would test permitted actions and denied actions, including access through alternative datasets or direct database tools where those routes exist.
I would also record whether data is queried live or copied into another storage layer. A copy creates another place where permissions, retention and exports matter.
The evidence I want is concrete: the identity used, the objects it can access, the records it can retrieve and the results of the negative tests. A screenshot of a tidy dashboard cannot answer those questions.
