The 7 Principles of GDPR

The GDPR is built on seven principles that sit at the very core of data protection law. These principles are set out in Article 5 of the regulation and establish the standard for how personal data must be collected, handled, stored, and used. Everything else in the GDPR flows from these seven principles. And any organisation that processes personal data is expected to demonstrate, at any point, that it is actively applying them. This is what the GDPR calls accountability — and it starts here.

Understanding these principles is essential, especially given that they provide the framework to assess every data processing activity the organisation carries out. Now, this article walks through each of the seven principles, looking at what each one means, plus what it requires in practice.

1: Lawfulness, Fairness & Transparency

The law, under Article 5(1)(a), states that personal data must be processed lawfully, fairly, and in a transparent manner in relation to the data subject.

These are three separate requirements, but they work together. One cannot satisfy two and ignore the third. All three must be met every time you process personal data.

a) Lawfulness

Processing personal data without a legal basis is illegal under the GDPR — full stop. The regulation provides six lawful bases, and one must be able to point to at least one before any processing takes place:

Consent — The individual has given a clear, specific agreement to their data being processed for a defined purpose. Consent must be freely given, which means it cannot be a condition of using a service. It must also be as easy to withdraw as it was to give.
Contract — Processing is necessary to fulfil a contract with the individual, or to take steps at their request before entering into one. For example, processing a customer’s address to deliver an order they placed.
Legal obligation — You are required by law to process the data. For example, an employer processing payroll data to comply with tax legislation.
Vital interests — Processing is necessary to protect someone’s life. This applies in genuine emergencies where the individual cannot give consent — for example, sharing medical information with emergency services.
Public task — Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority. This basis applies primarily to public bodies and government organisations.
Legitimate interests — You have a genuine and proportionate business reason to process the data, and that reason is not overridden by the rights and interests of the individual. This is the most flexible basis, but it requires a balancing assessment — you must weigh your interests against the potential impact on the individual.

One important point: the lawful basis must be identified before processing begins, not after. You cannot decide retrospectively which basis applies.

b) Fairness

Lawfulness alone is not enough. Even where a valid legal basis exists, the processing must not be done in a way that is deceptive, unexpected, or harmful to the data subjects.

Fairness is what catches the gaps that technical compliance misses. When an organization is using data in a way that people would not reasonably expect, or in a way that works against their interests, that is a fairness problem — regardless of whether they can point to a lawful basis.

The question always is, if the data subjects knew exactly what the organization is doing with their data and why, would they consider it reasonable? If the honest answer is no, fairness requires it to reconsider.

c) Transparency

People have the right to know what is happening with their data. Transparency is about being open and honest, which means telling individuals what data is being collected, why it is being collected, the intentions behind its collection, the data retention period, and who else may receive it.

This is where your privacy notice becomes important. Under the GDPR, a privacy notice is mandatory, and it cannot be a wall of legal text that nobody reads. It must be written in clear, plain language that the intended audience can actually understand. If the privacy notice requires a legal qualification to decipher, it is not compliant.

Transparency also means timing. The information must be provided at the point of collection — not buried somewhere on your website where it is unlikely to be found.

Ultimately, lawfulness, fairness, and transparency are simultaneous obligations. If your processing has a lawful basis, but data subjects have no idea it is happening, you have a transparency failure. If you have told people what you are doing, but the processing is harmful to them, you have a fairness failure. Compliance with this principle means satisfying all three — every time.

2: Purpose Limitation

The law states that personal data must be collected for specified, explicit, and legitimate purposes and must not be further processed in a manner incompatible with those purposes.

In plain terms, you must know exactly why you are collecting data before you collect it, and you cannot later use that data for something different.

Specified and explicit purposes

Article 5(1)(b) requires that the purpose for collecting personal data be defined clearly before any collection begins. A vague or open-ended statement does not meet this standard. A purpose like “we may use your data for business purposes” or “to improve our services” tells the individual very little about what will actually happen to their data — and that is precisely what the law is designed to prevent.

The purpose must be specific enough that an individual reading it can understand what their data will be used for and can make an informed decision about whether to provide it. In addition, other than being a legal requirement, defining the purposes clearly also disciplines how the organisation thinks about data collection. If one cannot articulate a clear reason for collecting a particular piece of data, that is a signal that perhaps you should not be collecting it at all.

Further processing

Organisations sometimes find themselves wanting to use data they have already collected for a new or additional purpose. The law does not automatically prohibit this, but it does require a compatibility assessment before any further processing takes place.

The GDPR sets out specific factors to consider when carrying out this assessment:

The link between the original purpose and the new purpose — how closely related are they?
The context in which the data was collected, and what individuals would reasonably have expected
The nature of the data, particularly whether it is sensitive or carries a higher risk of harm
The consequences of further processing for the individuals concerned
The safeguards in place, such as encryption or anonymisation

If the new purpose is incompatible with the original, you cannot simply proceed. You would need a fresh lawful basis — and in most cases, that means going back to the individual with a new, transparent explanation of what you intend to do and why.

Exceptions

The regulation also recognises that certain types of further processing are generally considered compatible with the original purpose, even where the new use differs. These are: archiving in the public interest, scientific or historical research, and statistical purposes. The law carves these out because of their broader social value. However, they are not a blank exemption — appropriate safeguards must be in place to protect individuals, and the processing must genuinely fall within one of these categories.

3: Data Minimisation

The GDPR states that personal data must be adequate, relevant, and limited to what is necessary in relation to the purposes for which it is processed.

This principle directly challenges a common organisational habit: collecting as much data as possible on the assumption that it might be useful one day. Article 5(1)(c) does not permit that approach. The purpose comes first — and the data collected must be determined by the purpose, not the other way around.

The three tests

Article 5(1)(c) of the GDPR sets out three requirements that apply together, not as alternatives:

Adequate — the data must be sufficient to actually fulfil the purpose. If you are collecting too little to achieve what you set out to do, that is also a problem. The law requires enough, but no more than enough.
Relevant — the data must be directly connected to the purpose. Data that is loosely or tangentially related does not meet this standard. If you cannot draw a clear line between a piece of data you are collecting and the specific purpose it serves, it does not belong in your dataset.
Limited — nothing beyond what is strictly necessary. This is the test that most organisations need to apply most rigorously. Every field on a form, every data point in a database, every piece of information retained in a system should be justifiable against a defined purpose.

All three tests must be satisfied. Collecting data that is relevant but excessive fails the principle. Collecting data that is adequate but not directly connected to the purpose also fails it.

As previously mentioned, collecting data “just in case it might be useful later” is not a legitimate reason under the GDPR. That reasoning puts data collection before purpose, which is the reverse of what Article 5(1)(c) requires. The purpose must be established first, and only then can you determine what data is genuinely necessary to serve it. If the purpose does not yet exist, neither does the justification for the data.

A concrete scenario

Consider an online retailer that asks customers to create an account before making a purchase. To process the order, the retailer needs a delivery address, an email address for order confirmation, and payment details. Those are adequate, relevant, and necessary.

Now suppose that same form also asks for the customer’s date of birth, their phone number, and their occupation. Unless the retailer can point to a specific, defined purpose that makes each of those fields necessary — not convenient, not potentially useful, but necessary — collecting them would breach Article 5(1)(c). The word necessary has a real meaning in law, and it sets a higher bar than organisations often assume.

4: Accuracy

According to the GDPR, personal data must be accurate and, where necessary, kept up to date. Every reasonable step must be taken to ensure that inaccurate data is erased or corrected without delay.

Inaccurate data causes real harm. A wrong medical record can affect treatment. An outdated address can result in sensitive correspondence reaching the wrong person. An incorrect entry on a financial database can damage someone’s credit. Article 5(1)(d) exists because the consequences of inaccuracy fall on the individual, not the organisation holding the data.

Two distinct obligations

This principle creates two separate requirements that operate at different points in the data lifecycle.

The first is accuracy at the point of collection. Data must be correct when it enters your systems. This means having processes in place to verify information where it matters, and not recording assumptions or unverified details as though they were established facts.

The second is keeping data current over time. The law qualifies this with the phrase “where necessary”, and that qualification is important. Not every category of data requires ongoing maintenance. A record of a transaction that occurred on a specific date does not change. But data that reflects a person’s current circumstances — their address, their health status, their employment, their contact details — can become inaccurate as circumstances change. Where the nature of the data is such that inaccuracy would have real consequences for the individual, organisations are expected to take reasonable steps to keep it up to date.

The right to rectification

Article 5(1)(d) directly underpins one of the individual rights provided by the GDPR: the right to rectification under Article 16. This right gives individuals the ability to demand that inaccurate personal data held about them be corrected. Organisations must respond to a rectification request within one month.

Understanding the connection between the principle and the right matters in practice. The law establishes the ongoing obligation — organisations must proactively maintain accurate data. Article 16 gives individuals the mechanism to enforce that obligation when it has not been met. One does not replace the other; both apply.

Without delay

The law uses the phrase “without delay” deliberately. When inaccurate data is identified — whether through an individual’s request, an internal review, or any other means — it must be corrected or erased promptly. Organisations cannot queue correction requests for a convenient moment or treat them as low priority. The GDPR recognises that inaccurate data actively causes harm for as long as it remains uncorrected, and the language of the law reflects that urgency.

5: Storage Limitation

Article 5(1)(e) of the GDPR states that personal data must be kept in a form that permits identification of data subjects for no longer than is necessary for the purposes for which it is processed.

Put simply: once you no longer need data for the purpose you collected it for, you no longer have a legal basis to keep it. Holding onto personal data beyond that point is not a storage decision — it is a breach of the law.

The core logic

Storage limitation follows directly from purpose limitation. Under Article 5(1)(b), data must be collected for a specific, defined purpose. Under Article 5(1)(e), it must be deleted or anonymised once that purpose has been fulfilled. The two principles work together: the purpose determines not just why data is collected, but how long it can legitimately be held.

Organisations sometimes retain data indefinitely on the basis that it might be useful in the future, or simply because deleting it has never been prioritised. Article 5(1)(e) does not accommodate either of those reasons. Retention must be tied to a purpose — and when the purpose ends, so does the justification for keeping the data.

Retention schedules

The GDPR expects organisations to think about retention before it becomes a problem. In practice, this means establishing a retention schedule — a documented policy that sets out, for each category of personal data, how long it will be held and what will happen to it at the end of that period. That outcome is typically deletion or anonymisation.

A retention schedule is evidence of accountability. If a supervisory authority asks how long you keep particular categories of data and why, a documented retention policy is how you demonstrate that the decision was considered and principled, not arbitrary.

Anonymisation

One legitimate path for organisations that want to retain data beyond the period of its original purpose is anonymisation. Data that has been truly anonymised — where no individual can reasonably be identified from it, whether directly or in combination with other information — falls outside the scope of the GDPR entirely. Anonymised data can be retained and used, for example, for long-term statistical analysis, without the constraints that apply to personal data.

The critical word here is truly. Pseudonymisation — replacing identifying details with codes or aliases — does not remove data from GDPR’s scope, because re-identification remains possible. Genuine anonymisation is an irreversible process. If there is any realistic means by which an individual could be identified from the data, it remains personal data, and the GDPR continues to apply.

Exceptions

As with purpose limitation, Article 5(1)(e) recognises that longer retention periods are justified in specific circumstances. Data may be kept for longer where it is processed for archiving in the public interest, scientific or historical research, or statistical purposes. These exceptions exist because of the broader social value of such activities. They are not, however, a general licence for indefinite retention — appropriate safeguards must be in place, and the processing must genuinely fall within one of these categories.

6: Integrity & Confidentiality

The law states that personal data must 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 and organisational measures.

This principle is commonly referred to as the security principle — and it is the one that makes clear that data protection is not just a legal or compliance function. It is an operational responsibility that runs across every part of an organisation.

Two distinct threats

Article 5(1)(f) addresses two separate categories of risk, and organisations must guard against both.

The first is unlawful or unauthorised processing — someone accessing, using, disclosing, or otherwise handling personal data without the authority to do so. This includes external threats such as cyberattacks and data theft, but also internal ones: an employee accessing records they have no legitimate reason to view, or data being shared with a third party without proper authorisation.

The second is accidental harm — data that is lost, corrupted, or destroyed not through any deliberate act, but through system failure, human error, or inadequate backup procedures. A database that is accidentally deleted, a laptop left on a train, an email sent to the wrong recipient — these are not malicious acts, but they are failures of integrity and confidentiality that the law requires organisations to prevent.

What “appropriate” means

The law does not prescribe specific technologies or exact measures. Instead, it uses the word appropriate — and that word does real work. What is appropriate is determined by the nature of the data being processed and the risks involved.

An organisation processing special category data — medical records, financial information, data relating to children — faces a higher level of risk and is expected to apply a correspondingly higher standard of security. A small business running a newsletter mailing list faces a different risk profile and is not held to the same technical standard as a hospital or a bank. The law is proportionate by design. What it does not permit is an organisation ignoring security on the basis that its data is low-risk, without actually having assessed that risk.

Technical and organisational measures

Article 5(1)(f) explicitly requires both technical and organisational measures — not one or the other. This distinction matters because it places security responsibility beyond the IT department.

Technical measures are what most people think of first: encryption of data at rest and in transit, access controls that limit who can view or edit particular records, multi-factor authentication, firewalls, and secure system architecture. These are essential, but they are not sufficient on their own.

Organisational measures are equally required: staff training on data handling procedures, clear policies on who can access what data and under what circumstances, processes for reporting and responding to security incidents, and contractual requirements placed on third parties who handle data on your behalf. A technically secure system operated by untrained staff, or without clear internal policies, does not meet the standard the law demands.

Security under the GDPR is a shared responsibility — across teams, across roles, and across the full lifecycle of the data.

7: Accountability

Article 5(2) of the GDPR states that the controller shall be responsible for, and be able to demonstrate compliance with, the principles laid out in Article 5(1).

Notice where this principle sits. Principles 1 through 6 are set out together in Article 5(1). Accountability stands alone in Article 5(2). That separation is deliberate, and it signals that accountability is not simply one principle among seven — it is the principle that gives all the others force. Without it, the remaining six are obligations with no mechanism of proof.

What makes this principle different

Principles 1 through 6 tell organisations what they must do with personal data. Article 5(2) adds a requirement of a different kind entirely: they must be able to prove that they are doing it.

Compliance under the GDPR is not self-declared. An organisation cannot simply assert that it processes data lawfully, minimises what it collects, or maintains appropriate security. It must be able to demonstrate those things — to a supervisory authority, to individuals whose data it holds, and through its own internal governance. If you cannot show your compliance, the law treats it as though compliance does not exist.

What “demonstrate” requires in practice

Accountability is made visible through documentation. The GDPR does not leave this abstract — Article 5(2) is supported throughout the regulation by specific requirements that together constitute the evidence of a compliant organisation:

Records of processing activities — Under Article 30, most organisations are required to maintain a written record of every processing activity they carry out: what data is processed, for what purpose, on what legal basis, for how long, and with whom it is shared. This document is often the first thing a supervisory authority will request.
Policies and procedures — Internal data protection policies, data handling procedures, and breach response protocols demonstrate that compliance has been thought through and embedded into how the organisation operates.
Staff training records — Training staff on data protection obligations is an organisational measure required under Article 5(1)(f). Records of that training are evidence that the obligation has been taken seriously.
Data Protection Impact Assessments — Where processing is likely to result in high risk to individuals, Article 35 requires a formal DPIA before that processing begins. A completed DPIA is evidence that risk was identified and addressed proactively.

None of these is a bureaucratic extra. They are the documentation trail that transforms a stated commitment to compliance into a demonstrable one.

Privacy by design

Accountability also requires that data protection is built into systems and processes from the outset — not applied as a correction after the fact. This is the concept of privacy by design, codified in Article 25 of the GDPR, and it flows directly from the accountability principle.

When an organisation designs a new product, builds a new system, or introduces a new process that involves personal data, data protection considerations must be part of the design from the beginning. Default settings must be privacy-protective. Data collection must be limited from the start. Retrofitting compliance onto a system that was built without it is both harder and riskier than building it in — and it is not what the law expects.

Final thought

The seven principles of GDPR function as a system rather than isolated rules. A lawful purpose that is well-defined, minimal in scope, accurately maintained, time-limited, properly secured, and provably so is what genuine data protection looks like. Remove any one element, and the framework is compromised.

These principles were written with data subjects in mind. Understanding them puts you on equal footing with the law, whether you are an organisation handling personal data or an individual whose data is being handled. That balance is exactly what the GDPR was designed to achieve.