The 7 GDPR principles: what they are and how to apply them
Article 5 of the GDPR sets out seven data protection principles. Here is the list, what each principle requires, a practical example for each, and how the UK GDPR and the old Data Protection Act 1998 count them differently.
There are seven data protection principles in the GDPR, all found in Article 5. The UK GDPR has the same seven. They are:
- Lawfulness, fairness and transparency
- Purpose limitation
- Data minimisation
- Accuracy
- Storage limitation
- Integrity and confidentiality (security)
- Accountability
The first six are listed in Article 5(1)(a) to (f). The seventh, accountability, sits on its own in Article 5(2) and requires the controller to be able to prove it complies with the other six. That split is why you will sometimes read that the GDPR has "six principles". Both counts describe the same text.
Below you will find a one-table overview, each principle explained with a practical example, the UK angle (including the Data (Use and Access) Act 2025 changes), and why people who learnt data protection under the Data Protection Act 1998 remember eight principles.
The seven principles at a glance
| Principle | What it requires | Example | Article |
|---|---|---|---|
| 1. Lawfulness, fairness and transparency | A legal basis for every processing activity, no processing people would not expect, and clear information about what you do. | A privacy notice that tells newsletter subscribers what you collect, why and for how long. | 5(1)(a) |
| 2. Purpose limitation | Collect for specified, explicit and legitimate purposes, and do not reuse the data for something incompatible. | Delivery addresses are not passed to a partner for marketing. | 5(1)(b) |
| 3. Data minimisation | Only data that is adequate, relevant and limited to what the purpose needs. | A webinar sign-up form asks for name and email, not date of birth. | 5(1)(c) |
| 4. Accuracy | Data is correct and, where necessary, up to date. Inaccurate data is corrected or erased without delay. | A changed address is updated in every system that sends post. | 5(1)(d) |
| 5. Storage limitation | Identifiable data is kept no longer than the purpose requires. | CVs from unsuccessful applicants are deleted after a set period. | 5(1)(e) |
| 6. Integrity and confidentiality | Appropriate security against unauthorised access, loss, destruction and damage. | Multi-factor authentication and role-based access to the HR system. | 5(1)(f) |
| 7. Accountability | The controller is responsible for compliance and must be able to demonstrate it. | A record of processing activities, policies, DPIAs and training logs you can hand to a regulator. | 5(2) |
The principles are not a checklist to tick off once. The ICO describes them as the spirit of the regime: they do not give hard and fast rules, and most of the detailed obligations later in the regulation exist to put them into practice. If you are unsure whether something is allowed, testing it against the seven principles is usually the fastest way to an answer.
How many data protection principles are there?
It depends on which law you are reading.
- EU GDPR: seven. Six in Article 5(1) plus accountability in Article 5(2).
- UK GDPR: seven. The UK kept Article 5 when it left the EU, and the ICO lists the same seven.
- Data Protection Act 2018, Parts 3 and 4: six each. The separate regimes for law enforcement processing (sections 34 to 40) and for the intelligence services (sections 85 to 91) each set out six principles. Most businesses never deal with these parts. They apply the UK GDPR.
- Data Protection Act 1998: eight. This is the source of most of the confusion. The 1998 Act was repealed on 25 May 2018, but its eight principles still turn up in training material and quizzes.
The eight principles of the Data Protection Act 1998, and where they went
Under Schedule 1 of the 1998 Act, data had to be processed fairly and lawfully, obtained for specified purposes, adequate and not excessive, accurate, not kept longer than necessary, processed in line with data subjects' rights, kept secure, and not transferred outside the EEA without adequate protection. Five of those map almost one-to-one onto the GDPR principles. The other three changed form:
| DPA 1998 principle | Where it lives now |
|---|---|
| 1. Fair and lawful processing | Principle (a), now with transparency added |
| 2. Specified and lawful purposes | Principle (b), purpose limitation |
| 3. Adequate, relevant, not excessive | Principle (c), data minimisation ("limited to what is necessary" is stricter than "not excessive") |
| 4. Accurate and up to date | Principle (d), accuracy |
| 5. Not kept longer than necessary | Principle (e), storage limitation |
| 6. Processed in line with data subjects' rights | No longer a principle. The rights have their own chapter (Chapter III, Articles 12 to 22) |
| 7. Appropriate security measures | Principle (f), integrity and confidentiality, backed by Article 32 |
| 8. No transfers outside the EEA without adequate protection | No longer a principle. International transfers have their own chapter (Chapter V) |
| (none) | Accountability, Article 5(2), is new |
So when someone searches for "data protection principle 6", they may mean either of two quite different things: data subjects' rights under the 1998 Act, or security under the GDPR, where integrity and confidentiality is the sixth item in Article 5(1). For policies and training written today, use the GDPR numbering.
Principle 1: Lawfulness, fairness and transparency
Article 5(1)(a) requires personal data to be "processed lawfully, fairly and in a transparent manner in relation to the data subject". The three words carry three separate requirements.
Lawfulness means each processing activity needs a legal basis under Article 6: consent, contract, legal obligation, vital interests, public task or legitimate interests. The UK GDPR has added a seventh, recognised legitimate interests, through the Data (Use and Access) Act 2025. Special category data, such as health information, also needs a condition under Article 9. Lawfulness also means not breaking other laws in the process, for example a duty of confidence or employment law.
Fairness means you do not process data in ways that people would not reasonably expect or that have an unjustified adverse effect on them. Processing can have a valid legal basis and still be unfair, for example if a cancellation flow is designed to make people give up more data than they intended.
Transparency means telling people, in clear and plain language, who you are, why you process their data and what their rights are. Recital 39 spells out that information must be easily accessible and easy to understand.
Example: an online shop sends a monthly newsletter. It relies on consent for the newsletter, so the sign-up box is unticked by default and every email has a working unsubscribe link (lawfulness). It does not quietly add customers who only bought once to a partner mailing list (fairness). The privacy notice linked from the sign-up form explains what is collected, why and for how long (transparency).
Principle 2: Purpose limitation
Article 5(1)(b) requires data to be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes". You decide why you are collecting data before you collect it, you write that purpose down, and you tell people.
Reuse for a new purpose is not banned, but the new purpose has to be compatible with the original one. Article 6(4) lists what to weigh: the link between the purposes, the context and the relationship with the data subject, the nature of the data, the possible consequences, and safeguards such as encryption or pseudonymisation. Further processing for archiving in the public interest, scientific or historical research, or statistics is treated as compatible, provided the Article 89(1) safeguards are in place.
Example: a university collects students' contact details to run their courses. Using those details to send timetable changes is within the purpose. Selling the list to a student loan broker is not, and would need a fresh legal basis and, in practice, consent.
UK note: the Data (Use and Access) Act 2025 amended the UK version of Article 5(1)(b) and added an Annex 2 listing reuses that are treated as compatible, such as responding to emergencies or safeguarding vulnerable people. It also added Article 5(3), which makes clear that a compatible purpose is not lawful on that ground alone: you still need a legal basis. According to legislation.gov.uk, these changes have been fully in force since 5 February 2026, and the ICO's purpose limitation guidance was updated in March 2026 to reflect them. The principle itself, and the count of seven, did not change.
Principle 3: Data minimisation
Article 5(1)(c) requires data to be "adequate, relevant and limited to what is necessary in relation to the purposes". Data minimisation is usually read as "collect less", but the word "adequate" also matters: you need enough data to do the job properly. Holding too little can lead to wrong decisions about someone.
The practical test is to go through every field you collect and ask what you would lose if you dropped it. If the answer is "nothing we use today", it should go. Article 25 turns this into a design requirement: by default, only the data necessary for each specific purpose should be processed (see privacy by design and by default).
Example: an events app wants continuous location access to suggest nearby events. A city or postcode chosen by the user would do the same job, so continuous tracking is more than the purpose needs. A webshop needs a delivery address, but it does not need date of birth unless it sells age-restricted products.
Principle 4: Accuracy
Article 5(1)(d) requires data to be "accurate and, where necessary, kept up to date", and says that "every reasonable step must be taken" to erase or rectify inaccurate data "without delay". The words "where necessary" matter: a historical record of what someone told you on a given date is not inaccurate just because things have since changed, as long as it is clear that it is a historical record. An address used to send invoices, on the other hand, has to be kept current.
Accuracy is closely tied to the right to rectification in Article 16. In practice it means a route for people to correct their data, a process for updating every system that holds the same data, and periodic checks where wrong data could cause harm.
Example: a customer tells customer service they have moved. The new address is entered in the CRM, but the billing system pulls from an old export and the next invoice goes to the previous address. The accuracy failure is not the data entry. It is the missing link between systems. Mapping where each data set lives, as you do in a record of processing activities, is what exposes this kind of gap.
Principle 5: Storage limitation
Article 5(1)(e) requires data to be "kept in a form which permits identification of data subjects for no longer than is necessary". When the purpose is fulfilled, the data should be deleted or anonymised. Longer storage is permitted only for archiving in the public interest, research or statistics, with appropriate safeguards.
The GDPR does not set retention periods. You set them yourself, based on the purpose and on other laws that require you to keep records, such as tax and accounting rules. What the principle requires is that each period is decided, justified, written down and actually enforced. A retention schedule that nobody applies does not meet the principle.
Example: a recruiter keeps CVs from unsuccessful candidates. A fixed period after the recruitment closes, the CVs are deleted automatically, unless the candidate has agreed to be kept on file for future roles. The period is recorded in the retention schedule together with the reason for it.
Anonymisation is an alternative to deletion only if the result is genuinely anonymous. Data where names are replaced by codes and a key still exists is pseudonymised, not anonymised, and is still personal data. Our article on pseudonymisation explains the difference.
Principle 6: Integrity and confidentiality (security)
Article 5(1)(f) requires data to be "processed in a manner that ensures appropriate security", including protection "against unauthorised or unlawful processing and against accidental loss, destruction or damage", using appropriate technical or organisational measures. This is the security principle, and Article 32 fills in the detail: measures must be appropriate to the risk, and examples include pseudonymisation and encryption, the ability to restore data after an incident, and regular testing of the measures.
"Appropriate" is the key word. There is no fixed list of required controls. A small consultancy with a customer list and a hospital with patient records face very different risks, and the measures should differ accordingly. Organisational measures count as much as technical ones: access rules, training, clear-desk policies and vendor checks.
Example: a health app stores users' symptom logs. It encrypts data in transit and at rest, limits access to named support staff with multi-factor authentication, reviews access rights every quarter and has a tested process for handling a personal data breach. Because the data is special category data and the risk is high, it also carries out a data protection impact assessment before launch.
Principle 7: Accountability
Article 5(2) states: "The controller shall be responsible for, and be able to demonstrate, compliance with paragraph 1." Accountability has two parts. You must comply with the six principles, and you must be able to show that you comply. If a regulator asks how you meet the storage limitation principle, "we delete old data" is not an answer. A retention schedule, a deletion log and the name of the person responsible are.
Article 24 makes the same point at a general level: controllers must implement appropriate measures "to ensure and to be able to demonstrate" compliance, review them, and adopt data protection policies where proportionate. In practice, the evidence usually includes:
- a record of processing activities under Article 30 (organisations with fewer than 250 employees are exempt only where the processing is occasional, unlikely to result in a risk to people and does not involve special category or criminal offence data)
- documented legal bases, purposes and retention periods for each processing activity
- privacy notices and consent records
- DPIAs for high-risk processing
- data processing agreements with suppliers
- security policies, access reviews and incident logs
- training records
- a data protection officer, where one is required or appointed
Example: a data subject complains to the regulator that a company kept their data for years after they closed their account. The company can show its retention schedule, the automated deletion job, and a log showing the job failed for three months last year and how that was fixed. It may still have a problem, but it can show it was in control. A company with no documentation cannot show anything at all.
What happens if you breach a principle?
Infringing the basic principles in Articles 5, 6, 7 and 9 falls in the higher tier of fines under Article 83(5)(a): up to EUR 20 million or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher. Under the UK GDPR the fixed cap is £17.5 million, with the same 4% alternative. Fines are only one tool: regulators can also order processing to stop, require data to be deleted, or issue reprimands, and individuals can claim compensation under Article 82.
In practice, principle breaches rarely appear alone. A security incident (principle 6) often reveals data that should have been deleted years ago (principle 5) and was never needed in the first place (principle 3), and the investigation then tests whether you can document any of it (principle 7).
How to check your organisation against the seven principles
A practical way to start is to take one processing activity at a time, for example payroll, recruitment or the newsletter, and answer seven questions:
- What is the legal basis, and have we told people about the processing?
- What is the purpose, and is anyone using the data for something else?
- Which data fields do we collect, and do we need each one?
- How do we keep the data correct, and how can people correct it?
- How long do we keep it, and is the deletion actually happening?
- Who has access, and which security measures protect it?
- Where is all of this written down, and who owns it?
If question seven has no good answer, the other six are hard to prove. That is why most compliance programmes start with the record of processing activities: it is the one document that ties purpose, data categories, legal basis, recipients, retention and security together for every activity. Our GDPR compliance checklist takes it from there.
How .legal helps with accountability
Most of the work behind the seven principles ends up as documentation: processing activities, legal bases, retention periods, security measures, DPIAs and supplier agreements. .legal Privacy keeps that documentation in one place, linked together, with tasks and reminders so it stays current, which gives you the evidence Article 5(2) asks for when a regulator or customer asks.
.legal compliance platform
Build compliance on strong GDPR principles
-
Principle-based compliance framework
-
Processing activity documentation
-
Automated retention management
-
Security measure tracking
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
-1.png?width=34&height=26&name=bws_shipping_rgb%20-%20Kopi%20(2)-1.png){kind=small}
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=225&height=26&name=KAUFMANN%20(1).jpg){kind=small}
