How do we let managers drill into KPIs while protecting employee-level information?

Introduction

Managers need to access KPIs to make informed decisions, but exposing detailed employee-level data risks privacy breaches and compliance violations. Balancing transparency and confidentiality is essential in South African business contexts where data protection is critical. This article outlines practical steps to enable KPI drill-downs while protecting sensitive employee information.

Separate Aggregate Measures from Employee-Level Details

The first key principle is to separate aggregate KPI data from detailed employee-level data. Aggregates can reveal individuals in small teams or through overlapping filters. Assess re-identification and permitted summary scope before granting access. Detailed rows containing personal or sensitive data should be stored separately and accessed only under strict controls.

Proposed operating rule: Store aggregate KPIs in dedicated tables or materialized views designed for broad access. Store employee-level data in separate tables with row-level security (RLS) enabled. Dashboards should query aggregate tables by default and only drill into detailed views if access is verified.

Enforce Access Control in the Data Layer Using Row-Level Security

Database controls are one layer; endpoints, exports, caches and privileged server paths need review too. PostgreSQL and Supabase support row-level security (RLS), which restricts which rows a user can see based on policies.

• Enable RLS on employee data tables.
• Define policies that allow managers to see only data relevant to their teams or roles.
• Use authenticated user context (e.g., JWT claims) to enforce these policies.
• Avoid relying on client-side filtering alone.

Trusted JWT claims may be stale after role changes. Include organisation scope and test revocation. Database membership checks have different behaviour; never trust client-supplied team identifiers.

Use Views Carefully and Securely

Database views can simplify querying but may bypass RLS if created with security definer privileges. This can expose all rows unintentionally.

Recommendation: Use an appropriate security-invoker view over protected base tables on supported PostgreSQL versions, and review grants. Ordinary views cannot have RLS policies attached directly. Always test views to ensure they do not leak restricted data.

Apply Deny-By-Default and Least Privilege Principles

Access control should default to denying all access unless explicitly allowed. Grant permissions only to roles that require them.

• Revoke broad SELECT privileges on sensitive tables.
• Grant minimal permissions to roles like 'manager' or 'team_lead'.
• Regularly audit permissions to prevent privilege creep.

This approach minimizes the risk of accidental data exposure.

Test Both Dashboard Screens and Data Exports

Managers may export reports or data extracts, which can bypass UI restrictions if not controlled.

• Test exports to ensure data filters and RLS policies apply.
• Validate that exported files do not contain unauthorized employee details.
• Include export scenarios in your security test plans.

Dashboard-Access Test Checklist

Use the following checklist to verify that dashboards enforce data protection:

Use this checklist during development, testing, and before production releases.

Hypothetical model for manager drill-down

Record trusted user-to-organisation-to-team membership, permitted columns and operations. A client-supplied session setting is not proof of membership. A custom setting needs a controlled server boundary that validates it and prevents context leaks across pooled connections.

Test under the actual application role. Table owners, superusers and bypass roles may behave differently. Decide whether summaries use permitted base rows or a separately authorised reporting function. Materialised aggregates do not automatically inherit the privacy decisions of source tables.

Use known records from two organisations and teams. Test cross-team and cross-tenant denial, direct queries, pagination, export and cache scope. Request an unnecessary salary or identity column: row permissions do not restrict columns. Review grants, projections and API response fields separately.

Integrate with SaaS Development Best Practices

Refer to Symaxx's dashboard development guide to discuss scope. For broader SaaS development considerations, visit our SaaS development overview.

Use marketing dashboard metrics wisely by consulting marketing dashboard metrics guide. For AI-enhanced workflows that can support reviewed reporting integrations, see AI CRM integration workflows and our AI automation glossary.

Conclusion

Separating aggregate KPIs from detailed employee data, enforcing row-level security at the data layer, and rigorously testing both dashboards and exports are essential to protecting employee-level information. Adopt deny-by-default and least privilege principles to reduce risk. Use the provided dashboard-access test checklist regularly as part of the access review.

If your business needs help implementing secure dashboards or SaaS applications, get in touch with Symaxx for expert assistance at our dashboard development service.

Implementing Audit Trails and Monitoring for Data Access

Protecting employee-level information extends beyond access control; comprehensive audit trails and monitoring are crucial for accountability and compliance. Choose audit evidence for the risk and applicable obligations. This checklist does not establish a legal requirement to log every SELECT or prove compliance.

Actions:

• Enable database-level logging of SELECT, INSERT, UPDATE, and DELETE operations on sensitive tables.
• Record authenticated actor, organisation, action, object reference, decision and time where needed. Redact sensitive values; logs are another dataset needing protection.
• Integrate audit logs with a Security Information and Event Management (SIEM) system or centralized logging platform.
• Set up alerts for unusual access patterns, such as a manager accessing multiple teams’ data or exporting large datasets unexpectedly.

Decision Evidence:

• Audit logs showing access only by authorized managers to their teams’ data.
• Alert records triggered by anomalous access attempts.

Recorded Fields:

• User ID
• Role
• Timestamp
• Operation type
• Table and rows accessed
• Query text or API endpoint

Expected Results:

• All access to employee-level data is recorded and traceable.
• Any unauthorized or suspicious access attempts are flagged promptly.

Recovery Steps:

• Investigate flagged alerts immediately.
• Revoke or adjust permissions if misuse is detected.
• Provide additional training or disciplinary action as per company policy.

Using Data Masking and Redaction for Sensitive Fields

When drill-downs require displaying some employee-level data, apply data masking or redaction to protect sensitive fields.

Actions:

• Identify sensitive columns (e.g., ID numbers, salary, medical info).
• Omit unnecessary sensitive fields. If masking is justified, test it; initials and partial identifiers can still identify a person and are not anonymous.
• Implement conditional masking based on user role or context.

Decision Evidence:

• Masking functions applied in SQL views or API responses.
• Role-based masking policies enforced.

Recorded Fields:

• Original value (stored securely)
• Masked value (presented to user)
• User role and context triggering masking

Expected Results:

• Managers see sufficient detail for decision-making but cannot view full sensitive data unless explicitly authorized.
• Masking is consistent across dashboard screens and exports.

Recovery Steps:

• Review masking rules periodically.
• Update rules if new sensitive data fields are added.

Hypothetical checklist: tests still to run

Consider a South African retail company with a dashboard showing sales KPIs. Managers can drill into employee sales data but must not see personal details like ID numbers or salaries.

Recovery Steps if Fail:

1. Identify missing or incorrect policy or role grant.
2. Adjust RLS policies and role permissions accordingly.
3. Re-test affected scenarios.
4. Document changes and communicate to stakeholders.

This is an unexecuted example, not a tested client case. Passing provides scoped evidence, not complete security or legal compliance.

---

For detailed technical guidance on implementing these controls, consult Symaxx's dashboard development guide.

Documentation boundaries for this decision

Supabase documentation explains that row-level security (RLS) requires enabling policies under the actual user role and authenticated context. It warns that service roles or keys can bypass these policies, so they must be kept server-side. Additionally, database views created with security definer privileges can bypass RLS and expose all rows unintentionally. Therefore, views should be created with security invoker permissions over protected base tables. This means dashboard developers must carefully configure RLS and views to prevent unauthorized employee data exposure. Source: Supabase row-level security

PostgreSQL's official documentation clarifies that enabling row-level security on a table filters access for roles subject to its policies. If no policy exists, a default-deny applies, blocking all rows. Policies can be tailored per command and role, and multiple policies combine permissively by default. The table owner usually bypasses RLS unless forced otherwise. This establishes that enforcing RLS at the data layer provides a robust mechanism to restrict managers’ access strictly to their team’s employee data, but it requires explicit policy definitions and testing to ensure correct enforcement. Source: PostgreSQL row security

The OWASP Authorization Cheat Sheet highlights the principle of least privilege, recommending that users receive only the minimum permissions necessary for their role. It also stresses a deny-by-default approach, where access is denied unless explicitly granted. This reduces the risk of privilege creep and accidental data leaks. For dashboards, this means roles like 'manager' should have tightly scoped permissions, and all access paths, including exports, must be validated to maintain employee data confidentiality. Source: OWASP authorization guidance

Frequently asked questions

How does row-level security prevent unauthorized data access?

Row-level security applies policies at the database level that filter rows based on user identity or role, ensuring users see only data they are permitted to access.

Can managers export employee data if RLS is enabled?

Exports must be tested and controlled because RLS applies at the query level. Proper policies and export filters prevent unauthorized data leakage.

What is the risk of using database views with RLS?

Views created with security definer privileges can bypass RLS, exposing all rows. Review security-invoker behaviour, grants and protected base tables; ordinary views cannot have RLS policies attached.

How often should access policies be reviewed?

Review after role, membership, field or export changes. Quarterly review is a possible operating rule, not a mandatory frequency established here.

Sources

• Supabase row-level security
• PostgreSQL row security
• OWASP authorization guidance