GDPR and CSV Exports: What You Can and Can't Share With a Third Party

You are about to send a CSV export to an agency, a freelance analyst, or a vendor. The file has customer data in it. Someone on your team says “make sure it’s GDPR compliant before you send it”. You nod, because you are not going to admit you do not know exactly what that means in practice.

Most people in RevOps, Sales Ops, and marketing operations are in this situation. They know GDPR exists, they know it applies to customer data, they know “anonymized” data is treated differently from raw data. They do not always know where the line is, what “anonymized” actually requires, and what hashing or redacting does to a file’s regulatory status.

This article is not legal advice. It is a plain-language explanation of what GDPR says about the kind of CSV sharing that happens every day in B2B operations, so you can have an informed conversation with your DPO or legal team and not send something you should not have.

What GDPR considers “personal data”

The starting point is simple. GDPR applies whenever you are processing personal data, which the regulation defines as any information relating to an identified or identifiable natural person.

In a typical sales or marketing CSV, that includes the obvious columns: name, email address, phone number, home or business address, IP address, user ID. It also includes less obvious columns: a job title combined with a company name often identifies a single individual, especially in smaller companies. A LinkedIn URL is personal data. A “last login” timestamp tied to a user account is personal data.

The test is not whether the column looks identifying on its own. The test is whether, in combination with other data the recipient might have, the row could be linked back to a specific person.

If the answer is “yes, even in combination”, the column is personal data, and GDPR applies to it.

If the answer is “no, not under any reasonable scenario”, the column is not personal data, and GDPR does not regulate sharing it.

The crucial distinction: anonymized vs pseudonymized

This is the single most useful concept to understand, and the one most people get wrong.

Anonymized data is data that has been processed in a way that the original individual can no longer be identified, by anyone, using any reasonable means. Once data is genuinely anonymized, it is no longer personal data, and GDPR does not apply to it. You can share it with whoever you want, for whatever purpose, without consent or a legal basis.

Pseudonymized data is data where the direct identifiers have been replaced with artificial identifiers (like hashes), but where re-identification is still possible if you have access to additional information (a key, a mapping table, another dataset). Pseudonymized data is still personal data under GDPR. All the obligations still apply: legal basis, consent where required, data processing agreements with recipients, the right to deletion, the right to access, breach notification, and so on.

The difference matters enormously in practice:

• Replacing email addresses with hashes is pseudonymization, not anonymization. The data is still in scope.
• Replacing names with fake names while keeping a usable customer ID is pseudonymization, because the ID still links rows to a specific real customer.
• Removing all direct identifiers and aggregating to the point where no row could ever be linked back to an individual is anonymization. This usually means dropping or generalizing many columns, not just the obvious ones.

Most “anonymized” CSV exports you see in the wild are actually pseudonymized. That is not a problem, as long as you treat them like the personal data they still are.

When you can share personal data with a third party

GDPR does not forbid sharing personal data with vendors, agencies, or consultants. It requires that the sharing has a legal basis, and that the recipient handles the data appropriately. The two main mechanisms are:

Data Processing Agreement (DPA). If the third party is processing the data on your behalf (running an analysis, building a model, doing the work you hired them for), they are a “processor” and you are a “controller”. You need a written contract that includes specific GDPR-mandated clauses about how they handle the data, security measures, sub-processors, breach notification, and what happens to the data when the engagement ends. Most reputable agencies and vendors have a DPA template ready.

Legitimate interest or consent. The original collection of the data must have a legal basis (consent, contract, legitimate interest, etc.), and the sharing has to be compatible with that basis. You cannot collect data for one purpose and share it for an unrelated one without a fresh basis.

In practice, for typical B2B operations work:

• Sharing your customer list with an agency you hired to do CRM cleanup: probably fine with a DPA in place, because it is processing on your behalf.
• Sharing your customer list with a vendor who will use it to enrich and resell: requires more careful legal review, because the vendor is acting as a controller, not a processor.
• Sharing aggregated or genuinely anonymized data with anyone: out of GDPR scope.

When in doubt, ask the legal or DPO team. The cost of asking is low, and “I didn’t think it applied” is not a defense.

What hashing actually changes (and what it doesn’t)

A common misconception is that hashing an email address makes the data anonymous, and therefore the file is outside GDPR scope.

This is wrong.

The European Data Protection Board (and most national supervisory authorities) have been clear that hashing is a pseudonymization technique, not an anonymization technique. A hashed email is still personal data, because:

• The original email can be recovered by anyone who can compute the hash and check against a list of likely emails (which, for a known company domain, is a small space).
• The hash links to the same individual every time, so a recipient with multiple files can build a profile around the hash without ever seeing the original value.
• The mapping between original and hash exists somewhere (you can recompute it any time you want), which is exactly what makes the data pseudonymous rather than anonymous.

Hashing is still useful. It is a strong security measure, it reduces the practical risk of exposure, and it is exactly what you should do when sharing a column for joining or deduplication. But the file containing it is still a file containing personal data, and you still need a legal basis and a DPA in place.

The same logic applies to:

• Truncating an email to the local part or the domain.
• Replacing a name with the initials.
• Replacing a customer ID with a different but consistent ID.
• Encrypting a column (especially if the recipient has the key).

All of these are pseudonymization. All of them keep the file in scope.

What genuine anonymization looks like

For a file to actually fall out of GDPR scope, re-identification has to be impossible “by reasonable means”, which in practice requires:

• No direct identifiers. Names, emails, phone numbers, addresses, government IDs are all removed, not just hashed. The recipient should not see any column from which an individual could be recovered.
• No persistent indirect identifiers. Internal customer IDs, even hashed, can still link rows across datasets in a way that builds a profile. For strict anonymization, the linkage between rows of the same individual should be broken.
• Generalization of quasi-identifiers. A row with country = Belgium, age = 47, job title = Head of Demand Generation, deal size = $238,000, closed = 2026-03-15 is likely unique even with all direct identifiers stripped. Anonymization requires generalizing or bucketing these dimensions until no row is uniquely identifiable.
• Aggregation where possible. Sharing “120 deals closed in Q1 in DACH, average value $42k” is anonymous. Sharing the same data at the row level, even with names stripped, often is not.

This is a high bar. Most CSV “anonymization” in the wild does not meet it, and that is fine, as long as you handle the file as pseudonymized data with a DPA and a legal basis.

The practical rule of thumb: assume your output is pseudonymized unless a privacy expert has reviewed it and confirmed otherwise. Treat the file as in-scope personal data. You can still share it; you just have to share it correctly.

A practical checklist before you send the file

Before you email, upload, or hand over a CSV with anything resembling customer data, walk through this:

• Is there a written DPA with the recipient that covers this kind of data?
• Is the recipient acting as a processor (on your behalf) or as a controller (for their own purposes)? The legal requirements differ.
• Is the original collection legal basis compatible with this sharing?
• Have I removed or transformed columns that are not needed for the work? “Send the whole export and let them filter” is the wrong default.
• For columns I kept, have I applied the right transformation (hash for joins, redact for unneeded data, fake for demos, generalize for quasi-identifiers)?
• Have I checked combinations of “safe” columns for unique re-identification?
• Have I confirmed how long the recipient retains the file and how it is deleted at the end?
• Is the transmission channel itself secure (encrypted email, secure file share, not a plain attachment to a generic inbox)?
• Have I documented what was shared, with whom, when, and under what basis? If a subject access request or a regulator audit lands, you will need this.

What “data minimization” actually means in practice

GDPR’s data minimization principle says you should only process personal data that is “adequate, relevant, and limited to what is necessary” for the purpose. In CSV-sharing terms, this is a strong argument for never sending more than the recipient strictly needs.

The shape of this in practice:

• If the agency only needs deals and segments, do not include contact emails or phone numbers.
• If the consultant only needs counts and distributions, do not include row-level data.
• If the vendor only needs to match against your customer list, send a one-column file of hashed identifiers, not your full CRM extract.
• If they say “send the whole export, I’ll filter later”, push back. The unused columns are a liability, not a convenience.

Data minimization is the single highest-leverage practice for reducing GDPR risk on outbound file sharing. It costs almost nothing to apply and removes most of the risk surface.

Where Asphorem fits in

The Data Anonymizer is designed for the realistic case: you are sharing data that needs to be transformed, column by column, before it can leave your environment. Each column gets the right strategy (redact, hash, fake, round, bucket, shift) for the role it plays in the recipient’s analysis.

Everything runs in the browser. The file is not uploaded to any server (including Asphorem’s), which is the only sensible default when the entire point of the exercise is to control where the data goes. There is no server log, no temporary file on a backend, no copy in cloud storage; the transformation happens locally and the only output is the file you choose to download.

For the column-by-column decision logic, see the companion piece on which anonymization strategy to use for each column. For a worked example of preparing a real file for a real third party, see how to anonymize a CSV before sharing it with a contractor.

Frequently asked questions

Does GDPR apply if my company is based outside the EU?

It applies whenever you process the personal data of individuals located in the EU, regardless of where your company is based. A US company with EU customers is subject to GDPR for those customers’ data. Many other jurisdictions (UK, Switzerland, Brazil, several US states) have similar regimes with their own quirks; the practical advice in this article translates well across most of them.

Is a signed NDA enough to share a CSV with a contractor?

An NDA is a contract obligation, not a GDPR legal basis. You still need a Data Processing Agreement (which includes the GDPR-specific clauses about security, sub-processors, deletion, breach notification, and so on) and a legal basis for the underlying processing. An NDA on top is good practice, but it does not substitute for the DPA.

What if I “anonymize” the file by deleting the name and email columns?

You have removed two direct identifiers. The file is probably still pseudonymous, not anonymous, because the remaining columns (especially combinations of company, role, deal value, dates, location) often re-identify individual records. Treat the file as still in scope unless you have done the work to confirm true anonymization.

Does encrypting the file in transit make it GDPR compliant?

Encrypting in transit is a security measure (and an important one), but it does not change the regulatory status of the contents. The file is still personal data, and the recipient still needs to handle it appropriately. Encryption protects the file from interception; it does not protect against the recipient mishandling it after they decrypt it.

What happens if the recipient has a breach involving my file?

If they are a processor acting on your behalf, they are contractually obliged (via the DPA) to notify you quickly, and you may be obliged to notify the supervisory authority within 72 hours of becoming aware. The fewer columns and the better the pseudonymization, the smaller the breach is in scope and impact. This is another argument for minimization: a breach of a hashed, generalized file is a much smaller incident than a breach of the raw export.

Can I rely on the recipient’s claim that their tools are GDPR compliant?

Their tools being compliant does not relieve you of your obligations as controller. You still need to vet them (security measures, sub-processor list, location of data, deletion practices), and you still need the DPA. “We use a GDPR-compliant CRM” is a reasonable starting answer; it is not a final one.