Running a privacy and access audit on your data stack

This is the normal state of most data stacks in 2026. The fix isn't a giant compliance project. It's a recurring, checklist-driven audit you can run in an afternoon.

Why this is a governance problem, not just an IT problem

Data governanceData governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → is the set of rules, roles, and processes that decide who can access, change, or move data, and how you prove it. In SaaS, the practical risk isn't abstract: it's a support agent seeing another customer's payment details, or a growth analyst exporting PII (personally identifiable information, like names, emails, or IP addresses) into a spreadsheet that ends up on a personal laptop.

Regulators care because the law says they should. Under the EU's GDPR (General Data Protection Regulation), companies must apply "data protection by design and by default" (Article 25) and can face fines up to 4% of global annual revenue or €20 million, whichever is higher, for serious violations (EU GDPR text). In the US, there's no single federal privacy law, but state laws like the CCPA/CPRA (California Consumer Privacy Act, amended by the California Privacy Rights Act) give the California Privacy Protection Agency enforcement power, and sector rules like HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (Health Insurance Portability and Accountability Act) apply if your SaaS product touches health data.

Auditors and enterprise customers now routinely ask for SOC 2 (System and Organization Controls 2, a US audit framework from the AICPA) reports before signing contracts. Access control is one of the first things a SOC 2 auditor tests.

The three layers where PII actually leaks

Most SaaS companies store customer data in a data warehousedata warehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.Voir la définition complète → (a centralized database optimized for analytics, e.g. Snowflake, BigQuery, Redshift). From there, data flows two ways:

1. Into BI tools (Looker, Tableau, Power BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète →, Metabase) for dashboards and reporting.

2. Out via reverse ETL (tools like Census or Hightouch that push warehouse data back into operational tools like Salesforce, HubSpot, or Intercom).

Each layer needs its own audit because permissions don't automatically inherit from one to the next. A column masked in the warehouse can still leak if the BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → tool caches an old extract, or if a reverse-ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → sync was set up before the masking rule existed.

The checklist: warehouse layer

Run this quarterly, or after any headcount change on data teams.

• List every role/user with query access. In Snowflake or BigQuery, pull the access grants directly:

• **Flag roles with SELECT * on raw PII tables.** Anyone outside data engineering or a named data protection role should not have unrestricted access to raw email, phone, ssn, ip_address columns.
• Check for column-level masking. Modern warehouses support dynamic data masking, showing j***@***.com instead of a real email to non-privileged roles. Confirm it's actually applied to production tables, not just staging.
• Review service accounts. These are non-human logins used by pipelines. They often have broader access than any single employee and are rarely reviewed. A service account for a marketing tool shouldn't have write access to billing tables.
• Confirm query logs are retained and searchable. You need to answer "who queried customer X's data, and when" for at least 90 days, ideally 12 months, to respond to a regulator or a customer's data subject access request (DSAR, a GDPR-mandated right to know what data a company holds on you).

The checklist: BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → tool layer

• Map dashboards to underlying tables. A dashboard for the marketing team shouldn't quietly join in a support table with raw complaint text and customer names.
• Check row-level and column-level security settings. Looker's PDTs (persistent derived tables) and access filters, or Tableau's row-level security, should restrict what each viewer sees, not just what they can edit.
• Audit "explore" or ad hoc query permissions. Most BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → tools let power users bypass curated dashboards and query the underlying model directly. That's where over-permissioning usually hides.
• Check export and download rights. Can a user export a full customer list to CSV? If yes, who, and is it logged?
• Review embedded/shared links. Many BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → tools let you generate a public or semi-public link to a dashboard. Search for any that expose PII and were never revoked.

The checklist: reverse ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → layer

Reverse ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → is newer and less scrutinized, which makes it the highest-risk layer in 2026.

• List every active sync and its destination (CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète →, ad platform, support tool, email marketing).
• Check field-level mapping. A sync built to send "customer tier" to a marketing tool shouldn't also carry "lifetime support notes" because someone selected the whole table instead of specific columns.
• Verify destination-side access. Once PII lands in HubSpot or an ad platform's audience tool, warehouse-level masking no longer applies. If you sync hashed emails to build an ad audience (a common pattern for retargetingretargetingShowing ads to users who have previously visited your site or interacted with your brand, to bring them back and drive conversion.Voir la définition complète →), confirm hashing actually happens before the sync, not after.
• Check sync frequency and staleness. If a customer exercises their GDPR right to erasure ("right to be forgotten," Article 17) and you delete them from the warehouse, does the next sync propagate that deletion downstream, or does stale PII linger in a marketing tool indefinitely?

For a practical checklist template, the OWASP guide on data protection is written for security engineers but its access-control principles mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → directly onto data stack audits.

A worked mini-example: sizing your exposure

Say your warehouse has 40 employee accounts and 15 service accounts with some form of query access. You review grants and find:

• 6 human accounts have unrestricted SELECT * on a raw customers table (should be 2: data eng lead and DPO-designated analyst).
• 3 service accounts feeding reverse-ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → tools have access to columns beyond what their sync actually uses.

That's 9 over-permissioned accounts out of 55, roughly 16% of all access grants. That percentage is exactly the kind of metric a board or a SOC 2 auditor wants to see tracked quarter over quarter, ideally trending toward zero. The absolute number matters less than whether you can produce it on demand and show it shrinking.

Who owns this, organizationally

Governance fails when it's nobody's explicit job. In practice:

• A Data Protection Officer (DPO) is legally required under GDPR for companies doing large-scale processing of sensitive data; smaller SaaS companies often assign this role part-time to a legal or ops lead.
• Data engineering owns warehouse-level grants and masking rules.
• Analytics/BI leads own dashboard-level permissions.
• RevOps or growth ops own reverse-ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → syncs, and often have the least security training of the three, which is why this layer needs explicit checklist ownership assigned, not assumed.

Key Takeaways

• Audit all three layers separately: warehouse grants, BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → tool permissions, and reverse-ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → sync mappings. Access doesn't automatically stay consistent across them.
• Service accounts and ad hoc "explore" query modes are the two most commonly overlooked sources of over-permissioning.
• GDPR (EU) and CCPA/CPRA (California) create real enforcement exposure; SOC 2 reports are the de facto commercial gate for enterprise SaaS deals, and both hinge on demonstrable access control.
• Track a simple metric quarterly: over-permissioned accounts as a percentage of total access grants, and show it declining.
• Reverse is the newest and least audited layer as of 2026: masking applied in the warehouse does not follow data once it lands in a or ad platform.