Security, Governance, Ethics and Compliance

Introduction

Business intelligence creates value by converting organisational data into information for decision-making. However, the same data may contain personally identifiable information, commercially sensitive figures, health records, financial details or information protected by law. A Power BI solution is therefore not only a collection of dashboards. It is also an information system that must control access, preserve confidentiality, support trustworthy interpretation and provide evidence of responsible use.

Security concerns whether authorised people can access data and whether unauthorised people are prevented from doing so. Governance establishes decision rights, standards, responsibilities and controls across the data lifecycle. Ethics addresses whether the collection, analysis and use of data are fair, justifiable and respectful of people. Compliance concerns conformity with laws, regulations, contractual obligations and internal policies.

These dimensions are interdependent. A technically secure report may still be unethical if it exposes sensitive information through an inappropriate aggregation. A legally compliant system may still be misleading if its visualisations conceal uncertainty or embed bias. Effective business intelligence therefore requires a combined approach involving technology, organisational processes and professional judgement.

Learning Objectives

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

1. Distinguish authentication, authorisation, row-level security and object-level security.
2. Design practical security roles in Power BI and explain their limitations.
3. Apply workspace permissions, app distribution, sensitivity labels and endorsement appropriately.
4. Explain lineage, auditing, ownership and stewardship in a governed BI environment.
5. Identify privacy, bias, transparency and responsible-AI risks in analytics.
6. Relate Power BI practices to regulatory and contractual obligations.
7. Evaluate a BI implementation and recommend proportionate governance controls.

1. A Security and Governance Model for BI

A useful governance model separates four questions:

• Who is the user? This is authentication, normally supported by an organisational identity provider.
• What may the user do? This is authorisation, such as viewing, sharing, editing or publishing content.
• Which data may the user see? This is data-level security, including row-level security (RLS).
• How should the organisation control and review the environment? This includes governance, audit, ownership, retention, classification and compliance.

Security should follow the principle of least privilege: a user receives only the access necessary to perform an approved responsibility. Least privilege reduces the impact of compromised accounts, accidental disclosure and inappropriate internal browsing. It does not mean that every user should have an individually customised permission set. Well-designed groups and roles are usually easier to administer and audit.

A practical control framework has five stages:

Security is not achieved by a single feature. It is a control system in which technical safeguards are supported by policies, training and periodic review.

2. Identity, Authentication and Authorisation

Authentication verifies identity. In a Microsoft environment this may use organisational accounts, multifactor authentication, conditional access and single sign-on. Authentication answers, “Who are you?” It does not by itself determine what the person may access.

Authorisation determines permitted actions after authentication. Examples include viewing a report, sharing a dashboard, editing a semantic model or administering a workspace. Permissions should be assigned through appropriate security groups rather than through informal individual sharing wherever possible.

Power BI workspaces commonly support role distinctions such as administrator, member, contributor and viewer. Exact capabilities depend on the service configuration and licensing, so organisations should verify current product documentation before implementation. A workspace role is not the same as an RLS role. Workspace roles govern actions on content, whereas RLS governs which rows of model data are returned to a user.

A common error is to assume that putting a user in a viewer role automatically restricts the data visible in a report. It does not. If the underlying model contains records for several regions, a viewer may see all regions unless RLS or another suitable control is implemented.

3. Row-Level Security

Row-level security restricts the rows returned from a semantic model according to the user’s role or identity. For example, regional managers may see only transactions belonging to their assigned region, while a corporate analyst may see all regions.

3.1 Static RLS

Static RLS defines a fixed filter for a role. A role called WestRegion might filter a Region column to “West”. This is simple and suitable where the number of stable groups is small. Its weakness is administrative effort: every change in regional membership may require role maintenance.

3.2 Dynamic RLS

Dynamic RLS uses the identity of the current user to retrieve permitted values from a security mapping table. A typical model contains:

• a business table, such as Sales;
• a dimension, such as Region;
• a security table linking user identifiers to permitted regions;
• relationships that allow the filter to propagate correctly.

A DAX expression may use USERPRINCIPALNAME() or an equivalent identity function to match the signed-in user to the security table. The exact identity value must be tested because it may differ between development and production environments.

A simplified conceptual relationship is:

Current user → Security table → Region dimension → Sales fact table

The security table should be maintained as controlled reference data, not as an ad hoc spreadsheet owned by one analyst. It should contain unique and valid mappings, documented identifiers and an approved change process.

3.3 RLS design risks

Important risks include:

• testing only with an administrator account, which may bypass or behave differently from ordinary users;
• incorrect relationship direction, causing filters not to propagate;
• duplicate or missing identity mappings;
• exporting or analysing data through another route that was not included in the design;
• totals and small groups revealing information indirectly;
• assuming that RLS protects data in every downstream copy or source system.

RLS should be tested using representative accounts: a user with one region, a user with multiple regions, a user with no mapping and an authorised enterprise user. Tests should confirm both permitted and prohibited records.

4. Object-Level Security and Information Exposure

Object-level security (OLS) restricts access to model objects such as tables, columns or measures. It is appropriate when different audiences must use the same model but should not even be able to query particular fields. For example, a workforce report may expose headcount but hide individual salary columns from general managers.

RLS answers “which rows?” OLS answers “which objects?” They may be combined. A finance analyst could see all rows but not a confidential acquisition table; a regional manager could see selected rows but only approved columns.

OLS must not be confused with merely hiding a field from a report visual. Hiding a column in a visual does not necessarily prevent a user with model access from querying or exporting it. Sensitive objects should be protected at the semantic-model security layer, and the result should be tested through the actual user experience.

Security also includes indirect disclosure. A report may not show salary directly, yet a small group’s average salary could permit an individual value to be inferred. Suppression thresholds, aggregation rules and careful export controls may be necessary.

5. Permissions, Sharing and Deployment

A governed Power BI environment distinguishes development, test and production. Developers should not normally alter production content without review. Deployment pipelines or equivalent release controls can support separation of duties, version traceability and rollback.

Recommended practices include:

1. Use groups for access assignment.
2. Separate content authors, approvers and consumers where practical.
3. Publish certified or approved content through managed apps rather than distributing many independent report links.
4. Review sharing permissions and external-access settings regularly.
5. Disable or restrict download, export and reshare functions where the data risk justifies it.
6. Document owners, sources, refresh schedules and intended audiences.
7. Remove access promptly when a person changes role or leaves the organisation.

A user who can edit a report may be able to change its filters, measures or interpretation. Therefore, edit permission is substantially more powerful than view permission. A report’s audience and its authorship group should be deliberately designed rather than allowed to grow informally.

6. Sensitivity Labels and Data Classification

Sensitivity labels communicate how information should be handled. A simple classification scheme might include Public, Internal, Confidential and Highly Confidential. Labels should be linked to handling rules, not treated as decorative tags.

A label can help users understand whether a report may be emailed, downloaded, printed or shared externally. In Microsoft Purview-integrated environments, labels may support protection mechanisms such as encryption and policy-based controls, subject to licensing and configuration. Labels do not replace RLS: a label can classify an entire item, whereas RLS restricts records for particular users.

Classification should occur at the source and be reviewed when content changes. A report based on public sales totals may become confidential when a new page includes customer-level detail. Classification decisions should consider:

• identifiability of individuals;
• commercial sensitivity;
• legal restrictions;
• consequences of unauthorised disclosure;
• retention and deletion requirements;
• whether combining apparently harmless fields creates sensitive information.

7. Lineage, Ownership and Endorsement

Data lineage describes the path from an original source through transformations, semantic models and reports to final consumption. Lineage helps an analyst answer: What source produced this number? Which reports will be affected if a field changes? Which datasets depend on a sensitive table?

Lineage is valuable for impact analysis, incident response, migration and regulatory inquiry. It is not necessarily a complete record of every transformation, especially when data passes through external tools, manual files or undocumented steps. Organisations should supplement automated lineage with data dictionaries and process documentation.

Ownership assigns accountability for a data asset. A business owner determines purpose and acceptable use; a technical owner supports operation; a data steward maintains definitions, quality and access rules. Ownership should be explicit, current and accepted by the responsible person.

Endorsement helps users distinguish trusted content from experimental content. Common governance concepts include promoted content, which has been identified as useful by a responsible creator, and certified content, which has passed a stronger organisational approval process. Endorsement does not guarantee that every number is correct. It signals that defined review criteria have been applied.

A useful endorsement checklist asks:

• Is the business definition documented?
• Are source systems identified?
• Are calculations and exclusions explained?
• Has security been tested?
• Is refresh reliability acceptable?
• Has a business owner approved the content?
• Is the report still current?

8. Auditing, Monitoring and Incident Response

Auditing records activity such as access, sharing, publishing, changes and exports, subject to the capabilities and configuration of the organisation’s platform. Audit data should have a defined purpose, appropriate retention and restricted access because audit records may themselves contain sensitive information.

Monitoring should combine technical and business indicators. Examples include unusual download volume, access from unexpected locations, repeated failed access attempts, sudden changes to security roles and publication of unapproved reports. An alert is not proof of misconduct; it is a prompt for investigation.

An incident process should define:

1. detection and initial triage;
2. containment, such as disabling sharing or access;
3. preservation of evidence;
4. assessment of affected data and people;
5. notification according to law and policy;
6. remediation and restoration;
7. a documented lessons-learned review.

Audit logs should not be collected merely because they are available. The organisation should define who reviews them, how often, what constitutes an escalation and how false positives are handled.

9. Privacy and Regulatory Compliance

Privacy is concerned with appropriate collection, use, disclosure and retention of information about identifiable people. Core principles found in many privacy regimes include purpose limitation, data minimisation, accuracy, security, accountability and limited retention. Specific legal duties vary by jurisdiction and should be assessed with qualified legal or privacy professionals.

A BI team should identify whether it processes personal data, sensitive personal data, employee data, customer data or data transferred across borders. Relevant obligations may arise from instruments such as the General Data Protection Regulation, sector-specific health or financial rules, employment law, contractual confidentiality and national data-protection legislation. Compliance cannot be inferred from the use of Power BI alone.

Practical privacy controls include:

• collect only fields needed for the stated analytical purpose;
• use pseudonymisation or aggregation where individual identity is unnecessary;
• define retention and deletion processes;
• document lawful basis or organisational authority where applicable;
• restrict access and exports;
• assess data-processing arrangements and international transfers;
• provide transparency notices where required;
• conduct a privacy impact assessment for high-risk processing.

Pseudonymisation reduces direct identification but does not necessarily make data anonymous. If a person can be reidentified by combining the pseudonymised data with another dataset, privacy obligations may remain.

10. Ethics, Bias and Transparency

Ethical analytics asks not only whether an analysis is technically possible, but whether it is justified and fair. Important questions include:

• Who benefits and who may be harmed?
• Were affected groups represented in the data?
• Is the use consistent with reasonable expectations?
• Can a decision be explained or challenged?
• Are errors distributed unevenly across groups?
• Has the organisation confused correlation with causation?

Bias can enter through historical decisions, under-representation, measurement choices, missing data, proxy variables or the way outcomes are labelled. For instance, using postcode as a predictor may act as a proxy for socioeconomic status or ethnicity. Removing a protected attribute does not guarantee fairness if correlated variables remain.

Transparency requires documentation of data sources, definitions, transformations, limitations and intended uses. A dashboard should not create false certainty through truncated axes, inappropriate visual encodings or unexplained benchmarks. Decision-makers should know whether a metric is a count, rate, estimate, forecast or target.

Responsible AI governance extends these concerns to predictive and generative features. Before deploying an AI-assisted insight, an organisation should define human accountability, evaluate accuracy and disparate impact, protect confidential prompts and data, record model limitations and provide a route for review or appeal. Human oversight must be meaningful: merely placing a human somewhere in the process does not correct an opaque or systematically biased system.

11. Data Ownership and Stewardship

Data ownership is an accountability arrangement, not a claim that an individual personally owns information about other people. The owner typically decides business purpose, access policy, quality thresholds and acceptable risk. Stewards implement standards, maintain definitions and coordinate issue resolution.

A data dictionary should define terms such as “active customer,” “net revenue” and “on-time delivery.” Without shared definitions, two technically accurate reports may produce conflicting results. Governance should also record the authoritative source, update frequency, quality checks and known limitations.

Data quality may be considered across dimensions such as accuracy, completeness, consistency, timeliness, validity and uniqueness. These dimensions are managerial controls rather than merely technical properties. A dashboard with excellent visual design cannot compensate for an unreliable source or ambiguous definition.

12. Illustrative Case: Regional Workforce Analytics

Background

A fictional organisation, Northstar Services, develops a Power BI workforce dashboard for managers. The model contains employee identifiers, department, location, salary band, absence data and training records.

Problem

The first prototype gives all managers access to a single report. Although the salary column is not displayed, users can export underlying data from a table visual. The regional filter is a report-level filter rather than security, so a manager can remove it and view other regions. Definitions of “absence rate” differ between HR and Finance.

Analysis

The risks are unauthorised disclosure, inappropriate inference about individuals, weak governance and inconsistent decision-making. The report also creates an ethical risk if managers use absence data to judge employees without considering disability, caring responsibilities or data quality.

Approach and solution

Northstar assigns a business owner in HR and a technical owner in the BI team. A security mapping table links approved manager identities to regions. Dynamic RLS restricts records, while OLS hides individual salary and sensitive absence-detail objects from general managers. A separate HR analyst role has broader access subject to approval.

The organisation replaces individual sharing with security groups, publishes the approved report through a managed app and restricts export features. A sensitivity label marks the report Confidential. The data dictionary defines absence rate, its denominator and the reporting period. A certified version is published only after security testing, reconciliation with HR records and approval by the data owner.

Audit reviews are scheduled monthly, with immediate investigation of unusual exports. The report includes a warning that absence statistics should not be used as an automated disciplinary decision. Aggregation and minimum-group rules reduce the risk of identifying individuals in small teams.

Outcome

Managers receive regionally relevant information without access to unrelated employee records. HR retains an approved route for detailed analysis, and users can identify the authoritative definition of each measure. Remaining risks are documented, including the possibility of bias in interpreting absence data and the need to review access when managers change roles.

Learning points

1. A visual filter is not a substitute for RLS.
2. Data minimisation and OLS can reduce exposure even for authorised users.
3. Governance requires ownership, definitions, testing and review.
4. Ethical use depends on context and interpretation, not only technical access.

13. Implementation Checklist

Before releasing a governed Power BI solution, confirm that:

• data sources and owners are documented;
• classification and retention requirements are known;
• workspace and app permissions use approved groups;
• RLS and OLS are designed and tested with representative accounts;
• export, sharing and external-access settings are appropriate;
• measures and business definitions are documented;
• lineage is available and material dependencies are understood;
• endorsement criteria have been met;
• audit and incident procedures are operational;
• privacy, bias and responsible-AI assessments are completed where relevant;
• users receive guidance on interpretation and acceptable use;
• access and content are scheduled for periodic review.

Challenges and Limitations

No security control is perfect. RLS may be undermined by poorly governed extracts, screenshots or downstream copies. Labels may be ignored if users do not understand them. Lineage may be incomplete when manual files and external transformations are involved. Audit logs can demonstrate activity but cannot always establish intent. Certification can create false confidence if review is performed once and never renewed.

Governance also creates costs. Excessive approval delays may encourage shadow reporting, while excessively permissive access increases risk. The appropriate design is proportionate: high-risk personal or strategic data requires stronger controls than genuinely public information. Controls should be reviewed as data, technology, law and organisational responsibilities change.

Chapter Summary

Security, governance, ethics and compliance are essential components of professional business intelligence. Authentication establishes identity, authorisation controls actions, RLS limits rows and OLS limits tables, columns or measures. Workspace permissions, managed apps, groups and deployment controls support separation of duties and controlled publication.

Sensitivity labels classify information and may support protective policies, while lineage explains dependencies across sources, models and reports. Ownership, stewardship and endorsement create accountability and help users identify trusted content. Auditing and monitoring provide evidence of access and change, but must be supported by incident-response procedures.

Privacy requires appropriate purpose, minimisation, security, retention and transparency. Ethical practice also requires attention to bias, indirect disclosure, explainability and the consequences of decisions. Responsible AI governance adds human accountability, testing, documentation and appeal mechanisms. Effective Power BI governance is therefore a continuous organisational process rather than a one-time technical configuration.

Key Terms

Authentication: Verification of a user’s identity.

Authorisation: Determination of what an authenticated user may do.

Business owner: Person accountable for the purpose, policy and acceptable use of a data asset.

Data lineage: Record of how data moves from source systems through transformations to reports and users.

Data minimisation: Collecting and using no more personal data than the purpose requires.

Data steward: Person responsible for maintaining data definitions, quality and operational governance.

Endorsement: Organisational indication that content has received a defined level of review or approval.

Least privilege: Providing only the access necessary for an approved responsibility.

Object-level security: Restriction of access to model tables, columns or other objects.

Pseudonymisation: Replacing direct identifiers while retaining a possibility of reidentification.

Row-level security: Restriction of records returned to a user according to role or identity.

Sensitivity label: Classification indicating how information should be handled and protected.

Transparency: Clear communication of sources, methods, definitions, limitations and intended uses.

Audit log: Record of relevant actions such as access, sharing, publishing or exporting.

Privacy impact assessment: Structured evaluation of privacy risks and safeguards for a proposed processing activity.

Responsible AI: Governance ensuring that AI is accountable, secure, fair, explainable and appropriately supervised.

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

Separation of duties: Division of responsibilities so that one person cannot improperly control an entire process.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.
2. What is the difference between RLS and OLS?
3. Why is a report-level filter not an adequate substitute for RLS?
4. What purpose does data lineage serve?
5. State two principles of privacy-conscious BI design.

Long Answer Questions

1. Explain how groups, workspace permissions, managed apps and deployment controls can support least privilege.
2. Describe the design and testing process for dynamic RLS.
3. Discuss how sensitivity labels, endorsement and ownership contribute to trustworthy BI.
4. Explain how bias can enter an analytics solution and propose controls to reduce it.
5. Evaluate the role of auditing and incident response in a governed Power BI environment.

Analytical / Application Questions

1. A regional manager can remove a report filter and view another region’s customers. Diagnose the control failure and recommend a secure redesign.
2. A dashboard reports absence rates for teams of three employees. Identify privacy and ethical risks and propose changes to the model and presentation.
3. An AI-generated insight recommends denying training opportunities to a group based on historical performance. Assess the governance issues and specify the checks required before any decision is made.

Multiple Choice Questions with Answers

Question 1

Which control restricts the rows returned to a user according to their role or identity?

A. Sensitivity labelling

B. Row-level security

C. Data lineage

D. Endorsement

Correct Answer: B. Row-level security

Question 2

What is the main purpose of object-level security?

A. To schedule data refreshes

B. To certify a report

C. To restrict access to tables, columns or measures

D. To record user activity

Correct Answer: C. To restrict access to tables, columns or measures

Question 3

Which principle gives users only the access necessary for their approved responsibilities?

A. Data minimisation

B. Least privilege

C. Purpose limitation

D. Open access

Correct Answer: B. Least privilege

Question 4

Why is hiding a sensitive column from a visual insufficient by itself?

A. It prevents all report filtering

B. It may not prevent querying or exporting the underlying object

C. It automatically deletes the source column

D. It disables data refresh

Correct Answer: B. It may not prevent querying or exporting the underlying object

Question 5

Which item best describes data lineage?

A. A list of user passwords

B. A record of the path from data source to report consumption

C. A method for encrypting a workspace

D. A measure of dashboard colour quality

Correct Answer: B. A record of the path from data source to report consumption

Question 6

What is the principal purpose of a sensitivity label?

A. To classify information and communicate or enforce handling requirements

B. To replace all security roles

C. To calculate a measure

D. To remove duplicate rows

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

Question 7

Which practice most directly supports controlled publication of trusted content?

A. Allowing unrestricted individual sharing

B. Publishing an approved report through a managed app

C. Removing report documentation

D. Testing only with an administrator account

Correct Answer: B. Publishing an approved report through a managed app

Question 8

Why can pseudonymised data still require privacy protection?

A. Pseudonyms always reveal names directly

B. Pseudonymised data cannot be stored

C. Individuals may be reidentified by combining it with other information

D. Pseudonymisation automatically makes data public

Correct Answer: C. Individuals may be reidentified by combining it with other information

Question 9

Which situation is an example of indirect disclosure?

A. A report displays a public annual total

B. A small group’s average allows an individual salary to be inferred

C. A report contains a documented data dictionary

D. A user signs in with multifactor authentication

Correct Answer: B. A small group’s average allows an individual salary to be inferred

Question 10

What is a central requirement of responsible AI governance?

A. Removing human accountability

B. Using historical data without evaluation

C. Providing oversight, documentation and routes for review or challenge

D. Hiding model limitations from users

Correct Answer: C. Providing oversight, documentation and routes for review or challenge