Personal Data (PII)

Customer databases, personnel files, log files with IP addresses: practically every company processes personal data, often in far more places than assumed. The GDPR ties extensive duties to this, from the legal basis to the reporting of data breaches. For IT decision-makers, the term is therefore not a legal footnote. It determines which systems must be particularly protected and where an incident becomes expensive.

What is personal data?

Under Article 4 GDPR, personal data is all information relating to an identified or identifiable natural person. Identifiable means: the person must be determinable directly or indirectly, for example via name, identification number, location data, or online identifiers. This means that, in addition to obvious details such as address or date of birth, IP addresses, device identifiers, customer numbers, and movement profiles also fall under the term.

In the English-speaking world, the abbreviation PII (Personally Identifiable Information) is widespread. It is often used synonymously, but in the US understanding it is defined more narrowly than the European term. For companies within the scope of the GDPR, the broad European definition is decisive.

A separate level of protection applies to special categories under Article 9 GDPR, including health data, biometric and genetic data, as well as details on religion, political convictions, or sexual orientation. Their processing is generally prohibited and permitted only under narrow exceptions.

How it works

Protection emerges from the interplay of legal, organizational, and technical measures:

  • Secure the legal basis: Every processing needs a basis under Article 6 GDPR, such as consent, a contract, or a legitimate interest. Without a basis, the processing is unlawful.
  • Know the data inventory: The record of processing activities documents which data is processed where and for what purpose. It is at the same time the map for all protective measures.
  • Live data minimization: What is collected is what is necessary for the purpose. Deletion policies ensure that data actually disappears after the deadlines expire.
  • Secure technically: Article 32 GDPR requires measures appropriate to the risk. These include encryption during transmission and storage, access control on the need-to-know principle, network segmentation around systems with sensitive data, as well as logging and tested backups.
  • Anchor organizationally: Authorization processes, training, data processing agreements, and a practiced reporting channel for data breaches make protection fit for everyday use. In the event of a reportable breach, 72 hours remain for the report to the supervisory authority.

Why it matters

  • High fines: the GDPR provides for fines of up to 20 million euros or four percent of worldwide annual revenue, whichever is higher.
  • Claims by data subjects: alongside official proceedings, waves of access requests and damage claims loom, which tie up considerable capacity after an incident.
  • Reputational risk: data breaches become public, at the latest through the notification duty toward data subjects. Lost trust has a longer effect than any fine.
  • Attractive target: identity data can be monetized. Systems with personal data are therefore in the focus of ransomware groups, which extract data before encryption and threaten to publish it.
  • Trust basis for business models: those who demonstrably protect customer data negotiate more easily with corporate customers and their data protection reviews.

Typical scenarios

A retail company consolidates customer data from shop, CRM, and newsletter system. Only the record of processing activities reveals how many copies exist. The number of storage locations is reduced, access is restricted on a role basis.

A service provider processes health data for health insurers. Because of the special categories, tightened requirements apply: the systems run in their own network segment, every access is logged, and the transmission is encrypted throughout.

A ransomware group intrudes via a compromised workstation. Because the personnel systems are strictly segmented, the spread there fails. The incident stays confined to non-critical systems and triggers no notification of the workforce.

PII vs. pseudonymized data

Pseudonymization replaces direct identifiers with references, for example a customer number instead of the name. Crucially: pseudonymized data remains personal, because the assignment is still possible with the separately stored key. The GDPR applies to it in full, but honors the measure as a risk reduction in the sense of Article 32.

To be distinguished from this is anonymization. It removes the personal reference irreversibly, so that the GDPR no longer applies to the data. The hurdle is high: if the reference can be restored through additional knowledge or linking with other sources, the data is only pseudonymous. For analyses and tests, it is worth checking which of the two levels is actually reached.

Protection with KAEMI

KAEMI secures the networks in which personal data flows. With microsegmentation , systems with customer or personnel data are precisely isolated. Access follows the need-to-know principle, and the visualization of all connections provides the evidence for data protection reviews. For employees in the home office and in the branch offices, the Zero Trust approach of Secure Access Service Edge ensures that every access to data inventories takes place authenticated, encrypted, and logged. If you want to approach the protection requirements of your data inventories in a structured way, you can reach us via the contact page .

Frequently asked questions about Personal Data (PII)

Is an IP address a piece of personal data?

Yes, as a rule. Dynamic IP addresses too are considered personal when the controller has the legal means to have the subscriber determined. The European Court of Justice has confirmed this. For practice this means: log files, analysis tools, and firewalls process personal data and belong in the record of processing activities.

What are special categories of personal data?

Article 9 GDPR lists data with an increased protection requirement: health data, genetic and biometric data, details on ethnic origin, political opinions, religious convictions, trade union membership, as well as on sex life or sexual orientation. Their processing is permitted only under narrow exceptions and requires stricter protective measures, such as end-to-end encryption and particularly restrictive access rights.

Is pseudonymized data still personal?

Yes. As long as the personal reference can be restored via a key or additional knowledge, the data remains within the scope of the GDPR. Pseudonymization is valuable nonetheless: it considerably lowers the risk in incidents and is expressly named as a protective measure by Article 32 GDPR. Only an irreversible anonymization ends the data protection duties.

Which technical measures does the GDPR specifically require?

Article 32 names, by way of example, pseudonymization and encryption as well as the ability to ensure confidentiality, integrity, and availability over the long term. The law does not prescribe concrete products; what is required is a level appropriate to the risk. In practice, access control with multi-factor authentication, network segmentation, logging, and regularly tested backups have proven effective.

When must a data breach be reported?

A breach of the protection of personal data must be reported to the supervisory authority within 72 hours of becoming known, unless it is unlikely to result in a risk to the data subjects. If there is a high risk, the affected persons must additionally be notified. Prepared reporting channels and clean logging decide whether this deadline is tenable.

From term to implementation: KAEMI supports you from the first assessment to day-to-day operations.