MarsalaMarsala
← Back to articles
InsightDec 18, 2024·7 min read

Privacy Layer for Growth Teams

I built a privacy layer that lets us experiment without scaring legal.

Insight on how I structured consent, tokenization and governance for growth teams.

By Marsala Engineering Team·
#Data#Compliance

Privacy Layer for Growth Teams

There’s no sustainable growth without trust; the privacy layer is my insurance policy.

Context

As a growth team, we live and breathe data. But with great data comes great responsibility. We were constantly walking a tightrope between moving fast and staying compliant with regulations like GDPR and SOC2. Every new campaign, every new tool, and every new experiment required a lengthy review process with the legal team. This slowed us down and created a culture of fear around using data.

The breaking point came when a well-intentioned A/B test accidentally exposed a small subset of user data. The incident was quickly contained, but it was a stark reminder that our ad-hoc approach to privacy was no longer sustainable.

That's when I decided to build a privacy layer. This layer is a set of tools and processes that abstracts away the complexity of privacy and compliance. It allows our growth team to move fast and experiment freely, while still ensuring that we are respecting our users' privacy and complying with all relevant regulations. Instead of waiting on legal for every campaign, growth plugs into governed APIs and gets instant answers (“Yes, you can email this cohort”, “No, delete these records”). Treating privacy like a product gave us velocity without anxiety.

Stack I leaned on

  • Supabase + Row Level Security for governed storage: We use Supabase as our primary data store for user data. Its built-in Row Level Security (RLS) allows us to enforce fine-grained access control policies at the database level. This ensures that our growth team can only access the data that they are authorized to see.
  • HashiCorp Vault for keys, salts, and secrets: We use HashiCorp Vault to manage our encryption keys, salts, and other secrets. This ensures that our sensitive data is always encrypted at rest and in transit, and that only authorized services can access the keys.
  • Segment consent mode + OneTrust for preference capture: We use Segment and OneTrust to capture and manage user consent. OneTrust provides the user-facing consent banner and preference center, while Segment's consent mode ensures that our downstream tools only receive data for the purposes that the user has consented to.
  • PostHog proxy that strips IP/PII before analytics ingestion: We use a PostHog proxy to strip IP addresses and other personally identifiable information (PII) from our analytics events before they are sent to PostHog. This allows us to collect valuable product usage data without compromising our users' privacy.
  • n8n automations for deletion + audit reporting: We use n8n to automate our data deletion and audit reporting processes. When a user requests to be forgotten, an n8n workflow automatically deletes their data from all of our systems. We also use n8n to generate weekly audit reports that are sent to our legal and compliance teams.
  • Metabase dashboards exposing lineage and consent status: We use Metabase to create dashboards that provide a real-time view of our data lineage and consent status. This allows our legal and compliance teams to see exactly where our data is coming from, where it is going, and what it is being used for.

Data Classification & Contracts

Every field lives in data-catalog.yml with:

  • Sensitivity tier (Public, Internal, Restricted, Sensitive).
  • Lawful basis and purpose.
  • Allowed destinations (analytics, ads, support).
  • Retention window + auto-deletion schedule.
  • Owner + Slack handle.

CI fails if you add a field without owner or retention.

Privacy Layer Architecture

  1. Consent capture: OneTrust widget writes preferences → Segment context → Supabase consent_states.
  2. Tokenization service: Node microservice takes email/phone, returns deterministic token; Vault stores salts so only authorized services can detokenize.
  3. Access proxy: Client SDKs hit our proxy; we drop IP, geo, device info unless consent allows it.
  4. Permission graph: Supabase table mapping teams ↔ datasets ↔ operations; RLS enforces at query time.
  5. Audit pipeline: n8n aggregates access logs, schema changes, and deletion events → legal Slack + weekly PDF for auditors.

Playbook

  1. Classify data and document purpose in Git (reviewed by legal + data).
  2. Tokenize PII before leaving the core DB; marketing/ads only see hashed IDs.
  3. Consent API everywhere: before any campaign, call consent.canSend(user, channel); if false, abort automatically.
  4. Log every use: jobs writing/reading restricted data log metadata (who, why, purpose) to Supabase.
  5. Automate deletions: deletion requests trigger n8n flow across Supabase, PostHog, CRM, S3 backups with SLA 48h.
  6. Review new tools: Linear “Privacy Intake” collects scope; once approved, metadata syncs to dashboards so legal sees every destination.

The Benefits of a Privacy Layer

  • Increased velocity: By abstracting away the complexity of privacy and compliance, the privacy layer allows our growth team to move faster and experiment more freely.
  • Reduced risk: The privacy layer helps us to reduce the risk of data breaches and compliance violations.
  • Improved trust: By being transparent about our data practices and giving users control over their data, we can build trust with our users.
  • Better data governance: The privacy layer provides a centralized place to manage our data, which improves our data governance.
  • Simplified compliance: The privacy layer simplifies compliance with regulations like GDPR and SOC2.

Consent API Example

import { consent } from "@marsala/privacy-sdk";

async function canSendUpsell(userId: string) {
  const decision = await consent.canSend({
    userId,
    channel: "email",
    purpose: "upsell_sequence_q1",
  });
  if (!decision.allowed) {
    throw new Error(`Consent denied: ${decision.reason}`);
  }
}

Developers call this helper everywhere instead of rolling their own checks.

Deletion Workflow

  1. User submits request via portal (or DPA email).
  2. n8n flow fetches tokens, looks up all destinations via data_usage_logs.
  3. Executes deletion/anonymization per service (Supabase, PostHog, CRM, S3 backups).
  4. Writes completion report to Supabase + sends PDF to legal/compliance.
  5. Updates customer record with “erasure complete” timestamp.

SLA is 48h; alerts fire at 24h and 36h if still open.

Consent Workflow

flowchart LR
User --> OneTrust --> SegmentConsent --> Supabase
Supabase --> ConsentAPI
GrowthTool -->|check channel| ConsentAPI
ConsentAPI --> Allow/Block

Experiments, emails, ads, and AI prompts call the API before running; we log every decision.

Metrics & Telemetry

  • Faster deletion requests: Deletion requests are now served in less than 48 hours, with an average of 16 hours.
  • Zero privacy incidents: We have had zero privacy incidents in 2024.
  • Quicker tool approval: The time to approve new tools has been reduced by 40%.
  • High consent coverage: 98% of outbound touches are now logged via the ConsentAPI.
  • Reduced manual legal reviews: Manual legal reviews per campaign have been reduced by 55%.
  • Effective unauthorized query blocking: We block an average of 42 unauthorized queries per month, which is a strong signal that the privacy layer is working effectively.
  • Automated data purpose expirations: 100% of data purpose expirations are now handled automatically.

Dashboards & Reporting

Metabase privacy board shows:

  • Data flow diagram (source → destination) with purpose tags.
  • Consent opt-in/out trends per channel.
  • Upcoming retention expiries (“Trial data expiring in 7 days”).
  • Access anomalies (restricted data queried outside business hours).
  • Self-serve audit export (CSV+PDF).

Legal no longer asks for screenshots—they open the dashboard.

Culture & Adoption

  • We host quarterly “Privacy + Growth” show-and-tells to demo wins (e.g., faster approvals).
  • Slack shortcut /privacy-route explains how any new idea should flow through the layer.
  • Every growth engineer has “privacy OKR” tied to reducing manual reviews.
  • During onboarding, new hires configure the SDK in a sample project and run deletion drills.

Implementation Timeline

  • Week 1: Inventory data, classify fields, stand up Supabase policies.
  • Week 2: Build tokenization + consent APIs, migrate key services.
  • Week 3: Connect dashboards (Metabase, Grafana), build deletion automation.
  • Week 4: Roll out SDK updates across growth repos, run privacy drill, present to legal.

In under a month we went from ad-hoc approvals to a governed system—because we treated it like a sprint, not a side project.

Ignoring privacy would have cost us far more (fines, lost trust, slower launches); the layer pays for itself every week a PMM ships without waiting on a committee.

FAQ

  • Who owns the privacy layer? Growth Ops builds it, Legal governs policies, Engineering maintains infra. Shared ownership keeps it alive.
  • Do experiments slow down? No—decisions happen faster because consent + data usage is clear.
  • What about vendors without strong privacy controls? We either proxy them (PostHog proxy) or block the integration. No exceptions.

Case Study: AI Support Pilot

When support wanted to pilot AI-generated replies, legal panicked. Using the privacy layer we:

  1. Tagged support transcripts as Sensitive; only anonymized versions flow to AI providers.
  2. Ran prompts through the Consent API to ensure only opted-in customers receive AI-generated drafts.
  3. Logged every AI request with purpose + retention (30 days) and auto-deleted transcripts after expiry.
  4. Surfaced usage metrics + audit logs in Metabase so legal saw exactly which tickets used AI.

Result: pilot approved in 48 hours instead of weeks, and we passed the SOC 2 audit with zero notes.

Developer Experience

  • @marsala/privacy-sdk exposes helpers (tokenizeEmail, canSend, withPrivacyContext).
  • ESLint plugin forbids importing raw PII modules outside allowed directories.
  • Storybook stories include consent toggles so designers understand states.
  • VS Code snippets insert metadata headers when creating new data fields or prompts.

We make the safe path the easy path.

Governance Rituals

  • Monthly privacy council reviews new tools, unresolved incidents, risky experiments.
  • Quarterly contract audit updates retention, owners, lawful bases.
  • Training refreshers (Loom + quiz) for growth squads.
  • Incident drills simulate breaches; we practice revoking tokens, notifying customers, regenerating salts.

Cost Snapshot

  • Supabase Pro: $25/mo (policies + audit logs).
  • Vault (HCP): $36/mo.
  • OneTrust: already company-wide; incremental $0.
  • n8n on Fly.io: $15/mo.
  • Engineering time: 1 day/month to maintain catalog + automations.

Cheap insurance compared to fines or lost trust.

What stuck with me

  • Legal needs real-time visibility of where data travels.
  • Teams accept constraints when they see the upside (fewer endless forms).
  • Tokenization must be purpose-specific; reuse causes compliance headaches.
  • Build privacy checks into CI and QA so issues fail fast.

What I'm building next

I’m building a CLI that lists which services touch PII and flags expired data purposes. Want to beta test it? ping me.


Want me to help you replicate this module? Drop me a note and we’ll build it together.

Marsala OS

Ready to turn this insight into a live system?

We build brand, web, CRM, AI, and automation modules that plug into your stack.

Talk to our team→