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.

With the introduction of the GDPR in 2018, data protection has become a popular topic both from a legal and technical perspective. The importance of efforts around privacy and data protection is personal data and its protection. Under the EU GDPR, there are key elements in the definition of personal data. 

Personal data is any information relating to an –

Article 4 of the EU GDPR mentions some examples of personal data in its definition (Art.4.1). It states that personal data could be ‘ […] 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’. Based on the definition of personal data and the examples stated in the EU GDPR, it may easily be inferred that technical information relating to hardware constitutes personal data, something that the new e-Privacy Regulation is expected to further clarify.

Hardware identifiers

Technical information attributed to hardware could take the form of numeric, alphanumeric or alphabetic codes used to uniquely identify a device or a batch of devices alone or within a network; for instance, the serial number of a device, the IMEI number, model number, MAC address, etc. Serial numbers are unique and assigned by a manufacturer to a device. This device could be a mobile phone, a television, a tablet, audio/video equipment, etc. According to guidance from Samsung, Serial numbers help manufacturers organise and keep track of their products. The IMEI (International Mobile Equipment Identity) number is a number that uniquely identifies a mobile communication device and no two mobile devices have the same IMEI. The IMEI number can be described as the digital fingerprint of your device. The model number is used to identify what type of device you have and applies to a number of devices that share something in common such as the manufacture or release year. While the model number is a hardware identifier, it is not unique to a device as multiple devices can have the same model number.

How can hardware identifiers be personal data?

Since these various numbers are merely hardware identifiers, how could they also be personal data? Of particular interest is the IMEI number which is often seen as the digital fingerprint of your device. Taking the definition of personal data and the IMEI number into account, the IMEI number becomes personal data as soon as it is associated with a person. Consequently, the IMEI number of a smartphone would not be regarded as personal data until it is purchased. However, when a person purchases the smartphone and activates it – which often leads to providing personal details such as name, email address, password or biometrics, i.e. opting for face ID unlock, the IMEI number becomes personal data as it is now linked to other information from the owner/user of the smartphone. 

At this point, the individual elements of the definition of personal data become important. Since personal data refers to information relating to an identified or identifiable person from direct or indirect inference, when various data points are capable of identifying a person, any data being combined with personal data, in turn, becomes personal data.  

Practical examples

Section 171 and 172 of the European Data Protection Board (EDPB) Guidelines on processing personal data in the context of connected vehicles and mobility related applications, states that when a person’s smartphone is paired with the dashboard of a rental car while using Bluetooth or USB connections, a variety of data is processed by the rental car. These might include phone identifiers, voice and data communications, contact lists, web browsing data, personal contacts, schedules, choice of music, radio and other streamed audio or video content, which all reveal personal information. As such, they help draw a precise profile of the data subject. Since IMEIs are being used to lock devices to carriers, blacklist lost or stolen phones, track the location of a smartphone, it is obvious why the IMEI number of a device should be considered as personal data after its purchase and subsequent activation. In addition, Law enforcement agencies routinely use IMEI numbers to track down criminals as well as for other forensic purposes. The use of IMEI numbers to track individuals makes a good case for why the IMEI number is personal data as soon as it becomes associated with a person by purchase, activation or however else. 

This conclusion also applies to all other hardware identifiers which are unique to the device and through which the device or its user may be traced. 

What can I do if I process IMEI numbers in the course of my business operations?

When considering whether your business processes personal data in the form of hardware identifiers, a number of factors are to be taken into account such as whether these identifiers become linked to a person through the purchase of a device, its activation or use. If you are unsure whether such identifiers constitute personal data, request a more detailed assessment from TechGDPR and its experienced consultants who will take your unique business operations into consideration and tailoring your compliance solutions.

The post Hardware identifiers: Is an IMEI number personal data? appeared first on TechGDPR.

What are HIPAA and the GDPR?

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

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

The key differences between HIPAA and GDPR relevant to MedTech 

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

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

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

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

Do HIPAA and GDPR overlap?

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

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

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

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

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

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

HIPAA and GDPR application

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

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

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

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

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

This 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.