Security, Privacy, Ethics, and Governance

Introduction

Business intelligence creates value by making organisational information easier to access, interpret, and use. The same accessibility can create serious risks. A report may contain salaries, customer identifiers, health information, commercially sensitive prices, or operational weaknesses. If the wrong person views, changes, exports, or distributes that information, the organisation may face financial loss, legal penalties, reputational damage, and harm to individuals.

Power BI security and governance are therefore not merely technical administration tasks. They are management systems for deciding who may access information, what they may do with it, how information is classified and protected, and how analytical decisions remain trustworthy and accountable. Effective governance balances three objectives:

1. Availability: authorised users can obtain information when needed.
2. Confidentiality: information is protected from unauthorised disclosure.
3. Integrity: data, models, reports, and interpretations remain accurate and reliable.

This chapter explains row-level security, workspace permissions, sensitivity labels, privacy principles, least-privilege access, governance policies, certification, lineage, and ethical standards for responsible Power BI use.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish authentication, authorisation, and auditing;
• apply row-level security (RLS) to restrict data by user or group;
• explain workspace roles and the principle of least privilege;
• use sensitivity labels and information-classification practices appropriately;
• describe privacy, security, and ethical risks in BI;
• interpret lineage and certification as governance controls;
• recommend a practical governance framework for a Power BI environment; and
• evaluate an applied case involving access, privacy, and responsible reporting.

1. Security as a Layered Control System

Security is strongest when several controls operate together. No single feature should be treated as complete protection.

1.1 Authentication, authorisation, and auditing

Authentication verifies identity: for example, a user signs in through an organisational identity provider. Authorisation determines what that authenticated user may do, such as view a report, edit a semantic model, publish an app, or share content. Auditing records relevant activity, such as access, sharing, export, modification, and administrative changes.

These concepts answer different questions:

A user who is correctly authenticated may still be unauthorised to view payroll information. Conversely, a user may have permission to view a report but not to edit its semantic model. Sound design separates these decisions.

1.2 Defence in depth

A practical Power BI environment may combine:

• identity and multifactor authentication;
• security groups rather than large numbers of individual assignments;
• workspace and app permissions;
• RLS in the semantic model;
• sensitivity labels and data-loss-prevention controls;
• controlled sharing and export settings;
• audit and monitoring processes; and
• periodic access reviews.

For example, a finance report may be published only to a finance app, restricted to finance users, protected by RLS, labelled confidential, and reviewed through audit logs. Each control addresses a different failure mode.

2. Row-Level Security

Row-level security restricts the rows of data returned to a user. A single semantic model can therefore serve multiple audiences while exposing each audience only to permitted records.

Suppose a sales table contains transactions for North, South, East, and West regions. A regional manager should see the records for the manager’s region, whereas a national director may see all regions. RLS implements this rule in the semantic model rather than relying only on separate report pages or visual filters.

2.1 Static and dynamic RLS

Static RLS assigns a fixed filter to a role. A role named NorthRegion might filter the Region column to North. This is straightforward but can become difficult to maintain when there are many users or changing organisational assignments.

Dynamic RLS uses a security mapping table. A typical mapping table contains a user identifier and an authorised business attribute:

A relationship connects the mapping table to the region dimension. A role filter can then use the signed-in user identity, commonly represented in DAX by USERPRINCIPALNAME(), to select the relevant mapping rows. The relationship propagates the filter to the fact table.

The logic is conceptually:

Here, u is the current user, r is a data row, and AuthorisedRegions(u) is the set of regions assigned to that user. The expression describes the intended access rule; its implementation depends on the model relationships and role definitions.

2.2 Designing reliable RLS

A reliable RLS design should:

1. define the business rule in plain language;
2. identify the authoritative source of user-to-business-unit assignments;
3. use stable user identifiers, normally organisational identities;
4. create a clear relationship from the security mapping table to the dimension table;
5. test users with multiple assignments and users with no assignment;
6. test totals, drill-through, export, subscriptions, and mobile access; and
7. document who owns the mapping table and how changes are approved.

A common error is to filter a visible report page and assume that the data is secured. A page filter changes presentation; RLS restricts the rows available to the user. Another error is creating a role but failing to assign users or groups to it in the relevant service environment. RLS must be tested after publication because permissions and identities can behave differently in development and production.

RLS is not a substitute for source-system security in every architecture. Data may be copied into extracts, exported by authorised users, cached, or accessed through another system. Security must therefore be considered across the complete data flow.

3. Workspace Permissions and Least Privilege

A workspace is a collaborative environment for developing and managing Power BI content. Workspace roles commonly distinguish capabilities such as viewing, contributing, editing, and administering. Exact features can vary with tenant configuration, licensing, deployment method, and Microsoft service changes; administrators should verify current product documentation.

The principle of least privilege states that a person or service should receive only the access necessary to perform an authorised task, for only as long as it is necessary. Least privilege reduces accidental changes, unauthorised disclosure, and the consequences of compromised accounts.

3.1 Practical permission design

A useful pattern is:

• Viewers consume approved content but do not modify it.
• Contributors create or update content within an agreed development area.
• Members or editors manage content where their operational responsibilities require it.
• Administrators control workspace settings, membership, and governance-sensitive operations.

Avoid giving administrator-level access simply because it is convenient. Use security groups, separate development and production workspaces, and controlled deployment processes. Business users can often receive access to a published app rather than direct access to the workspace.

Permissions should be reviewed when employees change roles, leave the organisation, or cease working on a project. Shared accounts should be avoided because they weaken accountability. Service principals and automated identities should have narrowly scoped permissions and documented ownership.

3.2 Workspace access is not the same as data access

Workspace permission and RLS operate at different levels. A user may have permission to view a report while RLS limits the rows displayed. An editor with permission to modify the semantic model may be able to alter or remove RLS. Consequently, model developers and workspace administrators require a higher level of trust than ordinary report viewers.

Access design should distinguish:

• who can build and change a model;
• who can publish and distribute a report;
• who can view the report; and
• who may export, share, or administer the underlying data.

4. Privacy and Sensitivity Labels

Privacy concerns the appropriate collection, use, disclosure, retention, and deletion of information about identifiable or potentially identifiable people. Personal data may include names, email addresses, employee identifiers, location records, device identifiers, or combinations of attributes that permit re-identification.

Important privacy principles include:

• Purpose limitation: collect and use information for specified legitimate purposes.
• Data minimisation: use only the data needed for the stated purpose.
• Accuracy: correct inaccurate or outdated information.
• Storage limitation: retain data only as long as justified.
• Confidentiality and security: protect information against unauthorised access or loss.
• Transparency and accountability: explain important uses and demonstrate compliance.

Legal requirements differ by jurisdiction and sector. Regulations such as the GDPR, national privacy laws, employment law, health-data rules, and contractual obligations may apply. A Power BI developer should not assume that a technical feature alone establishes legal compliance. Privacy officers, legal advisers, and information-security specialists may need to review the design.

4.1 Sensitivity labels

Sensitivity labels classify content according to its handling requirements. Typical categories might include Public, Internal, Confidential, and Highly Confidential. Labels can support consistent handling, visual marking, encryption, access restrictions, and downstream protection, depending on the organisation’s information-protection configuration.

A label should reflect the sensitivity of the information, not the importance of the report to its author. For example, a report containing aggregated public statistics may be Public, while a report containing employee salary records may be Highly Confidential.

Labels are useful only when supported by policy, user training, and technical enforcement. A label is not a replacement for RLS, workspace permissions, secure source systems, or careful sharing. Labels should be reviewed when a report combines sources or when a report is repurposed for a new audience.

4.2 Privacy-preserving presentation

Useful practices include:

• aggregate results where individual-level detail is unnecessary;
• suppress small groups when re-identification is possible;
• remove unnecessary names and direct identifiers;
• avoid publishing sensitive attributes in tooltips or drill-through pages;
• restrict exports and underlying-data access; and
• document retention and deletion requirements.

Aggregation does not automatically guarantee anonymity. For example, a dashboard showing a single employee in a small department may disclose information even without displaying a name. Analysts should consider combinations of fields and the possibility of linking the report with other datasets.

5. Governance for Trustworthy BI

Governance is the system of decision rights, policies, standards, roles, processes, and controls used to manage BI. It answers questions such as:

• Which data sources are approved?
• Who owns a semantic model?
• Which reports are official?
• How are changes tested and approved?
• How long is content retained?
• How are incidents reported?
• Which users may share or export information?

5.1 Governance roles

A practical governance structure may include:

• Executive sponsor: establishes strategic support and resolves cross-functional issues.
• BI or data governance council: sets standards and priorities.
• Data owner: accountable for a subject area, such as finance or sales.
• Data steward: maintains definitions, quality rules, and access processes.
• Workspace administrator: manages the technical environment.
• Report or model owner: maintains a specific analytical product.
• Privacy and security specialists: advise on risk, compliance, and controls.

These roles need not always be separate individuals, but responsibilities must be explicit.

5.2 Certification and endorsement

Certification communicates that an authorised authority has reviewed content against defined standards. Certified content should have a named owner, clear definitions, appropriate security, acceptable data quality, and a documented refresh process. Endorsement or promotion may indicate that content is recommended, but it may not represent the same level of formal approval as certification. Organisations should define the meaning of each status.

Certification is not permanent. A certified report can become unreliable when its source changes, its owner leaves, its measures are modified, or its refresh fails. Review dates and recertification criteria are therefore essential.

5.3 Lineage and impact analysis

Lineage shows relationships among sources, dataflows, semantic models, reports, dashboards, and other downstream assets. It assists users in answering:

• Where did this measure originate?
• Which reports depend on this dataset?
• What may be affected if a source column changes?
• Which content uses a sensitive source?

Lineage improves change management and incident response, but it is not automatically a complete data dictionary. Custom transformations, external exports, manually maintained files, and undocumented processes may not be fully represented. Lineage should be supplemented with ownership records, business definitions, and technical documentation.

5.4 Change management and audit

A controlled change process generally includes request, risk assessment, development, testing, approval, deployment, monitoring, and rollback. Version control or deployment pipelines can support separation between development, test, and production environments.

Audit information can reveal unusual sharing, repeated export activity, permission changes, failed refreshes, or access by unexpected users. Monitoring should be proportionate to risk and should itself respect privacy and employment requirements.

6. Ethics and Responsible BI

Ethical BI concerns whether analytical work is fair, transparent, explainable, proportionate, and respectful of human autonomy. A technically legal report may still be ethically problematic.

6.1 Common ethical risks

Bias may enter through historical data, missing populations, subjective labels, or unequal measurement practices. A dashboard ranking employee performance may disadvantage staff whose work is less easily quantified.

Misleading presentation can result from truncated axes, inappropriate averages, selective time periods, or unexplained exclusions. Visual accuracy is not enough; the interpretation must also be responsible.

Discrimination can occur when sensitive characteristics or their proxies influence decisions. Postal code, school, language, or employment history may act as proxies for protected characteristics.

Excessive surveillance can arise when dashboards track individuals continuously without a legitimate, communicated, and proportionate purpose.

Automation bias occurs when decision makers accept a dashboard or AI-generated insight without questioning data quality, assumptions, or uncertainty.

6.2 Ethical review questions

Before publication, ask:

1. What decision will this report influence?
2. Who benefits and who may be harmed?
3. Are the data and measures relevant to that decision?
4. Are affected people represented fairly?
5. Could individuals be identified or stigmatised?
6. Can users understand the definitions, limitations, and uncertainty?
7. Is there a human review and appeal process for consequential decisions?
8. Are access, retention, and sharing proportionate to the purpose?

These questions encourage responsible use without treating ethics as a final checklist only. Ethical considerations should influence data collection, modelling, visual design, deployment, and monitoring.

7. Applied Case: Regional Workforce Performance Dashboard

The following is an illustrative case.

Background

A national service organisation develops a Power BI dashboard showing response times, customer satisfaction, staff absence, and cases completed by region. Regional managers want detailed employee-level information, while the human-resources department requires confidentiality.

Problem

The initial design places the report in a broad workspace and grants many managers edit access. Employee names appear in drill-through pages. A spreadsheet maps users to regions, but it is updated irregularly. The report is labelled Internal even though it contains absence and performance information. Managers can export underlying data without a documented business need.

Analysis

The design has several weaknesses:

• workspace access is broader than necessary;
• the mapping table may be inaccurate or stale;
• employee-level data creates privacy and re-identification risks;
• the label does not reflect the sensitivity of the information;
• there is no clear certification owner; and
• changes to the mapping spreadsheet are not governed.

Approach and solution

The organisation establishes HR as the data owner and appoints a report owner. It creates separate development and production workspaces, publishes a controlled app for managers, and uses security groups for regional access. Dynamic RLS filters records through an approved user-to-region mapping table maintained by HR and reviewed monthly.

The report is redesigned so that most users see regional aggregates. Employee-level drill-through is removed for managers and retained only for a small, authorised HR group. Export permissions are restricted. A suitable confidential sensitivity label is applied, and the report receives certification only after definitions, refresh ownership, RLS tests, and privacy review are documented.

Lineage is recorded from the HR source through the semantic model to the report. Audit logs are reviewed for unusual exports and permission changes. Managers receive guidance explaining that the dashboard supports coaching and resource planning, not automatic disciplinary decisions.

Outcome

The revised solution reduces unnecessary exposure, clarifies accountability, and makes the report more credible. Managers retain useful regional insight, while HR retains controlled access to sensitive detail. The organisation also has a repeatable governance pattern for future dashboards.

Learning points

Security is not achieved by one setting. The case required model security, workspace design, information classification, privacy-preserving presentation, ownership, audit, and ethical guidance. It also demonstrates that governance can improve usefulness: clear definitions and trusted ownership increase adoption rather than merely restricting it.

8. Implementation Checklist

Before releasing a governed Power BI product, confirm that:

• the business purpose and intended audience are documented;
• data owners and technical owners are named;
• source data is approved and appropriately classified;
• workspace roles follow least privilege;
• RLS has been tested with representative identities;
• sensitive fields and unnecessary identifiers have been removed;
• export, sharing, and subscription settings are appropriate;
• lineage, definitions, refresh schedules, and dependencies are documented;
• certification or endorsement criteria have been met;
• audit and incident-response arrangements exist; and
• ethical risks, including bias, surveillance, and potential harm, have been reviewed.

Challenges and Limitations

Power BI controls do not eliminate all risk. A legitimate viewer may take a screenshot or disclose information verbally. RLS can be misconfigured, and a security mapping table can be wrong. Sensitivity labels may not prevent all forms of copying. Lineage may omit external or manual processes. Certification may create false confidence if review is superficial. Finally, privacy and ethics depend on organisational culture, law, and human judgement as well as software configuration.

Cloud BI environments also change over time. Features, licensing requirements, administrative controls, and integration behaviour may be updated. Professionals should consult current Microsoft documentation and organisational policy before implementation. High-risk uses should receive formal security, privacy, legal, and ethical review.

Chapter Summary

Power BI governance combines technical, organisational, and ethical controls. Authentication establishes identity, authorisation determines permitted actions, and auditing provides evidence of activity. RLS restricts rows within a semantic model and may be static or dynamic; dynamic RLS commonly uses an identity-based security mapping table. Workspace roles should be assigned according to least privilege, with development and production separated where appropriate.

Privacy requires purpose limitation, data minimisation, accuracy, appropriate retention, security, and accountability. Sensitivity labels communicate and may enforce handling requirements, but they do not replace model security or responsible sharing. Governance assigns ownership, controls change, documents lineage, and uses certification to identify trusted content. Ethical BI requires attention to bias, discrimination, surveillance, transparency, and human oversight. A mature solution joins these practices into a lifecycle of design, testing, publication, monitoring, review, and retirement.

Key Terms

Authentication: Verification of a user’s identity.

Authorisation: Determination of what an authenticated user may access or do.

Auditing: Recording and reviewing activity for accountability and investigation.

Certification: Formal indication that authorised content meets defined organisational standards.

Data minimisation: Use of only the information necessary for a legitimate purpose.

Data owner: Person or function accountable for a subject area and its appropriate use.

Dynamic RLS: Row-level security that determines access using user-specific attributes.

Endorsement: Organisational indication that content is recommended or promoted.

Information classification: Categorisation of information according to sensitivity and handling requirements.

Least privilege: Granting only the access necessary for an authorised task.

Lineage: Relationships showing how data moves from sources through models to reports and other assets.

Personal data: Information relating to an identified or identifiable person.

Privacy: Appropriate control over the collection, use, disclosure, and retention of personal information.

Row-level security: A model control that restricts which data rows a user can view.

Semantic model: Structured data model containing tables, relationships, measures, and business logic for reporting.

Sensitivity label: Classification applied to content to communicate or enforce handling requirements.

Static RLS: Row-level security using a fixed filter for a role.

Workspace: Collaborative Power BI environment for developing, managing, and sharing content.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.
2. What is the purpose of row-level security?
3. State the principle of least privilege.
4. Why should a sensitivity label not be treated as a complete security control?
5. What information can lineage help a BI team understand?

Long Answer Questions

1. Explain how static and dynamic RLS differ, including one advantage and one limitation of each.
2. Describe a workspace permission strategy for separating report consumers, developers, and administrators.
3. Discuss the main privacy principles relevant to a dashboard containing employee information.
4. Explain how certification, ownership, lineage, and audit contribute to trustworthy BI.
5. Discuss why legal compliance alone may not be sufficient for ethical BI.

Analytical / Application Questions

1. A regional manager can view a national sales report and export all underlying customer records. Analyse the risks and recommend layered controls.
2. A workforce dashboard shows absence rates for teams of two or three employees. Explain the privacy and ethical risks and propose a redesigned presentation.
3. A security mapping spreadsheet has not been updated after organisational restructuring. Design a process for correcting access, testing RLS, approving changes, and monitoring future accuracy.

Multiple Choice Questions with Answers

Question 1

Which control restricts the rows of a semantic model that a user can view?

A. Row-level security

B. Workspace naming

C. Report themes

D. Dashboard bookmarks

Correct Answer: A. Row-level security

Question 2

What is the main advantage of dynamic row-level security?

A. It removes the need for authentication

B. It can use user-specific assignments to filter data

C. It automatically certifies a report

D. It prevents all exports by default

Correct Answer: B. It can use user-specific assignments to filter data

Question 3

Which principle means that users receive only the access necessary for their tasks?

A. Purpose limitation

B. Data portability

C. Least privilege

D. Data duplication

Correct Answer: C. Least privilege

Question 4

What is the primary purpose of a sensitivity label?

A. To classify information and communicate or enforce handling requirements

B. To replace all workspace permissions

C. To calculate report measures

D. To create a data relationship

Correct Answer: A. To classify information and communicate or enforce handling requirements

Question 5

Which statement best describes lineage?

A. It records employee attendance

B. It shows relationships among sources, models, reports, and downstream assets

C. It assigns users to RLS roles automatically in every environment

D. It anonymises all personal data

Correct Answer: B. It shows relationships among sources, models, reports, and downstream assets

Question 6

Why should a certified report be reviewed again periodically?

A. Certification permanently prevents changes

B. The report, sources, ownership, or security may change over time

C. Certification applies only to report colours

D. Review is needed only when a user forgets a password

Correct Answer: B. The report, sources, ownership, or security may change over time

Question 7

Which is an example of data minimisation?

A. Including every available employee field in a dashboard

B. Collecting only the fields needed for the stated analytical purpose

C. Retaining all extracts indefinitely

D. Giving all managers access to raw records

Correct Answer: B. Collecting only the fields needed for the stated analytical purpose

Question 8

A manager has permission to view a report, but RLS limits the displayed records to the manager’s region. What does this illustrate?

A. Workspace permission and data filtering operate at different levels

B. Authentication is unnecessary

C. Certification removes the need for RLS

D. Lineage automatically changes the manager’s role

Correct Answer: A. Workspace permission and data filtering operate at different levels

Question 9

Which practice best addresses re-identification risk in a small workforce group?

A. Add more personal identifiers

B. Publish individual names in tooltips

C. Aggregate or suppress results where individuals could be inferred

D. Remove all audit records

Correct Answer: C. Aggregate or suppress results where individuals could be inferred

Question 10

Which is an ethical risk of using a dashboard as the sole basis for employee discipline?

A. It may encourage automation bias and ignore context or measurement limitations

B. It guarantees fair treatment

C. It eliminates the need for human review

D. It makes data definitions unnecessary

Correct Answer: A. It may encourage automation bias and ignore context or measurement limitations