BitBootcampBitBootcamp ← all explainers 🔄 Review ⚙ Settings

Drill 53 — Purpose Creep

Theme: Compliance, Privacy & Model Governance · Format: 20-min drill · Difficulty: core

The story

Device fingerprints and behavioral signals are collected during login and checkout for fraud prevention, under a consent notice that says "to protect your account." The data lands in the shared warehouse, access-controlled by team. Months later, a marketing analyst — with a perfectly valid warehouse grant — discovers the fraud tables are a goldmine for cross-sell targeting: device type, session patterns, login frequency. A campaign ships. Then a customer complains about an eerily well-targeted offer, a privacy audit pulls the thread, and the query history tells the whole story.

⏸ Stop here and ask the room: every access was authorized. What went wrong?

Run it — facilitator script

Timing: ~2 min story · ~10 min questions · ~3 min reveal · ~5 min transfer.

Read the story, pause at the blockquote, and stress the trap in the framing: no rule in the platform was broken. The drill works when the room realizes that's the problem, not the defense.

The analyst had permission — from whose point of view was this a violation?

Listen for: the customer's and the regulator's — consent defined a contract about use, and the platform only ever checked identity. The access-control system answered "who may read this table?" when the legally binding question was "for what purpose may this data be used?" Authorization and authorization-for-this-purpose are different predicates, and the platform only implemented one.

Weak signal: "the analyst broke the rules." The analyst followed every rule the platform expressed — the rules were incomplete. Blaming the analyst guarantees the next analyst repeats it.

What does "consent" attach to: the data, the team, or the use?

Listen for: the use — purpose travels with the data, not with the org chart. The same row can be simultaneously legal to query for fraud prevention and illegal to query for marketing; nothing about the row changes, only the purpose does. Consent language ("to protect your account") is a scope, and anything outside the scope needs new consent, whatever the warehouse permissions say.

Weak signal: "the data is ours — customers accepted the terms." Scope-blind consent reading is exactly the interpretation privacy regulators reject; consent to one purpose is not consent to all purposes.

How would the warehouse know that a fraud-prevention table is off-limits to a marketing query?

Listen for: purpose represented as machine-readable metadata — tags on tables and columns in the catalog, inherited by derived tables through lineage; grants that declare a purpose, with a policy engine matching grant purpose to data purpose (attribute-based access control); and a purpose-mismatch monitor on query logs as the detective control behind the preventive one.

Weak signal: "training and a policy memo." Anything that lives in human memory rather than the platform is the exact control that already failed in this story.

The reveal

A regulator opens an inquiry into consent scope: customers agreed to protection, not promotion. The reuse was technically trivial — same warehouse, same SQL, one grant — and that's exactly the problem. Nothing in the platform represented purpose, so nothing could enforce it, and a ten-minute query became a legal event.

Why this happens — the mechanics

Purpose metadata doesn't survive warehouse consolidation because nothing in the pipeline carries it. An ETL (Extract, Transform, Load) job preserves types, values, and schemas — the properties queries need — and strips the legal context, because no column type exists for "collected under the fraud-prevention consent notice, v3." Consolidation then works against governance by design: the whole point of a shared warehouse is to make everything joinable by everyone with a grant, and joinability is precisely the property that dissolves collection context. The moment fraud tables landed in the shared warehouse without a purpose tag, the violation stopped being a question of if.

Access control is team-shaped because identity infrastructure predates privacy law. Grants, roles, and groups answer the questions engineering organizations natively ask — who are you, which team are you on — and a marketing analyst with a warehouse grant is, by every check the platform runs, a legitimate user running legitimate SQL. Purpose limitation — the principle, anchored in the GDPR (General Data Protection Regulation — the EU's privacy law, Article 5(1)(b)) and echoed in consent-scope expectations elsewhere, that data may only be used for the purpose it was collected for — asks a question the grant model cannot even express: not who, but why.

That gap makes violation the path of least resistance. Doing the compliant thing — noticing that cross-sell is a new purpose, triggering a consent review, obtaining new consent — requires legal knowledge, judgment, and friction; doing the violating thing requires ten minutes of SQL and produces a great campaign. When the platform expresses no purpose boundary, every incentive points across the line, and each successful reuse normalizes the next one. The query history that eventually tells the whole story was there all along — nothing was hidden, because nobody involved believed anything was wrong.

Diagrams

Problem — how the failure unfolds:

sequenceDiagram
    autonumber
    participant FD as Fraud data
    participant WH as Warehouse
    participant MA as Marketing analyst
    participant CU as Customer
    participant RG as Regulator
    Note over FD: Collected to protect<br/>your account
    FD->>WH: Lands in shared warehouse -<br/>access by team, not<br/>purpose (silent)
    MA->>WH: Valid grant - queries<br/>fraud tables
    Note over MA: Cross-sell targeting built<br/>on fraud signals (silent)
    MA->>CU: Eerily well-targeted offer
    CU-->>RG: Complaint - privacy audit<br/>pulls the thread
    Note over WH: Query history tells<br/>the whole story
    RG->>WH: Inquiry into consent scope -<br/>protection, not promotion

Solution — where the guardrails go:

flowchart TD
    A["Device and behavioral data<br/>collected for fraud<br/>prevention"] --> T["Purpose tag travels with<br/>the data as metadata"]
    T --> G["Access grants name a<br/>purpose, not just a team"]
    G --> Q["Marketing requests access<br/>for cross-sell"]
    Q --> C["Consent review: cross-sell<br/>is outside consented scope"]
    C --> D["Request denied — or new<br/>consent obtained first"]
    T -.-> M["Purpose-mismatch monitor<br/>on query logs"]
    M -.-> AL["Off-purpose access flagged<br/>in days, not after a<br/>complaint"]

What good looks like

The lesson

Purpose limitation — the privacy principle that data may only be used for the purpose it was collected for — is an access-control dimension, not a policy memo. Data carries its consented purpose as metadata; access grants name a purpose, not just a team; and reuse for a new purpose triggers a consent review, not just a warehouse permission request. If the platform can't tell fraud prevention from marketing, then legally speaking, neither can you.

Named concepts: purpose limitation, consent scope, data-use governance, privacy by design.

Real-world echoes

Transfer

Pick our most sensitive dataset and answer: what purpose was it collected for, where is that recorded, and what — other than good intentions — stops a differently-purposed team with warehouse access from querying it tonight?

Make it a ticket: Tag our most sensitive dataset with its collected purpose in the catalog, and wire one warehouse policy that blocks — or at minimum flags — queries from grants that don't declare that purpose. One dataset, one policy, this sprint; the pattern scales from there.

Related