The Six Lawful Basis: What They Are, What They Need, and How to Choose the Right One

Part 1 of The Legal Basis Playbook

Every piece of personal data your organisation processes needs a reason to exist. Not a business reason — though that matters too — but a legal reason. Under the GDPR, that reason is called a lawful basis for processing.

Get it right, and you have a defensible, auditable ground for every processing activity in your RoPA. Get it wrong — or worse, pick the most convenient one without actually qualifying for it — and you're building your entire privacy programme on a fault line.

I've reviewed a lot of privacy notices, RoPAs, and DPIAs in my career. One of the most common gaps I see isn't a missing record or a broken retention schedule. It's lawful basis selection done as an afterthought: someone ticked "legitimate interests" because it sounded flexible, or chose "consent" because it felt safe, without understanding what either actually demands.

This series is my attempt to fix that — one basis at a time.

In this first article, I'll give you the full map: all six lawful bases, what each requires at a foundational level, and how to think about choosing between them. In the articles that follow, I'll go deep on each one — the edge cases, the regulator guidance, the practical traps, and how it interacts with India's DPDPA for those of us operating across jurisdictions.

Let's start at the beginning.

1. Consent — Article 6(1)(a)

What it actually requires:

• A clear affirmative action (no pre-ticked boxes, no silence)
• Granularity — separate consent for separate purposes
• Easy withdrawal, as simple as giving it
• No imbalance of power (consent from employees is almost always suspect)
• Documented proof of consent

The common misconception: Consent feels "safe" to many organisations because it's familiar — cookie banners, tick boxes, opt-ins. But consent is actually one of the hardest bases to maintain operationally. It expires, it gets withdrawn, and it requires ongoing audit trails.

When it's appropriate: Direct marketing, non-essential cookies, processing sensitive categories of data where no other ground applies, research with voluntary participants.

When it's not appropriate: Any situation where there is a power imbalance, where the data subject has no real choice, or where withdrawal would make your core service unworkable.

2. Contract — Article 6(1)(b)

What it actually requires:

• An actual contract with the data subject (not a third party)
• Processing that is necessary — not just useful or convenient
• The processing must relate directly to delivering the contract

The common misconception: "We have Terms & Conditions, so we can use contract as our basis." Not quite. The key word is necessary. If you could deliver the contracted service without that specific piece of data, the contract basis doesn't hold. Also — B2B contracts don't count here unless the data subject is the contracting party.

When it's appropriate: Processing delivery addresses to fulfil an e-commerce order, processing payment details to complete a subscription, processing candidate CV data when they've applied for a role.

When it's not appropriate: Behavioural profiling of customers, analytics, marketing, or any processing that goes beyond what's needed to deliver the service.

3. Legal Obligation — Article 6(1)(c)

What it actually requires:

• An actual legal obligation — a law, regulation, or binding court order
• The obligation must apply to you as the controller
• The processing must be necessary to comply with it

The common misconception: "We need to process this data to follow best practice / our internal policy / industry standards." Those aren't legal obligations. The obligation must be laid down in law — national or EU — and it must be specific enough to mandate the processing.

When it's appropriate: Retaining payroll records for tax compliance, reporting suspicious transactions under AML law, sharing data with regulators when legally required, retaining employment records under labour law.

When it's not appropriate: Internal policies, contractual obligations with third parties, or "industry standard" retention periods that don't have a legislative source.

4. Vital Interests — Article 6(1)(d)

What it actually requires:

• A life-or-death situation — literally
• Inability or impracticality of obtaining consent (typically because the person is incapacitated or unconscious)
• This is a last resort basis, not a general one

The common misconception: Organisations occasionally try to invoke vital interests for health and wellness contexts that don't come close to meeting the threshold. "We processed their health data to improve their wellbeing" is not vital interests. The EDPB is clear: this basis should only be used where no other basis can reasonably apply.

When it's appropriate: Emergency medical situations, natural disasters where identifying survivors is necessary, humanitarian crises.

When it's not appropriate: Almost every commercial context. If you're even considering this basis for a non-emergency scenario, stop and reconsider.

5. Public Task — Article 6(1)(e)

What it actually requires:

• A basis in law for the specific task
• The processing must be necessary for that public function
• Typically applies to public authorities, government bodies, and entities exercising delegated public functions

The common misconception: Private companies sometimes reach for this basis when they think their work "serves the public." That's not how it works. The public interest must be grounded in law, not in your mission statement.

When it's appropriate: Processing by government agencies (taxation, healthcare delivery, education), regulators, courts, and bodies with a specific legislative mandate to perform a public function.

When it's not appropriate: Private sector organisations in almost all commercial contexts, unless you have a specific statutory function or are performing a task explicitly mandated by law.

6. Legitimate Interests — Article 6(1)(f)

What it actually requires: (which everyone misses)

• A three-part Legitimate Interests Assessment (LIA):

1. Purpose test — Is there a genuine, legitimate interest?
2. Necessity test — Is the processing necessary to achieve it, or could you use less intrusive means?
3. Balancing test — Do the interests of the data subject override yours?
• Documentation of the LIA
• A right to object for data subjects, which you must be able to honour

The common misconception: Legitimate interests is often used as a catch-all — the "we couldn't find another basis" choice. It's actually the most sophisticated basis and the one that requires the most work to justify. Done properly, it's powerful and flexible. Done lazily, it's a regulator's open door.

When it's appropriate: Fraud prevention, network security, direct marketing to existing customers (with caveats), intra-group data transfers, personalisation that is genuinely in the data subject's interest.

When it's not appropriate: When you haven't done the LIA, when the data subject would clearly object if asked, or when sensitive data is involved without additional grounds under Article 9.

How to Choose: A Decision Framework

Choosing a lawful basis isn't a multiple-choice exam where any answer that "fits" will do. The GDPR doesn't rank the six bases in order of preference — but regulators have made clear that the choice must be appropriate, not just possible.

Here's a simple decision logic to use when evaluating a new processing activity:

Step 1 — Is there a legal obligation? If a law requires you to process this data, use legal obligation. No discretion needed — but document the specific law.

Step 2 — Are you performing a contract with this data subject? If the processing is strictly necessary to deliver a service or product the data subject has contracted for, contract is appropriate. Check that it's truly necessary, not just convenient.

Step 3 — Is this a life-or-death emergency? If there is an immediate threat to life and consent isn't obtainable, vital interests applies. This should almost never be your answer in a commercial context.

Step 4 — Are you a public authority performing a statutory function? If yes, public task may apply. Verify the legal mandate.

Step 5 — Have you obtained valid consent? If you have — and can maintain it — consent is appropriate. Only choose this if you can genuinely support withdrawal and ongoing management.

Step 6 — Have you conducted and documented a Legitimate Interests Assessment? If none of the above apply and you've done the LIA work, legitimate interests may be your basis. Don't skip the balancing test.

A Note for Those Operating Across Jurisdictions

For practitioners working at the intersection of GDPR and India's Digital Personal Data Protection Act (DPDPA) 2023, a key distinction is worth noting early:

The DPDPA uses the concept of "deemed consent" and "consent" as its primary processing grounds — it does not enumerate six separate bases the way GDPR does. This creates a cross-jurisdictional complexity for multinational organisations: what qualifies as a legitimate processing ground under GDPR may need to be re-mapped against DPDPA's framework separately.

I'll explore this in more depth in the individual posts, particularly in the consent and legitimate interests articles, where the divergence is most operationally significant.

What's Coming in This Series

Here's the full roadmap:

• Part 2: Consent — What makes it valid, what voids it, and why your cookie banner probably isn't enough
• Part 3: Contract — The most misused basis in product teams, and how to test necessity properly
• Part 4: Legal Obligation — How to trace your processing back to an actual law, not just a policy
• Part 5: Vital Interests — The emergency clause, its limits, and the rare scenarios where it applies
• Part 6: Public Task — Who this actually applies to, and how private entities sometimes mistakenly claim it
• Part 7: Legitimate Interests — The LIA in practice, the balancing test, and how to document it so it holds up

Each post will include: what the basis requires, how to test it, common mistakes, regulator guidance, and cross-jurisdictional notes for GDPR-DPDPA practitioners.

Final Thought

The lawful basis question is where privacy operations and legal strategy converge. It's not just a question for your DPO or your legal team — it's a question that product managers, engineers, marketers, and HR teams should be able to answer for every processing activity they own.

Because when an authority comes knocking, "we weren't sure which basis applied" is not a defence. But "we evaluated the options, chose this basis for these documented reasons, and can demonstrate we've maintained the conditions" — that's a programme.

That's what this series is built to help you build.

Next up: Part 2 — Consent. When it's real, when it isn't, and how to tell the difference.

Meanwhile, check out my LinkedIn post on similar topics

Devika Subbaiah is a Senior Privacy and AI Governance professional with 15 plus years of actual implementation experience. She writes about privacy operations, privacy engineering, and AI governance for practitioners who want to move from theory to execution.