Data subject rights (DSRs) are not optional check boxes. They are legally enforceable rights granted to individuals whose personal data is processed. Businesses must respect data subject rights throughout all stages of AI development, deployment, and ongoing system management. The GDPR grants individuals several rights over their personal data. Let us focus on four of these here:

1. Right to be informed: As with other data protection frameworks, transparency is key under the GDPR. This right takes the form of a duty to inform prior to the processing taking place. Businesses must include information on how they collect, use, store, and share data, the purpose of processing, the legal basis, data retention periods, and who may receive the data. Privacy notices are the typical repositories for this information. They must be concise, accessible, and written in plain language.
2. Right of access: Data subjects can request access to the exact personal data a business holds about them. Businesses must provide information about processing activities, data categories, and any third parties with whom they share the data.
3. Right to rectification: Data subjects can request organizations to correct incorrect or incomplete data without delay. Businesses must respond promptly and update the data across systems and third-party processors where necessary.
4. Right to object, right to be forgotten and right to revoke consent: It allows individuals to exercise control. The European Data Protection Board (EDPB)  published a case digest on right to object and erasure. Data subjects must be able to object to the use of their data and request its erasure when it is no longer necessary, when they withdraw consent, or for purposes like direct marketing.

Incorporating data minimization in AI Systems

One of the most effective ways businesses can respect data subject rights is by adhering to the data protection principle of data minimization. This GDPR principle requires businesses to collect and process only the minimum personal data necessary to achieve their specific purpose. Avoid over-collecting data, use anonymized or synthetic data for training, and regularly review AI outputs to remove unnecessary personal information.

Implement transparent data practices

Transparency is central to building trust and achieving legal compliance. Always define the purpose of processing, specifically the training of AI models. If businesses rely on legitimate interest, they must show that they gave data subjects the chance to object; otherwise, they invalidate their legal basis.

Clearly inform existing customers in advance when using their data to train AI models, and provide opt-out options before processing begins. Transparency is key. 

When there’s no direct relationship with the individual (such as when using publicly available data or from data brokers), the GDPR requires information to be provided within one month of its collection GDPR Articles 14.  

In 2023, the Italian DPA temporarily banned OpenAI’s ChatGPT, citing a lack of transparency around how it used personal data for training. The DPA later required the company to implement clear privacy notices and provide users with ways to exercise their rights.

Respect the right to access 

Can data owners request access to training data? 

This becomes complicated with large language models, but under the GDPR, individuals have the right to know if and how their data is being used.

How to exercise that right? 

Under the GDPR, individuals have the right to know if and how their personal data is used, including data processed by AI systems. While this is straightforward for users with an existing relationship (who can submit data subject access requests via account settings or customer support), it’s more complicated when there’s no direct connection.

In such cases, organizations must ensure proactive transparency by clearly informing people through privacy policies and AI transparency reports. Failure to uphold this right contributes to loss of trust and accountability in AI use and development.

Develop clear processes for data deletion and rectification 

Can data be corrected or deleted after it has been used to train an AI model? 

While difficult, companies must explore the use of data architectures that allow tracing of personal data contributions. The GDPR (Recital 26) considers even pseudonymous data, like randomly generated user IDs, as personal data since organizations can technically link it back to a person, directly or indirectly.

To reduce data subject risk while improving compliance, companies could implement the following measures:

• Data encryption: Businesses should ensure proper security implementation, especially when handling sensitive personal information.
• Anonymization and pseudonymization: Where possible, anonymize or pseudonymize data before using it in AI models. Anonymization and pseudonymization protect personal data by reducing breach risks and limiting the impact on individuals in case of a data exposure.
• Access control: Implement strict access controls and monitoring to ensure only authorized personnel can access personal data. This prevents unauthorized exposure of sensitive information.

By embedding these practices into AI development pipelines, organizations can take meaningful steps toward compliance, trust-building, and ethical AI deployment.

Ensure security and privacy by design

Organizations should build user trust and meet regulations by embedding privacy from the start, not treating it as an afterthought. This is the core of the privacy by design principle under the GDPR.

Key steps include:

• Promoting user choice and control: Provide clear opt-out options before processing data—whether in email campaigns, mobile app popups, or web trackers.). Empower users with privacy dashboards that let them view, manage, and delete their personal data at any time.
• Secure data handling: Businesses must encrypt personal data used in AI training while transmitting and at rest. Implement strict access control mechanisms to ensure that only authorized personnel can interact with sensitive data.

Embedding privacy and security into system architecture from the outset not only ensures compliance, trust-building, and ethical AI deployment.

Maintain ongoing communication and feedback loops

Transparency shouldn’t stop at data collection. When introducing AI processing, update your privacy notices to reflect new processing activities, as required by the GDPR. Use layered notices to highlight AI-specific practices like model training, profiling or automated decision-making. Importantly, inform users before processing, not after. True consent means giving people a real choice. Building feedback loops as user input is essential for improving fairness, spotting issues, and building trust in your AI systems.

Conclusion

As AI continues to shape modern business, respecting data subject rights is not just a legal obligation; it’s a foundation for responsible innovation. By embedding privacy by design, adopting transparent data practices, and enabling user control, organizations can align AI development with GDPR principles and foster long-term trust. Data protection isn’t a compliance checkbox, it’s a strategic imperative for ethical and sustainable AI.

Feel free to reach out to us for any clarification of AI compliance needs.

The post Respecting Data Subject Rights in AI: A Practical Guide for Businesses appeared first on TechGDPR.

Due to their age and general level of maturity and education, children are considered to be vulnerable and granted special rights in the eyes of the majority of jurisdictions. This is internationally recognised through, for example, the United Nations’ Convention on the Rights of the Child. This vulnerability is considered across different areas of legislation, including data protection, leading to specific provisions being included in the GDPR, such as Art. 8, laying the conditions for information society services to process children’s data.

Art. 8 GDPR’s requirements and the age of digital consent

Art. 8 of the GDPR is the only article that regulates the processing of children’s personal data specifically. It provides that the processing of personal data of children is lawful when the child is at least 16 years old (age of digital consent), or, if below that age, only where consent has been given by the holder of parental responsibility for said child. The GDPR also allows for the individual member state to independently legislate on whether the age limit can be lower than 16, so long as it is no lower than 13. Countries such as Germany and the Netherlands have opted to stick to the standard already established by the GDPR, while others, including Belgium and the UK prior to its departure from the EU, have lowered the threshold to the lowest possible age of 13. Notably, the UK’s current data protection provision still maintains that the age of digital consent is 13.

With this provision, the inevitable consequence is to first and foremost ensure that the age of a data subject is appropriately verified, in order to assess whether these rules apply and take the appropriate steps. However, recent cases and studies have shown that it is inherently difficult to gain consent of a parent or guardian, as there are no appropriate mechanisms in place to ensure that children are being truthful about their age.

Growing concerns about the processing of children’s data

One of the main issues that information society services face in regards to the processing of children’s data, is that these services are not aware that many of the users are actually under the age of digital consent. So far, the majority of these platforms have been relying on relatively lax forms of self declaration, meaning that the platforms offer services on the legal assumption that the user is responsible for declaring their age truthfully, which leads to users easily lying about their age to gain access to platforms where no extra assurance is required. 

UK’s Ofcom research has shown that for platforms such as TikTok and Facebook, which only required users to indicate their date of birth, the vast majority simply indicated a date of birth that would indicate that the user is older than they actually are. The main issue with this is that this may set up young users to be exposed to content that is not safe for their age, and also expose them to unlawful collection of their personal data from these platforms. 

It is therefore unsurprising that Meta and TikTok have been the two biggest companies being fined for violations in regards to misuse of children’s data by the Irish and UK’s data protection authorities respectively. In fact, the UK’s ICO noted that TikTok had been aware of the presence of under 13s in the platform but it had not taken the right steps to remove them. 

It becomes clear that the development and implementation of more stringent age assurance techniques is necessary to ensure that personal data of children is only processed in accordance with GDPR standards. Whilst the EU is yet to come up with specific guidelines in regards to this matter, the UK has published the Children’s Code, to be applied to online services likely to be accessed by children as a code of practice.

Age assurance mechanisms

Amongst 15 other standards that the Code implements, there is the need to ensure that the product and its features are age-appropriate based on the ages of the individual users. To be able to do so, the code requires that the age of users is established with the appropriate level of certainty, based on the risk level of the processing and taking into account the best interest of the child. Therefore, it is also crucial under the code, to carry out a Data Protection Impact Assessment (DPIA) prior to the processing of children’s data, to evaluate said risk level.

The code suggests some additional age assurance mechanisms that information society services may put in place, and the UK’s children’s rights foundation 5Rights has identified additional ones and its possible use cases, advantages and risks. Some of these include: 

• Hard Identifiers, such as sharing one’s ID or Passport or other identifying information. Those are considered to provide a high level of assurance, but raise concerns in regards to data minimisation and might otherwise lead to a disproportionate loss of privacy. Organizations are generally advised to implement appropriate storage limitation periods for those, limited to what is needed to verify an individual’s age once, making it tricky to demonstrate having checked that information, for compliance. Youtube and Onlyfans are examples of ISS that makes use of this mechanism to give access to age-restricted content.
• Biometric data relies on the use of artificial intelligence to scan for age-identifiers on a person’s face, natural language processing or behavioral patterns. It is more commonly used through facial recognition. However, it presents a high degree of risk due to the use of special categories of data, risk of discrimination by biased artificial intelligence and the effective profiling that takes place. Whilst it does provide a high level of assurance, it also requires a very stringent mechanism in place in order to ensure data is processed safely. GoBubble is a social network site made for children in schools that has been using this kind of age assurance technology, by requesting users to send a selfie upon sign up. Meta is also currently in the process of testing this method of age assurance, by working with Yoti, one of the leading age assurance technology developers.

• Capacity testing allows services to estimate a user’s age through an assessment of their capacity. For example, through a puzzle, language test or a task that might give an indication of their age or age range. Whilst this is a safe and engaging option for children, and does not require the collection of personal data, it might not be as efficient at determining the specific age of a user. The Chinese app developer BabyBus uses this type of methodology in its app, by providing a test where users are asked to recognise traditional Chinese characters for numbers.

More examples and use cases of age assurance mechanisms are provided in the 5Rights report. 

Therefore, although it may be difficult to strike a balance between appropriately verifying users’ age prior to sign up, and avoiding over-intrusive measures to do so, it is apparent that solely relying on the user being truthful about their age is no longer sufficient for the majority of platforms, especially when processing vast amounts of personal data, sensitive data or use personal data for targeted advertising. With the growing number of very young children accessing the internet, it is important to ensure that they are protected, their fundamental rights respected, and relevant data protection provisions are fulfilled. In recent years, large steps have been made in the development of alternative secure identity and age verification technologies. The tools are therefore available for organizations to ensure that their GDPR requirements are also met in this respect. 

TechGDPR is a consultancy based in Berlin offering GDPR compliance assessments, DPO-as-a-service retainers and hourly consulting. TechGDPR consultants help assess the vendors you wish to purchase your solutions from, navigate the complexity of international data transfers as well as guide you through the most compliant roll-out of the solutions you have purchased. TechGDPR routinely trains product development, HR, marketing, sales and procurement teams in understanding data protection requirements.  It offers an online training course for software developers, system engineers and product owners.

The post Processing children’s data and implementing age assurance mechanisms appeared first on TechGDPR.

Therefore, it is important to understand GDPR compliance. In most cases, the company that posts its vacancy and embarks on the recruitment process will be considered the data controller. This will make them responsible for adhering to several obligations.

Notably, here are some specific and recurrent instances, in the course of recruitment, headhunting and hiring, where a controller should look closely at the GDPR to make sure it is implementing the most appropriate and compliant solution. 

Legal bases: which is the most appropriate?

The lawfulness principle of the GDPR, first introduced in Article 5, requires that data is processed in a lawful manner, meaning that it must rely on at least one of the legal bases listed in the following Article 6. Not all legal bases are, however, always going to be applicable or the most appropriate choice, especially when dealing with candidates sourced online or applicants. The same holds true for current employees.

The imbalance of power when relying on consent

The European Data Protection Board (EDPB) acknowledges in their guidelines 05/2020 on consent, that there is a clear imbalance of power between an employer and their employee. Undeniably, the same is to be considered between a potential employer, and a prospective employee, or applicant. Although there is no dependency yet, one can still argue that an employer has a stronger bargaining position over a candidate that wishes to work for them. Therefore, the EDPB generally advises against the use of consent as a legal basis for processing activities carried out in this context. That is because, it would be difficult to prove that consent is freely given, as required by definition in Article 4 of the GDPR. In practice, it is likely that a candidate would feel obliged to provide their consent to any use of their data, as they might assume it gives them a better chance to get the job.

Legitimate interest is a good option, but comes with requirements

Instead, relying on legitimate interest might be preferable. However, the controller must still be mindful that it will also come with requirements. Based on Article 6 of the GDPR, the legitimate interest of the controller, cannot override the interests or fundamental rights and freedoms of the data subject. Which means that to begin with, the organization will have to, first and foremost, identify what the specific legitimate interest pursued is. Generally, sourcing individuals online, perhaps on professional social networking platforms, to find suitable candidates for a specific position, can be in the interest of growing a team and overall bettering an organization. However, merely identifying the interest is not enough. One would have to also balance this interest with the rights and freedoms of the data subject, also known as a balancing test, by performing a legitimate interest assessment.

Performance of a contract can be relied upon, but with limitations

Similarly, the legal basis of necessity for the performance of a contract might actually be the most appropriate for the processing of data of individuals who apply for an open position. Specifically, when interpreting the Article 6(1)(b) provision: in order to take steps at the request of the data subject prior to entering a contract. However, this might require strict adherence to the definition. It would have to be a contract that the data subject has requested. Therefore, for processing activities in the context of online recruitment and headhunting, it is unlikely that this legal basis can be relied upon. Instead, as mentioned above, legitimate interest might be the only option.

Online recruitment and the duty to inform

On the topic of online scouting and headhunting, there are further legal obligations that controllers need to be mindful of, when processing personal data for this purpose. Those being, depending on how these activities are carried out, the requirements of Article 14.

Reaching out to the candidate in due time

First and foremost, it is crucial to actually contact the candidate, if their data has been processed. In fact, Article 14 requires this communication to be done within a reasonable period after obtaining the personal data and at the latest within one month. That time-frame should also serve as a retention period for the data processed for this purpose, should the candidate not respond, for example. 

The communication should also require all the information to ensure that the transparency principle is met. Therefore, ideally the candidate should be directly informed, or at the very least be provided with a specific privacy notice indicating all the information required by Article 14 e.g. the identity of controller, the purpose of processing, the categories of data processed, etc…

Honoring data protection principles and data subject rights

Needless to say, the controller should adhere to the other principles of the GDPR. Notably, data minimization, by processing only the information that is strictly required to source the ideal candidate.

Furthermore, a controller should also inform candidates of and be mindful of data subject rights. Specifically ensuring that mechanisms are in place to allow for candidates to exercise them, and ensuring that the data be processed for a specific purpose, so once that has been fulfilled, the data should no longer be processed. In practice: if the data is only processed to reach out to potential candidates, and they reject the offer but do not expressly request the data to be erased, their personal information should still be erased, unless it serves another explicitly indicated purpose.

Processing special categories of data in recruitment

In accordance with Article 9 of the GDPR, special categories of data include the following: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data, health data and data related to sex life or sexual orientation.  As a general rule, processing data that falls under these categories is prohibited. However there are exceptions. Related to the context of hiring potential employees, two might be particularly relevant: explicit consent from the data subject and necessity to carry out legal obligations and exercising specific rights of the controller or the data subject in the field of employment and social security and social protection law, based on national law provisions.

How does this apply to recruitment?

There are several reasons. For example: a potential  employer might wish to request information about a candidate’s disability to make relevant adjustments, perhaps for interviews and, if relevant, for the work moving forward. Furthermore, many companies have established equal opportunity programs, dedicated for specific minorities and/or in a certain field. Alternatively, they wish to monitor whether they meet equal opportunity requirements. Some organizations might even get recognition for ensuring high standards for diversity e.g. Stonewall Top 100 employers in the UK, Human Rights Campaign Corporate Equality Index. However, in order to monitor those metrics and ensure diversity, they process special categories of data, such as race, disability (health data) and sexual orientation. 

Explicit consent or national law obligation?

As mentioned before, using explicit consent might be an issue, because it is hard to truly guarantee that it is freely given in this context. Especially when applying for an equal opportunity program, it is unlikely that the applicant has any choice but to disclose the relevant information, as that will be the deciding factor as to whether they meet the criteria to enter into the program. 

Instead, one can rely on the second exception, related to national legal obligations. In many countries, laws that ensure the equal treatment of minorities and penalize discrimination at work, often also include articles or sections that require positive action, in the field of employment. For example, in Germany, positive action is required by §5 of the Equal Treatment Act (AGG). In the UK, where the UK GDPR applies, this is provisioned in Article 159 of the Equality Act 2010. 

Organizations are left free to decide how to implement this, but this freedom has gradually led to defining metrics and equal employment opportunities. Since this is a way to exercise a legal right of the data subject, and a legal obligation of the controller, one could preferably rely on this exception, rather than explicit consent. 

In fact, best practice would be to rely on the national legal obligation exception where such exceptions apply, but request data subject’s explicit consent, which gives them the option not to reveal this information e.g. prefer not to say.

In conclusion…

Under the GDPR, controllers must process personal data of candidates and applicants lawfully. Not all legal bases are equally applicable: in the context of recruitment, relying on legitimate interest or performance of a contract might be more reliable than relying on the applicant’s consent, although those also have their rules and limitations too. 

Furthermore, a controller must ensure to note and follow the obligation to contact candidates that it scouts online, and keep in mind the one month deadline to get in touch.

Lastly, controllers might wish to get acquainted with national legal obligations in the scope of equal employment, as legal obligations in those frameworks provide them with a legal basis to process special categories of data, for the purpose of promoting diversity in the workplace. 

TechGDPR is a consultancy based in Berlin offering GDPR compliance assessments, DPO-as-a-service retainers and hourly consulting. TechGDPR consultants help assess the vendors you wish to purchase your solutions from, navigate the complexity of international data transfers as well as guide you through the most compliant roll-out of the solutions you have purchased. TechGDPR routinely trains product development, HR, marketing, sales and procurement teams in understanding data protection requirements.  It offers an online training course for software developers, system engineers and product owners.

The post Understanding GDPR Compliance in Recruitment appeared first on TechGDPR.

There is no precise definition under the GDPR of what constitutes a legitimate interest and this precisely opens the room for a controller to argue that certain business activities, for instance, sending direct marketing messages to a group of people are based on controller’s legitimate interest. 

Ultimately, all companies have different interests in processing personal data for different purposes. But are all these interests legitimate? 

The GDPR offers a few sections where certain characteristics can be extracted, reducing its scope and outlining this lawful basis. 

On one hand, the GDPR explicitly says that personal data can be processed for the controller’s legitimate purposes or third party purposes (Article 6.1.f). In other words, a company can have the intention of processing personal data for their own interest but if third parties need to receive personal data, this also constitutes a legitimate interest. 

Additionally, commercial interests are also part of the list. For example, if a company has a commercial interest to store the personal data of website visitors, this is possible in principle. 

Nevertheless, the processing of such personal data must be necessary. The latter means that it can’t be up to the controller’s discretion to process this data and it must be the only way to achieve those purposes. Thus, if it’s possible to do it in another way, then it’s not recommendable to rely on this legal basis. 

Taking the previous example, the company should determine that they do need to store website visitor data in order to better understand the customers and/or to know what is the customer’s interest using the company’s services so that it will be possible to improve the services and search external adequate suppliers if needed. 

But not everything ends here.

If such interest affects individuals’ fundamental rights and freedoms, it won’t be possible to carry out the processing, even if it is necessary. 

Hence, if a company informs on the privacy policy that they will collect website visitor’s data for improving the service but then those individuals start receiving weekly newsletters with products they are not interested in, it is not possible to do it under the GDPR. 

Purpose, Necessity and the Balancing Test: relying on legitimate interests as a lawful basis. 

As previously shown, three elements need to be considered whenever a company selects legitimate interest as their legal basis.

First, consider whether the activity at hand pursues a legitimate interest and none other. For instance, if a company stores employee bank account data for payment purposes, this is inextricably linked to the employment contract, therefore the legal basis of this processing activity is to allow the company to perform a contract, which means no legitimate interest is involved here. 

Secondly, the processing of the activity has to be necessary to achieve this legitimate interest. 

Finally, such interest must be balanced with individuals interest, rights, and freedoms. Moreover, if individuals are affected – particularly children- by that processing or would not likely expect that processing to happen, companies should avoid processing their personal data or find another lawful basis. An important factor that could trigger this last step is what the privacy notice disclosed to individuals. If companies include clear information about the processing, individuals are more likely to expect that processing.
We encourage companies to keep a record of the legitimate interests assessment (LIA) to demonstrate compliance if required. 

Use-cases: can companies rely on legitimate interest for direct marketing or web analytics?

There is no clear cut yes-or-no answer to these questions. 

Apart from the mandatory 3-step approach, it is important to keep in mind that the relationship with the individuals plays a very important role in determining the possibility to use this legal basis. Should the company have a previous client relationship, the individual could expect the processing of personal data. In other cases, a full Legitimate Interest Assessment (LIA) will lead to the applicability of the legitimate interest will be determined on a case-by-case basis. 

Ultimately, the information companies provide to the individuals is key for preventing possible claims. The privacy notice is the best place to provide as it, at the very least allows individuals to exercise the right for their data to not be subject to further processing.

In short, in this article, we discovered that if an appropriate assessment is implemented before processing any personal data based on legitimate interest, it is in effect broader in scope than other legal grounds. The legitimate-interest legal base can be flexible, but it requires both a documented internal assessment of the three stages within the company and external communication to those individuals involved. 

The post How to use legitimate interest under the GDPR? appeared first on TechGDPR.

This calls for some explanation. 

What is PII?

Personally, identifiable information is defined by the US Office of Privacy and Open Government as :

“Information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.”

To distinguish an individual is to identify an individual by discerning one person from another and to trace an individual is to process sufficient information to make a determination about a specific aspect of an individual‘s activities or status. Following this definition, name, email address, postal address, phone number, personal ID numbers (e.g., social security, passport, driver’s license, bank account) are considered PII.

Information is designed as linked if any piece of personal information can be used to identify an individual. (e.g.: birth name). Information is categorized as linkable information if, on its own, it may not be sufficient to enable to identify a person, but when combined with another piece of information, it could identify, trace, or locate a person (e.g.: birth date).

Take for instance two datasets containing different PII. When both datasets are accessible to the same person, it becomes possible to identify individuals from combining the datasets or accessing additional information about the subject. This is where information security comes into play. If controls designed at keeping the data sources separate are insufficient, then data is considered linked. When an additional source of information remains external or at a distance -the case with siloed databases within organisations or via a search engine on the internet for publicly accessible information, then that data is thought to be linkable.

What is sensitive PII?

PII is considered as sensitive if the loss, compromission, or disclosure without authorization of this data could result in harm, embarrassment, inconvenience, or unfairness to an individual. For instance, the following information is considered to be sensitive PII: 

• medical
• educational
• financial
• employment information

What is personal data under GDPR?

The GDPR in article 4, defines personal data as follows:

“Personal data” shall mean any information relating to an identified or identifiable natural person (‘Data Subject’); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity ».

In this definition we see four main elements: “any information”, “relating to”, “an identified or identifiable” and “natural person”.  

First element: “any information”

The term “any information” contained in the Directive clearly calls for a wide interpretation of the concept. Regarding the nature of the information, this means that both objective and subjective information of a person can be considered as personal data. Regarding the content, personal data covers any sort of information. The definition is also technology neutral, It does not matter how the personal data is stored (e.g.:  alphabetical, numerical, graphical, photographic, acoustic). As an example, images of individuals captured by a video surveillance system can be personal data to the extent that the individuals are recognizable.

Second element: “relating to”

In general terms, information can be considered to“relate” to an individual when it is about that particular individual. In order to consider the data related to someone, one of the three flowing features should be present: content, purpose, or result. These three features should be considered as alternative conditions and not as cumulative ones. Accordingly, the same piece of information may relate to different individuals at the same time, depending on what element is present with regard to each one.

Third element: “identified or identifiable”

“Identified” when, within a group of persons, he or she is “distinguished” from all other members of the group. The natural person is “identifiable” when, although the person has not been identified yet, it is possible to do it.  

What information can be an identifier? The GDPR provides a non-exhaustive list of common identifiers that, when used, may allow the identification of the individual to whom the information in question may relate (e.g., name, identification number, location data, online identifier). 

The concept of “directly” or “indirectly” identifiable implies that the extent to which certain identifiers are sufficient to achieve identification is something dependent on context.

Some characteristics are so unique that someone can be identified with no effort. If I mention “our boss”, you’ll know exactly who I am speaking about.

Fourth element: “natural person”

The concept of a natural person refers to Article 6 of the Universal Declaration of Human Rights, according to which “Everyone has the right to recognition everywhere as a person before the law”. The right to the protection of personal data is, in that sense, a universal one that is not restricted to nationals or residents in a certain country. Thus, a natural person deals with the requirement that « personal data » is about « living individuals ». Under the GDPR, the personal data of deceased individuals are not covered but may still indirectly receive some protection in certain cases, in particular when that personal data involves data subjects who are still alive.

What is sensitive data under the GDPR?

The following personal data are considered as special categories of personal data and are subject to specific processing conditions according to the Art. 9 of the GDPR:

• personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs;
• trade-union membership;
• genetic data, biometric data processed solely to identify a human being;
• health-related data;
• data concerning a person’s sex life or sensitive data. 

What about online identifiers?

Recital 30 of the Regulation clarifies the definition of “online identifier” mentioned

in Article 4: 

“Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.” 

Device IDs, IP addresses and Cookies are considered as personal data under GDPR. According to the definition of the PII, they are not PII because there are anonymous and cannot be used on their own to identify, trace, or identify a person. 

What about pseudonymised data?

A personal data is considered as anonymized if it does not relate to an identified or identifiable natural person or if it has been rendered anonymous in such a manner that the data subject is not or no longer identifiable.

Pseudonymisation of data means replacing any identifying characteristics of data with a pseudonym, or, in other words, a value which does not allow the data subject to be directly identified. Are pseudonymised data still considered as personal data?

According to the Article 29 of the Working Party opinion, personal data that has been de-identified, encrypted or pseudonymised but can be used to re-identify a person remains personal data and falls within the scope of the GDPR. Personal data that has been rendered anonymous in such a way that the individual is not or no longer identifiable is no longer considered personal data. For data to be truly anonymised, the anonymisation must be irreversible.

PII  includes any information that can be used to re-identify anonymous data. Information that is anonymous and cannot be used to trace the identity of an individual is non-PII. Device IDs, cookies and IP addresses are not considered PII for most of the United States. But some states, like California, do classify this data as PII. California classifies aliases and account names as personal information as well.

In a nutshell, PII refers to any information that can be used to distinguish one individual from another. The GDPR definition of personal data is – deliberately – a very broad one. In principle, it covers any information that relates to an identifiable, living individual. 

The post What is the difference between personally identifiable information (PII) and personal data? appeared first on TechGDPR.

Cold calling individuals is like throwing a rock in a pond with the hope of catching a fish. Obviously, the success rate is high enough to justify manning the phone with a single person all the way up to outsourcing a floor’s worth of call center advisers. But how can you continue making cold calls when you have purchased personal data?

With lots being said about the GDPR signalling death of sales and marketing as we know it, it’s hard to make sense of how much room remains for your organisation to call up an unsuspecting prospect in a compliant way. While you can’t avoid raising suspicion as to where the data subject’s number originated from, there is a wide spectrum of practices ranging from downright non-compliance data collection to the fully-fulfilled duty to inform. Though it is limiting to approach the Regulation with a single use case it remains the best way to avoid opening the floodgates to exceptions. For the purposes of this post, I’ll cite the following example:

Can personal data be sold and bought under the GDPR?

Inheriting personal data sets from a third party with no proper documentation (e.g.: legal basis for initial collection, records of the duty to inform being fulfilled by the initial controller, recorded consent or readily available consent matrix) is a liability for both the personal data broker and the purchaser. At the very least, records of processing activities should establish a trace of the transaction since personal data sold to a third party is a data transfer to a recipient. Additionally, your organisation will need to prove that subjects were informed this transfer would take place or that you informed them within a month of purchasing their personal data that your organisation now processes it. More on this further on. 

Failing to document what information was communicated and what legal base apply violates both the data protection principles of lawfulness and transparency and that of purpose limitation, exposing you to the heaviest of fines: 4% of annual turnover. If your organisation had purchased personal data from a third party source, don’t hide that information. Should your staff turn down a data subject request to know what the origin of that data is, make sure the staff has been trained to recognize the request as a genuine data subject request. Article 14.2.f) makes it compulsory for organisations to inform data subjects if requested as to the source of the data that was not collected from them directly.

The worst scenario on your call-center floor is for an agent to downplay that request and respond that the subject’s phone number was communicated by their line manager. You may need to review your processes, knowledge base and staff training as to how to handle data subject requests. You would be surprised how many people use built-in or third party app call recorders on their phones

While you can sell and purchase personal data, you have to be very clear about it. Unlike the CCPA, the GDPR does not make it a requirement to disclose that the data will be sold, instead it makes it a requirement to disclose who will be receiving it.

In that respect, the CCPA more explicitly acknowledges the commercial uses of personal data. It makes it a requirement to disclose such uses, to provide subjects to opt their data out of the sale. To that respect, it allows for slightly more traceability in the data supply chain than the GDPR does. Keep in mind that small print at the end of a 10-page privacy policy will not impress authorities. Requirements of concision and clarity can be found in Article 12.1.

Can our organisation cold call data subjects?

Yes, it can.

Central to data protection is your duty to inform. Fulfilling it puts your organisation in line with GDPR’s principle of lawfulness, fairness and transparency (GDPR Art.5.1).

It is likely that the applicable legal basis for processing personal data in your case is legitimate interest. Yet having determined an applicable legal base is not compliant unless the purpose and the legal base are formally communicated to the data subject.

Can data subjects refuse to be the target of your direct marketing?

Yes, under Article 21.1 of the GDPR, an individual has the Right to Object. While, typically this right designed to put the burden of proof on the controller that its processing of personal data is done in the controller’s legitimate interest, the data subject also has the right to outright object to the use of data for direct marketing. This means that your company will have to mark the personal contact data to prevent it from being used for that purpose. This is one of the only technical and organisational measures explicited in the GDPR. Apply it if the data is nonetheless required to serve other purposes such as the performance of a contract. Should the data serve no other purpose, the best practice principles of data minimization and purpose limitation dictate the complete deletion of the personal data.

As hinted above, do not expect the data subject to officially formulate a deletion or objection request via your data protection officer. Treat their request on the phone as officially as you can. Which naturally increases expectation on staff compliance training.

Must I perform my duty to inform during the call?

Where the CCPA does not makes it compulsory for organisations to disclose having transferred or sold their data unless the subject requests to know, the GDPR makes it a requirement to inform proactively about the transfer of personal data to a third party or recipient.

While a strict reading of the GDPR might lead you to believe that you should read your complete privacy policy on the phone, in reality the situation is not that extreme but needs to be broken down at little.

If, prior to the call, you have collected the contact information from the data subject, you will have already informed them, and collected consent (if such is your legal basis), on the purpose of processing. On the call itself, you might be inclined to remind the data subject of the legal base on which you are currently operating but there is no GDPR provision making this a requirement other than building trust and plain courtesy.

If you have not collected data from the data subject but amassed their contact details from a different source, or third party, then, you should inform data subjects of your full identity and contact details, what data you have collected, under what legal base(s) you have done so, what retention period governs that data processing and what rights the data subjects can exercise. GDPR. Art.14.3a) sets the duty to inform time frame to within a reasonable period after obtaining the personal data and no more than one month.

Should you place a call to the data subject before having informed them of the above, you should understandably be prepared to read this information out to them and facilitate the exercise of their data subject rights (GDPR Art.12).

A full list of elements your communication should include is available in Articles 12 to 14.

What if the data subject actually consents to their data being used when on call?

Technically, you could record the call to document consent but consent for that form of data collection -audio recording- would first be needed. Recording a call is nothing short of collecting biometric and personal data and, in many cases, transferring that data to servers or cloud services across the Atlantic. If your cloud provider is not listed under the EU-US / Swiss-US Privacy Shield and no other legal instrument allows for that transfer, the call recording would fail the compliance test on many levels.

A best practice often witnessed involves sending an opt-in email immediately after the call which recaps the essence of your phone conversation, what you agreed to share, the data the subject consented to disclosing and which were the purposes stated. You might want to consider including the date at which the conversation took place in the body of the text, i.e.: not relying on the email client’s automated time stamp.

Yes, your organisation can sell or purchase persona data and place cold calls.

The GDPR only prohibits both forms of personal data processing unless they are done unlawfully.
Unlawful data processing in the case of direct unsolicited marketing by phone is characterized by depriving data subjects of their rights, violating data protection principles of fairness, transparency and accountability, failing to inform them upon acquisition or collection of their data, depriving them of information when you first come in contact with a subject’s personal data and not supporting them in the exercise of their rights. If you have these items under control, you’re good to proceed with a fair degree of confidence in your compliance.

If you need help with reviewing your data protection practices, your data flows, your compliance documentation and call center staff or management training, get in touch.

TechGDPR specialises in digitised environments and products including AI, machine-to-machine / IoT transactions and Blockchain applications. We offer consulting packages, hourly support, staff training and workshops.

The post Personal data and cold calling under the GDPR appeared first on TechGDPR.

About WIFI-tracking

WiFi-tracking technology relies on devices such as smart phones sending so called probe requests. With enabled wireless network, a device will broadcast a probe in regular intervals to see which known or unknown wireless networks are available to possibly connect to. By capturing these requests along with some other information such as signal strength and time, a fairly accurate analysis of the location and behavior can be made. By combining data from different access points in close vicinity, an accurate location can be determined through trilateration.

The GDPR as introduced on May 25^th 2018, does make this practice harder: as MAC (Media Access Control) addresses are considered (pseudonymised) personal data, e.g. it can be used to single out a person, it requires a valid legal base and adherence to the other articles of GDPR. This article explores the possibilities for meeting these requirements.

Personal data and scope of the GDPR

The definition of personal data under the GDPR is outlined in Article 4(1):

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

On 19 October 2016, the Court of Justice of the European Union (the “CJEU”) published its judgment in Case 582/14 – Patrick Breyer v Germany. This judgement concludes that dynamic IP addresses are to be seen as personal data, and following the same logic, MAC addresses of personal devices are therefore certainly to be seen as personal data.

While alternatives for MAC addresses, such as hashed or encrypted versions, can be stored and processed, these would still be considered pseudonymous if they can uniquely single out a single device belonging to a natural person. Pseudonymising data does not move it out of scope of the GDPR as the data can still be linked back to a natural person, with the use of extra information.

As soon as position of devices is determined, there is location data available as well which certainly falls under the GDPR.

Once data is truly anonymized (e.g. aggregated data with a significant enough sample size), and it can no longer be related back to a single data subject, it will be out of scope of the GDPR and can be further used. Nevertheless a valid legal base will be required for the initial collection of any personal data.

Who is the controller?

Defining the different stakeholders is important to further analyze the GDPR compliance. The data subject within WiFi-tracking is the person with a personal, WiFi-enabled device that is being tracked. This person should be guaranteed GDPR compliant processing of his or her personal data. That includes the requirement of properly informing them about their data being processed their rights under the GDPR.

Defining the data controller and data processor is more challenging. The GDPR has defined that the controller is the one ‘determining the means and purpose for processing’ and the processor as the one ‘processing data on behalf of the controller, based on specific written instructions’. In a WiFi-tracking situation this may mean different things based on the specifics of the setup.

If a venue utilizes WiFi-tracking for its own purposes (such as capacity planning) with its own hardware using a third party software, it is quite likely that the venue is the controller, and the third party software provider the processor. This also requires a data processing agreement to be in place between the two to ensure the processor is given specific written instructions for processing.

In case the hardware is placed in the venue by a third party service provider, and the data is then made available directly to them for purposes pursued by the service provider, this may as well be determined to be the controller.

Legal bases

For the processing of personal data under the GDPR, the controller needs to define the legal base of processing. There are 6 possible legal bases (Art 6 GDPR, sub 1): (a) consent, (b) performance of a contract, (c) legal obligation, (d) vital interest, (e) public interest and (f) legitimate interest. Legal bases c, d and e do certainly not apply as WiFi-tracking can not be seen as a legal obligation, in anyone’s vital interest or in public interest in general. The other possible legal bases are analyzed hereunder.

Consent (Art 6.1a)

To claim the legal base of consent, the data subject will need to freely give prior consent to the processing in case. It is important to emphasize that consent need to be freely given and can therefor not be required for the provision or ‘payment with data’ of a service.

Recital 42: “… Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.”

Recital 43: “Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.”

If consent was a precondition of a service, but the processing is not necessary for that service, consent is deemed to be invalid. Mixing in the consent for tracking with the use of guest WiFi or a loyalty program, is therefor not possible. Consent to WiFi-tracking should be given as an additional, non-required option.

In addition, consent should be revocable as easily as it has been given. A system should be in place that allows for consent to be revoked at any place and time.

Collecting consent

1. Using a captive portal
2. Using proximity push notifications
3. Through a loyalty program

Performance of a Contract (Art 6.1b)

The performance of a contract may be used for fulfilling contractual obligations, as well as for the preparatory stages of concluding a contract. This however, would imply that at least at some point a ‘business’ relationship for the usage of data can be substantiated.

If data subjects may be rewarded in some kind of way for providing their tracking details and usage data, this could be a way to explore the use of Article 6.1b as a legal base, but not until the data subject has shown interest in such a relationship themselves, e.g. it can not be assumed. In short, for tracking behavior without further reward program, this legal base can not be applied.

Legitimate Interest (Art. 6.1f)

Legitimate interest may be the legal basis for processing user data if the interests of the user do not override the interest of the controller when considering the reasonable expectations of the data subject and their relationship with the controller, according to the GDPR. The determination of legitimate interest requires “careful assessment” of these reasonable expectations and the context of data collection.

A legitimate interest could be a purely commercial interest. The legitimate interest and it’s balancing against the interest of the data subject, need to be well documented and the essence of it is to be explained to the user.

What is important to consider for legitimate interest, is to analyze if there are less privacy-intrusive methods of reaching the same goal. If this is the goal, legitimate interest is unlikely to hold up.

Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC (which has been adopted as guidance under the GDPR) states:

The economic interests of business organizations to get to know their customers by tracking and monitoring their activities online and offline, should be balanced against the (fundamental) rights to privacy and the protection of personal data of these individuals and their interest not to be unduly monitored.

According to the same opinion, in case the goal of the tracking is marketing, there are more specific requirements under the ePrivacy Directive:

consent is required under Article 5(3) of the ePrivacy Directive for behavioral advertising based on tracking techniques such as cookies storing information in the terminal of the user.

Public space vs. private space

Strong opinions by data protection authorities, for example the Dutch DPA have been issued on WiFi-tracking in (semi-)public spaces. While WiFi-tracking within private (commercial) space can be legitimized, the moment personal data of those outside of the premises (e.g. passers-by) are analyzed it is very difficult to base this on legitimate interest.

If legitimate interest is used as a legal base, measures may need to be in place to ensure that only data subjects in the companies premises are being tracked.

Fulfilling the duty of information

Whichever legal base is chosen, as soon as personal data is collected of data subjects, they need to be informed. The regulation prescribes this as follows in Article 13:

Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: …

This means that the controller has the duty to inform data subjects. Which is in the situation of an app or website, normally practiced by publishing a privacy notice. In the case of WiFi-tracking, this is obviously more problematic. One way may be to display a clear notice at the border of the perimeter, for example with a sticker on the door.

At the same time, data subjects should also have the choice not to be subjected to data processing, and would therefor need to be advised to switch off their WiFi in case they wish to opt out.

Data minimization and storage limitation

Whatever personal data is stored under the GDPR needs to be the minimum amount required to meet the specified purpose, and needs to be stored no longer than required for this purpose.

In current implementations of data protection for WiFi-tracking, there is a big emphasis on timely anonymization and limited storage as means to protect the privacy of the users. NS, in the example below, uses a different hash per day in order not to be able to correlate information across multiple days.

Mechanisms to exercise rights

Whenever personal data is collected from data subjects, they have rights under the GDPR, and they need to be informed about them and given ways to execute their rights. These rights could be rights to justification, right to erasure, right to information and the right not to object to automated decision making. The first ones could be surfaced through a website, portal or app of some sort. The last one needs to be closely considered in terms of what happens with their date.

Example of WiFi-tracking in practice and their explanation of compliance to the GDPR.

At the time of writing, Nederlandse Spoorwegen (Short:NS, translated: Dutch Railways) uses WiFi-tracking on (at the time of writing) 6 of its larger train stations. They make travelers aware of this with stickers indicating the use of WiFi-tracking around the station, and explain the mechanics behind it in their privacy policy: https://www.ns.nl/en/privacy/in-and-around-the-station.html

In summary, they use the legal base of the legitimate interest “to improve our services and to increase your safety in and around the station.” and use technical measures to limit and further pseudonymize the MAC addresses collected:

“The MAC address is immediately ‘hashed’ – converted into a series of characters. This series is then sent to a server, where we add extra random characters and hash the series again (a process known as ‘salt’). The extra characters differ per day, and are not stored on a computer. We then ‘cut out’ some of the characters, so that there is no way that the series can be traced to an individual.”

Other requirements under the GDPR

As WiFi-tracking counts as monitoring of behavior, and should in most cases be considered on large scale, both the controller and processor will need to designate a data protection officer, and, in case it has no establishment in the EU, also designate a EU representative.

ePrivacy Regulation and Directive

The ePrivacy directive, and in the future the ePrivacy Regulation deals with communication instead of data processing, and is therefore relevant for the use of WiFi-tracking. It will be further scrutinized with the introduction of the ePrivacy regulation. The regulation prohibits companies from using consent collection methods that force users to agree to tracking in order to receive access to services. The Regulation provides three possible purposes for tracking:

• When it is necessary to transmit an electronic communication.
• When it is necessary to provide an information society service requested by the user.
• When it is necessary to measure the reach of an information service requested by the user.

The original draft of the ePrivacy Regulation also contains provisions for the protection of data subjects using public WiFi. That initial draft stated that tracking an individual’s location through a WiFi or Bluetooth connection was permitted. However, in response, Parliament and the Working Party proposed solutions that would require businesses that have locations which provide WiFi to obtain a data subject’s consent before tracking and to post a notice on the possible dangers of using their WiFi connection in a prominent place.

The latest draft of the ePrivacy regulation, dated October 2018, contains the following relevant passage in recital 25:

A single wireless base station (i.e. a transmitter and receiver), such as a wireless access point, has a specific range within which such information may be captured. Service providers have emerged who offer physical movements’ tracking services based on the scanning of equipment related information with diverse functionalities, including people counting, such as providing data on the number of people waiting in line, ascertaining the number of people in a specific area, etc referred to as statistical counting for which the consent of end-users is not needed, provided that such counting is limited in time and space to the extent necessary for this purpose.

Providers should also apply appropriate technical and organisations measures to ensure the level if security appropriate to the risks, including pseudonymisation of the data and making it anonymous or erase it as soon it is not longer needed for this purpose. Providers engaged in such practices should display prominent notices located on the edge of the area of coverage informing end-users prior to entering the defined area that the technology is in operation within a given perimeter, the purpose of the tracking, the person responsible for it and the existence of any measure the end-user of the terminal equipment can take to minimize or stop the collection.

Additional information should be provided where personal data are collected pursuant to Article 13 of Regulation (EU) 2016/679. This information may be used for more intrusive purposes, which should not be considered statistical counting, such as to send commercial messages to end-users, for example when they enter stores, with personalized offers locations, subject to the conditions laid down in this Regulation, as well as the tracking of individuals over time, including repeated visits to specified locations.

There is no final draft of the ePrivacy Regulation yet, so the exact implementation of these requirements remains unclear for the time being. It is expected that once officially adopted, the Regulation will come into force 24 months later.

Conclusion

Generally spoken, WiFi-tracking under the GDPR (and ePrivacy regulation in the future) is challenging. The main problems revolve around:

1. WiFi-tracking relies on MAC addresses, which are considered personal data, even in hashed form.
2. It is required to inform data subjects before collection of personal data takes place.
3. Consent as a legal base is challenging as it’s very difficult to collect valid, freely given consent from data subjects. Where consent may be collected, e.g. through a captive portal, it is quite unlikely to have a high conversion rate.

Possible approaches to GDPR compliance

There are some approaches that can be considered to utilize WiFi-tracking within the requirements of the GDPR:

1. Informing and asking for consent through a captive portal, push notification or app before tracking users.

Where the legal base of processing personal data would be consent, one approach may be to ask consent through a captive portal. This could be set up as an additional option when asking people to agree to conditions for using guest WiFi.

2. Relying on legitimate interest for tracking.

It seems possible to rely on legitimate interest for tracking in certain cases, but this limits what the tracked data can be used for. It needs to be possible to argue for a real, legitimate interest that can not or hardly be met using less privacy-intrusive methods. It can be further debated if direct marketing or advertising can constitute a legitimate interest for this purpose or not. If that is the case, all data subjects need to be given an easy way to opt-out of this tracking.

3. Find a way to moving the data out of scope of the GDPR though anonymized collection.

If a way can be found to properly anonymize data following the requirements of the GDPR, it will be out of scope of the GDPR and can therefor (from that point onwards) be processed freely. The challenge with this approach is the correlation of data which will become impossible if the data is anonymized right at collection. Also, for low traffic areas, the sample size may be too insignificant to ensure that tracking is truly anonymous.

NOTE: This article does not constitute or replace legal and professional advise. Consult your lawyer or privacy professional before using WiFi-tracking.

The post WiFi-Tracking and Retail Analytics under the GDPR appeared first on TechGDPR.

“In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimizing the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features.” (Recital 78)

Simply put, the GDPR expects companies and other organizations to implement technical and organizational measures at their earliest stages of design and at the earliest stages of their operations.  They need to do this in a way that safeguards privacy and data protection principles right from the start (“data protection by design”). Such requirements are also, quite frankly, simple due diligence in the world of reliable data management. So, how does one actually “design” data protection for data subjects?

What is Privacy by Design?

Privacy by design is not a new concept. It is the philosophy proposed by Dr. Ann Cavoukian, the Information and Privacy Commissioner of Ontario in the 1990s. Ann Cavoukian is widely recognized as the primary creator of the privacy by design concept. She defines it as an approach to technology design that embeds privacy-enhancing measures into technology at the point of design and production, and sells to technology to consumers with strong default privacy settings. The foundational principles of “Privacy by Design” as suggested by Ann Cavoukian are:

• Privacy by design is proactive, not reactive; it is preventative, not remedial. Privacy by design anticipates and protects privacy against negative and invasive effects of new products and technologies before they happen.
• Privacy by design ensures privacy as the default, which means that personal data are automatically protected in any given IT system. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy − it is built into the system, by default.
• Privacy by design means that privacy is embedded into the design and the architecture of the IT system. It is not bolted on, after-the-fact. The result is that privacy becomes an essential component of the core functionality that is being delivered.

• Privacy by design permits full functionality. When embedding privacy into a given technology, process, or system, it should be done in such a way that full functionality is not impaired, and to the greatest extent possible, that all requirements are optimized.
• Privacy by design extends securely throughout the entire lifecycle of the data involved. Strong security measures are essential to privacy, from start to finish. Privacy must be continuously protected across the entire domain and throughout the life-cycle of the data in question. There should be no gaps in either protection or accountability. The “Security” principle has special relevance here because, at its essence, without strong security, there can be no privacy.
• Privacy by design seeks to assure visibility and transparency, as they are essential to establishing accountability and trust.
• Privacy by design is consciously designed around the interests and needs of individual users, who have the greatest vested interest in the management of their own personal data. The architects should keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric!

After the GDPR came into force on May 25th, 2018 many companies became tempted to regard the regulation as a compliance burden. However, GDPR is about reputation and not just regulation. The benefits of meeting the requirement for data protection by design, which is essentially the GDPR’s version of “privacy by design” go far beyond any legal compliance.  Also, as stated earlier, much of it is standard housekeeping if you are already a company that prioritizes data security. 

New Consumer Privacy Expectations

Studies have shown that data privacy is a consideration steadily more expected by the consumers. According to a survey conducted online by The Harris Poll on behalf of IBM between March 20-26th, 2018, 78% of U.S. respondents say that a company’s ability to keep their data private is “extremely important” and only 20% “completely trust” organizations they interact with to maintain the privacy of their data. This suggests that privacy breaches not only have significant financial implications but can also cause reputational damage.  If consumers do not feel that their privacy is being protected, they will seek out other means of ensuring their privacy. 

Embracing privacy from the design phase enables companies to protect customers’ data and enhance their business reputation. It enables trusted, long-term relationships with the existing customers and the opportunity to attract new ones. Irrespective of whether they are affected by the regulatory framework itself, companies should make privacy an integral part of their DNA and their offering for their existence and for their customers’ well being. This is good news for those working in any sector, including IoT (Internet of Things), machine learning, and blockchain.

The reality—that brand reputation and consumer trust are inextricably linked—is especially true in the IoT context. According to one estimate, the total number of connected IoT sensors and devices is set to exceed 50 billion by 2022, up from an estimated 21 billion in 2018. Consumers (or as the GDPR calls them, “data subjects”) want organizations to give them more control over their personal information as the Internet of Things (IoT) grows, and connected devices harvest even more of their data, according to research from the Economic Intelligence Unit (EIU). As more devices, platforms, and infrastructure connect to the Internet in real-time, the most successful industry participants will be those that regard Privacy by Design as an opportunity to demonstrate that they are worthy of consumers’ trust.

A recent report by O’Reilly outlines the current state of machine learning adoption in the enterprise and reveals that in order to keep pace with developing privacy needs, machine learning needs to evolve. “With the EU’s recent General Data Protection Regulation mandates, more companies will begin to implement privacy safeguards into their machine learning practices”, says the report. It further reveals that the GDPR pushes for “privacy by design,” and that more businesses are taking interest in privacy-preserving analytic methods. These methods include techniques like differential privacy, homomorphic encryption, federated learning, and more.

Such privacy-preserving applications not only help companies become GDPR complaint but also allow users to benefit from the security of blockchain, among other technologies.  It’s worth noting that the popularity of new decentralized networks comes in large part from the expectation that they offer a means of protecting one’s identity. Ultimately, whatever the technology, taking early action to preserve personal privacy is a winner for both the parties, the companies and the users.  The sooner you start, the easier it will be. 

For more insights, follow TechGDPR on Twitter.

The post What the GDPR’s ‘Privacy By Design’ Really Means for Your Business appeared first on TechGDPR.

The California Consumer Privacy Act: Another GDPR?

The California Consumer Privacy Act incorporates several aspects of the GDPR into its legislation. It has a broader definition of personal data, and it emphasizes transparency with respect to the processing of data. Additionally, the law promotes subject access requests, the right to be forgotten, and data portability. It will enable data subjects to request the categories, sources, and business purposes of personal data collected by a company, and the data subjects can request what categories of personal data are being sold to different classifications of third parties.

Furthermore, a company must disclose information as to what specific personal data is collected, how it is collected, its purpose, and to whom it is shared and sold within 45 days of a data subject’s request. The company must have a way of verifying the identity of the individual making the request. Also, the business must publish its privacy policy online and include a conspicuous link saying “Do not sell my personal information” if it sells personal data.

Despite the obvious regulatory hurdles, the positive side for many tech companies is that much of what they have already undertaken to comply with the GDPR will serve them well once the California Consumer Privacy Act becomes Law.  Companies still not prepared for GDPR regulation, on the other hand, may now be under twice the pressure – and possibly suffer twice the scrutiny.

Data Privacy in California: Who is Affected?

The law protects any data subject who is a “natural person who is a California resident,” and it creates regulations for companies that conduct business in the state of California and collect consumers’ personal information for profit. Also, it must meet at least one of the following criteria: it has a gross revenue of more than $25 million annually, “alone or in combination, annually buys, receives for the business’[s] commercial purposes, sells, or shares for commercial purposes, alone or in combination, the personal information of 50,000 or more consumers, households, or devices,” or 50% or more of annual revenue comes from selling consumers’ personal data.

Just as companies outside of Europe who are handling the personal data of Europeans must comply with GDPR mandates, companies not within California’s borders are similarly compelled to comply with the state’s new data privacy requirements.  With the state set to surpass 40 million residents by the time the law comes into effect, it’s also fair to say that nearly all companies who handle the personal data of American consumers will be affected by this legislation to some degree.

A Different Approach from the GDPR

The penalties of the California Consumer Privacy Act reflect an American style compared to GDPR penalties. First off, the law allows consumers to sue the business for a violation. It is also possible for a company to be prosecuted by the California Attorney General if the violation is not corrected within 30 days. An organization could also be required to pay damages of up to $750 per consumer after a data breach, and if a company intentionally violates the law, they may be fined up to $7,500 according to each violation. Under the GDPR, a company faces a fine of €20 million or 4% of annual global turnover. Comparing penalties, the GDPR places much harsher penalties on companies, but the California legislation still indicates a significant shift in the U.S. perception of data privacy and consumer rights.

Under the GDPR, data processing requires a legal basis for the processing of personal data. If there is not a legal basis, consent is required from the data subject; without this consent, their personal data cannot be lawfully processed. However, a data subject’s consent to the processing of their personal data under the California Consumer Privacy Act appears to be assumed. The data subject can decide to opt-out of the sale of their personal data, rather than what would be seen as “opting-in” under the GDPR. Although consumers would be protected from a business discriminating against them for this reason, the businesses are still allowed to offer a financial incentive for allowing the sale or collection of personal data. Additionally, the right to opt-out will be honored for a minimum of one year before a company asks again. Nevertheless, assumed consent of data subjects in California highlights that although this is a progressive law in the United States, it still lacks much of the privacy rights gravitas established by the GDPR.

Consumer Privacy: 2020

The California Consumer Privacy Act will go into effect on  January 1, 2020, allowing businesses less than 18 months to prepare for the new regulations. While the Act is the first key example of data privacy legislation in the United States, it will not be the last. California’s significant influence over the technology sphere will quickly establish the importance of data protection—one that is likely to have an impact at both the the state and national level.  Even under current legislation, it’s unlikely that all consumers will remain happy with a company providing one set of superior privacy services to California residents and another set of services to everyone else.  Additionally, once a company has the capability, why not enable the same privacy process for all of their users and customers? Whether the incentives are political or for profit, the requirements for companies to provide advanced privacy options for consumers are becoming increasingly unavoidable.

Pierson Klein joined TechGDPR’s team as Legal Intern this summer. She is majoring in Law, Jurisprudence, and Social Thought at Amherst College (2020) in the U.S.A.

Follow TechGDPR on Twitter.

The post California Residents Gain Strongest Data Privacy Rights in US appeared first on TechGDPR.

All Hands on Deck for GDPR

Given that the Pirate Summit is one of the largest startup events in Europe, it stands to reason that my conversations there with founders were an accurate representation of current perceptions and concerns about the GDPR in the startup sector overall. Among the most common reactions is, “Oh, yes, GDPR. We already took care of that, and I’m glad it’s behind us now.”

Actually, not quite.

Such a  reaction is concerning because it leaves companies vulnerable to much larger problems later on. As TechGDPR continues to emphasize with our clients, GDPR compliance is never “done”; it is a process—one requiring ongoing vigilance over each new data-related activity that a company begins.  Whenever personal data is collected or processed, action needs to be taken.

The Size of Your Ship

The second most common reaction from founders is frustration and even resentment about the perception that startups and other smaller companies face a heavier burden to become GDPR compliant than larger, more established companies.  

In reality, even the smallest startup need not be overwhelmed. Unlike large corporations, whose compliance issues span multiple departments (and in many cases, continents), it remains far easier for a smaller company to analyze why it is collecting and processing data. Such questions can be sorted through in a matter of days within startups, setting a solid path for integrating GDPR practices throughout the company as it grows and expands.

In reality, even the smallest startup need not be overwhelmed. Unlike large corporations, whose compliance issues span multiple departments (and in many cases, continents), it remains far easier for a smaller company to analyze why it is collecting and processing data. Such questions can be sorted through in a matter of days within startups, setting a solid path for integrating GDPR practices throughout the company as it grows and expands.

Larger companies, on the other hand, often don’t know what data exists  where or why, and they are at a loss to justify many disparate mountains of personal data that have been collected for years—“just in case.” Big firms may have more resources for responding to the GDPR, but they also have far more holes to patch and processes to implement—not to mention the organizational aspect of involving many more people in their GDPR compliance efforts.

Changing Tides 

Being aware of how to implement key data collection storage is paramount, both for my fellow Pirates and for the rest of the global tech community. Sooner or later, all companies will need to properly comply if they want to stay in business. The key question is: which companies, regardless of size, will be proactive, and thus be able to feature their customer-focused privacy practices to attract and retain business? Conversely, which companies will sabotage their reputation by addressing personal data protection only because of the threat of serious fines or a devastating privacy breach?

As people (or, as the GDPR calls them,  “data subjects”) continue to increase their awareness of the rights and freedoms that any form of data privacy affords them, customers will increase their scrutiny of corporate privacy practices and seek out companies that align with customers’ data protection expectations. Successful companies will leverage the GDPR as a framework for the best practices in protecting customers’ or users’ personal data. Such companies will be able to build not only better data storage systems, but a better reputation among customers.

Staying on Course for GDPR Compliance

If you are a founder or leader of a startup or other small company and you are feeling overwhelmed by the GDPR, you are not alone. At TechGDPR, we are used to meeting clients who are grappling with the GDPR and don’t know where to start. We also spend a great deal of time reminding them of the advantages of sustained GDPR compliance.

The best place to start is in shifting our perception of the GDPR to see it as an opportunity for protecting privacy for everyone, including you. Every person who is part of a startup is also a “data subject” in countless databases and with a rapidly growing digital footprint. When we, as leaders in small companies, prioritize protecting human rights related to privacy, we are also advocating for our employees, our families, and ourselves—not to mention avoiding a few shipwrecks.

Silvan Jongerius is the Managing Partner of TechGDPR.

Follow TechGDPR on Twitter

The post Disruptive Startups Must Also Disrupt Common GDPR Assumptions appeared first on TechGDPR.