Most mid-market companies talk about privacy in their analytics stack the way they talk about flossing — they know they should, they nod when it comes up, and the actual practice is uneven. The good news is that a credible privacy posture at this size doesn’t require a six-figure platform or a dedicated governance team. It requires four habits, applied consistently, at the four places in the pipeline where each one is cheap.
The four places: ingest, warehouse, access, and audit. Get those right and you’ve covered the ground that matters for GDPR, CCPA, SOC 2 Type II, and most enterprise procurement reviews. Skip any one of them and the other three start leaking value, because privacy is a chain — the weakest link is the only one that counts.
Minimize at ingest
The cheapest data to protect is the data you never collected. This is not a slogan; it is the entire game. Once a field lands in your warehouse, every downstream system inherits it, every backup contains it, every model can be trained on it, and every breach exposes it. Filtering at the source costs almost nothing. Filtering after the fact costs forever.
In practice, this means going through your event tracking and your backend ETL with a real eye and asking, for each field: do we have a present, named, written-down use case for this? Not a “might be useful someday” use case. A real one. Phone numbers in a marketing event payload, full IPs alongside hashed user IDs, free-text comment fields piped straight to the warehouse — these are the obvious culprits, and they are almost always there because nobody pushed back when the schema was designed.
The mid-market move is to put the question in the contract. If you’re using data contracts (and you should be), include a purpose field on every PII column. No purpose, no column. This forces the conversation up to the team writing the schema, which is where it should happen, instead of leaving it for the data team to discover three months later.
Mask at the warehouse layer
The data that does get through ingest needs a second line of defense, because most of it doesn’t need to be readable by most of the people who can query it. The analyst building the cohort retention model does not need to see customer email addresses. The marketer slicing by region does not need to see exact IP addresses. The finance partner reconciling MRR does not need to see anything except the aggregates.
Modern warehouses make this easy enough that there is no excuse not to do it. Snowflake has dynamic data masking and row access policies. BigQuery has authorized views and column-level access controls. Databricks has Unity Catalog. The pattern is the same in all of them: define the masking rule once at the column, apply role-based predicates, and let the engine do the work. Analysts query the same table; what they see depends on who they are.
The trap to avoid is masking everything. Masking has a cost — debugging a pipeline through three layers of obfuscation is genuinely painful — and over-masking creates pressure to grant exceptions, which becomes the new normal. Mask the fields that need it (direct identifiers, contact info, anything regulated), leave the rest alone, and document the rule.
Role-based access, with real roles
RBAC fails in mid-market companies for a predictable reason: the roles are fictional. Everyone gets analyst because nobody wanted the conversation about who actually needs production marketing data. The result is that role-based access becomes a single role with some logging on top, which is not access control.
The fix is not to invent fifteen roles. It is to invent three or four that match how work actually happens. Read-only access to aggregated marts. Read access to PII-bearing tables for a defined business reason. Write access to staging. Admin. That’s it for most companies under a few hundred people. The boundary that matters is between the roles that can see direct identifiers and the roles that cannot — everything else is variation.
Tie the roles to your identity provider so provisioning and de-provisioning ride on the same rails as everything else. When someone leaves, their warehouse access dies the same hour their email does. When someone changes teams, their access changes with them. If your warehouse access is managed in a separate console with separate credentials, you do not have RBAC; you have a directory of exceptions.
Audit trail discipline
Audit logging is the part everyone turns on and nobody reads. The query log fills up, the storage bill climbs, and when an actual question comes — who pulled the customer table last Tuesday — nobody can answer it because the logs are eight columns of JSON and there’s no tooling to ask the question.
The discipline is not more logging. It is fewer, sharper logs that someone is actually going to look at. Two queries are worth running on a schedule and reviewing weekly: every access to a column tagged as PII, and every query that returned more than some sane row count from a sensitive table. Both should land in a small dashboard a real human looks at every Monday. If nobody is looking, you don’t have an audit trail; you have an audit archive.
For mid-market scale, the warehouse’s native query history plus a lightweight scheduled query is enough. You don’t need a separate SIEM, you don’t need a CASB, you don’t need a data security platform. You need someone whose job it is to read the dashboard. That role can be part-time, but it cannot be nobody’s.
What this is not
This posture will not pass an HBO-grade enterprise procurement review on its own. It will pass most mid-market enterprise reviews, including SOC 2 Type II controls around CC6. It will satisfy GDPR Article 25 (privacy by design and by default) when paired with documentation. It will not satisfy a regulated-industry tier (HIPAA, PCI-DSS Level 1) without additional controls, and you should not pretend otherwise. The point is to match the posture to the stage of the company. Spending enterprise-tier money on enterprise-tier controls before you have enterprise-tier exposure is the most common privacy mistake mid-market companies make, and it is just as wrong as the opposite.
The four habits — minimize, mask, restrict, audit — are the floor. They are also, for a company between fifty million and two hundred million in revenue, very close to the ceiling of what is worth doing. Beyond that, the next dollar of privacy investment goes into legal, contracts, and incident response — not the analytics stack.