What qualifies as personal data?

Article 4.1 of the GDPR defines personal data as “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.”

The EDPB explicitly identifies IP addresses as being personal data due to their ability to identify individual data subjects. If an IP address is successfully anonymized, then under the GDPR it is no longer considered personal data. 

The French Data Protection Authority (CNIL) ruled over a case dealing with the transfer of personal data to a company not in the EU. In the decision, the CNIL wrote:

“It should be noted that online identifiers, such as IP addresses or information stored in cookies can commonly be used to identify a user, particularly when combined with other similar types of information. This is illustrated by Recital 30 GDPR, according to which the assignment of online identifiers such as IP addresses and cookie identifiers to natural persons or their devices 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.” In the particular case where the controller would claim to not have the ability to identify the user through the use (alone or combined with other data points) of such identifiers, he would be expected to disclose the specific means deployed to ensure the anonymity of the collected identifiers. Without such details, they cannot be considered anonymous.”

What is an IP address?

An IP address is a way of identifying a device or user attached to the Internet. It is a set of numbers that distinguishes how the device requests and receives information from the Internet. The two main formats are IPv4 and IPv6. Originally, IPv4 was the sole way of identifying devices but it does not allow for as many unique addresses that are needed in the modern age. 

The format of IPv4 addresses are xxx.xxx.xxx.xxx where x is a decimal number. The format of IPv6 addresses is hexadecimal (2001:db8::ff00:42:8329), which means a value can be 0-9A-F. Static IP addresses are IP addresses that are constant and dynamic IP addresses can change over time. IP addresses can identify explicit addresses or the exact location of devices.

The GDPR perspective on IP addresses 

The GDPR explicitly includes “online identifiers” (e.g., IP addresses) as personal data when they can identify a person. Even if the controller doesn’t have the identifying data itself, if there are means reasonably likely (e.g., legal processes to get ISP logs) to link an IP to a person, then it qualifies as personal data. This logic comes from the CJEU case Breyer (C-582/14). The CJEU relied on Recital 26 of the GDPR, which states that in determining whether a person is identifiable, “to determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly.”

IP addresses can be personal data if the controller has legal ways to obtain additional info to identify someone via an ISP. This is due to the objective possibility of identification of a data subject. Under the GDPR there is less concern with whether it is probable or whether it has happened and the concern lies with whether it is objectively possible to identify an individual. Given an IP address, it is possible to identify an individual. EDPB decisions affirm that online identifiers like IP addresses are often treated as personal data because they can be combined with other information to profile or identify a data subject. 

Personal data vs PII 

Personal data, in the context of the GDPR, covers a much wider range of information than personally identifiable information (PII), commonly used in North America. In other words, while all PII is considered personal data, not all personal data is PII. For more information about PII vs personal data, read our blog post on the matter. 

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

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 aspersonal information as well.

Controllers must treat IP addresses as personal data

For organizations, this means IP addresses cannot be treated as neutral technical data. Controllers must:

• Identify a lawful basis for processing (e.g. consent, legitimate interest, contract performance).
• Provide transparency in privacy notices, clearly explaining why IP addresses are collected, who receives them (e.g., third-party providers), and how long they are retained.
• Apply data minimisation and storage limitation, ensuring IP data is only collected when necessary and retained for no longer than required.

In practice, this is highly relevant when embedding third-party services such as Google Fonts or analytics tools. Whenever a website loads resources from Google servers, the user’s IP address is transmitted to Google by default. Even when using Google Analytics with IP anonymisation enabled, the IP address is initially collected before truncation. The anonymisation feature represents a commitment by Google not to further process the full IP address, but technically, the IP is still transmitted during the request phase. From a strict GDPR perspective, this transmission itself constitutes processing.

ePrivacy Directive 

IP address collection via cookies or similar tracking technologies also engages the ePrivacy Directive. Where IP processing is linked to tracking or storing information on a user’s device, prior consent is generally required unless the processing is “strictly necessary” for providing the requested service. This creates a dual compliance requirement: organizations must assess both a GDPR lawful basis and ePrivacy consent obligations.

Anonymisation, pseudonymisation & risks

Pseudonymisation can reduce risks and demonstrate accountability, but it does not remove GDPR applicability. Organizations must still implement appropriate technical and organisational safeguards. In order to pseudonymize IP addresses, it is necessary to obscure the IP address. This is often done by: 

• For IPv4 addresses, the last segment is replaced with a zero or removed.
  • Example: 123.456.789.123 → 123.456.789.0
• For IPv6 addresses, a similar approach is applied, truncating the last portion.

Guidance from the European Data Protection Board makes clear that true anonymization must be irreversible. Simple IP truncation or masking is typically considered pseudonymization, not anonymization. This is because re-identification may still be possible, especially when combined with other data points. IP truncation reduces identifiability but does not automatically result in anonymisation. In most cases it constitutes pseudonymisation, meaning GDPR obligations still apply. Simply put: IP truncation is a risk-reduction measure (pseudonymization), not true anonymization under GDPR standards, unless re-identification is demonstrably impossible.

Real-world examples

• Analytics and server logs: IP addresses used for traffic analysis remain personal data.
• Security and abuse detection: Legitimate interest may apply, but retention must be limited.
• Advertising and profiling: IP-based tracking combined with cookies generally requires prior consent and careful transparency measures.

Conclusion 

Under the GDPR, personal data encompasses far more than obvious identifiers such as names or identification numbers. It includes any information that can reasonably be linked to an individual. IP addresses, whether static or dynamic, fall within this definition when identification is objectively possible. This identification includes even if indirect or requiring additional data from third parties. Reach out to TechGDPR for any help with regards to understanding the nuances of data protection legislative requirements. 

The post Is an IP address considered personal data?  appeared first on TechGDPR.

Executive Summary: The Dual Compliance Imperative and Strategic Findings

Organisations that leverage advanced data processing, particularly those developing complex Artificial Intelligence (AI) systems, face a critical and often unrecognized strategic risk: the prolonged retention of training data. European Union (EU) law establishes conflicting imperatives regarding data lifecycle management, creating a fundamental compliance challenge. The General Data Protection Regulation (GDPR) mandates personal data erasure as soon as the data is no longer required for its established purpose, while the newly implemented EU AI Act demands lengthy archival of system documentation.

The Inescapable Regulatory Conflict: Delete Now vs. Document for a Decade

The core of the conflict lies in the tension between personal data protection and system accountability. The GDPR is clear: personal data must be erased once its specific processing purpose is fulfilled. This is enforced by the Storage Limitation Principle (Article 5(1)(e)). Retention beyond this defined necessity, even if the data might be useful for future research or system retraining, is deemed a direct violation unless a new, distinct, and lawful purpose is established.

Conversely, the EU AI Act introduces stringent requirements for system traceability, particularly for High-Risk AI Systems (HRAS). Providers of HRAS must maintain comprehensive technical documentation, quality management system records, and conformity declarations for up to 10 years after the system is placed on the market (Article 18, EU AI Act). This requirement applies to system records, ensuring long-term accountability, but does not override the fundamental protection afforded to individuals’ data under the GDPR.

The GDPR Foundation: The “Storage Limitation” Principle 

The entire framework of data retention under EU law rests on the GDPR’s Storage Limitation Principle (Article 5(1)(e)).This foundational rule dictates that personal data must be kept “for no longer than is necessary for the purposes for which the personal data are processed.” This is the core principle driving all retention decisions.

The GDPR does not set generic retention times, instead placing the full burden on the data controller to define, document, and justify a specific deletion timeline for every category of data. If personal data (which is defined broadly to include information beyond PII, like cookie IDs) is used to train a system, the retention clock starts ticking. Organisations leveraging advanced data processing face a critical strategic risk: retaining training data for too long. The GDPR is unambiguous; personal data must be erased once its specific processing purpose. Retention beyond that, even for potential future research, is a direct violation unless a new, distinct, and lawful purpose is established.

Defining the Critical Strategic Risk for GDPR non-compliance

The strategic risk is precisely defined by failing to establish, document, and legally justify a specific deletion timeline for every category of personal data used in the training process. The absence of generic retention times in the GDPR places the full burden of definition and justification squarely upon the data controller. 

This environment forces organizations to confront a critical trade-off: is the unproven, speculative future value of raw personal data worth the risk of fines and potential data breaches? The calculation strongly favors deletion. As, 

• Failing to define and document specific deletion timelines exposes organizations to GDPR violations.
• Retaining data for future retraining or academic purposes is legally indefensible once the initial training purpose is fulfilled.
• Financial penalties for non-compliance can exceed the cost of implementing compliant, minimal-data systems.

The EU AI Act Layer: Traceability and Documentation 

The EU AI Act introduces a layered approach to retention centered on system accountability rather than individual personal data. The rules are tied to the system’s risk profile, with High-Risk AI Systems (HRAS) (EU AI Act, Chapter 3) having the most stringent obligations.

Data Governance (Article 10) for HRAS requires that training, validation, and testing data sets be relevant, representative, and free of errors. While not a direct retention rule, this implicitly requires maintaining data sets for a period necessary for auditing and quality checks during the development phase.

The most critical requirement is Documentation Retention (Article 18): HRAS providers must keep key records (Technical Documentation, Quality Management System, etc.) for 10 years after the system is placed on the market. This 10-year rule applies to documentation and metadata, not the raw personal data itself, which must be deleted sooner under the GDPR. This 10-year period covers documentation, quality records, and conformity declarations. It is vital to understand that this does not override the GDPR’s Storage Limitation Principle (Article 5(1)(e)). 

Raw personal data used for training must still be deleted sooner. However, the requirement for Record-Keeping (Logging) (Article 12) means that systems must automatically record events and usage logs. While these logs should ideally be anonymised, their retention period must be “appropriate” extending the non-personal data record-keeping timeline. This mandates a long-term, non-personal data retention strategy that must be carefully integrated with the strict, short deletion cycles required by the GDPR for raw personal data.

Blending the GDPR and EU AI Act Requirements

The intersection of the GDPR and the EU AI Act necessitates a blended compliance strategy, particularly concerning purpose and identification. The GDPR’s Purpose Limitation principle (Article 5(1)(b)) demands that the purpose for processing, such as system training, be explicitly defined. This definition directly dictates the maximum legal retention period for personal data.

Implementing De-Identification in Your AI Data Retention Strategy under the GDPR and the EU AI Act

The best path for long-term data use is de-identification:

• Pseudonymisation only reduces identifiability; the data remains personal data under the GDPR and the Storage Limitation Principle still applies.
• Anonymisation is the only legal release valve. If the data is permanently and irreversibly stripped of identifiers; it is no longer considered personal data (GDPR Recital 26). Therefore, it can be retained indefinitely.

It’s critical to remember that while the raw personal data must be deleted, the trained system itself (the output) can be retained.

Reconciling the GDPR’s Right to Erasure with the EU AI Act Traceability

The most direct legal challenge is reconciling the GDPR’s Right to Erasure (Article 17) with the ongoing need for system traceability under the AI Act. If a system is trained on personal data, the controller must maintain the technical ability to honor an erasure request.

This is the Purpose Limitation Conflict: if the initial purpose (training) is complete, retaining the raw personal data is a violation of the GDPR. Developers must implement technical solutions like secure deletion protocols immediately after a system is finalised. Using robust, irreversible anonymisation is the only way to retain data sets without triggering the GDPR’s strict retention clock.

When facing overlapping regulations, the GDPR always acts as the primary constraint on personal data. Its Storage Limitation Principle sets the hard ceiling for raw personal data retention. This is regardless of the EU AI Act’s documentation rules.

The crucial legal distinction is that PII and other personal data used to create the system must be subject to rigorous deletion procedures the moment the training purpose ends. The technical documentation, metadata, and system logs (which should contain no personal data) are then subject to the EU AI Act’s extended 10-year retention rules. This hierarchy demands that the deletion process (the GDPR) must happen first, leaving only the audit trail (EU AI Act) behind.

Table: Comparison of differences 

The Financial & Operational Cost of AI Data

Compliance is not just a cost, but a powerful risk mitigator. Storing raw personal data beyond the necessary period is a direct violation of the GDPR’s Storage Limitation Principle. This exposes an organisation to fines of up to 4% of global annual turnover (GDPR Article 83).

Beyond the fines, excessive data retention creates massive operational liability. Longer storage times mean higher infrastructure costs and a larger surface area for security breaches. Every day the data is held, the probability of a costly Data Subject Request (DSR) increases, demanding expensive legal and technical personnel to fulfill. Compliant, timely deletion is ultimately the most financially responsible strategy.

Should you store raw personal data for training?

Organisations often retain raw data for perceived future utility, perhaps for retraining a system. The GDPR forces a hard strategic trade-off: is the speculative future value of that raw personal data worth the immediate, tangible risk of massive fines and data breaches?

The EU AI Act demands auditable records, but these should be built from fully anonymised data or non-personal data metadata. The cost calculation is simple: the threat of financial penalty for retaining personal data too is a much greater risk or potential cost than developing a compliant, data-minimal system. A mature data strategy prioritises de-identification and deletion over retention, significantly reducing the organisation’s regulatory and financial exposure.

Strategic Recommendations

The regulatory landscape governing AI development in the EU is defined by a critical tension:

1. the immediate obligation to protect individual privacy (GDPR) and
2. the extended obligation to ensure system safety and traceability (EU AI Act).

Compliant data management requires recognizing the GDPR’s Storage Limitation Principle as the absolute constraint on personal data retention. This is regardless of the EU AI Act’s documentation timelines. The solution is architectural separation, where raw personal data is subject to automated deletion, and the audit trail is constructed exclusively from non-personal, irreversibly anonymized assets.

TLDR;

• Under the GDPR, personal data must be deleted once its specific purpose is fulfilled. This limits how long raw training data can be stored.
• For AI developers, this means models cannot indefinitely rely on historical raw personal data. This can potentially impact retraining strategies and model evolution.

The post AI Data Retention Strategy under the GDPR and the EU AI Act: Reconciling the Regulatory Clock appeared first on TechGDPR.

Ad Tech: Meta personalised ads, technical identifier system in App Store, IAB Europe’s consent mechanism

Meta has a few months to reassess the valid legal basis for how Facebook and Instagram use personal data to target advertising in the EU after the media giant was issued fines totaling 390 million euros. It related to a 2018 change in terms of service at Facebook and Instagram following the implementation of the GDPR where Meta sought to rely on the so-called “contract” legal basis for most of its data processing operations. Services would not be accessible if users declined to press the “I agree” button. The final decision states that Meta cannot use a contract as a legal basis for processing data on the grounds that the delivery of personalised ads is not necessary to fulfil Facebook’s contract with its users.

The final decision came under pressure from many privacy regulators in the EU/EEA, (under the one-stop-shop mechanism). In particular, the lead Irish regulator DPC disagreed with a number of counterparts and took the side of Meta that Facebook and Instagram services include, and indeed appear to be premised on, the provision of a personalised service that includes personalised or behavioural advertising. This reality is central to the bargain struck between users and their chosen service provider, and forms part of the contract concluded at the point at which users accept the terms of service. When it became clear that a consensus could not be reached, the regulators referred the dispute to the EDPB who later issued a binding decision.

Finally, the DPC was criticised for not freshly investigating all Facebook and Instagram data processing operations directed by the EDPB in its binding decision. The DPC believes that EDPB does not have a general supervision role akin to national courts in respect of independent national authorities and it is not for the EDPB to instruct and direct an authority to engage in an open-ended investigation. The DPC is now considering bringing an action for annulment before the CJEU in order to set aside the EDPB’s directions. 

The French privacy regulator CNIL fined Voodoo, a smartphone game publisher, 3 mln euros for using an essentially technical identifier for advertising without the user’s consent. The investigation showed: 

• When Voodoo offers an application on the App Store, Apple provides an ID for vendor technical identifier system, (IDFV), allowing the publisher to track users’ use of its applications. 
• An IDFV is assigned for each user and is the same for all applications distributed by the same publisher. 
• By combining it with other information from the smartphone, the IDFV tracks people’s browsing habits, including the game categories they prefer, in order to personalise the ads seen by each of them.
• When opening a game application, a first Apple-designed page, (App Tracking Transparency or ATT), is presented to the user in order to obtain their consent to the tracking of their activities on the applications downloaded on their phone. 
• When the user refuses the “ATT solicitation”, a second window is presented by Voodoo indicating that advertising tracking has been disabled while specifying that non-personalised advertisements will still be offered. 

During its checks, however, the CNIL found that when a user expresses their refusal to be the subject of advertising tracking, Voodoo still reads the technical identifier associated with this user and always processes information related to their browsing habits for advertising purposes, therefore without their consent. 

Similarly, the CNIL sanctioned Apple Distribution International with 8 mln euros for not having obtained the consent of French iPhone users, (using App Store), before depositing identifiers used for advertising purposes. Identifiers pursuing several purposes, including for advertisements broadcast, were by default automatically read on the user’s device without obtaining consent. 

Meanwhile, the Belgian data protection authority approved IAB Europe’s action plan for its Transparency and Consent Framework – a widely used approach to collecting and managing consent for targeted advertising cookies in the EU. A year ago, a Belgian regulator fined the company 250,000 euros for multiple violations of the GDPR including the absence of a legal basis for processing. The measures proposed in the action plan stem directly from the assumption that:

• The TC String, (a digital marker containing user preferences), should be considered personal data, and 
• IAB Europe acts as a (joint) controller for the dissemination of TC Strings and other data processing done by TCF participants. 

Both of these assumptions have been referred to the CJEU by the Belgian Market Court for a preliminary ruling, and such a referral was explicitly asked for by the Belgian authority itself in the course of the proceedings.

Legal processes and redress: administrative and civil remedies, data subject access rights

The CJEU has ruled that administrative and civil remedies provided for by the GDPR may be exercised concurrently with and independently of each other. Given that the parallel exercise of administrative and civil remedies could give rise to contradictory decisions, (eg, when the supervisory authority refuses a request from an individual and the latter brings the appeal to the court), a Hungarian court asked the CJEU whether one of those remedies might take priority over the other. The EU top court stipulated that it is for each Member State to ensure, through adopting the procedural rules, that the concurrent and independent remedies provided for by the GDPR do not call into question the effective remedy before a court or tribunal. 

The CJEU also confirms a broad definition of data subject access rights, (DSARs): data controllers must reveal the specific recipients of any data they shared unless it is impossible or excessive to do so. The court emphasized that DSARs are necessary to exercise other rights under the GDPR, such as the right to rectification, erasure, and restriction of processing. The related case concerns an individual’s request to a postal and logistical services company to disclose the identity of recipients to whom the company had disclosed, (sold), the individual’s personal data. At the same time, the access right should not adversely affect the rights or freedoms of others, including trade secrets or intellectual property and in particular the copyright protecting the software. However, the result of those considerations should not be a refusal to provide all information to the data subject. 

Investigations and enforcement actions: failed data access requests and health-related data consent

The Italian privacy regulator fined I-Model, (promoter and web agency specialised in the selection and management of personnel for events and communication), 10,000 euros for failure to adequately respond to access requests and unlawful processing, Data Guidance reports. After receiving confirmation from I-Model that the personal data in its files had been deleted, the complainant continued to receive job offers from the company. I-Model gave a formal response to the complainant’s requests for deletion of personal data on two occasions, merely stating that it had removed the data from the mailing list, but, in fact, continuing to store and process the data without a legal basis. 

The Finnish data protection commissioner fined an unnamed company 122,000 euros for not having consent in accordance with the GDPR to process data on body mass index and maximum oxygen uptake capacity. The company had asked for consent to process health-related data in general but had not specified the data it collected and processed and for what purposes. The disciplinary board paid special attention to the fact that the large-scale processing of health data is a key part of the company’s core business. Importantly, the company’s service is also available in other EU and EEA countries, which is why the issue was discussed in cooperation between supervisory authorities. One of the complaints had been initiated in another Member State. 

The Finnish regulator also imposed a penalty of 750,000 euros on the debt collection company Alektum. It had not responded to requests regarding a data subject’s rights. The company also complicated and slowed down the investigation by avoiding the supervisory authority. As a result, several complainants did not get access to their own data and did not have the opportunity, for example, to correct it or monitor the legality of the processing. Any organisation is obliged to respond to requests regarding the rights of the data subject within one month. If there are many requests or they are complex, a data controller can state that it needs an additional time of up to two months. In the case of one complainant, Alektum explained the non-response by saying that it no longer processed the data subject’s personal data. Even then, the company should have responded to the request.

Official guidance: AI supervision and transparency requirements, Privacy by Design as an international standard, EU whistleblowing scheme report

The Norwegian data protection authority has published an experience report on how you can get information about the use of Artificial Intelligence. Transparency requirements related to the development and use of AI are normally divided into three main phases:

• development of the algorithm,
• application of the algorithm,
• post-learning, and improvement of the algorithm.

The GDPR requirements for information are general and basically the same for all phases. But there are also requirements that only become relevant for certain phases. For example, the requirement to inform about the underlying logic of AI will usually only be relevant for the application phase. The full guidance, (in Norwegian), is available here. 

In parallel, the Dutch data protection authority is starting a new unit, which should give a boost to the supervision of algorithms. During 2023 it will identify the risks and effects of algorithm use, (cross-sectoral and cross-domain). Where necessary, collaborations will be deepened further with the other supervisors, (eg, on transparency obligations in the various laws, regulations, standards, and frameworks), preventing discrimination and promoting transparency in algorithms that process personal data. 

Denmark’s data protection authority looked at the newly approved EU whistleblowing scheme. During the first year of implementation, two out of three reports concerned data protection, (eg, regarding insufficient security of data processing, and monitoring of employees). That is partly because the national data protection authority was mandated to receive and process reports regarding breaches of EU law in a number of areas, including public tenders, product safety, environmental protection, food safety, reports of serious offenses, or other serious matters, including harassment. Nonetheless, many people associate the scheme with data protection only. All cases concluded in 2022 were completed within the deadlines, with an average time frame of 27 days.

Finally, the International Organisation for Standardisation is about to adopt ISO 31700 on Privacy by Design for the protection of consumer products and services. ISO 31700 is designed to be utilised by a whole range of companies — startups, multinational enterprises, and organisations of all sizes. It features 30 requirements and guidance on:

• designing capabilities to enable consumers to enforce their privacy rights, 
• assigning relevant roles and authorities, 
• providing privacy information to consumers, 
• conducting privacy risk assessments, 
• designing, establishing, and documenting requirements for privacy controls, 
• lifecycle data management, and 
• preparing for and managing a data breach. 

However, it won’t initially be an obligatory standard.

The post Data protection & privacy digest 3 – 17 Jan 2023: personalised ads dilemma: contract as a legal basis, in-apps tracking via technical identifiers 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.