# Who should be allowed to view a dashboard built from several private datasets? > Decide whether dashboard access should inherit from each source dataset or from a separately approved derived output with its own policy. Canonical URL: https://www.devobs.io/articles/qa-dashboard-derived-data-audience/ By: Finn Larson Published: 2024-10-05T22:16:22.581Z Updated: 2026-09-06T08:31:04.426Z Section: Authorization A dashboard built from multiple private datasets should be viewable by either people authorized for every contributing source, or by a separate audience for an explicitly approved derived output. Which one applies is a business release decision, not something a permission engine can guess from the word “dashboard.” Aggregation can still leak sensitive facts, and once you publish a result, later authorization changes do not undo what viewers already learned. ## Should access follow every contributing dataset? Usually, yes by default. If the dashboard behaves like a live lens into underlying restricted data, require viewers to satisfy the policy for each source that materially contributes to what they can see. That matches the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html), which recommends designing authorization around the actual resources and operations, enforcing least privilege, and denying by default. This is the safer model for drill-down dashboards, ad hoc filters, small cohorts, or views that expose row-level or near-row-level facts. In those cases, calling the result an “aggregate” does not change the sensitivity very much. ## When can the dashboard be its own approved output? Use a separate policy when your application has deliberately turned raw inputs into a governed release artifact: fixed transformations, approved fields, reviewed aggregation logic, and a named audience. That output is then its own resource with its own classification. This works well for board packs, department summaries, or published internal metrics. But the release decision belongs in your application and governance process. Authorization can enforce who may see `dashboard:q3_board_summary`; it cannot decide whether your transformation removed enough risk to justify broader access. ## What can aggregates still reveal? Quite a lot. A salary dashboard showing “average compensation by team” may still expose one person’s pay if a team is tiny or if users can compare slices over time. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is still the right framing here: authorization has to match the sensitivity of the resource being exposed, not just the storage location of the data. So pair permissions with release controls such as minimum group sizes, suppression of small cells, fixed query templates, and versioned approval of derived outputs. Authorization decides who can view. It does not make an unsafe aggregate safe after the fact. ## How should you model this in practice? Suppose a dashboard joins `sales_transactions` with `employee_compensation`. If it shows revenue per rep, quota attainment, and compensation ratio, viewers should generally need rights consistent with both datasets. If your application instead produces a monthly regional summary with no rep identifiers and suppresses low-count regions, you may classify that output separately and authorize the summary itself. This is a strong fit for [Ory Network Keto documentation](https://www.ory.com/docs/network/keto). Ory Keto is a fine-grained permission system based on Zanzibar design principles, and the docs say it can issue fine-grained permissions and allow permission inheritance through groups, roles, and hierarchies. That makes it well suited to model relationships such as `user can_view dataset:sales`, `user can_view dataset:compensation`, and `user can_view dashboard:board_summary` while your application keeps ownership of transformation and release rules. Use Ory Permissions or Keto to enforce the resource policy; keep classification review, aggregation thresholds, and release approval in your application or governance workflow. If you want a managed deployment path, [the Ory Keto GitHub repository](https://github.com/ory/keto) documents that Ory Network provides Ory Permissions powered by the open-source Ory Keto server, while self-hosting Keto is a separate deployment choice. That distinction matters here: the permission model can stay the same even though your operational path differs. ## Can aggregates be shared more broadly? Yes, when you explicitly approve the derived output for that audience and design the output so small-group or repeated-query inference is not the easy path back to restricted facts. ## What if one source becomes more restricted later? For source-dependent dashboards, tighten access immediately. For separately approved outputs, re-review the output classification; do not assume a new deny rule can retract information already released. Next step: inventory each dashboard, list its contributing datasets, and mark it as either source-dependent or separately approved output before you encode permissions in Ory Network. Reviewed: 2026-09-06 ## Source references - - -