The Bank of England, in its October statement, confirmed that many firms in the financial sector are already using AI, exploring opportunities to use quantum computing, and piloting DLT applications. One example is stablecoins built on DLT networks, which are already being used at scale by individuals and businesses worldwide for faster, cheaper cross-border payments and automated financial contracting. However, the bank admits that key barriers to scaling up blockchain solutions are regulatory frameworks that are not entirely suited to digital assets and cross-border initiatives. Blockchain’s inherent characteristics present unique challenges for GDPR compliance. 

When it comes to handling personal data, blockchains present a significant challenge in respecting data subject rights. Its immutability, for example, contradicts the fundamental “Right to be Forgotten”. The global distribution of blockchain nodes also complicates regulatory supervision. Conducting a Data Protection Impact Assessment (DPIA) is not just a legal requirement for high-risk blockchain-based personal data processing, but is an important step towards responsible innovation. To help organisations meet these requirements, TechGDPR has created a free downloadable Blockchain DPIA Template, which guides users through all required areas of GDPR compliance:

• Description of the processing operations
• Legal basis and necessity assessment
• Identification of risks
• Safeguards and technical measures
• Implementing privacy by design principles
• Data subject rights and governance structures

The pre-designed template includes ready-to-use sections, prompts, and examples, significantly saving time and ensuring that no critical aspect of your DPIA is overlooked.

Stay up to date! Sign up to receive our fortnightly digest via email.

UK Adequacy

The European Data Protection Board, EDPB, has issued its opinion on the adequate protection of personal data by the United Kingdom. In July 2025, the European Commission started the process towards the adoption of its draft implementing decision on the adequate protection of personal data by the UK. It extends the validity of certain parts of the previous adequacy decision until December 2031. In particular, the EDPB asks for the need to further clarify by the Commission recent changes in the UK post-Brexit legislation regarding: 

• removing the direct application of the principles of EU law, including the right to privacy and data protection
• new powers to introduce changes via secondary regulations, which require less Parliamentary scrutiny (eg, on international transfers, automated decision-making)
• changes to the rules governing third-country transfers
• processing exemptions for law enforcement 
• restructuring of the Information Commissioner’s Office 
• safeguards provided by the EU-US Umbrella Agreement, whose privacy and data protection safeguards are incorporated into the UK-US Cloud Act Agreement
• encryption to remain essential for ensuring the security and confidentiality of personal data and electronic communications.

AI Act and the GDPR

The European Parliament has published a study on the Interplay between the AI Act and the EU digital legislative framework, including the GDPR. In particular, the AI Act introduces requirements for fundamental rights impact assessments (FRIAs) in cases that often also trigger data protection impact assessments (DPIAs) under the GDPR. These instruments differ in scope, supervision, and procedural requirements, creating duplication and uncertainty. Transparency and logging obligations are also redundant across both regimes. Moreover, there is ambiguity over how data controllers and AI providers should manage rights of access, rectification, and erasure when personal data becomes embedded in complex AI models. 

In AI contexts, the GDPR-governed “legitimate interests” legal basis is widely regarded as the most relevant and frequently invoked basis, states the report. Meanwhile, consent is often impracticable and contractual or legal obligation bases rarely map neatly onto AI training or deployment scenarios. Finally, the AI Act introduces additional governance layers: the AI Office and the European AI Board at the EU level and the national GDPR supervisory bodies with respect to data protection issues, which produce a potentially overlapping set of competent supervisory bodies. 

Legal updates

Dragi report: The Future of Privacy Forum takes a closer look at the report on European competitiveness issued in 2024 by former Italian Prime Minister Mario Draghi, which calls for simplification of the GDPR, and criticizes “heavy gold-plating” by Member States in GDPR implementation. The Commission is now set to announce a Digital Omnibus package with proposals to quickly reduce the burden on businesses. However, changes to the GDPR fundamental principles could bring any reform into conflict with the TFEU and the Charter and lead to action before the Court of Justice. 

GDPR enforcement: On 21 October, the European Parliament passed the regulation on additional procedural rules regarding the enforcement of the GDPR. The document aims to harmonise the criteria for assessing the admissibility of cross-border complaints and clarifies the rights of complainants and entities under investigation. The regulation establishes the same admissibility standards no matter where in the EU the GDPR complaint was filed. Both complainants and companies involved will have the right to be heard at specific stages of the investigation and will receive preliminary findings to express their views before a final decision is issued. 

Data for research: From 29 October, researchers can request data access from very large online platforms and search engines to study systemic risks. Access to public platform data has been available since the Digital Services Act (DSA) came into force in February 2024. Researchers now have the opportunity to request access to platforms’ internal data and to investigate its impact on society. Since datasets can allow direct or indirect inferences about individual users through their interactions, profiles, or other published content, researchers must comply with the requirements of the GDPR when carrying out their projects.

More from supervisory authorities

DSA and the GDPR: The EDPB has closed the consultation on the guidelines on the interplay between the Digital Services Act and the GDPR. One of its sections examines the limits on automated decision-making that involves the processing of personal data by intermediary service providers. The paper also further examines the transparency of processing and deceptive design patterns prohibited by the DSA when these practices involve personal data.  It also reviews the relationship between profiling restrictions and advertising technology, systematic risk assessments and minors’ data protection.

China privacy updates: China has issued its first national standard for certification of cross-border personal information processing. The standard, which takes effect on March 1, 2026, sets out fundamental principles, security requirements, and obligations for safeguarding individuals’ rights in cross-border data processing. Reportedly, the certification is valid for three years. The applicant may reapply for certification for continual use of such certification six months before its expiration. In general, under the Chinese Personal Information Protection Law (PIPL), a data handler may transfer personal information outside of China if one of the following three conditions (with some exemptions) is met:

• Apply for and pass the security assessment;
• Sign and file the standard contract; or
• Obtain the personal information protection certification.

Hacked emails

Almost one in ten people affected by cybercrime in the previous year experienced unauthorised access to an online account or email. To provide targeted support to consumers in such cases, the German Federal Office for Information Security (BSI) published a guide – Emergency checklist: Hacked account (in German). If a person can no longer log in despite having the correct password, their email account may have been hacked. Changes in settings or attempts to log in from new devices can also be signs. To protect your account, the BSI recommends securing it with either a strong password combined with two-factor authentication or with passkeys. 

IoT security

According to America’s NIST, IoT products often lack product cybersecurity capabilities that their customers, organisations and individuals can use to help mitigate their cybersecurity risks. Manufacturers can help their customers by providing necessary cybersecurity functionality and the cybersecurity-related information they need. To that end, NIST closes public consultations and offers a public draft of Foundational Cybersecurity Activities for IoT Product Manufacturers. This publication describes recommended activities that manufacturers should consider performing before their IoT products are sold to customers. 

GenAI guidance

European Data Protection Supervisor (EDPS) has published its revised and updated guidelines on the use of generative AI and processing of personal data by EU institutions, bodies, offices, and agencies (EUIs), reflecting the fast-moving technological landscape and the evolving challenges posed by generative AI systems. It introduces several key updates, including:

• a refined definition of generative AI for greater clarity and consistency
• a new, action-oriented compliance checklist for EUIs to assess and ensure the lawfulness of their processing activities
• clarified roles and responsibilities, assisting EUIs in determining whether they act as controllers, joint controllers, or processors
• detailed advice on lawful bases, purpose limitation, and the handling of data subjects’ rights in the context of generative AI.

Capita fine

The UK’s privacy regulator, ICO, issued a fine of 14 million pounds to Capita for failing to ensure the security of personal data related to a breach in 2023 that saw hackers steal millions of people’s information, from pension records to the details of customers of organisations Capita supports. For some people, this included sensitive information such as details of criminal records, financial data or special category data. Capita processes personal information on behalf of over 600 organisations providing pension schemes, with 325 of these organisations also impacted by the data breach.

The investigation found that Capita, in its capacity as a data controller, had failed to ensure the security of the processing, as well as lacking the appropriate technical and organisational measures. In particular, Capita did not prevent both privilege escalation and unauthorised lateral movement through the network, and did not effectively respond to security alerts when detected.    

Grindr fine confirmed

On October 21, Norway’s Borgarting Court of Appeal upheld Grindr’s multi-million privacy fine for violating Art. 9 of the GDPR, which forbids the processing of specific categories of personal data. The court decided that sharing a dating app user ID with advertisers revealed sensitive information regarding their sexual orientation. It further stated that consent was invalid since it was combined with service access, giving customers no real option.

Grindr’s multi-page privacy policy was also unclear concerning the extent and beneficiaries of data sharing, according to the Digital Policy Alert legal blog.

In other news

Data security fine: Australian Clinical Labs (ACL) has been ordered to pay AUD 5.8 million for breach of the Privacy Act 1988 following a 2022 cyber incident which impacted the personal information of over 223,000 individuals. This is the first civil penalty under the Privacy Act, DLA Piper law blog reports. The incident occurred within the IT environment of ACL’s subsidiary, Medlab Pathology, which was acquired only 3 months prior. Critical vulnerabilities in the subsidiary’s IT systems were not properly identified before the acquisition, as part of the due diligence process, as ACL intended to fully integrate them into its own IT environment within the following 6 months.

Insurance data security fines: The New York state Attorney General secured a 14.2 million fine from car Insurance companies over data breaches. Eight car insurance companies’ poor cybersecurity allowed hackers to steal driver’s license numbers to fraudulently obtain unemployment benefits, failing to protect the private information of more than 825,000 New Yorkers. These companies allowed people to obtain a car insurance price quote using an online tool. Some of the companies also provided password-protected tools to insurance agents to generate quotes for customers. The investigation found that data thieves were able to exploit a “pre-fill” function in the companies’ online quoting tools.

Electronic identification services fine: In Finland, the Data Protection Ombudsman has imposed an 865,000 euro fine on Aktia Bank for neglecting information security in its electronic identification service. Due to a short-term disruption, some people who logged into various services with Aktia’s bank codes had access to other customers’ highly personal information, as the service mixed up the identification of people. The regulator found that the bank had shortcomings in the planning, implementation and testing of a technical change made to the service.

Patient data breaches

Polish regulator UODO imposed an approximately 10,000 euro fine on Gyncentrum for failing to report a personal data breach. A medical centre specialising in infertility treatment, among other things, sent a communication, the subject line of which indicated the name of a genetic test, to another person, also a patient of the centre (with the same name). The document contained personal data: first name, last name, bank account number, and address. It also included the transfer amount and the name of the test performed, revealing that it was part of an extensive prenatal diagnostic program. The patient herself learned of the incident from another patient at the centre. 

In Guernsey, the Medical Specialist Group (MSG) was also fined 100,000 pounds following a cyber-attack. In 2021, the MSG became aware of a personal data breach after it received suspicious emails indicating that its email server had been accessed by cybercriminals. These vulnerabilities enabled criminals to access and steal e-mails stored on the server, some of which contained sensitive patient health data. These e-mails were subsequently used to facilitate multiple phishing campaigns targeting MSG patients over a series of months. The MSG notified the regulator of this breach. The inquiry found that the company routinely failed to install security updates to its e-mail server over the course of 13 months. This included updates directly related to the breach exploit and other critical vulnerabilities. 

California privacy violations

California’s Attorney General secured a settlement with Sling TV, a streaming service, resolving allegations that the company violated the California Consumer Privacy Act (CCPA) by failing to provide an easy-to-use method for consumers to stop the sale of their personal information and by failing to provide sufficient privacy protections for children. Sling TV is an internet-based live TV service that offers both a paid subscription and a free, ad-supported streaming service. Unlike traditional television, where advertising is based on the content of the programming, Sling TV uses its internet-based platform to deliver highly targeted advertising, using detailed consumer data such as age, gender, location, and income to personalise ads for viewers, often without their awareness.   

In case you missed it

Digital health care: Privacy International suggests that a Digital Health Technology Assessment (dHTA) is needed to make sure that tools developed by the private sector and relied on by public healthcare providers do not harm people and their rights. The Health Technology Assessment (HTA) is a longstanding practice that is used to assess the effectiveness and safety of technological innovations before they can be used in the diagnosis, treatment, management and prevention of health problems.

Thus, there is an overwhelming need for clear and specific rules that engage with the specific needs and challenges of new and emerging practices.

Multi-party computation: An EDPS blog article states that across sectors from health research to financial systems, data sharing continues to drive innovation, yet it also intensifies privacy and compliance challenges, making the balance between access to data and confidentiality increasingly difficult. Secure multi-party computation (SMPC) proposes a way to reconcile these seemingly conflicting goals – enabling organisations to jointly compute insights without revealing their underlying data. Under SMPC, multiple parties can work together to compute a result from their private data without ever exposing that data to one another. Unlike traditional encryption, which protects data only while it’s stored or transmitted, SMPC ensures confidentiality throughout the computation process itself for:

• hospitals improving disease prediction models using patient data,
• banks detecting cross-border fraud patterns,
• governments analysing the impact of social policies,

From a legal perspective, SMPC challenges traditional interpretations of privacy law. Frameworks like the GDPR were not designed with cooperative computation in mind; thus, they must be embedded within transparent governance frameworks and ethical oversight.

The post Data protection digest 19 Oct – 2 Nov 2025: New AI Act and GDPR study & personal data stored on Blockchain appeared first on TechGDPR.

Blockchain is transforming industries by enabling transparency, trust, and decentralization. However, when it comes to handling personal data, blockchain presents significant challenges. The GDPR places strict requirements on data processing, many of which are difficult to reconcile with blockchain’s core characteristics. The European Data Protection Board (EDPB) recently issued draft guidance (Guidelines 02/2025 on processing of personal data through blockchain technologies, for public consultation) where they suggested that when personal data is processed on a blockchain a Data Protection Impact Assessment (DPIA) has to be carried out, and with a low threshold for data being ‘personal’, even transactions would be personal data in many cases.

We created a comprehensive Blockchain DPIA Template that helps organisations meet these requirements by providing a structure and toolkit to assess, document, and manage privacy risks in blockchain systems.

Why Blockchain Needs a Data Protection Impact Assessment 

A Data Protection Impact Assessment, or DPIA, is a crucial process mandated by the GDPR for processing activities that pose a high risk to the rights and freedoms of individuals, or are on specific blacklist. It helps organizations identify and minimize the data protection risks of a project. For emerging technologies like blockchain, which often involve novel data processing methods, conducting a thorough DPIA is not just a legal requirement but a fundamental step towards responsible innovation. This article introduces our new blockchain specific DPIA template, designed to help navigate the complexities of GDPR compliance in decentralized environments.

The challenge of the GDPR in decentralized systems

Blockchain technology introduces features that directly affect privacy and data protection. The GDPR requires organisations to uphold data subject rights, such as the right to erasure, the right to rectification, and the right to access. These rights can be difficult to enforce on an immutable and distributed ledger.

In a typical blockchain network, data is stored across many nodes, sometimes in different legal jurisdictions. This raises questions about international data transfers and how organisations can maintain control over the information they process.

Blockchain’s inherent characteristics present unique challenges for GDPR compliance. Its immutability, for instance, clashes with the fundamental right to erasure. The global distribution of blockchain nodes also complicates data transfers and jurisdictional oversight.

Risks of non-compliance

If an organisation fails to adequately assess and mitigate data protection risks, it may face regulatory action, reputational harm, or loss of user trust. A blockchain DPIA is a critical step to show accountability and demonstrate compliance with the GDPR.

Failing to comply with the GDPR can result in significant fines and severe reputational damage. For blockchain projects, where trust and transparency are paramount, avoiding such risks is critical for long term success.

About the Blockchain DPIA Template

Who is it for?

The blockchain DPIA template is designed for privacy professionals, compliance officers, legal teams, blockchain developers, and project leads. It provides a structured way to assess the data protection implications of blockchain-based processing.

This template is an invaluable resource for privacy professionals, blockchain developers, and data protection officers, or DPOs, who are grappling with GDPR compliance in the blockchain space.

What does it include?

The template guides users through all required areas of a DPIA under the GDPR:

• Description of the processing operations
• Legal basis and necessity assessment
• Identification of risks
• Safeguards and technical measures
• Data subject rights and governance structures

It focuses on blockchain-specific concerns such as data immutability, public ledger transparency, pseudonymisation, and decentralised accountability.

The template provides a comprehensive framework covering various aspects of a blockchain project. It systematically addresses processing operations, establishes the appropriate legal basis, facilitates thorough risk assessment, and outlines necessary safeguards to uphold data subject rights.

Alignment with GDPR Article 35 and privacy by design principles

Our template is meticulously aligned with Article 35 of the GDPR, which mandates DPIAs for high risk processing. It also strongly promotes privacy by design principles, encouraging privacy considerations from the very initial stages of development.

Key Features and Structure of the Template

Comprehensive processing description

The template helps users map how personal data flows through blockchain systems. This includes both on-chain and off-chain components, data categories, infrastructure models, and participating entities. The template offers a structured approach to mapping how personal data flows and is processed within blockchain environments, a critical first step in any DPIA.

Risk identification tailored to blockchain

The template includes a detailed risk taxonomy specifically designed for blockchain environments. It highlights risks such as:

• Immutability preventing data deletion
• Broad visibility of data on public chains
• International data transfers to unknown jurisdictions
• Difficulties in exercising data subject rights

It specifically addresses the unique risks posed by blockchain technology, including issues related to immutability, transparency, and decentralized governance.

Measures to reduce risk and demonstrate compliance

The template includes practical tools and suggestions for implementing effective risk mitigation strategies and technical safeguards, such as encryption, pseudonymization, and the appropriate use of off chain storage solutions. These are aligned with the GDPR principles of data protection by design and by default.

Benefits of Using This Template

Saves time and ensures completeness

The blockchain DPIA template includes ready-to-use sections, prompts, and examples. It reduces the risk of overlooking key aspects of the GDPR and ensures all critical issues are addressed. Using a pre designed template significantly saves time and helps ensure that no critical aspect of your DPIA is overlooked.

Builds trust with regulators and stakeholders

A well-documented DPIA shows that your organisation takes data protection seriously. It provides a clear record of decisions, risk mitigation strategies, and safeguards, which can be shared with regulators or partners. Demonstrating a commitment to data protection through a thorough DPIA builds trust with regulators and enhances user confidence in your blockchain project.

Supports privacy-respecting innovation

The template helps teams think about data protection from the start. It supports innovation that respects individual rights and meets the expectations of users and regulators alike. Ultimately, this template supports and promotes responsible innovation, allowing blockchain projects to thrive while respecting individual privacy rights.

How to Use the Template Effectively

• Integrating it early in the blockchain development lifecycle.
• A collaborative approach involving legal, technical, and compliance teams is essential for a holistic and accurate DPIA.
• Periodic reviews and updates as the project evolves.

The TechGDPR Blockchain DPIA Template

Our blockchain DPIA template provides a practical solution for navigating these complexities. It helps ensure that blockchain projects are built with privacy and accountability in mind. DPIAs are not merely a bureaucratic hurdle; they are an indispensable tool for ensuring that blockchain technology develops in a privacy respecting manner. By proactively identifying and mitigating data protection risks, we can foster a future where decentralized systems empower individuals while upholding their fundamental rights.

Our Blockchain DPIA Template is available for free and can below.

The post Introducing the Blockchain DPIA Template for GDPR Compliance appeared first on TechGDPR.

Whether it’s about a blockchain, a CRM or cloud storage, this is plain and simple wrong. In the case of blockchain, sure, you may have solved a particular compliance issue, but that doesn’t make your blockchain ‘fully GDPR compliant’.

You will need the right tools to become GDPR compliant, but tools alone will not fix your problems. It’s always about how you use them.

It depends on the data

Your cloud storage provider may be fine for storing an email address and a name, but will hardly ever be able to help you meet the stringent requirements surrounding ‘Special Categories of Personal Data’ (Art. 9, GDPR), such as biometrical, medical or genetical data.

Every data processor you add to your list, will increase your compliance risk, as you are (under most circumstances) primarily responsible for the protection of the Personal Data you are entrusted with. Moreover, you can not trust that your processors are doing what they claim they are doing, you have the obligation to ensure it yourself (even though in practice this is hardly ever done).

What about GDPR tools?

There are tons of tools for GDPR out there, ranging from pimped project management tools giving you a list of tasks to complete to ‘become GDPR compliant’, to sophisticated Data Protection Management Systems. All these systems can help you with compliance, but are not going to achieve it for you. You will still need drive the process, ensure the right information is in there, the right organisational processes are in place, and essentially build a deep understanding of your data-flows and take responsibility for your compliance.

In addition, you will probably be using these tools to also store some kind of personal data. Possibly of your staff that will be using it, or of those people submitting a subject request, or otherwise. So you are potentially increasing your risk profile with these tools as well.

Can you build ‘GDPR compliant’ software?

No you can’t, but you can ensure that the product you are building can be used in a GDPR compliant way by following the following 7 key points:

1. Think about privacy right from the beginning: data protection by design is a key principle, and required by the GDPR (Art. 25), and not doing this could already lead to fines of the ‘lower’ category.
2. Work out the (potential) data flows of your product or service and make sure you understand exactly which Personal Data goes where.
3. Ensure that all of the team involved in product development know at least the GDPR essentials and they are incentivised to take this seriously.
4. Document your efforts to GDPR compliance so you can prove your commitment to it, and your considerations when questions may arise at a later point in time.
5. Select your vendors that will have access to, or process the Personal Data that has been entrusted to you with care. Ensure they are aware of their obligations and take them seriously, always have a Data Processing Agreement in place, and know where (exactly) your data resides.
6. If you can, keep Personal Data out of the US and out of the hands of US companies. While companies in the US may be self-certified under the EU-US Privacy Shield, there is a more fundamental conflict in the laws between the countries: The EU requires data to be kept secure, while the US requires data to be disclosed to authorities. While this hasn’t been tried in court (yet), this will pose a problem as some point.
7. Map out your data processing activities (which is a requirement for certain companies and we recommend it for everyone) and visualise the personal data flow from the moment you receive or first access it, to the moment you delete it. It’s about the full personal data lifecycle. Ideally use data protection management software like Niobase to map this out (contact us for a discount code if you are interested).

“It’s all about how you process data, the tools you use is just a part of that.”

The GDPR does have a provision for certification mechanisms under Article 40 that could help demonstrate compliance, but to date there are no approved certifications a company can apply for. While the market seems to like the rubber stamp approach, the requirements of such a seal or certificate will likely be a lot higher than just taking basic steps towards GDPR compliance as suggested above. Also, it’s unlikely such certifications will ever apply to a product or service.

A process can be GDPR compliant. A product can’t be ‘GDPR compliant’ by itself, independent of it’s use or the process it aids.

The post GDPR compliant products debunked: it’s all about HOW you use it appeared first on TechGDPR.

In my opinion, however, this needs to be seen with more nuance, and as lawyers like to say, it all depends on the specific circumstances; blockchain is not always strictly immutable, the right to be forgotten is not absolute, and the definition of personal data is still not 100% clear. If you look past the headlines and dive into the details, you will see this situation is not that black and white.

1. Blockchain is not always strictly immutable

Already in the very first paper on blockchain, “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto, there was the notion of pruning: “Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.” Meaning even in the first-generation protocol of Bitcoin, there is a technical method to delete certain data from the chain. So far, this has not been implemented, but there is a methodology to achieve this without breaking the system. Obviously in this particular way, a node operator could still choose to maintain all data that ever comes across, so in practice this may not with with Bitcoin unless additional safeguards to guarantee this are being put in place.

With later-generation protocols, such as with EOSIO, there is more sophisticated governance in place. By designating certain block producers who could, based on a constitution, agree to remove certain data, or mutually agree to block access to certain data for the outside. Even though this may limit transparency and centralizes some of the decision making, this may still be a feasible solution for certain use cases. For example Europechain aims at setting up networks with only EU/EEA block producers that are all under a Data Protection Agreement (DPA), specifically to offer a GDPR compliant way in which blockchain can be used while keeping most of the advantages of using blockchain in place.

Immutability can for certain purposes be very valuable, but for Personal Data it may not be ideal.

2. The right to be forgotten is not absolute

The right to be forgotten if often cited as the holy grail of protection your personal data, but it can not always be applied. According to Article 17, it can for example be used under the following circumstances:

• Personal data is no longer needed for the purpose, for example, if it was processed for the provision of a contract (Article 6.1(b)), but the contract has been cancelled or has expired.
• It was processed under consent (Article 6.1(a)), and the consent has been withdrawn.
• It has been processed under legitimate interest, but the legitimate interest has been challenged and no overriding interests prevail.
• The processing was unlawful in the first place.

The right to be forgotten does for example not apply if the processing is (still) necessary for the performance of a contract, for scientific or historical reasons in the public interest, to comply with a legal obligation, or if the legitimate interest continues to overrule the interest of the data subject.

If a controller has made personal data public, and publishing on a public blockchain should be seen as making public, they are required to inform others who are processing the data that is should be deleted. It’s an interesting question how that should work in a distributed environment with public actors, but this is not impossible.

3. The definition of personal data is still not 100% clear

In blockchain environments clearly readably personal data should not be used. In particular within public permissionless blockchains there is no good reason to do so. Most projects resort to storing hashes of information or transactions on-chain to prove certain things off-chain. Depending on the circumstances, such hashes could be considered pseudonymous or anonymous. Pseudonymous data is still in-scope of the GDPR, and should therefor adhere to it, anonymous data is out of scope. What exactly is to be considered pseudonymised following a specific approach, and therefor in scope of the GDPR, was previously (before the GDPR) explained in Opinion 2014/05 of the Working Party 29 (WP216). However, this has not been formally adopted by the EDPB. This makes it a lot harder to establish if, for example hashed information is pseudonymous or anonymous from the perspective of the GDPR.

Is the right to be forgotten in blockchain really a problem?

Well yes. Very often, there are certainly potential problems with storing pseudonimysed personal data in a blockchain, however one should be looking at the particular circumstances: which source-data is pseudonimised, encrypted or hashed, where is it stored, and can it be related to other on-chain events, what happens if you delete the source-data, and how strong is the entropy?

To find solutions for this challenge, it is important to consider both the technical (immutability) and the legal (how absolute is the right to erasure?) aspects, and the overall situation. It will stand or fall with the small details, and because the GDPR is a new regulation and blockchain a new technology, it will always be a risky undertaking to deploy this ‘in the wild’.

The only way in which this challenge can be approached, is through Privacy by Design: ensuring all privacy controls are implemented right from the start, and making sure products, protocols and their apps and UX are designed in a privacy friendly way. Launching an immutable system with privacy weaknesses that are not fully thought through, and documented, is quite clearly a violation against Article 25 of the GDPR on Data Protection by Design and by Default.

The post GDPR’s Right to be Forgotten in Blockchain: it’s not black and white. appeared first on TechGDPR.

1. Is the Opinion 05/2014 by Working Party 29 still valid?

Article 29 Working Party issued comprehensive guidance on Anonymisation Techniques in April 2014 (WP216), setting a high standard for the requirements of true anonymisation, and specifies what is to be interpreted as pseudonymisation – which is merely a method to reduce linkability of a dataset with the original identity of a data subject.

Many applications of DLT requires some verification data to be stored on-chain, which, depending on interpretation and the specific requirements can be seen as anonymous or pseudonymous.

During its first plenary meeting on May 25th, 2018 the European Data Protection Board (EDPB) endorsed a number of GDPR related WP29 Guidelines, but not “Opinion 05/2014 on Anonymization Techniques” by “Art. 29 Working Party”.

The EDPB should clarify whether this opinion by WP29 may be used as a guideline, or ideally issue new guidelines that allow for sufficiently protected pseudonymous data and verification hashes to be recognised as anonymous.

2. Clarification of distribution of responsibilities in a decentralised environment (DLT) according to given roles under GDPR.

The architecture (or topology) of systems using DLT is vastly different from more traditional systems comprising of a client-server, or client-cloud architecture. The GDPR is clearly designed for a client-server architecture, with clear distinguishable rights and duties between a data controller, who is primarily responsible, a data processor, who processes data on behalf of a controller, and a data subject, of whom the personal data is being processed.

This is not translatable into blockchain or distributed ledger technology, where every node could play every role, not overseen by a central entity or system. Participants may have different roles under different circumstances, and may have multiple roles at the same time. In addition, the requirement of concluding a Data Processing Agreement in a public permissionless network is very difficult to fulfil, and other overarching measures may be required.

Clarification of the GDPR roles of the different actors within the blockchain ecosystem, under different circumstances is highly desirable to give innovators enough legal certainty to continue their efforts.

3. Clarification regarding deletion and rectification obligations under DLT.

Under Article 16 and 17 of the GDPR, data subjects have the right to have incorrect personal data corrected, and have their personal data that is no longer required erased.

This poses a problem when using DLT, that primarily derives its trust from its immutability. Because data, including personal data on DLT can not be rectified or erased, and many blockchains are public, the best practice so far is to not directly store personal data on a blockchain but only a verification value, also known as a hash, of some kind. However, as highlighted before, there is no current valid guidance on exact limits of anonymisation, so how this is to be applied remains unclear.

Technical approaches to resolve this problem exist, for example through the ability of nodes to restrict access to certain information, to only allow ‘keyed hashes’, which all have a unique key stored off-chain that can be deleted, or by using a mutable implementation of DLT, which unfortunately hardly ever helps us trust the technology as it relies on a trusted third party and should not be seen as a true solution. Which defeats the appeal of blockchain and DLT.

Within current practices using data backups in more traditional settings, it can also not be assumed that all personal data is effectively deleted, in particular from offline tape backups. It can also be questioned what the technically implementation of ‘deleting data’ in a traditional sense is: under most circumstances this is just ‘unlinking’ data, which can still be recovered.

Further guidance, and more flexibility on the interpretation of deletion and rectification obligations, in particular in a blockchain environment, is requested.

4. Request to ensure future guidance takes the different blockchain and DLT architectures into account.

When the EDPB or other regulators are providing guidance on blockchain under the GDPR, it is essential to understand and consider the different blockchain architectures currently available, and possibly those of the future. A public permissionless blockchain, free to join, participate in and download for everyone, is vastly different from a private permissioned one, related technologies that are technically not blockchain but still fall within the scope of distributed ledger technologies, such as Tangle and Hashgraph, have yet another very different architecture requiring a different approach.

We’d like to urge the regulators and in particular the EDPB to take these fundamental differences into account when issuing further guidance.

The post Blockchain & DLT under the GDPR explained to the European Commission appeared first on TechGDPR.

On Confidentiality

Before getting into the details, I first want to emphasize that TechGDPR works with a wide variety of clients, and we approach our specialized consulting for each client with the utmost confidentiality–unless, that is, a client states otherwise. Zcash is among our clients that have taken steps to publicly discuss this GDPR-compliant assessment. It is with permission of both Zcash and Least Authority that TechGDPR released our report.

Zcash GDPR assessment on the P4 protocol

In October 2018, TechGDPR conducted a GDPR compliance assessment of the P4 protocol specification on behalf of the Zcash Company and Least Authority. This assessment reflects important conversations among regulators, compliance advisors, and implementers of blockchain and other cutting edge technologies in the context of the GDPR and other privacy-protecting regulations.

Data gathered while utilizing the P4 protocol is mostly anonymous, and only a few types of data could potentially be flagged as personal, and therefore in scope of the GDPR. The risk of identifying natural persons through the use of Least Authority’s S4 storage service is significantly mitigated by the use of zero knowledge proofs in Zcash’s shielded transactions. Other regulations, such as financial regulations, anti-money laundering regulations, and know-your-customer regulations, may be triggered by anonymous online services. And although new regulations around the world are attempting to make services providers responsible for their users’ content, Zcash has been favorably received by financial regulators.

TechGDPR’s Findings

The assessment conducted by TechGDPR (PDF available here) asserts that implementation of P4 does not likely raise any major issues regarding GDPR compliance, apart from the consideration whether or not to allow customers to use S4 for data processing under GDPR, and how to effectively prevent this (see finding #11: “Possible role of data processor”). A few matters require highlighting as they may become an issue in the future as the usage of the service changes (finding #2: “File deletion, garbage collection”), or the interpretation of the GDPR evolves further (findings #1: “Logging IP Address” and #3:”Consequences of maintaining a full node”). The biggest concerns are related to the processing of data within S4, not within P4. The P4 protocol itself only presents concerns if subscribers insist on paying from transparent addresses.

TechGDPR also concluded that as long as Zcash transactions cannot be linked back to a natural person, because they are private or because no link between the t-address and the user exists, the transaction within Zcash and payment information itself should be considered anonymous and therefore out of scope of the GDPR.

In our opinion, the P4 service allows for as close to anonymous usage as you can get with current technology, with important caveats regarding user practices and user volume. The full benefits of P4 can only be realized if the user is extremely cautious with how they use it, as is the case with most privacy-preserving solutions today. Least Authority has tried to make it harder for users to make mistakes (i.e., by requiring Tor), however, it is still possible to gather some information through leaked metadata or trivial mistakes by the user that may, over time, be enough to link the usage back to a person. As the user base grows, maintaining anonymity will become easier to establish a relationship between specific users and their data or metadata will become increasingly difficult.

Privacy-enhancing technology, including P4, is not perfect. It is difficult to use, and requires perfect handling by both the user and Least Authority. Still, technologies like P4 go a long way toward challenging the advertising-surveillance model of the modern internet, and illustrate how blockchain-based technologies could show a new way forward.

Zcash looks forward

A statement released on Friday by Zcash declared, “We are at the beginning of what promises to be a longer journey toward privacy-by-design in the realm of blockchain technology.”

Total anonymity may not be possible, but the policies outlined in the GDPR show legitimate demand and P4 demonstrates that we can get pretty close.

The post Is total privacy GDPR compliant? Zcash report shows how “Privacy by Design” handling of personal data gets us close. appeared first on TechGDPR.

GDPR for Blockchain

Since GDPR compliance for blockchain companies is our main focus at TechGDPR, we have been carefully following developments where these two issues overlap. We’ve seen the first official guidance on blockchain and the GDPR coming out from CNIL, (the French data protection authority); we contributed to a paper on Blockchain and GDPR by the German Blockchain Association, and to the workshop on GDPR and Blockchain by the EU Blockchain Observatory and Forum, that resulted in the Thematic Report on Blockchain and the GDPR. I personally have also published a primer paper on Privacy by Design in Blockchain, something I’m looking forward to expanding on in 2019.

Conferences, Meetups and other Events

At conferences and meetups, the specific challenges of blockchain and the GDPR were a much requested topic, which resulted in TechGDPR speaking at different conferences on this particular cross-over area, like Blockchain Conference Berlin, Privacy for Everyone Berlin, Free and Safe Berlin, Digital Era 2018 in Riga, Data Natives in Berlin, at the Datenschutztagung at the Leibnitz Universität Hannover, at the Blockchain & GDPR meetup at DWF, and at the Blockchain nights of the Humboldt Universität zu Berlin. We also hosted multiple invite-only workshops together with our legal services partner, Lacore.

Our Team and Clients

During the year, Abigail Garner and Alex Carroll joined our permanent team, and we had two fantastic interns, Pierson Klein and Barbara Moss last summer and winter. We have worked with many amazing clients, both inside Germany and far beyond, and have been able to deep dive into some very interesting projects, some of which will be publicly released in the next months to come.

We’re looking forward to helping more technology companies understand and implement the requirements of the GDPR, and to also help them with implementation of privacy by design, and ongoing privacy management. Whereas 2018 was the year of bringing companies to GDPR compliance, 2019 will be the year of ensuring privacy throughout the life cycle of a product and service, from the very beginning of the design and development of a product through the management of efforts on a daily or monthly basis.

Looking ahead to 2019

We have planned many exciting things for 2019. First of all, we are currently in the process of shooting the video material for our online courses that can be expected in Q2. One course is on general GDPR compliance, and the other is specifically for developers. We created “GDPR Compliance and Privacy for Software Developers,” as we learned in 2018 that a solid understanding of the requirements on the implementation level is key to implementing the GDPR requirement, privacy (data protection) by design.

We’re also moving office in February, to a location that is being prepared for us right now, and which we will share with our partner company, Least Authority.

Connecting the blockchain scene in Berlin with BerChain

With my not-for-profit initiative BerChain, an organisation that aims to connect the blockchain scene in Berlin – we’re organising an event at the end of January to bring together the Berlin blockchain scene and political Berlin, with confirmed attendance of a secretary of state of the Netherlands, and of a state secretary of Berlin, as well as many more high profile speakers and attendants, with support from Berlin Partner, Innogy Innovation Hub, Factory Berlin, TechGDPR and T-labs.

I’m also moderating the Factory Berlin Blockchain Brunches again (bi-monthly in 2019), where we look at exciting projects in blockchain during a brunch session in the cinema room of Factory – Görlitzer Park. We have six such events lined up for 2019, with the first one on January 17th in the morning. (Let me know if you want to join and are not a Factory member, there is a list I can put you on).

Our new newsletter: ‘Practical Privacy’

At the end of January, we will send out our first newsletter on Practical Privacy, where we focus on the practical aspects of how technology companies can better manage their GDPR and privacy requirements, and to keep you up to date with the developments in privacy-related regulations that apply to technology companies, guidance, and rulings. To join our newsletter mailing list, sign up here.

Privacy Tech Meetups in Berlin

As soon as we are settled into our new office in Berlin Friedrichshain, we will also start a series of meetups about privacy tech. We will look at, among other things, the technological solutions that can help you with privacy management and compliance. More information will follow soon, so watch this space.

I’m looking forward to a super exciting 2019. It might turn out to be a roller coaster, but we will be ready for it!

The post The GDPR + Blockchain: Reflecting back and looking ahead appeared first on TechGDPR.

The shift from quick fixes to caring about privacy

It is a pleasure to work with the continuously growing pool of companies who see privacy and data protection as a real priority. Some companies are even seeking to leverage it as a competitive advantage as customers begin to see the value in data privacy and seek products and services while taking data protection into consideration.

These thoughts became the base for my latest presentation “Privacy by Design for Blockchain”, which I gave at both the DWF Blockchain Meetup in Berlin, “GDPR & Blockchain,” and at the Data Natives Conference 2018, also in Berlin.

In my research for these presentations, I discovered  that much of the work done on Privacy by Design dates back to the mid-1990’s, when Dr. Ann Cavoukian, then Privacy Commissioner of Ontario, Canada developed the Seven Foundational Principles of Privacy by Design. Dr. Cavoukian has been leading great work in this area ever since, currently leading the Privacy by Design Centre of Excellence at Ryerson University.

Blockchain, GDPR and Privacy by Design primer

As I have been investigating how blockchain, GDPR, and the Seven Foundational Principles of Privacy by Design correlate—and could be interpreted as in compliance with Article 25 of the GDPR—I have written a primer on the matter. I plan to develop this document into a more in-depth work in the future, but I thought it would be worth sharing my initial thoughts here. I welcome all comments and suggestions through email, Twitter, or LinkedIn.

Download the 5-page primer to Privacy by Design and GDPR in Blockchain – Silvan Jongerius (PDF).

Silvan Jongerius is the CEO of TechGDPR.

Greg McMullen of COALA IP, as well as Abigail Garner of TechGDPR have kindly reviewed this work.

The post GDPR, Blockchain, and the Principles of Privacy by Design appeared first on TechGDPR.

Breaching blockchain networks is far more difficult than breaching more centralized parties, but users’ privacy can still be compromised in other ways. Web trackers and cookies are excellent examples to demonstrate this problem. These little bits of code live on websites to inform third parties about the habits of users on a given page or platform. On the everyday internet, when data such as an email address can be linked to a particular purchase history, a person’s identity can be compromised.

While trickier to unpack, blockchain activity can be uncovered in a similar way. Site visits can reveal an individual’s identity when they are matched with the public ledgers which blockchain networks rely on to make transactions. The public ledgers designed to enforce the security of transactions can then be used as a means of compromising personal data. A regulator or a law enforcement agency can then run a test on a blockchain network to identify activity it sees to be in violation of the law. In many cases, they already have.

It may be impossible to access someone’s personal data without a public and private ledger, yet advanced number crunching of public ledgers and transaction histories can find correlations that frequently link certain behaviors to a particular individual, or at the very least, vastly narrow a search to a point that’s too close for comfort. This occurs in the same way that a few “likes” on Facebook can be run through data analysis tools to make predictions about one’s purchasing habits, political opinions, and personal psychology. The use of QRNGs is one way of addressing such problems, but the technology is still a long way from solving immediate concerns.

It is also possible to link online purchases back to certain cryptocurrency accounts when a user converts such cryptocurrency into a real currency. That conversion, combined with web trackers, has contributed to why many Bitcoin exchanges are insecure. By monitoring online activity, various third parties can find correlations between an individual’s private information and purchases made using cryptocurrency.

These issues are not limited to cryptocurrencies alone, as all blockchain networks rely on a public and private key to function. The public-private key combo is a major component in blockchain security, but there are still ways to circumvent it. As regulators become more aware of such faults, there may become means for policing networks. As it concerns the GDPR, any vulnerability to users’ personal data is a potential vulnerability for a company.

While each blockchain project, crypto-coin, or other decentralized platform has its own unique needs and weak spots, there are many measures that can be taken immediately to ensure that these kinds of risks are minimized. Tempting as it may be to suggest a list of plugins, procedures, or protocols, the truth of the matter is that there is no one-size-fits-all solution. In many cases, the best practice is to consult professionals who can understand both blockchain technology and the legal mandates of the GDPR in a complex enough way to both improve your company’s security for users, as well as demonstrate the process to regulators.

If companies undertaking blockchain projects want to remain competitive and secure, they must begin recognizing the limits to privacy that blockchain provides and seek proactive ways to respond. The best combination of solutions will be different for every company, but the first step is recognizing that there’s no such thing as an unbreakable chain.

Jesse Van Mouwerik is TechGDPR’s Client Relations Manager and Content Designer.

Follow TechGDPR on Twitter.

The post The Limits of Blockchain Privacy and the GDPR appeared first on TechGDPR.

Do I have a website? Do I use analytics for that website?

It seems obvious, but before considering the risks of any platform, any peer-to-peer network, or even any business model, consider your website. On your typical website, information is being collected about who is visiting. This could be as mundane as basic analytics, or a even standard email list. Depending on how this information is gathered (and how consent to share data is established), it’s possible to be in possession of what the GDPR classifies as personal data. This is a problem that can easily be solved if attention is paid to web analytics early on.

Do apps impact the privacy of my blockchain network?

It could be your own app, or it could be someone else’s. Many bitcoin exchanges, for example, are very vulnerable to hacking, raising the chances of losing the personal data of their users. Conversely, more traditional financial institutions have an interest in monitoring certain blockchain activity, especially cryptocurrencies. This creates a financial incentive to keep an eye on the size of crypto markets, as well as their weaknesses. Having the ability to identify data controllers in the event of a breach is an important step towards improving application security, particularly for blockchain companies.

Do I have a contingency plan in place if a regulator approaches me?

Let’s assume that you found a startup using blockchain technology, and are making meaningful efforts to comply with GDPR regulations. Is there someone in your organization who can prove this? For reasons unanticipated, regulators may need to inquire about your data storage practices. If that occurs, having someone assigned to providing key information is critical. If you cannot do this (and show it on a technical level), difficulties can quickly arise. To that end, it is important to ensure that companies have defined internal guidelines and contingency plans concerning data security in general. These guidelines can then be pragmatically applied to how blockchain technology is being used. It may be important to distinguish between broader company practices and a particular blockchain project. All of these needs require the effort of more than one person or department, but can be much better coordinated with the help of a Data Protection Officer. 

Am I or any of my B2B Partners working with end users?

Even if your startup isn’t working with end users, one of your partners might be. B2B transactions can end up involving some degree of personal data depending on the partnership.  It’s good to be aware of this as it concerns your own partnerships. A common assumption is that unless a blockchain company is not purely made for ordinary consumers, it does not have to worry about personal data or data security as it relates to EU citizens. This is a myth. Though there is less likelihood of having trouble, the trouble that a B2B product could have is also less clear, varying from case to case.  There are often straightforward specifications surrounding different cases, especially as it concerns B2B marketing.  But if a company is to comply, it must know what these specifications are.

What tools am I relying on to conduct my business?

This could apply to digital tools or standard hardware. Blockchain platforms, whether on servers or smartphones, require the interaction of many different devices.  Having at least some idea of device security is the key to maintain the integrity of your blockchain network, especially when it comes to IoT products, which pose a data security risk if they are not properly patched. Though blockchain can also potentially improve IoT security, articulating a concise strategy that also shows compliance takes some time.

Do I really need a DPO? If so, how often?

As already mentioned, DPOs at companies provide regulators with the information they need when questioned, but that isn’t their only function. They also do a great deal of important work for companies undertaking any significant data processing. In Germany, for example, companies of a certain size are now required to have DPOs. If a full-time DPO hire isn’t necessary, companies can also outsource DPO work to trusted third parties. What’s most convenient for blockchain startups is typically to use the services of a blockchain DPO. This way, the DPO is already familiar with the technology in use, as well as understanding GDPR requirements.

Nearly all blockchain startups are affected by at least one of the above scenarios. In each case, being prepared is far easier and far less costly than being hesitant.

To stay up to date on how the GDPR affects technology, follow TechGDPR on Twitter.

The post Blocks Ascending: The GDPR Checklist for Any Blockchain Project appeared first on TechGDPR.