When does the GDPR apply?

The GDPR applies when public or private organization process personal data. These assume one of two distinct roles, either as a data controllers and data processors. When discussing role distribution in supplier or customer relationships, we label one or the other as data controller or processor, respectively. However, one logically determines this at the level of a single processing activity.

The law is extremely clear about the territoriality, targeting and offering of goods and services. Thus, the GDPR applies to your non-EU company if: 

1. you establish a company or a subsidiary in the EU.
   No matter your product or service, your employees are people too and their data is protected by law. This places you under data controller obligations.
2. you provide goods and services (for a fee or not) to people in the EU.
   Since processing their personal data is a requirement to provide said goods and services, you are under data controller obligations.
3. you provide processing services (SaaS, PaaS) to a company to which the GDPR applies by virtue of the above points.
   The GDPR becomes applicable when handling personal data for a company established in the EU. In this case you likely assume data processor obligations.

Supplying services to end users

Beyond the letter of the law, your sales teams faces demanding questions from client procurement teams and end users alike. This is the case whether you offer B2B, B2B2C or B2C goods and services. Sales teams need to understand what procurement teams asked of them. At the very least, it communicates a sense of preparedness. In practice, they should only occasionally forward less obvious questions to the tech, product or legal teams.

Your internal or external data protection officer (DPO) or chief privacy officer (CPO) should sit comfortably astride legal and tech. If they do, have them train sales to reduce back and forth communication. These individuals see data processing from the technical perspective of data flows. Importantly, they understand risk from the perspective of risk to the data subject.

Leveraging privacy

Being able to address data subject requests (DSRs) in a timely manner, ensures you remain a contender in your client’s procurement shortlist. Some clients operate in a highly regulated field so compliance is crucial to them. Others show high ethical drive and understand non compliance as a risk to their operations. For clients who don’t care, your common relationship will deteriorate at the first privacy pinch from data subject requests. Pressure will come from their own vertical relationships in the supply chain, or enquiries by supervisory authorities.

If your business enjoys a direct relationship with people in the EU, you likely assume a data controller role. This is the case with the provision of B2C goods and services. The full requirements of transparency, security and accountability apply, so do the performance of data subject rights. Subjects are savvier now about exercising their rights. You can expect their privacy experience with you to make it onto social media if they don’t trust your practices.

Supplying services to other organizations

When supplying SaaS or PaaS solutions, the B2B / B2B2C scenario likely makes you a data processor. The requirements for security and accountability apply to both controllers and processors. Yet, transparency obligations are fulfilled by the data controller. This is done through their own channels or via a notice your platform allows them to provide to their end-users. However, your ability to be forthcoming with demonstrations immediately satisfy your customers’ expectation that you are set up to help them demonstrate how they comply.

Transparency is not the only obligation you will help your customer fulfil. Say you provide a platform that corporate customers can use to create user retail experiences. They remain responsible for collecting proof of consent to the data processing resulting from triggering your platform features (e.g. shopping cart memory or reward schemes). Your platform being the front-end of user interaction for your customers, ask yourself whether your platform

• provides your customers with consent collection mechanisms, collecting proof of consent and allowing for user revocation of consent;
• provides APIs to push data from your platform to your customer’s ERP, therefore triggering data transfers and access right management;
• helps generate records of processing activities that satisfy GDPR Article 30 requirements;
• helps generate a privacy notice based on the factual data processing caused by the user’s choice of features.

Engaging a non-compliant SaaS solution remains the data controller’s statutory responsibility. Yet remember that their DPO and legal counsels can be powerful show-stoppers when signing procurement contracts. No one appreciates manual work, much less when it involves getting it from the less responsive solutions providers out there.

Are employees people too?

You bet they are. Tunnel vision is frequent when focusing on exporting your product. Yet, when setting up a subsidiary to manage staff locally or remotely contracting staff in the EU, the data you process about them for employment and project management purposes is subject to regulation. Job boards and recruiting agencies allow you to tap into talent but the nature of the services you use may vary. Yet your obligations on the underlying data remain those of transparency, lawfulness and retention.

When onboarding and during the employment lifecycle, employees yield and generate tons of personal data. Some of that data may be highly sensitive, such as that associated with sick leave and disabilities. Remember that your HR systems may not be contracted in the EU and likely plug into other tools. That is often the case with payroll management, training and employee development. As you would expect, this tool landscape comes with additional challenges for complex organizations sharing services across multiple jurisdictions. Due diligence should take place before onboarding a tool and continuously while feature testing.

What about applicants?

No evidence suggests that merely looking at profiles on LinkedIn triggers GDPR obligations. The GDPR refers to that data as publicly available. However, the moment you make use of a third party tool or structure information, requirements are triggered. This customarily takes the form using spreadsheet trackers for driving applicants through a conversion funnel or sharing them for assessment. Not all applicant tracking software is created equal. Identifying a supplier based in the EU does not guarantee that its compliance is up to par. At the very least, you should expect them to know what compliance you need their solution to offer. 

Don’t take their word for it, challenge their assertions and document their response.

What does it take for non-EU companies to become compliant?

How is compliance defined and measured?

At its heart, compliance is about developing and maintaining the ability to demonstrate awareness of risk and risk control. Note that in data protection we do not measure risk in financial terms, nor in terms of corporate reputation. We see privacy risk through the lens of impact to the data subject. However, whether you rely on staff that is good at understanding ISO norms or legal officers good at interpreting legal provisions, your compliance essentially relies on whether your product owners understand:

• what data they need (data);
• what they are doing with it (purpose);
• to whom they have provided access to -e.g. through APIs- (recipients);
• where it comes from (source & confidentiality),
• how they legitimize its handling (legal basis), and
• what rights can be exercised against that data (DSRs).

This inventory is not established in a week. Not unless employees actually speak to one another and have nothing else on their plate. Needless to say, the inventory is never perfect. Worse, it is often erected on erroneous assumptions. For instance, ruling too quick on what is not personal data or failing to register the implementation of an API as triggering a processing activity. Have you ever had an awkward discussions with partner procurement teams?

For organizations making use of the ISO27001 security management cookbook. The 27701 extension is the cherry on top to help demonstrate, to customers and authorities, the organization is serious about compliance. Serious enough that it allows a third party to independently audit its compliance management system (ISMS and PIMS respectively). 

What do you need in order to demonstrate compliance?

You’ll need Records of Processing Activities (RoPA) to start with. That will put everyone on the same page; from your tech teams, to your legal teams, your product owners, your sales and procurement teams. It will allow you to update your privacy notices, enter (and exit!) sales discussions comfortably. You’ll need to review all your 3rd party contracts to identify where Data Processing Agreements (DPAs) and international transfer mechanisms are missing. You may also need to perform impact assessments based on whether your activity is blacklisted.

You might need to drop vendors with appalling documentation or those refusing to provide it. For instance, consent management platforms will lur your into thinking you don’t process personal data. If you are not willing to change suppliers, then maintain a list of vendors to deprecate for compliance issues and communicate it to upper management. You’ll need robust security documentation, and a fair share of training and awareness raising at all levels of the organization. Perhaps least discussed but most wanted on your compliance journey, is an organizational appetite for change management.

Much like that of ISO27001, whether your company is EU or non-EU-based, what helps you demonstrate GDPR compliance is the amount of available, relevant, readable, useful [and used !] documentation that demonstrate accountability. Compliance and product teams are already getting creative with MS copilot, allowing it to read through emails, repositories and spreadsheets. Are your ready to let an algorithm adjudicate on your company’s compliance and leave you none the wiser? AI is likely to become an audit support tool in first and second party audits. It is however unlikely to replace the auditor’s judgement and decisional independence any time soon for third party audits that rely on market-leading certification bodies.

The post Embracing the GDPR as a non-EU company appeared first on TechGDPR.

A multitude of new regulations are either in the ordinary legislative procedure or already in force. These include the Data Act, the Data Governance Act, the Digital Services Act, the Digital Markets Act, the Cyber-Resilience Act, European Health Data Space Regulation, the Artificial Intelligence Act. Data regulations in the European Union (EU) are becoming more complex and challenging for businesses to comply with. The increasing number of administrative burdens and compliance requirements in these regulated areas are a valid concern for businesses. Supervisory enforcement, for enacted regulations will be a wake-up call for organizations that are not prepared. Tech players operating in the EU and authorities overseeing those activities face the similar challenge of adapting to legislative overlap. New fines, new supervisory authorities and new compliance requirements are expected. To better understand this burst of regulation, the EU’s strategic policies must be carefully examined.

What is the EU aiming for?

• The United States (US) and China (CN) have different advantages in the field of technological competitiveness. 
• The US has a strong private sector with abundant financial resources, while CN has a state-sponsored private sector. 
• The EU meanwhile wants to shape its own digital future, and create a competitive Digital Single Market while enforcing European democratic values. In a short span of time, the European Commission has implemented digital transformation policies to become more competitive in the global economy, reduce the carbon footprint that arises from the red-tape bureaucracy and go digital. 
• Better public services and comprehensive scientific research will be strengthened by the re-use of data envisaged in the European Strategy for Data. 

Understanding the distinct European view on data 

Greater productivity for IoT and data-enabled products are also on the list. But greater accessibility to data is needed to enable innovation in a data-driven economy. This explains why data intermediaries are expected to play a key economic role, as envisioned in the Data Governance Act. Making more data available to smaller players will be made possible by creating common European data spaces in strategic sectors. There are multiple underlying reasons for the data spaces, all of which align with the strategic data policies of the European Union.

• The new regulations are in line with the existing strategic objectives, allowing for organizations to get ahead of the game by embracing the EU’s strategic data policies. 
• The industrial data space and co-generated industrial data is part of the Data Act. 
• The common European health data space is also regulated with the upcoming European Health Data Space Regulation. 
• Green Deal data space, financial data space, energy data space, agricultural data spaces, are also mentioned in the “European Strategy for Data”.

EU strategic goals

• The digitalisation of public services and the digital transformation of businesses are of high priority in the 2030 Digital Compass: the European way for the Digital Decade. 
• The Digital Compass goals are consistent with the rising amount of data being created in the EU. 
• The EU is determined to maintain its regulatory norms and standards in its relations with international partners. 
• By 2030, the EU aims to build an interconnected data processing ecosystem conscious of fundamental rights and in full compliance with legal requirements. As stated in the 2030 Digital Compass policy, the EU will continue to promote the ethical use of AI, establish strict cybersecurity and resilience requirements, tackle disinformation and illegal content online, ensure the operational security of digital finance and facilitate transformation of e-government. Respectively, these strategic policies are being covered by the Artificial Intelligence Act, the NIS2 directive and Cyber-Resilience Act, the Digital Services Act, the Digital Operational Resilience Act for the financial sector and European Health Data Space Regulation.

Implications for the future

These new regulations pave the way for the EU to achieve its new industrial strategy of climate neutrality and digital leadership. They help to reduce the carbon footprint and prevent red tape bureaucracy. 

• The digital transformation is essential for a greener EU.
• The reuse of data is also critical. 
• As stated in the EU Strategy for Data, this includes greater productivity and competitive markets, as well as improvements in health and well-being. 

The emergence of data-driven ecosystems can prove itself in the long run but it may take years for the EU to figure out the interplay of new regulations within the existing legal frameworks, the preparation of new guidelines and the appropriate degree of coordination between supervisory authorities. 

The EU will need to ensure that data and data-enabled products and services are available throughout the single market. Considering the EU’s goal of building a legal digital framework and becoming an international market leader, similar regulations may spread over time to different continents through the Brussels Effect. The key intention is to create a European data ecosystem that is respectful of fundamental rights. Whether these strategic intentions will be translated into the regulatory scope as intended remains to be seen. 

The post Making sense of new EU-wide data regulations, the red thread behind the digital single market appeared first on TechGDPR.

What are the benefits of an online GDPR training course?

One of the most convenient methods of providing GDPR training is through the use of an online course. There are a range of benefits to this method as compared to other methods of training, including flexibility, the scope of the course, and portability. TechGDPR offers an online training course which is specifically designed for developers and technically oriented roles, although its contents will be valuable for employees in multiple areas of an organisation. Past users of the course found the information to be both valuable and interesting. In fact, over 90% of those who provided feedback on the course ranked the course as being either “enjoyable” or “very enjoyable.”

Flexibility: One of the main benefits of training employees on GDPR through an online course is the flexibility this method offers. A self-paced online course can fit into any schedule. As a result, employees are able to take the course whenever it is convenient for them. Additionally, participants in the online training course take their time with sections they want more familiarity with. Furthermore, after completing the course, individuals will be able to keep the handouts and resources provided within the course to help guide and refresh their knowledge of the GDPR.

Scope and Focus: Employees whose job functions do not directly relate to managing compliance efforts might not see the benefits of GDPR training. However, a course specifically designed for employees in these capacities, whether they be a software developer or a CTO, will demonstrate to these individuals the importance of considering the GDPR in their operations. The online course works to answer common questions and address misconceptions on the GDPR. The course has seven lessons: Data Protection Overview, Legal Basis & Consent, Design Considerations around Data Subject Rights (DSRs), Data Controllers and Processors, Risks and Measures, Data Transfers, and Emerging Technologies. Some of these sections will be of more specific relevance to technology teams, while others will provide important general information about the GDPR to any user of the course.

Portability: Employees can take an online course anywhere. No matter where your company or employees are located, you can take advantage of the educational resources provided by the course. This is an important consideration for companies with a number of remote employees, who can take the course from wherever they might be located.

Documentation: A further benefit of online training is that it will allow for an organisation to document its compliance efforts. Additionally, upon correctly answering 60% or more of the questions on assessments throughout the training course, users are able to obtain a certificate of completion.
Importantly, the content covered and the depth of information will vary dramatically depending on the chosen method. Аn online course is not as customisable as a live webinar or in-house training. Due to the time required to build and adjust an online course, customisation is only feasible for large-scale deployments.

What are the benefits of in-house training sessions and webinars?

The most effective training method is a live in-house session. There is also the possibility of having a live webinar as a training option for your organisation instead. There are many advantages to choosing a live session for GDPR training. The customizability of the course includes both the content of the training and a Q&A after the session.

Content: Unlike the online course, the webinar can be customised to your specific needs as an organisation. Up to 30% of the training program can be customised to reflect the actual work situations, typical challenges, and operations of your organisation. This will make it easier for employees to retain the knowledge they gain throughout the training as it is immediately applicable on familiar situations. The program will cover the basics of GDPR and common issues related to compliance. After training, employees will be more confident identifying areas of difficulty in adhering to the GDPR.

Duration: Both the in-person session and the webinar session will last between 1,5-2,5 hours. After the live training session there will be time for a Q&A to answer any questions employees may have. Training should take place both annually and as part of the onboarding process for new employees.

Flexibility: Similar to the online course, the webinar allows participants to be located anywhere. This benefits employees who work remotely, or companies with employees located in different time zones. Multiple sessions of in-house training are also possible, so as to make interruption to your daily operations as minimal as possible.

Documentation: The live training sessions also provide documentation of GDPR compliance efforts for organisations.

Regular GDPR training and documentation of this training will keep staff up-to-date as there are new developments in technology and the law. A shared understanding of GDPR requirements across staff will help reduce the possibility of GDPR violations and data breaches. Learn more about TechGDPR’s in-house training options here.

The post GDPR Training Modes for Technology Teams appeared first on TechGDPR.

What are HIPAA and the GDPR?

HIPAA refers to the Health Insurance Portability and Accountability Act of 1996. HIPAA was enacted to specifically deal with how medical data are shared and processed. Unlike HIPAA the GDPR regulates any information which can lead to the identification of a living person whether it is health-related or not. The GDPR denotes health data as special categories of personal data, commonly referred to as sensitive data. This means that non-consensual processing of health-related data is strictly prohibited unless the processing purposes are related to medical diagnosing, preventative or occupational medicine, provision and management of health or social care or treatment, in accordance with a contract with a medical professional or based on Union or Member State law. 

The GDPR defines health data as personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his/her health status (GDPR Art.4). HIPAA denotes protected health information as any data uncovering an agent’s identity in respect to his or her past, future or present physical or mental condition, provision of and payment for the health treatment and services. Both definitions are similar, yet HIPAA also designates financial information of the recipient of the treatment as health data. The GDPR applies to all organizations operating in the EU or offering goods or services to individuals located in the EU territorially no matter of the citizenship. HIPAA, on the other hand, applies to special covered entities within the US, those include healthcare providers, health care clearinghouses and health plan providers.

The key differences between HIPAA and GDPR relevant to MedTech 

The principal difference between the regulations is obviously their scope. As previously stated, the GDPR relates to all organizations processing all types of data relating to a person. Furthermore, the GDPR applies to a much broader range of entities. Even if the company is located in the US (or anywhere in the world) and processes data of subjects located in the EU, it must comply with the GDPR. Contrastingly HIPAA only applies to covered entities located in the US. 

The right to be forgotten is another aspect specific only to the GDPR. It stipulates that under certain conditions, such as the revoking of previously granted consent or when the data is no longer necessary, the data subject may exercise a right to request a free of charge erasure of his or her personal data. If a company relies on third-party cloud storage services, it should ensure that it is able to locate and erase the data when required. The GDPR is also stricter on data breaches, it only grants 72 hours to report a data breach while HIPAA allows for up to 60 days to report a data breach if more than 500 individuals. If less than 500 people are affected, the data breach may be reported by the final day of reporting each year. 

The GDPR also introduced the notion of privacy by design and by default. The concept postulates that when developing new services related to MedTech, or any other sector, involving processing personal data, the company must always consider privacy. HIPAA makes no mention of such a framework for launching new services is present in HIPAA. 

Both regulations are compulsory and impose fines for non-compliance. HIPAA fines are mostly around $25.000 per violation, although in the worst case circumstances a company may be fined of up to $1.5 million per year. GDPR opens the door to potentially much larger maximum fines of up to 4% of the annual worldwide turnover. 

Do HIPAA and GDPR overlap?

There are some similarities and overlap between HIPAA and the GDPR which is good news for companies required to comply with both regulations. Firstly, both include obligations relating to individuals or entities handling data on behalf of covered entities who control the processing of data. Under HIPAA, those are distinguished as business associates and are required to sign a business associate agreement (BAA), this is similar to the data processors under the GDPR.

Secondly, HIPAA, as is the case with the GDPR, requires companies to ensure safeguards are in place to protect the data collected and stored from unauthorised access and disclosure. Article 32 of the GDPR specifically deals with the obligation of minimising risks of a security breach. Appropriate measures include pseudonymisation and encryption of data, maintenance of ‘ongoing confidentiality, integrity, availability and resilience of processing systems and services’ as well as ‘ability to restore availability and access to data in the event of an accident’. The same article prescribes regularly testing, assessing and evaluating the effectiveness of security measures in place. Furthermore, the entity subject of the GDPR shall ensure all personnel processing data on their behalf adheres to the code of conduct prescribed by the legislation and does not process data except on their instructions.

Parallel obligations of the covered entities can be found under HIPAA’s Security Rule. HIPAA also postulates confidentiality, integrity, and availability of protected health information in electronic form (ePHI). Likewise, covered entities must ensure potential security threats, or unlawful uses or disclosures of ePHI, are considered and addressed. HIPAA also obliges the covered entities to ‘ensure compliance of the workforce’. 

Both regulations call for minimisation of data collection and minimisation of data disclosure. Data should be disclosed for research purposes, judicial proceedings, public health interest and if required by law in both legislations.

HIPAA and the GDPR grant data subjects analogous rights. In particular, with a few exceptions, such as access to psychotherapy notes, both regulations grant the data subject the right to access and review a copy of the processed data. Moreover, if the information is inaccurate or incomplete, the data subject has a right to request an amendment of the information.

HIPAA and the GDPR grant data subjects a right to be informed of how and for what purpose their personal data is used and processed, this includes information regarding the recipients or categories of recipient to whom the personal data have been or will be disclosed. The privacy notice must include information on individual rights with respect to their personal information and how those rights may be exercised, and the covered entities obligations as well as the purpose of data usage and processing. Interestingly, both GDPR and HIPAA require the privacy notice to be written in clear and plain language.  

HIPAA and GDPR application

Two global trends may be identified with regards to MedTech and data processing. On one hand, there is an evident explosion of consumer health data. Technological advancement has stimulated vast growths in consumer-generated health data. Those can be put to work through data analytics to extract powerful insights. Secondly, as life expectancy increases and larger sections of the population account for senior citizens, the market boom for healthcare is explained by a demand to further digitise and employ analytics to identify the most cost and health effective treatments and insurance plans. 

Beyond the similarities and differences outlined earlier, there is a fair amount of divergence in how the two frameworks are implemented. Consider an app developer seeking to re-use healthcare data to extract insights. Under the GDPR, this app developer handles a special category of data and this handling is subject to strict safeguards. However, in the US, the same app developer will not be is not a subject HIPAA and the GDPR -provided they do not process personal data from an EU data subject. That is because HIPAA postulates that only covered entities of healthcare providers and insurers or their business associates are subject to the legislation. In other words, medical data that is collected and processed in a hospital will be subject to HIPAA and considered PHI.

If an individual voluntarily provides his or her health information to a mobile app, which is not connected to healthcare activities of a covered entity (i.e. not a business associate of any covered entity), most likely this falls outside of HIPAAs’ jurisdiction but the app developer remains subject to additional state or federal law. An example of such laws is the FTC Act that generally regulates commercial use of personal data or the Children Online Privacy Protection Act with regards to the use of children’s data. Ultimately, this has an effect on how consent should be extracted to process the data, as well as on the appropriate security and organisational protection measures, regardless of HIPAA. 

This article is for information purposes only, and does not constitute or replace legal advice. Seek professional support for any specific questions you may have.

The post HIPAA, the GDPR and MedTech appeared first on TechGDPR.

This can either be an internal position, or can be assigned based on a service contract. Any assignment of a DPO should be free of conflict of interest, and should report to the highest body in the organisation. While a DPO could also have another position in the company, this means that it can not be combined with many other roles, such as CTO, CEO, CMO or anyone in a department with an interest that is not aligned with data protection. The DPO must have the freedom and independence to independently report breaches to the authorities.

DPO as a Service/External DPO

Unless you represent a large organisation, it is usually much easier and more cost efficient to assign an external DPO with a service contract to monitor your compliance for you.

TechGDPR offers DPO services based on a monthly contract, where a certain amount of service hours are included every month. A DPO from TechGDPR is not only experienced and skilled, he or she also has the technical know-how to talk with you on a technical level, and is your trusted advisor for any privacy and data protection related matters. It’s not just about compliance, it’s also about doing the right thing for your data subjects and your organisation, and TechGDPR helps you with that.

The key tasks of a DPO under the GDPR, include the following activities:

• Informing and advising the data controller or the data processor and the employees who carry out processing of their obligations.
• Monitoring compliance with the GDPR, with other provisions and with the data protection policies of the controller or processor.
• Assigning responsibilities, raising awareness, and training of staff involved in processing operations.
• Performing or leading GDPR related audits.
• Performing or providing advice about data protection impact assessments.
• Cooperating with the supervisory authority.
• Acting as the contact point for the supervisory authority on issues relating to processing.
• Be responsible for prior consultations.
• Having due regard to the risk associated with processing operations, taking into account the nature, scope, context and purposes of processing.

Beyond the tasks specified in the GDPR, a TechGDPR Data Protection Officer will help you with many other things as well: handling subject access requests, change advisory and keeping you up to data about technology-related GDPR matters.

The post How to appoint a data protection officer? appeared first on TechGDPR.

After analysing the statements relating to Data Protection and GDPR, here is some high level response to the key points.

Blockchain Strategy Implementation Principles [p5]

“IT-Sicherheit und Datenschutz garantieren: Nur wenn Blockchain-Anwendungen den von Expertinnen und Experten empfohlenen Anforderungen an die IT-Sicherheit und den rechtlichen Anforderungen des Datenschutzes genügen, können Risiken minimiert, Missbrauch verhindert und eine hohe Akzeptanz erreicht werden.”

Machine Translated Version
“Guarantee IT security and data protection: Only if blockchain applications meet the IT security and legal requirements for data protection recommended by experts can risks be minimized, misuse prevented and a high level of acceptance achieved.”

In its current implementation this would disregard one of the key differentiator and benefits of blockchain technology: the decentralisation of responsibilities to enable trust. Expecting that blockchain can meet all requirements by itself, is like fitting a square peg in a round hole.

Misuse in blockchain does not always come from the classical and expected angle: centralisation in an environment that is expected to be decentralised can be a large problem for the integrity of the network and the data. To prevent misuse of this kind, the regulatory framework must inherently support new governance structures.

Creating the right framework conditions, 3a [p13]

“Insbesondere die Kompatibilität der Blockchain-Technologie mit der Datenschutz-Grundverordnung (DSGVO) ist immer wieder Thema. Aus Sicht der Bundesregierung ergibt sich aus der Blockchain-Technologie aktuell kein Änderungsbedarf bei der DSGVO. Vielmehr muss die Blockchain-Technologie datenschutzkonform ausgestaltet und angewendet werden.”

Machine Translated Version
“In particular, the compatibility of blockchain technology with the General Data Protection Regulation (GDPR) is a recurring issue. From the point of view of the Federal Government, there is currently no need for changes to the GDPR as a result of blockchain technology. Rather, the blockchain technology must be designed and applied in compliance with data protection regulations.”

This completely disregards that the very clear definitions in the GDPR about Data Controllership and Data processorship are too narrow for any distributed system. There is no sensible way actors in a distributed (or decentralised) environments can fit the definitions. At the very least, there should be clear guidance on how this is to be interpreted and how the controller and processor roles under the GDPR should be fulfilled in an environment where, by design, no one party is fully responsible in all situations, all of the time. On the notion of the right to erasure, it should be understood that a ‘mutable blockchain’ does not aid in decentralising trust as the very concept foresees. Much more important may be defining what precisely constitutes personal data.

I would also plea for the implementation of guidance that takes specific situations into account: Are there data that will not have to be deleted if they are collected under specific circumstances? At current, the guidance can not be applied directly, and no guidance is available, which makes different groups of experts speculate about different possible solutions. This is not helpful for the ecosystem.

Creating the right framework conditions, 3a [p13] (continued)

“Etwaige Unsicherheiten bei Entwicklern und Anwendern von Blockchain-Lösungen sollten adressiert werden, um die Entwicklung verbraucher- und datenschutzkonformer Lösungen zu befördern. Dabei sollten bestehende technische Lösungen (u. a. Verwendung von Hashwerten, Pseudonymisierung, Zero-Knowledge-Proof) und die Grundsätze privacy-by-design und privacy-by-default Anwendung finden.”

Machine Translated Version
“Any uncertainties among developers and users of blockchain solutions should be addressed in order to promote the development of consumer- and data protection-compliant solutions. Existing technical solutions (e.g. use of hash values, pseudonymisation, zero knowledge proof) and the principles of privacy-by-design and privacy-by-default should be applied.”

While the usage of existing technical measures as well as data protection by design is already mandatory under the GDPR, addressing the uncertainties in this regard is elemental to ensure. These uncertainties may be addressed through clear guidance by the data protection regulators. The finding of data protection-compliant solutions however, may very likely require a combination of technical solutions and legal leeway. Claims by software developers having found so called ‘GDPR compliant’ blockchain solutions should be assessed in detail. More often than not it will only solve a subset of compliance problems, and will usually come at cost to decentralisation or governance.

The mentioned initiative of organising a round table on data protection and blockchain in the first half of 2020 is a great way to exchange further ideas and implementable solutions. I would be happy to contribute.

The post Response to the GDPR-relevant points in the German Blockchain Strategy of September 2019 appeared first on TechGDPR.