Power BI Public Publishing: Best Practices & Security Considerations

Power BI has become a foundational analytics platform for public health units, enabling teams to explore complex datasets, uncover trends, and communicate insights to a wide range of audiences. From disease surveillance dashboards to program performance monitoring, its ability to translate data into clear, interactive visuals has made it an indispensable tool for evidence-informed decision-making.

As public health organizations increasingly emphasize transparency and public reporting, the ability to share insights broadly can be both powerful and risky. Tools that make data easy to publish can also make it easy to share more than intended. Without careful governance and disciplined report design, well-intentioned public reporting can unintentionally expose sensitive or protected information.

This post outlines key best practices and security considerations for using Power BI’s public publishing capabilities responsibly, with a focus on ensuring that public-facing reports remain both informative and safe.

Overview #

Power BI’s Publish to Web feature allows users to share interactive reports publicly without requiring report consumers to have a Power BI license. To use the feature, a Power BI license is required: a Power BI license is sufficient when publishing from My Workspace, while a Power BI Pro or Premium Per User license is required when publishing from shared workspaces. No Power BI Premium or Fabric capacity is required.¹

However, this convenience comes with significant privacy and security risks that must be understood before use. The only appropriate use of this feature is for reports intentionally designed for unrestricted public access, and only after a thorough review has been confirmed that no sensitive or internal data can be exposed.

Publish to Web should never be used as a workaround to avoid purchasing Power BI Pro licenses for report consumers or adopting a governed sharing model such as Power BI Premium or Fabric for internal reporting. Using it in this way introduces unnecessary risk by bypassing authentication, authorization, and security controls.

Privacy & Security Risks #

The “Publish to Web” feature lacks fundamental security capabilities, including Row-Level Security (RLS) and other access control mechanisms. As a result, it is inherently unsuitable for sensitive, confidential, or internal-use data.

Additionally, publicly generated report URLs provide no usage tracking or access visibility, making it impossible to determine who has viewed or interacted with the report. While these URLs may appear secure due to their long and complex structure, replying on “security through obscurity” is a dangerous practice that can lead to unintended data exposure.

Data Preparation Best Practices #

Before reviewing the best practices below, it is important to understand what Power BI refers to as the semantic model.

1. Always assume that any data available within the Power BI semantic model could be exposed when using “Publish to Web.”
2. Do not rely solely on visualization choices to protect data privacy. Even if a visual displays only aggregated or summarized values, the underlying data in the semantic model may still be accessible when using “Publish to Web.”
3. Always create custom measures rather than relying on default aggregation behaviour. Built-in aggregations often enable the “Show Data Point as a Table” option when users right-click on visuals. if accessed, this feature exposes the entire underlying, unaggregated dataset. This represents the single highest risk for uninteded data access in Power BI reports published to web.
4. Perform aggregation and suppression upstream of Power BI (e.g,. in Python, R, SQL) before data is loaded into the model. Aggregating solely within Power BI (via visuals and/or DAX) does not necessarily prevent access to lower-level data that remains in the semantic model.
5. Use the “Query Reduction” preset to reduce unintended interactivity.
6. Check both interaction directions for all visual element relationships. Disable any interactions that are not necessary for intended report functionality.
7. Lock and hide filters at the visual, page, and report levels to prevent unintentional user-drive data exposure.
8. Visualizations should be applied at the highest level of aggregation that maintains interactivity without risking data exposure.
9. When using bookmarks for report navigation, ensure that only selected visuals are affected by choosing the “selected visuals only” option.
10. Hiding visual headers on visualizations can help restrict viewer access to extra options that might compromise data security.

Additional thought: be cautious of excessive filters and slicers that, when combined, may allow users to narrow results to very small populations. Even aggregated data can pose re-identification risks if users are able to apply multiple filters that effectively expose low-level or individual-level information.

Administrator Abilities #

Power BI administrators can restrict which users are allowed to use the “Publish to Web” feature, reducing the likelihood of accidental or inappropriate usage. However, administrators cannot disable the “Show Data Point as a Table” feature across an organization, nor can they enforce data preparation or report design best practices centrally.

Because of these limitations, every report intended for public publishing must be reviewed individually to ensure it does not expose unauthorized or sensitive data. This review should be repeated after any updates have been made to the report (including the data refresh, model/relationship change, etc.), as changes can introduce new exposuure risks.

Report & Data Review #

Before publishing any report publicly, conduct a comprehensive review of both the data and report configuration.

• Review the tabular data included in the semantic model to confirm that no sensitive fields or records are present. This can be done during the final data preview in Power Query, or by insepcting tables directly in the Data View (table icon on the far left) within Power BI Desktop.
• Validate report-level, page-level, and visual-level settings to ensure only the intended data is accessible. This review step is essential and should be treated as a mandatory safeguard before any report is made publicly available.

Further Reading #

For additional context on Power BI security capabilities and governance considerations, I recommend reviewing Grant Gamble’s blog post on Power BI security features². For a deeper technical exploration of data exposure risks, specifically pertaining to the “Show Data as a Table” feature, I would recommend checking out Chris Webb’s blog post³.

Implementing these best practices helps ensure that publicly shared Power BI reports remain secure, performant, and trustworthy. More importantly, they allowed organizations to leverage Power BI’s public sharing capabilities without unintentionally exposing sensitive data or undermining governance standards.