Which GDPR lawful basis actually applies?

Every use of personal data needs a lawful basis under Article 6 of the General Data Protection Regulation (GDPR). There are six. Picking the right one is not paperwork. It decides which rights a person can use against you. It decides how the activity can change later. It decides what you can fall back on if the person stops cooperating. And it decides how the file reads when a regulator (the supervisory authority) looks at it.

The most common mistake we see is defaulting to consent. A privacy notice says the company handles data "on the basis of your consent" — for accounts, billing, security logs, tax records, the lot. It sounds polite and careful. It is usually wrong, and the error hurts in three ways at once. Consent can be withdrawn at any moment, and the legal ground goes with it — so customer ties look more fragile than they are. Claiming the wrong basis is itself a finding a regulator can make against you. And it quietly signals that nobody read Article 6 closely.

The six bases — and why their order misleads

Article 6(1) lists six co-equal lawful bases, in this order:

• Consent — the person has agreed to it.
• Contract — it is needed to carry out a contract with that person.
• Legal obligation — a specific law requires it.
• Vital interests — it is needed to protect someone's life.
• Public task — it is part of an official public function.
• Legitimate interests — a written-down interest of yours (or a third party's) that is not outweighed by the person's rights.

Consent sits first on the list, so people often assume it is the main basis and the rest are exceptions. The regulation says no such thing. The six are equal. In practice consent is the narrowest of the six. For most business processing, the right answer is usually contract, legal obligation, or legitimate interests.

The fastest test: the "minus-data" question

Before walking the six, here is the test that settles most cases in a sentence. For the activity in front of you, ask: if the person withdrew consent right now, would the operation keep running?

If you could stop on request without breaking anything important, consent may fit. If you cannot stop charging the customer, keeping the tax invoice, or logging the security event just because they asked — then the work is not optional. Consent is the wrong basis, and one of the other five applies. A companion test for contract: imagine the data gone. Can the contracted service still be delivered? If yes, the data was not needed for the contract.

The six bases, one at a time

Consent (Article 6(1)(a)) — the narrowest, not the broadest

The European Data Protection Board (EDPB) Guidelines 05/2020 set a high bar. Consent must be freely given, specific, informed, and unambiguous. It must be as easy to withdraw as to give. "Freely given" means a real choice — you cannot tie a service to consent the service does not need (Article 7(4)). "Specific" means it attaches to one named purpose, not a whole privacy notice. "Unambiguous" means an active step — a pre-ticked box does not count. And Article 7(1) puts the burden of proof on you. If you cannot show when and how consent was given, it is as good as unprovable.

Consent works well for truly optional things — marketing-email signup, non-essential cookies, and special-category data where nothing else fits. It works badly, and draws regulator attention, when claimed for processing the person cannot really refuse. A tell-tale sign you have it wrong: if a customer withdrew consent and the service ran on unchanged, the basis was never consent.

Contract (Article 6(1)(b)) — the strongest when it fits

Contract covers processing needed to perform a contract with the person, or to take steps they asked for before signing. Two words carry the weight. "Necessary" is narrow. Sending the customer what they ordered is necessary; analytics on how they use it usually is not. "Party" matters in business-to-business (B2B) deals. When a business buys your service, the contract is with the business — so its employees' data usually rides on legitimate interests, not contract. Where contract fits cleanly (accounts, payment, delivery), record it as contract and move on. Regulators do not expect you to avoid it.

Legal obligation (Article 6(1)(c)) — the cleanest test

This covers processing a specific EU or Member State law requires — a law you can cite. "We do this for compliance reasons" is not enough. "We keep VAT invoices for the statutory period under [named statute]" is. The usual entries: tax records, employment records, anti-money-laundering checks, and sector reporting. The trap is treating "I would feel safer keeping this" as a legal duty. Keeping data beyond what the law requires sits on some other basis — often legitimate interests — and then the retention period is yours to defend, not the legislator's.

Legitimate interests (Article 6(1)(f)) — the workhorse

This is where most private-sector, non-contract processing should sit. It is also the basis used most carelessly. It is a three-part test, written down in a Legitimate Interests Assessment (LIA): purpose (a specific, real, lawful interest), necessity (no gentler way to get there), and balancing (the person's rights and reasonable expectations do not outweigh it). Marketing to existing customers, follow-up where the prospect reached out first, fraud prevention, and network security (named in Recital 49) usually qualify. Processing that would surprise the person usually does not. Surprise is the sign the balancing test fails. An honest LIA is two pages, and sometimes it concludes the interest does not win. That is the assessment working, not failing.

Vital interests and public task — probably not you

Vital interests (Article 6(1)(d)) is for life-or-death cases where consent cannot be obtained — the unconscious patient in the emergency room. If a small firm has more than one vital-interests entry in its records, the second usually belongs elsewhere. Public task (Article 6(1)(e)) is for public bodies doing official work. Most private firms read about it once and never use it.

Special-category data needs a second key (Article 9)

The six Article 6 bases cover personal data in general. Some data gets a stricter rule. Data that reveals health, race or ethnic origin, political views, religion, trade-union membership, sex life or sexual orientation — plus genetic data and biometric ID data — is "special category." Article 9 starts by banning its processing outright. The ban only lifts when one of the Article 9(2) conditions is met. That condition sits on top of the Article 6 basis, not instead of it.

The catch that surprises people: there is no Article 9 route for legitimate interests. If your Article 6 basis is legitimate interests and the data is special-category, the Article 9 question is still open. For most small operators the realistic condition is explicit consent under 9(2)(a) — a stricter standard than plain consent. For employers it is often 9(2)(b); for clinicians, 9(2)(h). If none of the ten conditions fit, the work cannot lawfully go ahead as designed. Rework it to take the special-category data out.

A short mapping checklist

When you work through an activity, in order:

1. Describe the processing concretely. "Marketing emails to existing customers about new features" works; "marketing" does not.
2. Name the people involved. Customers, employees, prospects, children — the group shapes the balancing test.
3. Test contract first. Truly needed for a contract with that person? If yes, contract.
4. Test legal obligation next. A specific law that requires it? If yes, legal obligation.
5. For special-category data, find the Article 9(2) condition that lifts the ban.
6. Test legitimate interests honestly. Run the three-part test, write the LIA, and accept its answer.
7. Fall back to consent only where refusal would not break the relationship, the consent moment can meet Article 7, and withdrawal can be honoured at once.
8. Record the chosen basis in the Records of Processing Activities (RoPA), one row per activity, and make sure the privacy notice says the same thing.

What this settles, and what it doesn't

This is practitioner instinct, not legal advice. The right basis for any one activity depends on your contracts, your jurisdiction, the data, the people, and your regulator's guidance. Use this framing to produce a defensible first draft. Then bring it to your privacy counsel for the final call. Two ideas are worth keeping. The withdrawal question is the fastest way to tell whether consent is wrong — for most processing, it is. And an honest Legitimate Interests Assessment is short, structured, and sometimes says no.

When you want this ready to use

Sylvan Assurance's GDPR Checklist turns this into working documents: a 30-question self-assessment, a one-person Records of Processing Activities workbook, a privacy-notice cheat-sheet with consent copy, a 72-hour breach decision tree, and a three-letter Data Subject Access Request pack — with higher editions adding deeper guides, pre-built Excel workbooks, a yearly compliance calendar, and Data Protection Officer materials up to a Data Protection Impact Assessment template. Editions from $49; the toolkit page has the full breakdown.

The free GDPR readiness assessment at sylvanassurance.com/free/gdpr walks your situation in about thirty questions and returns a tailored guide. It runs entirely in your browser; your answers are never sent anywhere.

Prefer the long form? The companion Sylvan Press title, GDPR Compliance, covers the same ground in depth.