# Security and Governance in Power BI

> Chapter 17 of the Courseiva PL-300 curriculum — https://courseiva.com/learn/pl-300/security-and-governance

**Official objective:** 4.3 — Configure permissions, data sensitivity labels, and audit logs

## Introduction

How do you stop the wrong person from seeing a sensitive sales report while letting the right person edit the data model? That is the core problem that security and governance solve in Power BI. For the PL-300 exam, you need to understand the three pillars that keep your reports safe: permissions (who can do what), data sensitivity labels (how sensitive is this data), and audit logs (who did what and when). Without these, your organisation’s data would be as unprotected as leaving a filing cabinet open in a public hallway.

## The Community Centre Access and Permissions Analogy

Inside a busy community centre that hosts several different groups. You are the centre manager, and you need to make sure the right people can get into the right rooms without causing chaos or risking anyone’s safety. The pottery club has its own locked cupboard for glazes, the youth group uses a meeting room with a whiteboard full of private notes, and the treasurer keeps sensitive financial records in a filing cabinet in the office. You decide to give every member a coloured lanyard. A red lanyard lets someone enter the building and use the main hall. A blue lanyard adds access to the pottery cupboard and the office. A green lanyard allows entry to the youth room and the storage closet. You also put a sticker on the treasurer’s filing cabinet that says “Confidential — do not photograph or remove.” Finally, you install a sign-in log at the front desk so you can see who came into the building, which room they swiped into, and at what time. 

 This system is exactly how Power BI handles security and governance. The coloured lanyards are “permissions” (who can see or edit which reports and datasets). The confidentiality sticker is a “sensitivity label” that warns users how to handle the data. The sign-in log is the “audit log” that records every action taken inside the Power BI service. Without these layers, anyone with a key could wander into any room, peek at private information, and there would be no record of who did what.

## Core explanation

Security and governance in Power BI is the framework that controls who can access your reports and dashboards, how they can interact with the underlying data, and what record exists of their actions. Think of the Power BI service as a secure office building. The very first layer of security is “permissions.” Permissions are rules that define exactly what a person (or a group of people) is allowed to do inside Power BI. There are several types of permissions you need to know for PL-300. 

 - “Workspace roles” control what someone can do inside a specific workspace. A workspace is a container for dashboards, reports, datasets, and dataflows. The four main roles are Admin, Member, Contributor, and Viewer. An Admin can add or remove other users and delete the workspace. A Member can edit content and share it with others. A Contributor can edit content but cannot share it or add new members. A Viewer can only look at the reports and dashboards — no editing allowed.

 - “Item-level permissions” let you control access to a single report, dashboard, or dataset without giving full workspace access. For example, you could allow a colleague to “read” a specific sales report by sharing it directly, even though they are not a member of the workspace that holds it.

 - “Row-level security” (RLS) is a more granular permission. It limits which rows of data a specific user can see within the same report. For instance, a regional manager might only see sales data for their own region, while the national manager sees all regions. RLS is configured on the dataset, not on the report itself.

 The second pillar is “data sensitivity labels.” These labels come from Microsoft Purview Information Protection (formerly known as Microsoft Information Protection). A sensitivity label is like a stamp you put on a report or dataset that tells users how sensitive the information is and what they are allowed to do with it. Common labels include “Internal,” “Confidential,” and “Highly Confidential.” Once you apply a label to a Power BI dataset or report, that label travels with the data — even when someone exports it to Excel, PDF, or PowerPoint. This is critical for governance because it prevents someone from accidentally (or deliberately) taking sensitive data outside the secure environment without a warning to treat it carefully. Labels can also enforce encryption and watermarking. 

 The third pillar is “audit logs.” An audit log is a record of every significant action that happens inside the Power BI service. This includes actions like viewing a report, sharing a dashboard, exporting data, changing a permission, or adding a sensitivity label. Audit logs are stored centrally in the Microsoft Purview compliance portal, and administrators can search them to answer questions like “Who viewed the quarterly revenue report last week?” or “Did anyone export the customer list to Excel?” For PL-300, you need to know that audit logging must be turned on in the Microsoft 365 admin centre, and that the logs are kept for 90 days by default (or longer if you have a premium licence with retention policies). 

 Together, these three elements — permissions, sensitivity labels, and audit logs — form the backbone of governance in Power BI. They replace the old way of doing things, which was often a messy combination of emailing Excel files around (with no record of who had a copy) and putting reports on shared drives that anyone in the company could access. Power BI gives you a central, auditable, and label-aware way to share data while keeping control.

## Real-world context

Let us walk through what an IT professional or a Power BI administrator actually does with security and governance in a real business. Imagine you work for a medium-sized retail company called “BrightBuy.” The company has 500 employees across three regions: UK, US, and Australia. You are responsible for the Power BI service. 

 Your first task is to set up workspace roles. You create a workspace called “Sales Analytics” and invite the head of sales (Sarah) as an Admin so she can manage her team’s access. You invite three data analysts as Members so they can edit reports and share them with regional sales managers. You invite the regional managers as Viewers so they can only read the reports. 

 Next, you configure Row-Level Security (RLS). You want each regional manager to see only their own region’s sales data inside the same “Sales by Region” report. To do this, you open the dataset in Power BI Desktop, go to “Manage Roles,” and create a role called “UK Region.” You write a DAX formula (a simple data filter) like: [Region] = “UK”. You then publish the dataset to the service, and in the dataset settings, you assign the UK regional manager’s email address to that role. Now when the UK manager opens the sales report, they only see UK rows. The US manager sees only US rows, even though they all use the same report file. 

 The third step is applying sensitivity labels. Your compliance officer has set up three labels in Microsoft Purview: “Internal,” “Confidential,” and “Highly Confidential.” You go into the Power BI workspace, select the sales report, and in the settings you apply the “Confidential” label because it contains employee salary data alongside sales figures. This label will now force anyone who exports the report to Excel to see a header that says “Confidential — do not share externally.” Encryption settings can also block the export entirely. 

 Finally, you set up audit logging. You go to the Microsoft 365 admin centre, navigate to “Audit,” and ensure logging is enabled (it often is by default for organisations with the right licence). A week later, the CEO calls you because someone accidentally shared a sensitive financial report with a vendor. You use the audit log to search for the “Share report” action within the last 7 days. You find that a junior analyst named Alex shared the report on Tuesday at 3:14 PM. You then know exactly who made the mistake and can have a conversation with Alex to reinforce the training. You also revoke the external share immediately. 

 - You routinely export audit logs to a Log Analytics workspace for long-term retention and advanced querying.

 - You create a sensitivity label policy that auto-labels any dataset containing the word “salary” or “PII” (personally identifiable information) as “Highly Confidential.”

 - You use the “Protect” tab in the Power BI admin portal to enforce that all new workspaces must default to a minimum of “Confidential” label st.

## Exam focus

The PL-300 exam tests your knowledge of security and governance in a very specific way. You will see scenario-based multiple-choice questions, often with a “which of the following” format. The exam expects you to know the exact name, purpose, and limitations of each piece. 

 One of the most heavily tested concepts is the distinction between “Workspace roles” and “Item-level sharing.” A common trap question goes: “You need to allow a user to edit a report in a workspace, but they should not be able to share it with others. Which role should you assign?” The correct answer is “Contributor.” The trap is that many beginners choose “Member” because it sounds like “editing” is the main activity, but Members can indeed share. Similarly, “Admin” is too permissive, and “Viewer” does not allow editing. 

 Another common exam topic is Row-Level Security (RLS). They will ask you to configure RLS in Power BI Desktop, and then test that you know you must assign users to the roles AFTER publishing to the Power BI service. The exam frequently presents a scenario where you have set up RLS, but the user still sees all data. The trap is that the user was not assigned to the role in the service, or the user has a higher-level permission (like workspace Admin) that bypasses RLS. Remember: workspace Admins and Members see all data regardless of RLS rules. 

 Sensitivity labels are another frequent question area. The exam expects you to know that labels come from Microsoft Purview Information Protection, not from Power BI itself. You will see questions like “Which tool is used to create sensitivity labels?” The answer is “Microsoft Purview compliance portal.” A trap is that some might answer “Power BI admin portal” or “Azure portal.” You also need to know that labels can be applied to datasets and reports, and that they persist when data is exported. 

 Audit logs are tested in two ways. First, you need to remember that audit logging must be enabled in the Microsoft 365 admin centre (specifically under “Audit” in the compliance centre). Second, you will be asked to identify which activities are logged. Common logged activities include viewing a report, exporting data, sharing a dashboard, and applying a sensitivity label. A trap question might ask “Which action is NOT logged?” and include an obscure action like “changing a chart colour” (which is not logged because it is an interaction, not a security-significant event). 

 Key topics to memorise: 

 - The four workspace roles: Admin, Member, Contributor, Viewer. Know the exact abilities of each.

 - Row-Level Security is configured in Power BI Desktop under “Manage Roles,” and users are assigned in the service under “Dataset Settings.”

 - Sensitivity labels are created in Microsoft Purview, applied in Power BI service, and persist on export.

 - Audit logs are stored in Microsoft 365 compliance centre and kept for 90 days (default).

 - The difference between sharing a report (item-level permission) and granting workspace access (workspace role). Sharing allows access to a single item only, workspace roles allow access to everything in the workspace.

 One final exam trap: they love to ask about “app workspaces” vs “classic workspaces.” Classic workspaces (from before 2020) had a different permission model (only Admin and Member). The modern workspace (the only one tested heavily now) uses the four-role model. If a question mentions a workspace created in 2021 or later, assume modern roles.

## Step by step

1. **Create a workspace and assign roles** — In the Power BI service, create a workspace for your team’s reports. Add users and assign each person the correct role (Admin, Member, Contributor, or Viewer). This step establishes the first layer of security by controlling who can edit, share, or only view content. A common beginner mistake is to give everyone Admin access, which breaks governance.
2. **Configure Row-Level Security (RLS) in Power BI Desktop** — Open your dataset in Power BI Desktop. Go to the “Manage Roles” button in the Modelling tab. Create a role (e.g. “UK Managers”) and write a DAX filter like [Region] = “UK”. This step defines who sees which rows, but no one is assigned yet. Publishing this to the service is required before you can link users to the role.
3. **Assign users to RLS roles in the Power BI service** — After publishing the dataset, go to the dataset settings in the Power BI service. Under “Row-Level Security,” select the role you created and add user email addresses. This step is where the filter becomes active. Without this, the role does nothing. Remember that workspace Admins and Members see all data regardless of assignment.
4. **Apply sensitivity labels to datasets and reports** — In the Power BI service, navigate to a workspace, select a report or dataset, and in the settings choose a sensitivity label from the drop-down list (e.g. “Confidential”). This step stamps the data with a classification that persists on export. You must have labels already set up in the Microsoft Purview compliance portal before they appear here.
5. **Enable and search audit logs** — Go to the Microsoft 365 admin centre, navigate to “Audit,” and ensure logging is turned on (usually default). To search, select the date range and activity type (e.g. “View report” or “Share dashboard”). This step is crucial for investigating who accessed sensitive data or performed suspicious actions. For PL-300, know that you must use the compliance centre, not the Power BI admin portal.
6. **Review and adjust sharing permissions for individual items** — For a specific report or dashboard that should be shared with external users or a small group, use the “Share” button in the report interface. You can set permissions to “Allow recipients to share” or not. This step provides granular control beyond workspace roles. Remember that sharing the report does not automatically share the dataset — recipients must also have dataset access.

## Comparisons

### Workspace Roles vs Item-Level Sharing

**Workspace Roles:**
- Grants access to all content in the workspace.
- Roles include Admin, Member, Contributor, Viewer.
- Does not require the recipient to have a Pro licence if the workspace is on Premium capacity.

**Item-Level Sharing:**
- Grants access only to a single report or dashboard.
- Uses the Share button and allows optional co-sharing permissions.
- Requires the recipient to have a Pro licence unless Premium capacity applies.

### Row-Level Security (RLS) vs Sensitivity Labels

**Row-Level Security (RLS):**
- Filters the data rows a user can see within a dataset.
- Configured in Power BI Desktop with DAX filters.
- Bypassed by workspace Admins and Members.

**Sensitivity Labels:**
- Classifies the sensitivity of the entire report or dataset.
- Configured in Microsoft Purview and applied in Power BI service.
- Enforces protections (encryption, watermarks) on exported files.

### Audit Logs vs Activity Logs (Usage Metrics)

**Audit Logs:**
- Records security and governance actions (share, export, permission change).
- Stored in Microsoft 365 compliance centre.
- Retained for 90 days by default.

**Activity Logs (Usage Metrics):**
- Records user interaction data (views, opens, popularity).
- Stored within Power BI as usage metrics reports.
- Retained is indefinite based on data refresh cadence.

### Power BI Pro Licence vs Power BI Premium (Per User or Capacity)

**Power BI Pro Licence:**
- Required for sharing reports and collaborating in workspaces.
- Allows recipients without a licence to view reports only if assigned to Premium capacity.
- Cost per user per month.

**Power BI Premium (Per User or Capacity):**
- Dedicated capacity that allows free users to view shared reports.
- Also allows larger data sizes and higher refresh rates.
- Cost is per capacity (monthly) or per user (Premium Per User).

## Diagram

_The three pillars of Power BI security and governance: permissions, sensitivity labels, and audit logs, along with their sources and relationships._

```mermaid
flowchart TD
    A[Power BI Service] --> B[Sensitivity Labels]
    A --> C[Permissions]
    A --> D[Audit Logs]
    B --> E[Created in Microsoft Purview]
    B --> F[Applied to Reports & Datasets]
    B --> G[Persists on Export to Excel/PDF]
    C --> H[Workspace Roles: Admin, Member, Contributor, Viewer]
    C --> I[Item-Level Sharing]
    C --> J[Row-Level Security (RLS)]
    D --> K[Microsoft 365 Compliance Centre]
    D --> L[Records: View, Share, Export, Label Change]
```

## Common misconceptions

- **Misconception:** Row-Level Security (RLS) prevents users from seeing the report at all if they do not have access to any rows. **Reality:** RLS does not prevent access to the report. It filters the data so the user sees only the rows they are allowed to view. If a user has no matching rows, they will see an empty report, not a blocked error. (Beginners confuse filtering data with denying access. RLS filters, it does not remove the report from the user’s view.)
- **Misconception:** Sensitivity labels only affect the report inside Power BI, not when it is exported. **Reality:** Sensitivity labels in Power BI are designed to persist when data is exported to Excel, PDF, or PowerPoint. They travel with the file and can enforce encryption, watermarking, and visual markings like headers or footers. (People assume labels are “stickers” that only live inside the source application, but Microsoft Purview labels are sticky by design and travel across formats.)
- **Misconception:** If you share a report with someone, they automatically get access to the underlying dataset. **Reality:** Sharing a report does not automatically grant access to the underlying dataset. The recipient can view the report only if they have at least read permission to the dataset, or if the report uses DirectQuery or Live Connection to a shared dataset. For imported data, the dataset must be in a shared workspace or shared separately. (This mistake comes from thinking of reports and datasets as a single file, when they are actually separate items in Power BI with independent permissions.)
- **Misconception:** Audit logs record every single action a user takes in a report, such as changing a filter or clicking a slicer. **Reality:** Audit logs only record significant administrative and security-related actions, such as viewing a report, exporting data, sharing, changing permissions, or applying labels. Normal interactive actions like changing filters or sorting columns are not logged. (The word “audit” sounds comprehensive, but in practice it is tuned to governance needs, not fine-grained user behaviour.)
- **Misconception:** A workspace Admin role gives a user full access to view and edit all reports, but they cannot see other people’s personal data in a report protected by RLS. **Reality:** Workspace Admin and Member roles bypass Row-Level Security entirely. A user with Admin or Member access to a workspace can see all rows of data in any dataset within that workspace, regardless of RLS rules. (It is counter-intuitive that a higher permission (workspace role) overrides a lower-level security rule (RLS). This is a very common exam trap.)

## Key takeaways

- Workspace roles (Admin, Member, Contributor, Viewer) control the level of access a user has to all content in a workspace, with Admin and Member bypassing Row-Level Security.
- Row-Level Security (RLS) filters data at the row level but does not block access to the report itself; workspace Admins and Members see all data despite RLS.
- Sensitivity labels are created in the Microsoft Purview compliance portal, not in Power BI, and they persist when data is exported to Excel or PDF.
- Audit logs record security-related actions (view, share, export, label changes) but do not track routine interactions like filters or slicer clicks.
- Sharing a report individually gives item-level access but does not automatically grant access to the underlying dataset unless the dataset is in a shared workspace or separately shared.
- To enforce that a user can edit a report but not share it, assign the Contributor workspace role, not the Member role.
- Audit logs are retained for 90 days by default, and you can extend retention with a premium licence or by exporting logs to Log Analytics.
- Sensitivity labels can be configured to enforce encryption, watermarking, and visual markings on exported files, providing protection outside Power BI.

## FAQ

**What is the difference between a workspace role and sharing a report?**

A workspace role (Admin, Member, Contributor, Viewer) gives a user access to everything in the workspace. Sharing a report gives access only to that specific report, not to other items in the workspace. Think of workspace roles as a master key to a room, while sharing is a key to a single drawer inside that room.

**Can I apply a sensitivity label to a single visual in a report?**

No, sensitivity labels apply to the entire report or dataset. You cannot label individual pages or visuals separately. The label covers the whole report and travels with any export of the report.

**Who can see audit logs in Power BI?**

Only users with the “Audit Log” role in the Microsoft Purview compliance portal, or global administrators, can view audit logs. Regular Power BI users cannot see audit logs. You must have permission to the compliance centre, not just to Power BI.

**Do sensitivity labels prevent someone from exporting data?**

Labels can be configured to encrypt the exported file or to block export entirely, depending on the label settings in Microsoft Purview. The label itself does not automatically block export, but it can enforce protections like encryption, watermarking, or visual markings.

**What happens if I share a report with someone who does not have a Power BI Pro licence?**

The recipient will be prompted to start a free trial or purchase a Pro licence, unless the report is in a workspace assigned to a Premium capacity. In Premium capacity, users with a Free licence can view reports shared with them, but they cannot edit or share them further.

**How long are audit logs kept by default?**

Audit logs are retained for 90 days by default in the Microsoft 365 compliance centre. Organisations with an add-on licence (e.g. Microsoft 365 E5) can extend retention up to 10 years. For PL-300, remember the default of 90 days.

**Can I use Row-Level Security on a live connection to Analysis Services?**

Yes, but the RLS must be configured in the source Analysis Services model, not in Power BI. Power BI respects the RLS rules defined in the source. This is a common exam point: Power BI’s RLS is for imported data only; for live connections, RLS is managed at the source.

## Check your understanding

1. **Which workspace role allows a user to edit reports but not share them with others?**

   Answer: The Contributor role allows editing but not sharing. The Member role allows editing and sharing. The Admin role allows all actions including adding and removing users.

2. **Where are sensitivity labels for Power BI created?**

   Answer: Sensitivity labels are created in the Microsoft Purview compliance portal, not in Power BI itself. Once created, they become available in the Power BI service to apply to reports and datasets.

3. **Does Row-Level Security (RLS) block a workspace Admin from seeing all data?**

   Answer: No, workspace Admins and Members bypass RLS. They can see all rows in any dataset within that workspace regardless of RLS filters. Only Viewers and Contributors are subject to RLS.

4. **What is the default retention period for audit logs in Power BI?**

   Answer: Audit logs are retained for 90 days by default in the Microsoft 365 compliance centre. Organisations can extend this with additional licences.

5. **If you share a report with an external user, do they automatically get access to the underlying dataset?**

   Answer: No, sharing a report does not automatically grant access to the underlying dataset. The recipient must also have at least read permission on the dataset, or the dataset must be in a shared workspace accessible to them.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/pl-300/security-and-governance