Privacy and Data Protection
Protecting personal and sensitive data: data protection law, data classification, data loss prevention, and what to do after a data breach.
Privacy and security
Privacy is the right of people to decide, within the law, what information about them is collected, how it is used and with whom it is shared. Information security protects data — any data — against unauthorized access, change and loss. The two overlap but are not the same:
- A perfectly secured database can still violate privacy, if it holds data that should never have been collected or is used for a purpose people were never told about.
- Privacy is impossible without security: promises about personal data mean nothing if anyone can read it.
In the EU, privacy and data protection are fundamental rights, and in the EU and the UK data protection law applies to every organization that handles personal data. In the United States, which rules apply depends on the state, the sector and the kind of data. Either way, they reach almost every IT team, help desk included.
Data protection law
Most of this page uses the concepts of the EU's General Data Protection Regulation (GDPR, Regulation (EU) 2016/679), which has applied since 25 May 2018. It is the most influential privacy law: the United Kingdom kept a near-copy after Brexit, and many other countries modeled their laws on it. Which law applies to you depends on where your organization is and whose data it handles.
The GDPR (in Dutch the Algemene verordening gegevensbescherming, AVG) is the European Union law on the processing of personal data. It covers organizations established in the EU and also organizations elsewhere that offer goods or services to, or monitor, people in the EU. Maximum fines are €20 million or 4% of worldwide annual turnover, whichever is higher. In the Netherlands, the Autoriteit Persoonsgegevens (AP, the Dutch Data Protection Authority) supervises compliance; the Uitvoeringswet AVG adds Dutch details, for example on the citizen service number (BSN), which may only be used where a law allows it.
The United States has no single federal privacy law like the GDPR. Personal data is protected by a patchwork:
- Sector laws: HIPAA for health data held by health care providers, health plans and their business associates; the Gramm-Leach-Bliley Act (GLBA) for financial institutions; COPPA for online services that collect data from children under 13 (its rule was updated in 2025, with compliance required from 22 April 2026).
- The Federal Trade Commission (FTC) uses Section 5 of the FTC Act, which prohibits unfair or deceptive practices, against companies that break their own privacy promises or protect data carelessly.
- State laws: the California Consumer Privacy Act (CCPA), expanded by the California Privacy Rights Act (CPRA), applies to for-profit businesses that do business in California and have annual revenue above $25 million (adjusted for inflation), buy, sell or share the personal information of 100,000 or more California residents, or earn half their revenue from selling or sharing it. The California Attorney General and the California Privacy Protection Agency (CPPA, also called CalPrivacy) enforce it. Well over a dozen other states, such as Virginia, Colorado and Texas, have comprehensive privacy laws of their own, with similar ideas and different details.
The GDPR still applies to a US organization that offers goods or services to people in the EU or monitors them, and the UK GDPR does the same for people in the UK. The principles, lawful bases and roles below are GDPR concepts; US laws use other terms (the CCPA speaks of businesses, service providers and consumers) but many of the same ideas: notice, purpose limits, rights to access and delete, and reasonable security.
In the United Kingdom, the UK GDPR (the GDPR as kept in UK law after Brexit) and the Data Protection Act 2018, which adds UK details and exemptions, set the rules. The Data (Use and Access) Act 2025 amended both; most of its data protection changes took effect on 5 February 2026. Among them are "recognised legitimate interests" (a fixed list of purposes, such as crime prevention and safeguarding, that need no balancing test), wider room for automated decisions with safeguards, and some analytics and functionality cookies without consent. Maximum fines are £17.5 million or 4% of worldwide annual turnover, whichever is higher. The regulator is the Information Commission, which took over from the Information Commissioner's Office (ICO) on 30 September 2026 with the same role and powers; its guidance is on ico.org.uk. The concepts on the rest of this page are the same as in the EU GDPR.
Personal data
Personal data is any information relating to an identified or identifiable living person. "Identifiable" is broad: not just a name, but anything that can single someone out, directly or combined with other data. Examples are names, email addresses, phone numbers, home addresses, employee numbers, IP addresses, device identifiers, location data, photos and voice recordings. A help desk ticket that says "the printer on the third floor jams when Sanne prints her payslip" is full of personal data.
Special categories of personal data need extra protection and may in principle not be processed, unless one of the specific exceptions in the law applies: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used to identify someone, health data, and data about a person's sex life or sexual orientation. Data about criminal convictions has its own, similarly strict rules.
The principles
Article 5 of the GDPR lists the principles that every processing activity must follow. Most of the rest of the law works them out.
| Principle | Meaning in practice |
|---|---|
| Lawfulness, fairness and transparency | A lawful basis for every processing; tell people what you do with their data, in clear language |
| Purpose limitation | Collect for specified purposes; do not reuse for a new, incompatible purpose |
| Data minimization | Only the data that is necessary for the purpose |
| Accuracy | Keep data correct and up to date; fix errors |
| Storage limitation | Keep data in identifiable form no longer than needed |
| Integrity and confidentiality | Appropriate security: access control, encryption, backups, logging |
| Accountability | Be able to demonstrate compliance: records of processing, policies, assessments, agreements |
Data Governance and Privacy works out purpose limitation and the statistical-purpose rule for analytics.
Lawful bases
Every processing of personal data needs one of six lawful bases (Article 6): consent; performance of a contract with the person; a legal obligation (for example tax records); vital interests (protecting someone's life); a public task; or the legitimate interests of the organization, weighed against the person's interests. Consent is only valid when it is freely given, specific, informed and unambiguous, and it can be withdrawn as easily as it was given — which is why employers rarely rely on consent from their own staff.
Roles: who is responsible
The GDPR assigns responsibility by role, not by who physically holds the data.
- The data controller is the organization that decides why and how personal data is processed. It is responsible for compliance and is the party people and the supervisory authority deal with.
- A data processor processes personal data on behalf of a controller and only on its instructions — a payroll service, a cloud provider, a managed service provider running your servers. Under the GDPR, the controller and processor must have a written processor agreement (also called a data processing agreement) that sets out the instructions, security measures, use of subprocessors, breach reporting and what happens to the data at the end.
- The data subject is the person the data is about.
Inside an organization, security frameworks add operational roles.
| Role | Who | Responsibility |
|---|---|---|
| Controller | The organization | Decides purpose and means; accountable under data protection law |
| Processor | A supplier | Processes on instructions; secures data; reports breaches to the controller |
| Data owner | A business manager | Classifies the data and decides who may access it |
| Data custodian or steward | IT staff, data managers | Implements the owner's rules: storage, backups, access, quality |
| Data protection officer (DPO) | Independent adviser (staff or contracted) | Advises and monitors compliance; contact for the authority and for data subjects |
| Data subject | Customer, employee, patient … | Has rights over their own data |
A data protection officer (DPO; in Dutch functionaris gegevensbescherming, FG) is mandatory for public authorities and for organizations whose core activities involve large-scale, regular and systematic monitoring of people or large-scale processing of special categories of data or criminal-conviction data. The DPO must be able to work independently and reports to the highest level of management. In Dutch, the processor agreement is a verwerkersovereenkomst.
US law has no general duty to appoint a DPO, though many companies appoint a chief privacy officer anyway. HIPAA requires health care organizations to designate a privacy official and a security official. The written contract with a processor is required by sector and state laws: HIPAA calls the processor a business associate and the contract a business associate agreement (BAA); the CCPA requires a contract with every service provider or contractor that limits what it may do with the data.
Under the UK GDPR, the rules for a data protection officer (DPO) are the same as in the EU: mandatory for public authorities and for organizations whose core activities involve large-scale, regular and systematic monitoring of people or large-scale processing of special categories of data or criminal-offence data, independent, and reporting to the highest level of management. The written processor contract is required as well. In addition, organizations that use personal information must pay the regulator an annual data protection fee, unless they are exempt.
Data subject rights
People can exercise rights over their data: to be informed, to access it (and get a copy), to rectification, to erasure ("the right to be forgotten", which has exceptions such as legal retention duties), to restriction of processing, to data portability, to object, and not to be subject to decisions based solely on automated processing with significant effects. The organization must respond without undue delay and within one month, extendable by two months for complex requests.
There is no general federal right to see or delete your data; the rights come from state and sector laws. The CCPA gives California residents the right to know what a business collects and how it is used, to delete, to correct, to opt out of the sale or sharing of their personal information, to limit the use of sensitive personal information, and not to be discriminated against for using these rights. A business must respond within 45 calendar days, extendable by another 45 days if it tells the consumer. HIPAA gives patients the right to access and amend their health records, and other state privacy laws give similar rights with their own deadlines.
The UK GDPR gives the same rights as the EU GDPR: to be informed, to access, to rectification, to erasure, to restriction, to data portability, to object, and rights around automated decisions. The deadline is one month, extendable by two months for complex requests. Searches need only be reasonable and proportionate (a rule the Data (Use and Access) Act 2025 wrote into law with effect from 1 January 2024). Since 5 February 2026 the clock starts only once the organization has the request and any proof of identity or fee it asked for, and it can be paused while the organization waits for a clarification it reasonably needs. Since 19 June 2026, organizations must also have a way to make a data protection complaint, acknowledge each complaint within 30 days and deal with it without undue delay.
DPIA and privacy by design
A data protection impact assessment (DPIA) is a structured assessment of a planned processing activity that is likely to result in a high risk to people's rights and freedoms. A DPIA describes the processing and its purpose, assesses whether it is necessary and proportionate, identifies the risks to the people involved, and records the measures that reduce them.
Under the GDPR, a DPIA is required before such processing starts — for example large-scale processing of health data, systematic monitoring of a publicly accessible area on a large scale, such as camera surveillance, or profiling with significant effects on people. The Autoriteit Persoonsgegevens publishes a list of processing types for which a DPIA is always required. If a high risk remains, the authority must be consulted before starting.
No federal law requires a DPIA from private companies; federal agencies write privacy impact assessments (PIAs) under the E-Government Act of 2002. Several state privacy laws, such as Virginia's and Colorado's, require a data protection assessment before high-risk processing such as targeted advertising, selling personal data, processing sensitive data or profiling. In California, CPPA regulations in force since 1 January 2026 require risk assessments for processing that presents a significant risk, with a first summary due to the agency by 1 April 2028.
The UK GDPR has the same requirement as the EU GDPR: a DPIA before processing that is likely to be high-risk, such as large-scale processing of health data, systematic monitoring of public areas or profiling with significant effects. The UK regulator publishes its own list of processing types that need a DPIA, among them biometric and genetic data, tracking people and innovative technology. If a high risk remains, the regulator must be consulted before starting.
Privacy by design and by default (Article 25) asks for data protection to be built in from the start rather than bolted on: collect fewer fields, pseudonymize where possible, limit who can see what, set short retention, and choose the most privacy-friendly setting as the default — a new user profile is private until the user decides otherwise.
Data classification
Data classification is assigning data a level according to its sensitivity and the impact of its disclosure, change or loss, so that everyone knows how to handle it. The data owner decides the level; labels (in document headers, file metadata, email subject tags) make it visible. Not only personal data is classified: designs, contracts, network diagrams and passwords all have a level.
| Level | Examples | Handling rules (example) |
|---|---|---|
| Public | Website text, press releases, published prices | No restrictions; changes still need approval |
| Internal | Intranet pages, internal phone list, procedures | Staff only; share outside only with a business need; normal disposal for paper without personal data |
| Confidential | Customer records, salaries, contracts, network diagrams | Need-to-know access; encrypted at rest and in transit; no private email or personal cloud storage; shred paper |
| Secret (or restricted) | Merger plans, encryption keys, security incident details, control system designs | Named individuals only; access logged; strong encryption; no copies without approval; certified destruction |
Organizations choose their own names and number of levels, and governments use their own schemes, so read your own policy. The principle is the same everywhere: the higher the level, the fewer people, the more protection, the more logging. Data also needs protection in each of its states — at rest, in transit and in use; see Cloud Security and Compliance for encryption at rest and in transit.
Data loss prevention
Data loss prevention (DLP) is a set of tools and rules that detect sensitive data in use, in motion or at rest and prevent it from leaving the organization through unauthorized channels. DLP runs on endpoints (copying to a USB stick, uploading in a browser), on the network and email gateway, and in cloud services. It recognizes sensitive data by classification labels, by patterns (bank account numbers, national identification numbers such as the Dutch BSN, the US Social Security number or the UK National Insurance number), by fingerprints of specific documents, or by exact matches against a database. When a rule matches, it can log, warn the user, block, quarantine or encrypt.
Pattern matching alone produces many false alarms, so good rules add
validation. This sketch looks for email addresses and International
Bank Account Numbers (IBANs) in an outgoing message, and only
reports an IBAN if its check digits are valid. All data is fake: the
bank code TEST does not exist.
import re
IBAN_PATTERN = re.compile(r"\b[A-Z]{2}\d{2}[A-Z0-9]{11,30}\b")
EMAIL_PATTERN = re.compile(r"\b[\w.+-]+@[\w-]+(?:\.[\w-]+)+\b")
def iban_is_valid(candidate):
"""ISO 13616 check: move 4 characters to the end, letters to numbers, mod 97."""
rearranged = candidate[4:] + candidate[:4]
digits = "".join(str(int(ch, 36)) for ch in rearranged)
return int(digits) % 97 == 1
def scan(text):
findings = []
for match in IBAN_PATTERN.finditer(text):
if iban_is_valid(match.group()):
findings.append(("IBAN", match.group()))
for match in EMAIL_PATTERN.finditer(text):
findings.append(("email", match.group()))
return findings
outgoing = """Hi, please refund customer bram.jansen@example.com
to account NL13TEST0123456789. Ticket reference NL00TEST0000000000."""
for kind, value in scan(outgoing):
print(f"{kind:<6}{value}")
print("verdict:", "hold for review" if scan(outgoing) else "send")
IBAN NL13TEST0123456789 email bram.jansen@example.com verdict: hold for review
The ticket reference looks like an IBAN but fails the check digits, so it is not reported. Real DLP products combine many such detectors, count matches (one email address in a message is normal; five hundred is an export) and use context. Detectors for US Social Security numbers and UK National Insurance numbers cannot lean on check digits the way the IBAN detector does, so they rely on the format, on numbers that are never issued (no Social Security number starts with 000, 666 or 9) and on context words such as "SSN" nearby. Expect some false positives anyway, and make it easy for users to ask for a review rather than to work around the tool.
Data breaches
Under the GDPR, a personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. That is broader than "hackers stole our database". All of these are data breaches:
- An email with a customer list sent to the wrong recipient.
- An unencrypted laptop with personnel files left on a train.
- Ransomware that encrypts the patient records, even if nothing was copied — availability counts too.
- A shared folder accidentally open to everyone.
- Paper files thrown in an ordinary bin.
What the GDPR requires:
- The controller notifies the supervisory authority (in the Netherlands the Autoriteit Persoonsgegevens) without undue delay and where feasible within 72 hours of becoming aware of the breach, unless the breach is unlikely to result in a risk to people. Information may be supplied in phases if the investigation is still running; a late notification must explain the delay.
- When the breach is likely to result in a high risk — think of identity fraud, discrimination, or exposure of health data — the controller also informs the people affected, without undue delay, in clear language with advice on what they can do. This is not needed if, for example, the data was strongly encrypted and the key was not compromised.
- A processor informs its controller without undue delay; the controller does the notifying.
- Every breach is documented internally — facts, effects and measures taken — including the ones that did not need to be reported, so the decision can be checked later.
A breach can also be a security incident under other rules: an organization covered by NIS2 may have to report the same event to its cybersecurity authority within 24 hours (see Governance, Frameworks and Compliance).
US law usually defines a breach more narrowly, and who must be told depends on the data and the sector:
- State breach-notification laws exist in all 50 states, the District of Columbia, Guam, Puerto Rico and the US Virgin Islands. They typically cover unauthorized access to or acquisition of specific data, such as a name together with a Social Security number, a driver's license number or a financial account number, and often exempt encrypted data. You notify the affected residents under each state's law: some states say "without unreasonable delay", others set a fixed number of days, and many also require a notice to the state attorney general (in California when more than 500 residents are affected).
- HIPAA: a health care organization notifies the people affected without unreasonable delay and no later than 60 calendar days after discovering the breach. Breaches affecting 500 or more people also go to the Department of Health and Human Services (HHS) within that time, and to the media when more than 500 residents of a state are affected; smaller breaches are reported to HHS within 60 days after the end of the calendar year.
- Non-bank financial institutions report a breach of unencrypted customer information affecting 500 or more consumers to the FTC within 30 days of discovery (Safeguards Rule). Public companies disclose a material cybersecurity incident to the Securities and Exchange Commission (SEC) within four business days of deciding that it is material.
- A service provider or business associate informs the organization it works for, which does the notifying. Document every incident and why you did or did not notify; under HIPAA that documentation is required.
For critical infrastructure, the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) will require reports to the Cybersecurity and Infrastructure Security Agency (CISA) within 72 hours, and within 24 hours of a ransom payment, once CISA's final rule applies. That rule had not been published by early October 2026, so check its status.
What the UK GDPR requires (the same as in the EU):
- The controller notifies the regulator (the Information Commission, formerly the ICO) without undue delay and where feasible within 72 hours of becoming aware of the breach, unless the breach is unlikely to result in a risk to people. Report early and add details as the investigation goes on; a late notification must explain the delay.
- When the breach is likely to result in a high risk to people, the controller also informs them without undue delay, in clear language with advice on what they can do.
- A processor informs its controller without undue delay; the controller does the notifying.
- Every breach is documented internally, including the ones that did not need to be reported.
The same event can fall under other rules: operators of essential services report significant incidents under the NIS Regulations 2018 within 72 hours, and the Cyber Security and Resilience Bill, still before Parliament in October 2026, would add a first report within 24 hours. Telecom and internet providers have their own breach-reporting rule under the Privacy and Electronic Communications Regulations (PECR).
Handling the incident itself follows the incident response process.
Pseudonymization and anonymization
Pseudonymization replaces identifying values with pseudonyms (tokens) so that the data can no longer be linked to a person without additional information, which is kept separately and protected. The GDPR encourages it as a security measure, but for the organization that pseudonymized it, the data is still personal data: whoever has the additional information — the key or the lookup table — can re-identify people. The EU Court of Justice added in 2025 (case C-413/23 P) that for a recipient who has no realistic means to re-identify anyone, the same data may not be personal data. The sender still has all its GDPR duties, including telling people who receives their data (see Data Governance and Privacy). Anonymization removes the link irreversibly, for everyone; anonymous data is outside the GDPR. True anonymization is harder than it looks, because combinations of ordinary fields (postal code, birth date, gender) can single out individuals, especially when combined with other data sets.
A common technique is a keyed hash: a hash-based message authentication code (HMAC) of the identifier with a secret key. The same input always gives the same token, so analysts can still count and join records per customer without seeing who the customer is.
import hashlib
import hmac
# Demo key for this example only. A real key is random, long, and kept in a
# secrets manager, separate from the pseudonymized data.
DEMO_KEY = b"demo-key-not-for-production"
def pseudonym(value):
"""Return a stable token for a value: same input, same token."""
normalized = value.strip().lower().encode("utf-8")
digest = hmac.new(DEMO_KEY, normalized, hashlib.sha256).hexdigest()
return "P-" + digest[:12]
# Fictional customers of a fictional energy supplier
records = [
{"email": "anna.devries@example.com", "city": "Utrecht", "kwh": 2710},
{"email": "bram.jansen@example.com", "city": "Delft", "kwh": 1985},
{"email": "Anna.deVries@example.com ", "city": "Utrecht", "kwh": 2840},
]
for record in records:
print(pseudonym(record["email"]), record["city"], record["kwh"])
# Why a plain hash is not enough: anyone can hash a list of guessed
# addresses and compare. Without the key, that does not work for HMAC tokens.
plain_token = hashlib.sha256(b"bram.jansen@example.com").hexdigest()
for guess in ["anna.devries@example.com", "bram.jansen@example.com"]:
if hashlib.sha256(guess.encode("utf-8")).hexdigest() == plain_token:
print("plain hash re-identified:", guess)
P-b142193641f9 Utrecht 2710 P-492c3bbad839 Delft 1985 P-b142193641f9 Utrecht 2840 plain hash re-identified: bram.jansen@example.com
The first and third records get the same token because the address is normalized first (trimmed, lowercase), so the analyst sees two readings for one customer. An unkeyed hash of an email address is not pseudonymization worth the name: email addresses are easy to guess, so anyone can hash a list of candidates and look them up, as the last lines show. The HMAC key prevents that — and is exactly the "additional information" that keeps this data personal data. Whoever holds the key can recompute every token, so it is protected like any other secret.
Retention, deletion and transfers
Retention and deletion
Storage limitation means every category of data needs a retention period, recorded in a retention schedule: how long, why, and what happens afterward. Some periods come from law (examples below), others from the purpose (job applicants' data shortly after the vacancy is filled, camera footage after a few weeks unless there is an incident). After the period, data is deleted or anonymized, preferably automatically. How retention works out for logs, with a per-log-type policy, is shown in Logs, and for analytical data in Data Governance and Privacy.
Dutch tax law, for example, requires businesses to keep their financial administration for seven years.
The IRS asks businesses to keep tax records generally for three years (six or seven in some situations) and employment tax records for at least four years. HIPAA requires its compliance documentation to be kept for six years, and the CCPA requires businesses to tell consumers, when they collect the data, how long they keep each category or how they decide.
A UK limited company, for example, must keep its company and accounting records for six years from the end of the last financial year they relate to, and longer in some cases.
Deletion includes copies: exports, test environments, mailboxes and backups. Backups usually cannot be edited record by record; the accepted approach is that deleted data disappears as old backups expire, and is not restored into production in the meantime (see Backup and Recovery). When devices or paper leave the organization, use secure disposal (see Physical Security).
International transfers
Personal data may leave the European Economic Area only with appropriate safeguards: an adequacy decision of the European Commission for the destination country, standard contractual clauses (SCCs) with an assessment of the destination's laws, or binding corporate rules within a group. For the United States, the EU–US Data Privacy Framework (adopted in 2023) covers transfers to certified organizations. Earlier arrangements were struck down by the Court of Justice of the EU; the EU General Court upheld this one in September 2025, and an appeal to the Court of Justice was pending as of October 2026, so check its status at the time you rely on it. The United Kingdom has an adequacy decision, renewed in December 2025 and valid until 27 December 2031.
US law sets few general limits on sending personal data abroad. The exception is national security: data brokers may not make Americans' sensitive data available to foreign-adversary countries or companies they control (Protecting Americans' Data from Foreign Adversaries Act of 2024), and since 8 April 2025, a Department of Justice rule (28 CFR part 202) prohibits or restricts transactions that give countries of concern (China, Cuba, Iran, North Korea, Russia and Venezuela) access to bulk sensitive personal data or government-related data. In the other direction, a US organization that receives personal data from Europe usually relies on the Data Privacy Framework (DPF): it self-certifies with the Department of Commerce and commits to the framework's principles, which the FTC (or, for airlines, the Department of Transportation) can enforce, and can also join the UK Extension and the Swiss–US framework. Otherwise the European sender uses standard contractual clauses or the UK equivalents. The EU decision behind the DPF was upheld by the EU General Court in September 2025; an appeal to the Court of Justice was pending as of October 2026, so check its status.
Personal data may leave the UK to countries covered by UK adequacy regulations, which the government calls data bridges: among others the EEA countries and, through the UK Extension to the EU–US Data Privacy Framework (since 12 October 2023), certified US organizations. Otherwise it needs appropriate safeguards — the International Data Transfer Agreement (IDTA), the UK Addendum to the EU standard contractual clauses, or binding corporate rules — with a transfer risk assessment. Since 5 February 2026, the Data (Use and Access) Act 2025 sets the test: protection after the transfer must not be "materially lower" than in the UK. In the other direction, the EU renewed its adequacy decision for the UK in December 2025, valid until 27 December 2031, so data flows freely from the EU to the UK.
Cloud region choice is covered in Cloud Security and Compliance.