Our Analytics Vendor Asked for Customer Data. We Almost Sent It Unredacted.

We'd signed a new analytics vendor. Onboarding was smooth. Then they sent the intake email:

"To configure your dashboards, we'll need a sample export of your customer data. Ideally 3-6 months of transaction history with customer identifiers so we can set up cohort analysis."

Our marketing ops lead pulled the export. 47,000 rows. Customer name, email, transaction amount, date, product category, location.

She was about to attach it to the reply when she paused and Slacked me: "Do I need to do anything with this before I send it?"

Why "Just Delete the Name Column" Doesn't Work

The instinct is to delete the obviously personal columns (name, email, phone) and send the rest. But look at what's left:

CustomerId,TransactionAmount,Date,ProductCategory,City,PostCode
1001,£2340.50,2024-11-15,Electronics,Leeds,LS1 5AR

CustomerId is a direct identifier. City + PostCode + purchase pattern is potentially re-identifiable. If someone knows that customer #1001 bought £2,340.50 of electronics in Leeds on November 15th, they can probably figure out who that is.

GDPR doesn't just cover names and emails. It covers any data that can be used to identify a person directly or indirectly. A transaction history with location data is personal data even without a name column.

The Actual Risk

Most vendor data sharing incidents don't become headlines. They become ICO complaints from individual customers who discover their data was shared without appropriate safeguards. The fine might be modest (£10K-50K), but the investigation takes months, the legal costs are real, and the reputational impact with that specific customer is permanent.

More practically: your vendor's security is now your problem. If their systems are breached and your unredacted customer data is in there, you're jointly liable. You've extended your data breach surface to include every vendor you share data with.

What We Do Now

Every data export that leaves our organisation goes through ComplyTech first. The marketing ops team doesn't need to understand regex or run scripts. We built a simple internal web form that takes a CSV upload, calls the API, and returns the cleaned file.

For the analytics vendor use case, pseudonymisation works better than redaction because they need consistent customer identifiers for cohort analysis:

curl -X POST https://api.comply-tech.co.uk/api/v1/anonymise \
  -H "X-Api-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "CustomerId,Name,Email,Amount,Date,City,PostCode\n1001,Sarah Jones,sarah@gmail.com,£2340.50,2024-11-15,Leeds,LS1 5AR",
    "contentType": "csv",
    "strategy": "Pseudonymise",
    "frameworks": ["GDPR"]
  }'

The vendor gets realistic-looking data with consistent fake identifiers. They can build cohort analysis on the pseudonymised IDs. They can't identify actual customers.

The Five-Minute Rule

We now have a policy: if a data export can be anonymised in under five minutes, there's no excuse for sending it raw. With the API, most exports take 30 seconds. The barrier is so low that "I didn't have time" isn't a credible answer anymore.

Try It