The six lawful bases, and how to choose one you can defend

Article 6 gives you six lawful bases and no ranking between them. Here's what separates them in practice, why the choice is harder to change than to make, and what you need to hold to justify it.

Every use you make of personal data needs a lawful basis. Article 6(1) sets out six of them, lettered (a) to (f), and the regulation puts no hierarchy between them. Consent is not the default and not the safest option. It is one of six, and for a lot of ordinary business processing it is the worst fit.

The choice matters more than it first appears, because the basis you pick changes which rights the data subject has. Get it wrong and you either grant rights you did not need to grant, or you deny rights the person was entitled to.

The six, and what actually separates them

Five of the six turn on necessity. The processing has to be necessary for the stated purpose, which the ICO describes as more than useful and more than standard practice: a targeted and proportionate way of achieving something specific. If you could reasonably achieve the same purpose with less data, or without the processing at all, the basis does not hold.

Taking the six one at a time

Consent, Article 6(1)(a)

Article 4(11) sets the standard: freely given, specific, informed and unambiguous, by a statement or clear affirmative action. Each word removes an option. Freely given rules out consent bundled into terms you must accept to receive the service. Specific rules out one tick covering several unrelated purposes. Unambiguous rules out pre-ticked boxes and inferred agreement from continued use.

Two obligations follow that catch people out. Article 7(3) requires withdrawal to be as easy as giving it was, which means a one-click opt-in cannot have a written-request opt-out. And Article 7(1) requires you to be able to demonstrate that consent was given, so you need a record of what was shown, what was agreed, and when.

Consent suits marketing to people with no existing relationship, optional cookies, and processing a person could reasonably decline without losing anything they came for. It does not suit anything you will continue doing after someone objects.

Contract, Article 6(1)(b)

This covers processing necessary for performance of a contract to which the data subject is party, or to take steps at their request before entering into one. Both halves matter: a quote requested before any contract exists is covered by the second limb.

The limit is the word necessary, and it is assessed against the contract you actually have. Delivering an order needs a delivery address. Sending a satisfaction survey afterwards is a separate purpose that the contract does not require, and it needs its own basis. The test is not whether the processing is connected to the contract but whether the contract could be performed without it.

Legal obligation, Article 6(1)(c)

Processing necessary for compliance with a legal obligation to which the controller is subject. The obligation has to come from law, not from a contract, a trade body, or an insurer's requirements. Where it applies it is clean and easy to evidence: cite the statute.

Retaining accounting records for the statutory period is the standard example. Retaining everything else for the same period because it is simpler is not, and that conflation is worth watching for in a retention schedule.

Vital interests, Article 6(1)(d)

Necessary to protect the vital interests of the data subject or another natural person. Recital 46 frames this as processing essential for someone's life, and in practice it is a basis for emergencies rather than for a standing activity.

It is worth knowing about because it exists for the case where nothing else fits and somebody is at risk. It is not a general fallback, and relying on it for routine processing would be difficult to defend.

Public task, Article 6(1)(e)

Necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. Article 6(3) requires that the basis for the task is laid down in law, so this is not available simply because an activity is beneficial.

Public authorities generally rely on this rather than legitimate interests for their core functions, and Article 6(1) expressly disapplies legitimate interests to processing carried out by public authorities in the performance of their tasks.

Legitimate interests, Article 6(1)(f)

Necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where overridden by the interests or fundamental rights and freedoms of the data subject, in particular where the data subject is a child.

This is the most flexible and the most demanding. It is the only basis requiring you to weigh your position against the individual's, and the only one where Article 21 gives the person a right to object and force you to demonstrate compelling legitimate grounds to continue. Recital 47 offers two anchors that help: reasonable expectations at the time of collection, and the example that processing necessary for fraud prevention constitutes a legitimate interest.

Special category data needs a second condition

One point that causes real difficulty: an Article 6 basis is never sufficient on its own for the categories listed in Article 9. Health data, biometric data used to identify someone, data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, and data concerning sex life or sexual orientation all need an Article 6 basis and, separately, an Article 9(2) condition.

The two are cumulative rather than alternative, and they are chosen independently. An employer processing sickness absence records typically relies on legitimate interests or legal obligation under Article 6, and on Article 9(2)(b) covering employment and social security law, under Article 9. In the UK, several Article 9(2) conditions additionally require a condition from Schedule 1 of the Data Protection Act 2018, and some of those require an appropriate policy document to be in place.

If your record of processing has one column for lawful basis and the processing includes special category data, the record is incomplete. Two columns, filled in independently.

Where teams get it wrong

Reaching for consent because it sounds respectful

Consent under GDPR is a high bar. It has to be freely given, which means a genuine choice with no detriment for refusing. If the person cannot say no without losing the service, the consent is not real, and a basis that is not real is no basis at all.

Consent also carries the strongest set of downstream rights. It can be withdrawn at any time, and withdrawal has to be as easy as giving it was. If your processing has to continue regardless, consent was the wrong choice and you have written yourself a promise you cannot keep.

Stretching contract past what the contract actually needs

Article 6(1)(b) covers what is necessary to deliver the contract the person entered. Delivering the goods is necessary. Analysing their purchase history to improve your product is a different purpose, and it needs its own basis, usually legitimate interests with an assessment behind it.

Treating legitimate interests as the fallback

Legitimate interests is the most flexible basis and the one that asks most of you. It is the only one requiring you to weigh your interests against the individual's, and the only one where the person can object under Article 21 and force you to justify continuing. It is a legitimate choice for a great deal of ordinary processing. It is not a way of avoiding the question.

Using legitimate interests for a public authority function

Article 6(1) closes with a sentence that is easy to miss: the legitimate interests basis shall not apply to processing carried out by public authorities in the performance of their tasks. A public body processing for its core function needs public task, not legitimate interests, and choosing the wrong one there is a structural error rather than a judgement call.

Working it out in practice

A sequence that tends to produce the right answer, applied per purpose rather than per system:

1. 1Write the purpose specifically enough that someone could disagree with it. If it cannot be argued with, it cannot be tested.
2. 2Ask whether a law requires this processing. If yes, legal obligation, and cite the law.
3. 3Ask whether the contract with this person could be performed without it. If not, contract.
4. 4For a public authority performing its function, public task, with the legal basis for the task identified.
5. 5Otherwise, ask whether the person would reasonably expect this and whether your interest survives the three-part test. If it does, legitimate interests, with the assessment written down.
6. 6Consider consent last rather than first, and only where the person could genuinely decline and you would genuinely stop.
7. 7If the data includes special categories, repeat the exercise against Article 9(2).

The order matters. Working down from consent tends to produce consent everywhere, because it feels safest. Working up from the necessity-based options produces a basis that reflects what you would actually do if someone objected.

You cannot quietly swap basis later

Article 13(1)(c) requires you to tell people, at the point of collection, both the purposes of the processing and the legal basis for it. That statement is a representation about how you will treat their data and which rights they have.

Switching basis afterwards, when the first one turns out to be inconvenient, undermines that. If you told people you were relying on consent and they withdraw it, moving to legitimate interests to carry on processing is the exact outcome consent was supposed to prevent. Decide before you collect, record why, and if the purpose genuinely changes, treat that as new processing with its own notice.

Reusing data for a new purpose

The basis you record is tied to a purpose, so a new use raises the question of whether it is compatible with the original one. The Data (Use and Access) Act 2025 restructured those provisions and, usefully, confirmed that they apply in addition to the requirement to have a lawful basis rather than instead of it. Compatibility is not a substitute for Article 6.

It also splits the rules according to how the data was collected. Where the original basis was consent, the position is more restrictive: a new use is compatible only in narrower circumstances, and getting consent for the new purpose is the primary route. Where the original basis was anything else, a wider set of rules applies.

The practical consequence reinforces the point about choosing consent by reflex. Consent is not only the basis with the most downstream rights attached; it is also the one that most constrains what you can later do with the data. An organisation that collected under consent because it felt respectful has narrowed its future options in a way it probably did not intend.

The basis determines which rights apply

This is the most practical reason to choose carefully. Data subject rights are not uniform across the six bases, so the choice you record decides what you will have to do when someone asks.

Reading that table backwards is a useful check. If you would refuse a portability request for this data, contract or consent is probably the wrong basis to have recorded. If you would keep processing after an objection, legitimate interests will require you to demonstrate compelling grounds, and you should know now whether you could.

Pick the basis per purpose, not per system. One CRM can hold data processed under contract for order fulfilment, legal obligation for tax records, and legitimate interests for account management. The record of processing is where those distinctions live.

What to hold as evidence

Accountability under Article 5(2) means being able to demonstrate the choice, not merely to have made it. For each processing purpose you want:

• The purpose, written specifically enough that necessity can be tested against it.
• The basis chosen, and a short note on why the alternatives did not fit.
• For legitimate interests, the completed three-part assessment.
• For consent, the record of what was shown, what was agreed, and when.
• The categories of data the purpose actually needs, checked against what you hold.

That last line is where most of the difficulty sits. Necessity is a claim about the data you hold, and it can only be tested against an accurate picture of what that is. A purpose described as needing a name and an email address is hard to defend if the same folder also holds passport scans nobody remembers collecting.

How EmberHound fits

EmberHound scans enrolled company devices and reports what personal data is on them, by category and location. That gives the necessity test something concrete to work against: the data you actually hold, rather than the data the system was designed to hold. Findings export as dated evidence you can attach to a processing record.

It does not choose your lawful basis, and no tool can. That judgement stays with your DPO or your legal adviser. What it removes is the guesswork underneath the judgement.

This article is general information, not legal advice. Confirm the obligations that apply to your organisation before acting on it.