Security, Governance and Ethical Analytics

Introduction

A dashboard is not merely a visual display of data. It is an information system that influences decisions, allocates resources, evaluates people and may expose confidential information. In Power BI, effective analytics therefore requires more than building attractive charts. It requires controls that determine who may access data, which data they may see, how information is classified, how changes are monitored and whether analytical conclusions are ethically defensible.

Security, governance and ethics are related but distinct. Security protects data and services from unauthorised access or misuse. Governance establishes decision rights, policies, standards and accountability for managing data and analytics. Ethical analytics asks whether data is collected, analysed and used in ways that respect people, avoid unjustified harm and support responsible decisions.

This chapter presents a practical framework for applying these principles in a Power BI environment. It focuses on row-level security (RLS), object-level security (OLS), permissions, sensitivity labels, classification, lineage, audit controls, governance roles, privacy, consent, fairness, transparency and responsible dashboard use.

Learning Objectives

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

1. Explain the relationship between security, governance and ethical analytics.
2. Design and test row-level and object-level security in Power BI.
3. Distinguish workspace roles, item permissions, app access and data-source permissions.
4. Apply sensitivity labels and data-classification principles appropriately.
5. Use lineage, impact analysis and audit information to govern analytical assets.
6. Describe the responsibilities of data owners, stewards, custodians, analysts and reviewers.
7. Evaluate privacy, consent, fairness, transparency and responsible-use risks.
8. Recommend practical controls for trustworthy dashboards.

1. The Governance Context of Business Intelligence

Business intelligence creates value by converting operational data into information for decisions. The same process can create risks. A sales dashboard may reveal customer identities; a workforce dashboard may expose health-related information; a profitability report may disclose commercially sensitive prices. A poorly governed dashboard can also encourage users to treat estimates as facts or use a performance measure for a purpose for which it was never designed.

A useful governance model contains four layers:

These layers should reinforce one another. Technical access controls cannot correct an unethical purpose, and an ethical policy is ineffective if users can freely export confidential data.

The principle of least privilege

The principle of least privilege states that a person or system should receive only the access necessary to perform an authorised task. It limits the consequences of compromised accounts, accidental disclosure and inappropriate curiosity. Least privilege should be applied to workspaces, reports, semantic models, data sources, export functions and administrative operations—not only to the dashboard itself.

Separation of duties

Separation of duties prevents one person from controlling every stage of a sensitive process. For example, an analyst may develop a report, a data owner may approve its business definition, and a platform administrator may publish it. This reduces the possibility that an individual can create, approve and conceal an inappropriate change.

2. Identity, Permissions and the Power BI Security Model

Power BI security is layered. A user may have permission to open a report but still be unable to see some rows. Conversely, a user may be excluded from a workspace but receive access through a published app. Effective design therefore requires an access matrix rather than assumptions based on a single setting.

2.1 Common permission layers

1. Identity and group membership: Authentication establishes who the user is. Security groups are generally preferable to assigning many individual users because membership can be reviewed centrally.
2. Workspace roles: Roles commonly distinguish administrative control, editing, contribution and viewing. The exact capabilities depend on the service configuration and licensing model.
3. Item permissions: A report, dashboard, semantic model or dataflow may have direct permissions that differ from workspace membership.
4. App audiences: A published app can expose selected content to defined audiences without granting broad workspace editing rights.
5. Data-source permissions: Gateways, databases, files and cloud services have their own authorisation rules.
6. Semantic-model security: RLS and OLS restrict what is visible within the model.
7. Export and sharing controls: Users may be able to export summarised or underlying data, share links, subscribe to reports or connect through other tools. These capabilities require explicit governance.

A sound access review asks: Who is the user? Which group grants access? Which item is accessible? What data can be seen? Can it be exported? What evidence records the decision?

3. Row-Level Security

3.1 Concept

Row-level security restricts records according to the identity or role of the viewer. A regional manager may see transactions for one region, while a national manager may see all regions. RLS is implemented in the semantic model, usually through roles and filters.

A static role uses a fixed filter, such as Region = “North”. A dynamic role uses the signed-in identity to retrieve permitted values from a security mapping table. Dynamic RLS is more scalable when users and organisational assignments change frequently.

3.2 A recommended model pattern

A robust pattern separates business data from security mappings:

• Fact table: transactions, sales or service events.
• Dimension table: regions, departments or business units.
• User-access table: user identifier, permitted region and possibly access level.
• Relationships: the access table filters the relevant dimension, which filters the fact table.

The user-access table should be maintained as governed data, not as an informal spreadsheet owned by an individual analyst.

A conceptual dynamic filter can be expressed as:

Here, USERPRINCIPALNAME() represents the identity supplied by the Power BI service, and UserAccess[UserEmail] is the authorised identity column. The expression is meaningful only if identities are normalised consistently and the mapping table is correctly related to the model.

3.3 Static and dynamic RLS

3.4 Implementation and testing sequence

1. Identify the business boundary: region, department, client or legal entity.
2. Define the data owner and the approved access rule.
3. Build a security mapping table with unique, validated identities.
4. Establish relationships that propagate filters correctly.
5. Create roles and apply filters in the semantic model.
6. Publish to a controlled workspace.
7. Assign groups to roles in the service.
8. Test each role using representative accounts.
9. Test boundary cases, such as a user with two regions or no assigned region.
10. Review export, drill-through and connected-experience behaviour.
11. Document the rule, owner, test evidence and review date.

3.5 Common RLS failures

RLS may fail when a relationship is inactive, filtering is blocked by an incorrect model design, identities differ in capitalisation or format, a user belongs to an overly broad role, or an administrator has elevated rights that bypass ordinary viewing restrictions. RLS also does not automatically protect copies exported by an authorised user. Therefore, it is a viewing control, not a complete data-loss-prevention strategy.

4. Object-Level Security

Object-level security restricts access to model objects such as tables and columns. It is appropriate when a user should receive a report but must not see particular fields—for example, salary, national identification number, clinical notes or confidential pricing.

OLS is different from hiding a field in the report interface. A hidden visual or hidden field is not necessarily protected; users may still discover data through other queries or connected tools. OLS must be applied in the semantic model and tested with the relevant identity.

RLS answers, “Which rows may this user see?” OLS answers, “Which tables or columns may this user query or discover?” Both may be required. A manager could be permitted to see all departmental rows through RLS while being denied access to an employee’s personal contact column through OLS.

A practical design principle is to avoid placing highly sensitive attributes in a widely shared model unless they are genuinely required. OLS is valuable, but reducing unnecessary data collection and modelling is often safer than relying on a complex restriction.

5. Sensitivity Labels and Data Classification

5.1 Classification as a decision tool

Data classification describes the harm that could result from inappropriate disclosure, alteration or loss. A simple classification scheme may include:

Labels should be based on the information and its context, not on the visual attractiveness of the report. A dashboard containing aggregated figures may still be sensitive if small groups can be re-identified.

5.2 Sensitivity labels

Sensitivity labels can communicate classification and support protective controls across reports, semantic models and exported content, depending on the organisation’s licensing, configuration and information-protection capabilities. A label is not a substitute for permissions, RLS, OLS or secure source systems. It should be applied consistently, inherited where supported and reviewed when content is transformed or combined.

5.3 Personal and sensitive data

Personal data is information relating to an identified or identifiable person. Sensitive categories vary by jurisdiction but may include health, biometric, financial, racial or political information. Analysts should apply data minimisation: collect, retain and expose only what is necessary for the stated purpose.

Aggregation does not automatically make data anonymous. A report showing one employee in a small team, or a rare condition in a small geographic area, may permit inference. Suppression thresholds, grouping, perturbation or removal of attributes may be required, subject to legal and analytical requirements.

6. Lineage, Impact Analysis and Auditability

6.1 Lineage

Lineage records the path from source data through transformations and semantic models to reports, dashboards and downstream outputs. It helps answer:

• Where did this metric originate?
• Which reports depend on this dataflow or model?
• What may break if a column is renamed?
• Which business process produced the source value?

Lineage is essential for change management and incident response. It also supports transparency by allowing a reviewer to understand how a reported number was produced.

6.2 Impact analysis

Before changing a field, measure or relationship, an analyst should identify dependent reports and critical consumers. The change should be classified by risk. A formatting change may need ordinary review; changing the definition of “active customer” may require owner approval, communication and regression testing.

6.3 Audit controls

Audit information can record events such as report access, sharing, export, publication, permission changes and administrative actions, subject to the organisation’s platform configuration and retention arrangements. Audit controls should answer five questions:

1. What event occurred?
2. Who performed it?
3. Which asset was affected?
4. When did it occur?
5. Was the event authorised and appropriately handled?

Audit data itself may contain personal information and must be protected. Monitoring should be proportionate: the purpose is accountability and risk detection, not unjustified surveillance.

A governance team should define alert conditions, such as repeated failed access attempts, unusual bulk exports, sharing of restricted reports or changes to security roles. Alerts require an investigation process; collecting logs without ownership creates little protection.

7. Governance Roles and Operating Model

Governance becomes practical when responsibilities are assigned.

A responsibility assignment matrix can clarify who is responsible, accountable, consulted and informed for activities such as model publication, RLS approval, incident response and metric definition. Governance should be risk-based: a financial-regulatory report deserves stronger review than an internal exploratory analysis.

8. Privacy, Consent and Lawful Use

Privacy is not simply secrecy. It concerns appropriate collection, use, disclosure, retention and control of information about people. A responsible analytics process should document:

• the purpose for collecting data;
• the lawful or organisational basis for processing;
• the minimum data required;
• retention and deletion requirements;
• who may access the information;
• whether individuals were informed;
• how correction, objection or access requests are handled where applicable.

Consent, where used, should be informed, specific and freely given rather than hidden in a general statement. Consent for service delivery does not automatically authorise unrelated employee profiling or marketing analysis. In some situations, another lawful basis may apply, but this requires competent legal and organisational advice.

Privacy impact assessment is appropriate when analytics involves sensitive data, systematic monitoring, vulnerable groups, large-scale profiling or automated decisions with significant effects. Analysts should not infer that a technically possible use is an authorised use.

9. Fairness, Transparency and Human Oversight

9.1 Fairness

A dashboard may reproduce bias present in historical data, institutional processes or the choice of metric. For example, measuring employee performance only through recorded activity may disadvantage staff whose work is collaborative or less digitally visible.

Fairness is context-dependent. Different definitions may conflict. Demographic parity, for example, compares selection rates across groups, whereas equal opportunity compares true-positive rates among people who meet a criterion. Neither definition is universally correct, and satisfying one may not satisfy another. Ethical review must therefore consider the decision, affected groups, legitimate business purpose and consequences.

Useful review questions include:

• Are some groups missing or under-represented in the data?
• Are categories defined consistently?
• Does the measure reflect opportunity as well as outcome?
• Could a proxy variable reproduce a protected characteristic?
• Are errors more harmful for one group?
• Is there a process for challenge and correction?

9.2 Transparency

Users should be able to understand the purpose of a dashboard, the meaning of important measures, the period covered, data limitations and the responsible owner. A useful report includes definitions, refresh information, caveats and contact details. Technical complexity does not remove the duty to explain decisions in accessible language.

9.3 Human oversight

A dashboard should support judgement, not silently replace it in high-impact decisions. Where analytics informs employment, credit, healthcare, education or access to services, a qualified person should review relevant context, challenge anomalous outputs and provide a route for appeal. “The dashboard said so” is not an adequate accountability statement.

10. Responsible Dashboard Design

Responsible design combines security with interpretive clarity.

Recommended practices include:

• show the reporting period and refresh status;
• distinguish actuals, forecasts, targets and estimates;
• define measures in plain language;
• avoid unnecessary personal detail;
• use aggregation and suppression for small groups where appropriate;
• avoid misleading axes, selective time windows and decorative distortion;
• show uncertainty or limitations when they affect decisions;
• use accessible colour, labels and alternative text;
• prevent unauthorised export and sharing;
• provide a clear owner and escalation route;
• test with users from different roles and abilities.

A dashboard may be technically accurate yet ethically misleading if it presents a partial denominator, hides missing data or encourages ranking people without context. Visual design is therefore part of governance, not merely aesthetics.

11. Applied Case: Northstar Retail Group

The following is an illustrative case.

Background

Northstar Retail Group operates stores in four regions. Its Power BI sales app is used by store managers, regional directors, finance staff and executives. The organisation plans to add employee productivity and customer-service data.

Problem

The initial prototype placed all transactions and employee details in one shared model. Managers could export underlying data, regional boundaries were maintained manually in report filters, and the definition of “service productivity” was not documented. A small store could be identified from a chart even when customer complaints were very few. Executives also received reports through uncontrolled personal sharing links.

Analysis

The risks were not limited to unauthorised access. The prototype created privacy, inference, fairness and interpretation risks. Manual filters were not reliable security controls. The productivity measure rewarded short handling time but ignored complaint complexity, potentially disadvantaging employees who handled difficult cases.

Approach and solution

Northstar adopted the following design:

1. A governed user-access table mapped organisational identities to permitted regions.
2. Dynamic RLS filtered regional data through the region dimension.
3. OLS excluded personal contact and disciplinary columns from the management model.
4. Employee-level analysis was restricted to authorised HR users and separated from general sales reporting.
5. Reports were classified as Internal or Confidential, with export and sharing reviewed by the platform administrator.
6. Lineage documentation identified source systems, transformations, measures and dependent reports.
7. A data owner approved metric definitions, while a privacy adviser reviewed the employee and complaint data.
8. Complaint counts below an agreed minimum were grouped or suppressed to reduce re-identification risk.
9. The productivity metric was redesigned to include case complexity and was labelled as an indicator rather than a definitive measure of employee value.
10. A dashboard note explained purpose, limitations, refresh timing and the process for challenging an anomalous result.
11. Audit reviews examined role changes, exports and unusual sharing activity.

Outcome

The revised solution reduced unnecessary exposure and made responsibilities clearer. Managers could view authorised regional summaries without seeing restricted personal fields. HR retained a separate controlled analysis for legitimate workforce purposes. The organisation also discovered that several historical measures were not comparable because source definitions had changed; this was documented rather than concealed.

Learning points

The case demonstrates that security controls, data modelling, privacy review and metric design must be considered together. RLS did not solve the problem alone. Governance improved when ownership, lineage, classification, audit and review processes were connected to the technical implementation.

12. Implementation Checklist

Before publishing a governed dashboard, confirm that:

• the purpose and intended audience are documented;
• data sources and owners are known;
• classification and sensitivity labels are appropriate;
• RLS and OLS have been designed where necessary;
• role testing includes normal and exceptional users;
• workspace, app, item and source permissions are consistent;
• export, sharing and subscription behaviour has been reviewed;
• measures, assumptions and limitations are documented;
• privacy, consent and retention issues are addressed;
• fairness and accessibility have been considered;
• lineage and impact information are available;
• an audit and incident-response process exists;
• a review date and accountable owner are recorded.

13. Challenges and Limitations

No single control guarantees trustworthy analytics. RLS can be misconfigured, OLS may not cover copied data, labels may be ignored, and audit logs may be incomplete or retained for too short a period. Identity data can become stale when employees change roles. Aggregation can still permit inference. Fairness cannot be established by one statistical test alone, and transparency may be difficult when complex models contribute to a result.

Governance can also become excessive. If approval processes are slow, users may create shadow spreadsheets and unapproved reports. Effective governance should therefore be proportional, automated where possible and designed with users. Standards should protect people and information while enabling legitimate analysis.

14. Contemporary Developments

Cloud analytics increasingly connects dashboards to data products, automated pipelines, generative AI assistants and natural-language interfaces. These capabilities can improve productivity but introduce additional risks: an assistant may expose information through an inappropriate prompt, generate an incorrect explanation or make a sensitive attribute easier to discover. Organisations should apply existing permissions to AI experiences, record significant generated content where appropriate, validate outputs and prohibit confidential data from being entered into unauthorised tools.

Data governance is also moving toward product-oriented ownership, where a business domain is accountable for the quality, meaning, security and usability of its data products. This approach can improve accountability, but it requires clear interfaces, common standards and active stewardship.

Chapter Summary

Security, governance and ethical analytics are complementary requirements for professional Power BI practice. Permissions operate across identities, workspaces, apps, items, data sources and semantic models. Row-level security limits the records a user can see, while object-level security limits the tables or columns they can access. Both must be designed, tested and documented.

Sensitivity labels and classification communicate risk and can support protective controls, but they do not replace technical permissions. Lineage and impact analysis explain how data moves through the analytical environment and help manage change. Audit controls provide evidence of access and administrative activity, while governance roles assign accountability.

Responsible analytics requires purpose limitation, data minimisation, appropriate consent or lawful use, protection against re-identification, fairness review, transparency and human oversight. A trustworthy dashboard is therefore not only accurate and available; it is appropriately restricted, explainable, usable, reviewable and aligned with legitimate organisational objectives.

Key Terms

Security: Protection of information and systems from unauthorised access, alteration or disclosure.

Governance: Policies, decision rights, standards and accountability for managing data and analytics.

Ethical analytics: Analytics conducted with attention to rights, fairness, harm, transparency and responsibility.

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

Separation of duties: Dividing responsibilities so one person cannot control all critical stages.

Row-level security (RLS): A control that restricts which records a user can view.

Object-level security (OLS): A control that restricts access to model tables or columns.

Static RLS: RLS based on fixed role filters.

Dynamic RLS: RLS based on the identity of the signed-in user and an access mapping.

Sensitivity label: A classification marker that communicates information-protection requirements.

Data classification: Categorisation of information according to sensitivity and potential harm.

Data minimisation: Collecting and exposing only information necessary for a stated purpose.

Lineage: The documented path from source data through transformations to analytical outputs.

Impact analysis: Examination of assets and processes affected by a proposed change.

Audit control: A mechanism for recording and reviewing relevant activities and events.

Data owner: The person accountable for permitted use, meaning and access decisions.

Data steward: The person responsible for metadata, definitions and quality practices.

Fairness: The context-dependent principle that analytical processes should not create unjustified disadvantage.

Transparency: The provision of understandable information about purpose, data, measures and limitations.

Human oversight: Qualified review and accountability for decisions informed by analytics.

Review Questions

Short Answer Questions

1. What is the difference between row-level security and object-level security?
2. Why is least privilege important in a Power BI environment?
3. What information can lineage help an analyst discover?
4. Why does aggregation not always guarantee anonymity?
5. State two responsibilities of a data steward.

Long Answer Questions

1. Explain how workspace roles, app access, item permissions and semantic-model security interact.
2. Describe a complete process for designing and testing dynamic RLS.
3. Discuss the relationship between data classification, sensitivity labels and technical controls.
4. Explain how privacy, fairness and transparency influence dashboard design.
5. Evaluate the governance roles needed to operate a trustworthy analytics environment.

Analytical / Application Questions

1. A regional manager can view the correct rows but can export employee contact details from the same model. Diagnose the control weakness and propose a revised design.
2. A performance dashboard ranks support employees using average handling time only. Analyse two possible fairness risks and recommend improved measures or safeguards.
3. A report is shared with a broad audience after a measure definition changes. Design an impact-analysis, communication and audit process for managing the change.

Multiple Choice Questions with Answers

Question 1

Which control restricts the records visible to a user while leaving the model structure generally available?

A. Row-level security

B. Object-level security

C. Sensitivity labelling

D. Lineage tracking

Correct Answer: A. Row-level security

Question 2

Which design is most suitable for regional access that changes as employees move between regions?

A. A separate report for every employee

B. Dynamic RLS using an identity-to-region mapping table

C. A visual filter applied by each user

D. A public report with regional slicers

Correct Answer: B. Dynamic RLS using an identity-to-region mapping table

Question 3

What is the main purpose of object-level security?

A. To record report refresh times

B. To classify a report as confidential

C. To restrict access to tables or columns

D. To identify downstream reports

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

Question 4

Which principle requires users to receive only the access necessary for their authorised work?

A. Data portability

B. Least privilege

C. Open publication

D. Maximum disclosure

Correct Answer: B. Least privilege

Question 5

Why is a hidden column not necessarily a sufficient protection for sensitive data?

A. Hidden columns always prevent report refresh

B. Users may still access the data through other interfaces or queries

C. Hidden columns automatically become public

D. Hidden columns cannot contain text

Correct Answer: B. Users may still access the data through other interfaces or queries

Question 6

Which governance artefact shows how source data flows into reports and dashboards?

A. Lineage information

B. A colour palette

C. A user survey

D. A workspace theme

Correct Answer: A. Lineage information

Question 7

Which statement about sensitivity labels is most accurate?

A. They replace all permissions and security roles

B. They are only useful for public reports

C. They communicate classification and may support protective controls

D. They guarantee that exported data cannot be copied

Correct Answer: C. They communicate classification and may support protective controls

Question 8

A dashboard reveals the identity of individuals in a very small subgroup. Which risk is most directly involved?

A. Re-identification or inference

B. Database indexing

C. Visual rendering latency

D. Measure formatting

Correct Answer: A. Re-identification or inference

Question 9

Why should a high-impact decision informed by a dashboard include human oversight?

A. To remove the need for data validation

B. To ensure context, challenge and appeal remain possible

C. To make all decisions identical

D. To eliminate the need for access controls

Correct Answer: B. To ensure context, challenge and appeal remain possible

Question 10

Which role is primarily accountable for defining permitted use and approving access to a data asset?

A. Data owner

B. End user

C. Graphic designer

D. Report subscriber

Correct Answer: A. Data owner