GDPR for Crypto and Web3 Platforms: What You Must Have Before Launch
🔒 IP & IT Law · GDPR Guide
GDPR for Crypto and Web3 Platforms: What You Must Have Before Launch
The specific GDPR obligations that apply to crypto and Web3 platforms — the immutability problem, KYC data retention, cookie consent, DPAs, and cross-border transfers — and what to have ready before you go live.
1
Why crypto platforms have unique GDPR challenges
The obligations standard SaaS doesn’t face
2
The immutability problem: blockchain vs GDPR
Right to erasure on an immutable ledger
3
What you must have before launch
The pre-launch GDPR compliance checklist
4
Cookie consent, privacy policy, and DPAs
The three documents every platform needs
5
GDPR compliance timeline for crypto startups
What to do now vs what can wait
🔒 Section 1
Why crypto platforms have unique GDPR challenges
GDPR applies to any platform that processes EU personal data — regardless of where the platform is incorporated. For crypto and Web3 platforms, three specific factors make GDPR compliance materially harder than for standard SaaS.
Three GDPR challenges unique to crypto and Web3
Why the standard SaaS compliance approach does not work
3 challenges
1
KYC data creates a heavy personal data processing burden
If you are a VASP, you are required by AML/CFT regulation to collect and retain significant personal data: full name, date of birth, government ID, address, and for higher-risk clients, source of wealth. This creates a large, sensitive personal data set subject to GDPR — with strict requirements for retention periods, access controls, breach notification, and data subject rights.
The tension: AML/CFT law requires retention of KYC data for 5 years (and up to 10 in some jurisdictions). GDPR requires data minimisation and limits retention to what is necessary. These obligations can conflict — and you must be able to document the legal basis for every retention decision.
2
Blockchain data is pseudonymous but not anonymous — GDPR applies
A common misconception: “we don’t process personal data — we only store wallet addresses on-chain.” Wallet addresses are pseudonymous, not anonymous. If a wallet address can be linked to an identified individual — through KYC records, on-chain analytics, or public information — it is personal data under GDPR.
Practical implication: Any on-chain data associated with a KYC’d user is personal data. Your smart contracts, transaction history, and on-chain records may constitute GDPR-regulated processing. You need to have a legal basis for this processing and address the right to erasure problem.
3
Cross-border data transfers are the norm in crypto infrastructure
Crypto platforms typically use cloud infrastructure, KYC providers, analytics tools, and compliance services across multiple jurisdictions — including the US, Israel, and other non-EEA countries. Every transfer of EU personal data to a third country requires an appropriate transfer mechanism: Standard Contractual Clauses (SCCs), adequacy decision, or other approved safeguard.
The practical burden: Most crypto platforms have not mapped their data flows or executed SCCs with their sub-processors. This is a systematic GDPR gap — and one that data protection authorities are increasingly investigating following Schrems II.
GDPR enforcement in crypto is accelerating
European data protection authorities have issued fines against crypto exchanges and payment platforms for inadequate data protection practices. The “we are in crypto, GDPR doesn’t really apply to us” assumption is no longer viable.
⛓️ Section 2
The immutability problem: blockchain vs right to erasure
GDPR’s right to erasure (Article 17) requires that you delete personal data when a user requests it. Blockchain’s core property is immutability — data written to the chain cannot be deleted. This creates a direct conflict that you need to address in your architecture and documentation before launch.
🔗 On-chain data
Immutable — cannot be deleted
Transaction records and hashes
Transaction amounts, timestamps, and cryptographic hashes are written permanently to the chain. If these can be linked to an identified individual, they are personal data that cannot be deleted by technical means.
Wallet addresses associated with KYC’d users
Once you have KYC’d a user and linked their wallet address to their identity, that wallet address is personal data in your systems — even though the address itself is publicly visible on-chain.
Smart contract interactions
If smart contract calls include or are linked to personal data, those interactions are permanent on-chain records. Design smart contracts to avoid personal data on-chain wherever possible.
EDPB guidance: pseudonymisation is the key
The European Data Protection Board acknowledges that on-chain personal data cannot always be erased. The recommended approach: keep personal data off-chain; use cryptographic keys or hashes on-chain that become meaningless when the off-chain key is deleted.
💾 Off-chain data
Mutable — GDPR applies in full
KYC records and identity documents
Full name, date of birth, government ID scans, address, and proof of residence — stored in your KYC system. These are fully mutable: you can delete them, subject to AML/CFT retention obligations.
User profile data and account information
Email addresses, phone numbers, passwords (hashed), preferences, and account settings. All deletable on a valid erasure request — subject to any legitimate override.
Transaction metadata in your database
Your internal database records of user transactions — separate from the on-chain record. These are your data and are fully deletable. Ensure your database schema separates the on-chain hash from personal data fields.
AML/CFT retention obligations override erasure
GDPR’s erasure right does not apply where retention is required by law. KYC data must be retained for 5 years post-relationship under AMLD6. Document this clearly in your privacy notice and data retention policy.
The architecture solution
Keep all personal data off-chain, and ensure on-chain data uses only pseudonymous identifiers (wallet addresses, hashed keys) that are meaningless without the off-chain key. When a user requests erasure, delete the off-chain mapping — the on-chain data becomes effectively anonymised. Document this architecture in your data protection impact assessment.
✅ Section 3
What you must have before launch
Some GDPR requirements are pre-launch obligations — you cannot process EU personal data without them in place. Others can be addressed post-launch as the platform scales. Here is the non-negotiable pre-launch list.
GDPR pre-launch compliance checklist
Required before you process EU personal data
Pre-launch
Legal basis documented for every processing activity
For each category of personal data you process (KYC, marketing, analytics, platform use), document the legal basis: consent, contract performance, legal obligation, or legitimate interests. GDPR requires you to identify the basis before processing begins.
Privacy notice / privacy policy published and accessible
A GDPR-compliant privacy notice explaining: who you are, what data you collect, the legal basis for each processing activity, retention periods, rights available to data subjects, and how to exercise them. Must be written in plain language and accessible at or before the point of data collection.
Cookie consent mechanism implemented correctly
A compliant cookie consent banner that presents options before setting non-essential cookies, does not use pre-ticked boxes, allows granular category selection, and records consent. “Accept all” without a “reject all” option is not compliant under GDPR and ePrivacy.
Data Processing Agreements (DPAs) signed with all processors
Every service provider that processes EU personal data on your behalf — KYC providers, cloud hosting, analytics, email marketing, customer support — must have a GDPR-compliant DPA in place. Check your agreements with AWS, Google Cloud, Stripe, Sumsub, and every analytics tool you use.
Cross-border transfer mechanisms in place
If personal data is transferred to a non-EEA country (US, Israel, India, Singapore), you need a lawful transfer mechanism: EU Standard Contractual Clauses (SCCs), an adequacy decision, or Binding Corporate Rules.
Data retention policy and deletion mechanism
A documented policy setting out how long each category of personal data is retained and why. KYC data: 5 years from end of relationship (AML/CFT minimum). You must be able to actually delete data — have a technical mechanism in place.
Data subject rights process in place
A process to handle: access requests (provide all personal data held within 30 days), erasure requests (delete where no retention obligation applies), rectification requests, and objections to processing. Log all requests and responses.
Data breach response procedure documented
GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Have an incident response plan that includes: breach identification, internal escalation, supervisory authority notification, and individual notification where required.
DPAs with sub-processors: the most overlooked requirement
The most common GDPR gap in crypto platforms at launch is missing DPAs with sub-processors — particularly KYC providers and analytics tools. Without a DPA, every transfer of EU personal data to that provider is a GDPR violation.
📄 Section 4
Cookie consent, privacy policy, and DPAs
Three documents every crypto platform needs — and what specifically must be in each for it to be GDPR-compliant, not just GDPR-labelled.
User-facing
Cookie consent mechanism
What it must do and what it cannot do
Must do: Present before setting non-essential cookies. Offer granular categories. Provide an equally prominent “reject all” option. Record and store the consent choice with a timestamp. Allow withdrawal as easily as giving consent.
Cannot do: Pre-ticked boxes. Consent obtained through scrolling or continued use. “Accept all” without a “reject all.” Burying the reject option in settings two layers deep.
Crypto-specific: Most analytics tools used in crypto (Mixpanel, Amplitude, Heap) are tracking cookies — they require consent.
User-facing
Privacy notice / privacy policy
GDPR Article 13/14 mandatory content
Must include: Your identity and contact details. Data protection officer contact (if applicable). Categories of personal data collected. Legal basis for each processing activity. Retention periods. Third-party recipients and sub-processors. Cross-border transfer mechanisms. All data subject rights.
Crypto-specific additions: Explicit section on KYC data — legal basis (AML/CFT legal obligation), retention period (5 years), and limitation on erasure right. Section on on-chain data and the immutability limitation.
Not acceptable: A generic SaaS privacy policy repurposed for crypto. A policy that promises erasure of data that cannot actually be erased.
B2B requirement
Data Processing Agreements (DPAs)
GDPR Article 28 mandatory for all processors
What it covers: The subject matter, duration, nature and purpose of the processing. The type of personal data and categories of data subjects. Your obligations and rights as controller. The processor’s obligations: only process on your instructions, ensure confidentiality, implement appropriate security, assist with data subject rights.
Who needs a DPA: Every service provider that processes EU personal data on your behalf — cloud hosting (AWS, GCP, Azure), KYC providers (Sumsub, Onfido, Jumio), analytics platforms, email services, customer support tools.
What it cannot fix: A DPA does not make an unlawful transfer lawful. If the provider is in a third country without an adequacy decision, you also need SCCs.
These three documents are the minimum GDPR infrastructure for a crypto platform processing EU personal data. A privacy policy that does not address the KYC data retention conflict, a cookie banner without a genuine reject option, or a missing DPA with your KYC provider are all active GDPR violations from the moment your first EU user signs up.
📅 Section 5
GDPR compliance timeline: what to do now vs what can wait
Not everything needs to be perfect at launch. Here is a realistic sequencing of GDPR compliance work — what must be in place before you process EU data, and what can be addressed in the first 6 months of operation.
GDPR compliance timeline for crypto platforms
What must be done before launch vs within 6 months
5 stages
1
Before launch: core compliance infrastructure
Pre-launch — non-negotiable
Privacy notice/policy. Cookie consent mechanism. DPAs with all processors. SCCs for cross-border transfers. Legal basis mapping. Data retention policy. Data breach response procedure. These must be complete before your platform processes a single EU personal data point.
2
Month 1–2: data mapping and ROPA
First 60 days of operation
Build a complete Record of Processing Activities (ROPA) — documenting every processing activity, data categories, legal basis, retention periods, and recipients. Your ROPA is what the supervisory authority will request in any investigation.
3
Month 3–4: DPIA for high-risk processing
Required for large-scale KYC processing
A Data Protection Impact Assessment (DPIA) is mandatory for processing that is likely to result in high risk to individuals — including large-scale processing of biometric data (facial recognition in KYC). If your KYC process involves biometric checks, a DPIA is not optional.
4
Month 5–6: staff training and internal policies
Operational compliance phase
Internal data protection policies (acceptable use, data handling, breach reporting). Staff training on GDPR obligations, data subject rights handling, and breach identification. Annual review cycle for the privacy notice and ROPA.
5
Ongoing: monitoring, updates, and incident response
Permanent operational requirement
GDPR compliance is not a project with an end date — it is an ongoing operational requirement. Monitor for regulatory guidance changes. Review your cookie consent mechanism annually. Update DPAs when vendors update their terms. Test your breach response procedure at least annually.
Get your GDPR compliance right before launch — not after
Our data protection team works with crypto and Web3 platforms on pre-launch GDPR compliance: privacy notices, cookie consent, DPAs, ROPA, and DPIA. We understand the specific tensions between GDPR, AML/CFT, and blockchain architecture.
Post Comment