Access And Privacy Policies Basics

Why this matters

As a BI Developer, you translate data into dashboards and models people use to make decisions. Access and privacy policies keep sensitive data safe while still letting the right people do their work.

• Real tasks you will face:
  • Configure row-level and column-level security for dashboards and semantic models.
  • Mask sensitive fields (emails, phone numbers) by default; unmask only for approved roles.
  • Classify datasets (public, internal, confidential, restricted) and map controls to each class.
  • Set up audit logging to track who viewed or exported data.
  • Implement retention and deletion rules for datasets and extracts.

Concept explained simply

Access policy answers: Who can do what with which data, under which conditions. Privacy policy answers: Why we have the data, what we are allowed to do with it, and how we minimize exposure.

Mental model

Think of your data platform as a building:

• Doors and keys: authentication and role-based access (who gets in).
• Rooms: datasets, tables, and dashboards.
• Room labels: data classifications (public, internal, confidential, restricted).
• Blinds on windows: masking and aggregation to hide detail.
• CCTV: audit logs proving who went where and when.
• Cleaning schedule: retention and deletion to remove stale data.

Key principles

• Least privilege: Grant the minimum access needed to perform a task.
• Need-to-know: Access is tied to a legitimate business purpose.
• Data classification: Tag data by sensitivity and align controls accordingly.
• Purpose limitation and consent: Use personal data only for approved purposes and only when consent or legal basis exists.
• Retention and deletion: Keep data only as long as necessary; delete or anonymize afterward.
• Auditability: Log access, changes, and data exports.
• Separation of duties: Builders, approvers, and reviewers are not the same person when stakes are high.

Worked examples

Hands-on exercises

These mirror the interactive exercises below. Try them here first.

Exercise 1 — Build an access control matrix

Create a simple matrix for three roles and three datasets with actions (view, explore, export).

1. Define roles: executive, sales_manager, data_analyst.
2. Define datasets: regional_sales, customer_pii, finance_summary.
3. Apply least privilege and privacy principles to fill which actions each role gets.
4. Add expiry for temporary exports where needed.

• You restricted customer_pii to only those with a documented need.
• You limited export to the smallest necessary audience.
• You added review/expiry notes for elevated access.

{"executive": {"regional_sales": ["view","export"], "customer_pii": [], "finance_summary": ["view","export"]},
"sales_manager": {"regional_sales": ["view","explore"], "customer_pii": [], "finance_summary": ["view"]},
"data_analyst": {"regional_sales": ["view","explore"], "customer_pii": ["view_masked"], "finance_summary": ["view","explore"]}}
Notes: data_analyst gets only masked PII; exports restricted to executive; reviews every 90 days.

Exercise 2 — Write a masking rule

Design a transformation that exposes masked emails to most users and full emails only to support role.

1. Create a derived column email_masked showing first 2 letters + ">***" + domain.
2. Define policy: if user has attribute can_view_pii = true then email_exposed = email else email_exposed = email_masked.
3. Ensure dashboards use email_exposed, not raw email.

SELECT CASE WHEN current_user_has('can_view_pii') THEN email
            ELSE CONCAT(SUBSTR(email,1,2),'***',SUBSTR(email,INSTR(email,'@')))
       END AS email_exposed
FROM customers;

• Masking applies by default.
• Only an approved attribute/role reveals full data.
• Dashboards reference the exposed field, not raw PII.

Common mistakes and how to self-check

• Over-granting access: Everyone gets editor or export rights. Self-check: Review last 30 days of audit logs; identify unused high-privilege roles and revoke.
• Relying only on encryption: Encryption at rest does not replace RLS/CLS. Self-check: Impersonate a user and verify row/column filters work.
• Unmasked PII in extracts: CSV exports bypass masking. Self-check: Test export with non-privileged role; verify masking persists.
• No expiry on temporary access: Access persists indefinitely. Self-check: Add end-dates and schedule reviews.
• Missing purpose documentation: Access granted without why. Self-check: Require a ticket with purpose and legal basis.

Practical projects

Who this is for

• BI Developers, Analytics Engineers, and Data Analysts who publish dashboards, data models, or extracts.
• Team leads who review and approve data access.

Prerequisites

• Basic SQL and familiarity with your BI tools security features (roles, groups, RLS/CLS).
• Understanding of your organizations data classification scheme.

Learning path

• Before: Data classification and catalog basics.
• Now: Access and privacy policies (this lesson).
• Next: Advanced RLS/CLS patterns, auditing and monitoring, data retention automation.

Next steps

• Implement one masking rule in a real dashboard and test with two roles.
• Set a quarterly review for high-privilege roles.
• Document a simple access request workflow for your team.

Mini challenge

You are asked to allow a vendor to view customer-level purchases to help with a campaign.

• Write one rule that protects privacy while enabling analysis.
• Specify the approval needed and the expiry date.
• State what you will log to prove compliance.

Glossary

• PII: Personally Identifiable Information (e.g., name, email, phone).
• RLS: Row-Level Security; filters data by user/group.
• CLS: Column-Level Security; hides or masks sensitive columns.
• RBAC/ABAC: Role- or Attribute-based access control models.
• Purpose limitation: Use data only for stated, legitimate purposes.

About the quick test

The quick test is available to everyone for free. Only logged-in users will have their progress saved.