Security, Governance, Ethics and Accessibility

Introduction

Business intelligence (BI) systems transform operational data into information used for planning, performance management and decision-making. Because dashboards can expose commercially sensitive, personal or legally protected information, visualization is not only a technical activity. It is also a governance, risk-management and ethical responsibility.

A well-designed dashboard must answer four questions:

1. Who is allowed to see the data?
2. How can users be confident that the data and metrics are reliable?
3. Is the presentation fair, lawful, transparent and appropriately interpreted?
4. Can people with different abilities, devices and contexts understand and use it?

Power BI and Tableau provide technical mechanisms such as authentication, permissions, workbooks, datasets, row-level security, sensitivity labels and auditing. However, technology alone does not create effective governance. Organisations require clearly assigned ownership, documented policies, review processes and an ethical culture.

This chapter examines security, governance, privacy, ethics and accessibility as connected elements of responsible BI practice.

Learning Objectives

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

• distinguish authentication, authorization, permissions and row-level security;
• design basic role-based and row-level security controls in Power BI and Tableau;
• explain data ownership, stewardship, certification, lineage and retention;
• apply privacy, classification and confidentiality controls to BI content;
• identify ethical risks such as misleading visual encodings, bias and inappropriate disclosure;
• design dashboards that are accessible to users with visual, motor, cognitive or hearing-related needs;
• evaluate governance controls through a practical business scenario.

1. Security as a BI Responsibility

BI security protects the confidentiality, integrity and availability of information. These three objectives are often called the CIA triad.

• Confidentiality means that information is accessible only to authorised people.
• Integrity means that data and calculations are accurate, complete and protected from unauthorised alteration.
• Availability means that authorised users can access required information when needed.

A dashboard may be visually attractive but still be unsafe. For example, a regional manager who can filter a report to display an individual employee's salary may have excessive access. Similarly, a sales dashboard that uses an unapproved revenue definition may preserve confidentiality but fail the integrity requirement.

Security should be designed in layers:

Security is most effective when controls are applied according to risk. A public marketing dashboard may require little restriction, whereas a workforce analytics report may require strict access, aggregation and auditability.

2. Authentication, Authorization and Permissions

Authentication verifies identity. Examples include a password, a security token, a biometric factor or an organisational identity provider. Authorization determines what an authenticated user may do. Permissions are the specific rights granted by an authorization system.

Common permission levels include:

• viewing a report;
• interacting with filters and visualizations;
• exporting summarized or underlying data;
• sharing content;
• creating or editing reports;
• publishing or certifying datasets;
• managing workspace membership;
• changing security roles;
• deleting or transferring content ownership.

The principle of least privilege states that users should receive only the access necessary for their responsibilities. Least privilege reduces the consequences of compromised accounts and accidental disclosure. Access should normally be granted through managed groups rather than individually, because group-based administration is easier to review and remove.

The separation of duties principle prevents one person from controlling every stage of a sensitive process. For example, a report developer may build a financial dashboard, a data owner may approve its definitions, and an administrator may publish it. Separating these responsibilities reduces the risk of undetected error or misuse.

A useful access review asks:

• Does each user still need this access?
• Is the access appropriate to the user's current job?
• Can the user export or reshare the information?
• Has the dataset owner approved the access?
• Is access logged and periodically reviewed?

3. Role-Based Access Control and Row-Level Security

3.1 Role-based access control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. A role represents a business responsibility rather than an individual person. Examples include Sales Analyst, Regional Manager, Human Resources Specialist and Executive Viewer.

RBAC is particularly appropriate for workspace or content permissions. A typical arrangement might be:

Role names and capabilities vary between Power BI and Tableau deployments. The principle remains the same: permissions should reflect business duties and be documented in an access matrix.

3.2 Row-level security

Row-level security (RLS) restricts the records returned to a user. Two users may open the same report but see different rows. For instance, a regional manager may see sales for the manager's region, while a corporate executive may see all regions.

A simple conceptual rule is:

Here, D is the complete dataset, r is one record, Region(r) is the region attached to that record, and Region(user) is the region assigned to the authenticated user. The rule is applicable only when the user identity is reliably mapped to an approved region and the data model correctly propagates the filter.

RLS is not the same as hiding a visual. Hiding a chart or applying a page filter may leave underlying data available through another visual, export or query. RLS must be implemented at the semantic or data-model layer and tested through realistic access paths.

3.3 RLS implementation pattern

A robust RLS design commonly includes:

1. a business data table containing transactions;
2. a security mapping table containing user identifiers and permitted organizational units;
3. a relationship or filter mechanism connecting the mapping table to the business data;
4. a role that applies the identity-based filter;
5. tests for ordinary users, managers, administrators and users with multiple assignments.

In Power BI, RLS roles are generally defined in the model and users or groups are assigned to those roles after publication. In Tableau, user filters, groups, entitlement tables and data-source filters can support similar outcomes. Exact features depend on the product edition, deployment architecture and identity configuration, so implementation should be validated against current platform documentation.

3.4 RLS risks and testing

RLS can fail when:

• a user identifier is inconsistent between the identity provider and the mapping table;
• relationships are missing, inactive or bidirectional in an unsafe way;
• a manager needs several regions but the model allows only one;
• export permissions reveal more data than the dashboard displays;
• administrators bypass model restrictions through privileged access;
• aggregated figures permit re-identification of individuals.

Testing should use a matrix of personas and expected results. Testing only as the report author is inadequate. The team should verify filters, drill-through pages, tooltips, downloads, subscriptions, mobile views and connected spreadsheet access.

4. Governance: Making BI Trustworthy

Data governance is the system of decision rights, responsibilities, policies, standards and controls used to manage data. BI governance extends this system to datasets, metrics, reports, workspaces and analytical processes.

Governance answers questions such as:

• Who owns the customer data?
• Which definition of “active customer” is approved?
• Which source is authoritative?
• Who may publish a KPI to executives?
• How are errors reported and corrected?
• When should an unused report be archived?

4.1 Ownership and stewardship

A data owner is accountable for the business use, access decisions and risk associated with a data domain. Ownership is usually assigned to a business function, such as Finance, Human Resources or Operations.

A data steward performs operational governance activities. Stewards may maintain data definitions, investigate quality issues, document transformations and coordinate access reviews. A technical custodian may manage storage, pipelines and platform configuration without owning the business meaning of the data.

These roles should not be confused. A database administrator may be able to technically access payroll data, but the Human Resources data owner remains responsible for deciding appropriate business access.

4.2 Certification and endorsement

A certified dataset or report has passed a defined review process. Certification commonly considers:

• source authority and ownership;
• documented metric definitions;
• data quality checks;
• refresh frequency and failure handling;
• security and privacy review;
• appropriate lineage and documentation;
• business acceptance.

Certification should not be a decorative label. The organisation should define who can certify, what evidence is required and when certification expires or must be renewed. A report may be technically correct but not certified because its source, owner or intended use is unclear.

4.3 Lineage and impact analysis

Data lineage records how data moves and changes from origin to consumption. A lineage chain may include source systems, extraction jobs, transformations, semantic models, reports and exported files.

Lineage assists with:

• identifying the effect of changing a source column;
• tracing a KPI back to its origin;
• investigating discrepancies;
• demonstrating regulatory accountability;
• finding duplicated or obsolete reports.

Lineage is not necessarily proof that data is correct. It describes relationships and transformations; it does not by itself validate business logic. A documented but incorrect calculation remains incorrect.

4.4 Retention and lifecycle management

A BI lifecycle may be expressed as:

Figure: A governed BI content lifecycle.

Retention means keeping data or content for a justified period and disposing of it securely when the period ends. Retention must consider legal obligations, contractual requirements, operational needs, investigation holds and storage costs. Keeping everything forever increases privacy and security risk; deleting too early may breach legal or audit requirements.

A retention schedule should identify the content type, responsible owner, retention trigger, retention period, archival method and approved disposal method. Exact periods depend on jurisdiction and sector; they should be determined with legal and records-management specialists rather than assumed from a generic rule.

5. Privacy, Classification and Confidentiality

Privacy concerns the appropriate collection, use, disclosure and retention of information about identifiable people. Confidentiality concerns preventing unauthorised access. The concepts overlap but are not identical: confidential commercial data may not be personal data, and personal data may sometimes be lawfully published in a controlled context.

5.1 Data classification

A classification scheme helps determine controls. A simple example is:

Classification should be applied to fields, datasets, reports and exports where appropriate. A report containing one restricted visual may require the classification of the most sensitive information it exposes.

5.2 Privacy principles

Common privacy principles include:

• Purpose limitation: use information for specified, legitimate purposes.
• Data minimization: collect and display only what is necessary.
• Accuracy: provide mechanisms to correct material errors.
• Transparency: explain what is collected and how it is used.
• Security: protect information against unauthorised access or loss.
• Storage limitation: retain information no longer than justified.
• Accountability: maintain evidence that controls are applied.

The exact legal duties vary across jurisdictions. Frameworks such as the EU General Data Protection Regulation, the UK GDPR, the California Consumer Privacy Act and sector-specific rules may apply differently depending on location, organisation, data subject and processing activity. This chapter provides governance principles, not legal advice.

5.3 Re-identification and disclosure risk

Removing names does not always make data anonymous. A combination of age, location, occupation and transaction date may identify a person, especially when linked with external information. Small groups create particular risk: a dashboard showing the average absence rate for two employees may allow an observer to infer sensitive information.

Controls include aggregation, suppression of small cells, generalisation of dates or geography, masking, pseudonymization and restricting drill-through. Pseudonymization replaces direct identifiers but does not eliminate privacy obligations if re-identification remains possible.

5.4 Confidentiality in practice

Confidentiality controls should address more than report viewing. Teams should review:

• download and export settings;
• email subscriptions and alerts;
• screenshots and printed reports;
• embedded analytics;
• mobile access;
• external sharing;
• development and test environments;
• cached extracts and backup copies.

A secure platform cannot prevent every human disclosure. Staff training, clear labels and appropriate operating procedures are therefore essential.

6. Ethical Visualization and Responsible Interpretation

Ethical visualization concerns both the data and the way the visual communicates. A technically accurate chart can still mislead when its scale, denominator, selection or annotation encourages an unsupported conclusion.

6.1 Honest visual encoding

Common risks include:

• truncating a bar chart axis so small differences appear large;
• using a three-dimensional effect that distorts area or volume;
• comparing counts when rates are required;
• omitting a relevant time period;
• displaying a moving average without explaining the window;
• using red and green as the only distinction;
• showing a correlation as if it proves causation;
• choosing a dramatic outlier while hiding the distribution.

Charts should use scales and labels that support accurate comparison. If an axis is truncated for a legitimate reason, the truncation should be obvious and explained. The designer should disclose definitions, units, time periods, exclusions and material limitations.

6.2 Bias in data and models

Bias may enter through historical decisions, missing data, measurement choices, sampling, labels, algorithms or interpretation. A dashboard can reproduce bias even if its calculations are arithmetically correct.

A responsible review asks:

• Who is represented and who is missing?
• Are some groups measured differently?
• Does a proxy variable encode protected characteristics?
• Are denominators comparable across groups?
• Could the visualization stigmatize a population?
• Who benefits and who may be harmed by the decision?

Fairness does not always mean treating everyone identically. For example, comparing service response times across regions may require adjustment for distance, service type or case complexity. Adjustments should be justified rather than used to conceal unequal outcomes.

6.3 Transparency and human judgment

High-impact decisions should not be delegated blindly to a dashboard. Users should understand the data source, refresh time, metric definition and known limitations. Automated alerts or scores should support professional judgment, not remove accountability. Where an analytical output affects employment, credit, healthcare or access to essential services, additional legal, ethical and human-review safeguards may be required.

7. Accessible Dashboard Design

Accessibility means that people with different abilities can perceive, understand, navigate and interact with information. It also improves usability for everyone, including people using mobile devices, operating in poor lighting or working under time pressure.

Important practices include:

Perceivable information

• Use sufficient contrast between text, marks and background.
• Do not communicate meaning through colour alone.
• Provide text titles, labels, summaries or alternative descriptions.
• Use patterns, shapes or direct labels where colour categories matter.
• Avoid excessively dense visuals and unreadably small text.

Operable interaction

• Make filters and controls clearly labelled.
• Provide logical tab or keyboard navigation where supported.
• Avoid interactions that depend only on hovering.
• Keep touch targets sufficiently large on mobile devices.
• Ensure that focus order is understandable.

Understandable content

• Use plain, precise language.
• Define unfamiliar terms and abbreviations.
• Explain units, time periods and filter state.
• Use consistent titles, legends and interaction conventions.
• State when data is unavailable rather than implying zero.

Robust delivery

• Test with screen readers and accessibility checkers where available.
• Check keyboard operation and zoom behavior.
• Test on desktop, tablet and mobile layouts.
• Confirm that exported formats remain understandable.
• Involve users with disabilities in testing.

Colour choices should be evaluated for common forms of colour-vision deficiency. A red-green pair may be indistinguishable to some users; labels, symbols or annotations should provide a second channel of meaning. Accessibility standards such as the Web Content Accessibility Guidelines can provide useful reference points, but compliance should be assessed in the context of the actual platform and jurisdiction.

8. Practical Governance Workflow

A repeatable BI governance workflow can be organized into the following stages:

1. Define purpose and audience. State the decision the dashboard supports and identify intended users.
2. Identify data and risks. Record sources, personal data, confidential fields, legal constraints and business impact.
3. Assign ownership. Name the data owner, steward, technical custodian and report owner.
4. Design access. Use groups, least privilege, RBAC and RLS where records differ by user.
5. Document meaning. Define measures, dimensions, filters, refresh schedules and exclusions.
6. Validate quality. Reconcile important figures to trusted sources and test edge cases.
7. Review ethics and accessibility. Examine bias, interpretation, disclosure risk, colour, navigation and alternative descriptions.
8. Approve and publish. Apply classification, certification status and controlled distribution.
9. Monitor. Review audit events, failures, user feedback, access and data quality.
10. Retain or retire. Archive or securely delete content according to the approved lifecycle.

This workflow should be proportionate. A low-risk internal operational report may need a light review, while a dashboard used for regulatory reporting or employee decisions requires stronger evidence and approval.

9. Illustrative Case: Regional Workforce Dashboard

Background

A fictional national retailer, Northstar Stores, creates a workforce dashboard for regional managers. The dashboard includes headcount, overtime, absence, turnover and training completion. The first version contains employee names, exact absence dates and individual salary information.

Problem

Managers report that the dashboard is useful but slow. An internal review identifies excessive access, inconsistent turnover definitions and a risk that small regional teams could be identified. The dashboard uses red for “poor performance” and green for “good performance,” creating accessibility concerns. Some managers can export the complete dataset.

Analysis

The dashboard has four risk categories:

• Confidentiality: salary and absence information are sensitive.
• Privacy: small groups and exact dates may identify individuals.
• Integrity: turnover is calculated differently by region.
• Accessibility and ethics: colour-only status categories may stigmatize teams and exclude users with colour-vision limitations.

The organisation also discovers that no clear data owner has approved the definitions or retention period.

Approach and solution

Northstar assigns Human Resources as data owner, a workforce analyst as steward and the BI team as technical custodian. It creates a certified semantic model with documented definitions. Regional managers receive RLS access to aggregated regional data. Individual-level information is removed from the manager dashboard and retained only in a restricted HR report for authorised specialists.

The security mapping table connects approved organisational identities to one or more regions. The team tests users with one region, multiple regions, no region and executive access. Export permissions are limited, and audit logs are reviewed monthly.

The dashboard displays rates with denominators, suppresses results for very small groups and replaces exact absence dates with approved time-period summaries. Status is communicated through text labels, icons and colour. A glossary explains turnover, absence rate, refresh date and data limitations. The dashboard receives certification after HR and information-security review.

Outcome

Managers retain the information needed for workforce planning, while access to individual records is reduced. Metric disputes decline because definitions are documented. The revised design is more accessible and less likely to stigmatize small teams. The organisation also gains an auditable process for reviewing access and retiring obsolete reports.

Learning points

• A dashboard's audience should determine its level of detail.
• Aggregation is both a privacy control and a communication choice.
• RLS must be tested through exports and alternative navigation paths.
• Certification requires ownership, definitions, quality evidence and review.
• Ethical and accessibility review should occur before publication, not after complaints.

10. Technology, Automation and AI Considerations

Modern BI platforms increasingly provide automated insights, natural-language queries, anomaly detection and AI-assisted report creation. These capabilities can improve productivity but introduce additional governance questions:

• What data is sent to the AI feature or service?
• Does the feature respect existing permissions and RLS?
• Can generated explanations invent unsupported causes?
• Are prompts, outputs or user interactions retained?
• Does the model perform differently across groups or languages?
• Can a human verify the result before a consequential decision?

AI output should be treated as an analytical aid rather than an authoritative fact. Organisations should document approved use cases, restrict sensitive inputs, validate generated calculations and preserve human accountability. The presence of an automated explanation does not remove the need for source lineage or metric definitions.

Challenges and Limitations

Governance involves trade-offs. Strong restrictions can reduce usability and encourage users to create uncontrolled shadow spreadsheets. Excessive aggregation can protect privacy but make a report less useful. Frequent access reviews require time and accurate identity data. Certification can become bureaucratic if it is disconnected from actual risk. Accessibility features may vary across products, browsers and export formats.

No control is perfect. RLS may be bypassed by a privileged administrator, aggregation may still permit inference and a certified report may become incorrect after a source change. Governance is therefore a continuing process of design, monitoring, review and improvement rather than a one-time approval.

Best-Practice Checklist

Before publishing a governed dashboard, confirm that:

• the purpose, audience and decision context are documented;
• data owner, steward and technical custodian are assigned;
• data classification and privacy risks are recorded;
• workspace permissions follow least privilege;
• RLS is implemented where users require different records;
• exports, drill-through, subscriptions and mobile views are tested;
• metric definitions, sources and refresh times are visible;
• lineage and certification status are available;
• retention and disposal responsibilities are defined;
• charts do not exaggerate, conceal or imply unsupported conclusions;
• bias, small-cell disclosure and harmful interpretation have been reviewed;
• colour is not the sole carrier of meaning;
• keyboard, screen-reader, contrast and mobile considerations are tested;
• audit and incident-response procedures are operational.

Chapter Summary

Security, governance, ethics and accessibility are interdependent foundations of trustworthy BI. Authentication establishes identity, authorization grants appropriate capabilities, and permissions should follow least privilege and separation of duties. RBAC manages access to content and functions, while RLS limits the records visible to different users. Effective RLS requires reliable identity mapping, sound data relationships and testing of exports and alternative access paths.

Governance assigns ownership and stewardship, standardizes metric definitions, supports certification, records lineage and controls the BI lifecycle. Classification, privacy-by-design, minimization, aggregation and retention reduce confidentiality and disclosure risks. Ethical visualization requires honest scales, transparent definitions, appropriate denominators and critical attention to bias and harm. Accessibility requires information that can be perceived, operated and understood by users with varied abilities and technologies.

A mature BI function treats dashboards as governed products. It combines technical controls with documented responsibilities, user testing, auditability, human judgment and continual review.

Key Terms

Authentication: Verification of a user's identity.

Authorization: Determination of what an authenticated user is allowed to do.

Accessibility: Design that enables people with varied abilities and technologies to use information and interfaces.

Certification: Formal approval indicating that a dataset or report has met defined quality, ownership and governance requirements.

Confidentiality: Protection of information from unauthorised access or disclosure.

Data classification: Categorization of information according to sensitivity and required controls.

Data governance: Policies, responsibilities, standards and processes for managing data.

Data lineage: Record of how data moves and changes from source to analytical output.

Data owner: Person or function accountable for business use, access and risk associated with a data domain.

Data steward: Person responsible for operational activities such as definitions, metadata and quality coordination.

Least privilege: Providing only the access necessary for a person's responsibilities.

Privacy: Appropriate collection, use, disclosure and retention of information about people.

RBAC: Role-based access control, in which permissions are assigned to roles and users are assigned to roles.

Retention: Controlled preservation of data or content for a justified period.

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

Separation of duties: Distribution of sensitive responsibilities among different people or roles.

Sensitivity label: A classification or handling indicator attached to data or content.

Stewardship: Day-to-day management of data meaning, quality and governance requirements.

Transparency: Clear communication of data sources, purposes, methods, definitions and limitations.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorization?
2. Explain the principle of least privilege.
3. What problem does row-level security solve?
4. Distinguish a data owner from a data steward.
5. Why should colour not be the only way to communicate dashboard status?

Long Answer Questions

1. Explain how RBAC and RLS can be combined in a secure BI environment. Include implementation and testing considerations.
2. Discuss the roles of classification, lineage, certification and retention in BI governance.
3. Explain how a technically accurate visualization can still be ethically misleading.
4. Develop an accessibility strategy for an executive dashboard used on desktop and mobile devices.
5. Discuss privacy risks in dashboards containing information about small groups and propose appropriate controls.

Analytical / Application Questions

1. A regional manager can view a dashboard for one region but can export records for every region. Diagnose the governance failure and recommend corrective actions.
2. A dashboard reports that one department has a higher absence rate than another, but the departments have very different workforce sizes and job types. What additional analysis and disclosure would be needed before making a performance judgment?
3. Design a governance workflow for a dashboard used to allocate public services. Identify the owner, access controls, privacy safeguards, ethical review, accessibility tests and monitoring evidence required before publication.

Multiple Choice Questions with Answers

Question 1

Which control restricts the records returned to a user according to the user's identity or role?

A. Row-level security

B. Data certification

C. Data lineage

D. Visual formatting

Correct Answer: A. Row-level security

Question 2

What is the main purpose of role-based access control?

A. To assign permissions according to job-related roles

B. To remove the need for authentication

C. To guarantee that all data is public

D. To replace data-quality testing

Correct Answer: A. To assign permissions according to job-related roles

Question 3

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

A. Storage limitation

B. Least privilege

C. Data generalization

D. Open publication

Correct Answer: B. Least privilege

Question 4

Which statement best describes data lineage?

A. It records how data moves and changes from source to output

B. It encrypts every report automatically

C. It defines the colour palette of a dashboard

D. It replaces the need for a data owner

Correct Answer: A. It records how data moves and changes from source to output

Question 5

Why can a small-cell dashboard create a privacy risk?

A. Small groups may make individual information easier to infer

B. Small groups always produce inaccurate arithmetic

C. Small groups cannot be displayed in any chart

D. Small groups prevent authentication

Correct Answer: A. Small groups may make individual information easier to infer

Question 6

Which is an example of an ethically misleading visualization?

A. Showing a clearly labelled rate with its denominator

B. Using a truncated axis that exaggerates a small difference

C. Providing the refresh date and source definition

D. Using direct labels alongside colour

Correct Answer: B. Using a truncated axis that exaggerates a small difference

Question 7

Which practice improves accessibility?

A. Using colour as the only indicator of status

B. Removing all text labels to reduce clutter

C. Providing labels or symbols in addition to colour

D. Making filters dependent only on hover actions

Correct Answer: C. Providing labels or symbols in addition to colour

Question 8

Who is generally accountable for business use, access decisions and risk associated with a data domain?

A. Data owner

B. External viewer

C. Dashboard consumer

D. Graphic designer

Correct Answer: A. Data owner

Question 9

What is the main purpose of certification of a BI dataset or report?

A. To indicate that defined governance, quality and ownership checks have been completed

B. To guarantee that the data will never change

C. To allow unrestricted external sharing

D. To eliminate the need for access controls

Correct Answer: A. To indicate that defined governance, quality and ownership checks have been completed

Question 10

Which practice best supports responsible use of AI-generated BI insights?

A. Accepting every generated explanation without review

B. Disabling all documentation because the output is automated

C. Validating outputs, restricting sensitive inputs and retaining human accountability

D. Allowing AI features to bypass existing permissions

Correct Answer: C. Validating outputs, restricting sensitive inputs and retaining human accountability