Most teams treat the choice of legal basis as paperwork - a dropdown to fill in once, deep inside a privacy notice nobody reads. That dropdown is the difference between lawful processing and a regulatory infraction. And unlike most compliance choices, you do not really get to change your mind later. This piece walks through the six bases, the ones teams routinely misuse, and what actually holds up under regulator scrutiny.
The "We'll Just Get Consent" Trap
If there is one default we see in privacy reviews more than any other, it is this - teams pick consent for everything, because consent feels like the safest answer. It is not. It is usually the worst one.
Consent under GDPR has a specific shape. It has to be freely given, specific, informed, unambiguous, and as easy to withdraw as it was to grant. The moment access to your product depends on it, or the moment you bury it inside a fifteen-paragraph terms-of-service, it stops being valid consent and starts being a regulator magnet. We covered the four-part test in detail in consent under GDPR - what counts as valid consent.
There is a deeper problem. If you build your entire processing operation on consent, you have handed your users a switch that turns your business off. Every withdrawal becomes a delete request. Every consent fatigue moment becomes an unsubscribe. The companies that lean hardest on consent are the ones whose data flows are most fragile, not most defensible.
The right answer is almost never "consent for everything." It is "the right basis for each purpose."
The Six Bases, Demystified
Article 6 gives you exactly six lawful grounds. You pick one - sometimes one per processing activity. Here is the working version, not the textbook version:
| Basis | When It Fits | Where Teams Get Burned |
|---|---|---|
| Consent | Marketing emails, optional cookies, anything truly voluntary | Pre-ticked boxes, bundled consent, conditional access - all invalid |
| Contract | Processing strictly needed to deliver what the customer signed up for | Stretching it to cover analytics, profiling, or behavioural ads |
| Legal Obligation | Tax records, KYC/AML, court orders, statutory reporting | Industry guidance is not law - be specific about which statute |
| Vital Interests | Genuine life-or-death situations - medical emergencies, disasters | Almost never the right basis for B2B SaaS. If you are reaching, it is wrong |
| Public Task | Public authorities and bodies exercising official powers | Private companies rarely qualify - and "public interest" is not enough |
| Legitimate Interests | Fraud prevention, network security, basic analytics, B2B prospecting | Requires a documented LIA. "It helps the business" is not a balancing test |
Two things to internalise. First, you do not pick a basis for "the company" - you pick one per processing purpose. The same customer's data might sit under contract for service delivery, legal obligation for tax records, and legitimate interests for fraud monitoring. Second, the bases are not interchangeable. Each one carries different rights for the data subject and different obligations for you. Our piece on data subject rights under GDPR walks through how the rights differ across bases.
Legitimate Interests - The Most Misunderstood Basis
Legitimate interests is the most flexible of the six, and the most misused. It looks like a free pass. It is not.
Using legitimate interests requires a three-part test, written down before you start processing:
What is the legitimate interest you are pursuing? "It helps the business" is not enough; "detecting payment fraud across our customer base" is.
Is the processing actually needed to achieve that purpose, or could you do it with less data, with anonymised data, or not at all?
Do the rights and reasonable expectations of the data subject override the interest? If a user would not expect this, it usually fails.
This is the Legitimate Interest Assessment, or LIA. It is not optional, it is not retroactive, and "we never wrote one down" is treated by regulators as evidence the basis was never actually established.
If you cannot write the LIA in three short paragraphs that an outsider would find convincing, you do not have a legitimate interest. You have a hopeful guess.
You Cannot Switch Bases After the Fact
This is the part most teams discover too late. Once you have told users their data is processed under a particular basis, you cannot quietly migrate to a different one when it becomes inconvenient - for example, swapping consent for legitimate interests because withdrawal rates are hurting the funnel.
The European Data Protection Board has been explicit on this. Switching bases mid-flight is treated as unlawful processing of everything that came before, plus a transparency violation on top. The only legitimate move is to stop the original processing, notify users, and re-establish on the new basis going forward - usually with a fresh action from the user.
Which is why the documentation matters more than the dropdown. Your Record of Processing Activities (RoPA) should list, for each processing purpose: the basis chosen, the date, the rationale, and - for legitimate interests - the LIA that supports it. If a regulator asks why you picked what you picked, the answer is not a meeting. It is a document.
Teams treat the legal basis as something you set once at launch and forget. It is not. Every new feature that touches personal data is a new processing purpose, and may need its own basis. A new analytics integration. A new vendor that processes data on your behalf. A new use of existing data - repurposed marketing, AI training, customer scoring. Each one needs the basis question asked and answered before the data starts flowing, not after the support ticket arrives.
What Teams Default To vs What the Regulator Wants
Pattern-matching from a few hundred privacy reviews - here is the gap between how most teams handle legal basis and what actually holds up under scrutiny.
❌ Default Pattern
- Consent for everything
- One basis listed in the privacy notice, full stop
- "Legitimate interests" with no analysis attached
- Switching basis quietly when consent rates drop
- Re-using customer data for marketing under "contract"
✅ What Auditors Want
- The right basis for the actual purpose
- A basis recorded per processing activity in the RoPA
- A documented LIA - purpose, necessity, balancing test
- A locked basis, with a transparency notice if it ever changes
- A separate basis (consent or LI) for the secondary purpose
The Cost of Getting It Wrong
Picking the wrong basis is rarely the headline of an enforcement action - it is the substrate underneath one. A breach happens, a complaint lands, a journalist asks a question, and the regulator's first move is to ask why you were processing the data in the first place. If the answer is wobbly, the fine is not just for the breach. It is for unlawful processing, going back as far as the records do.
On the operational side, the cost is more familiar. Enterprise deals stall in legal because your DPA cannot articulate basis-per-purpose. Cyber insurance underwriters flag it as a control gap. M&A diligence finds three years of consent-based processing that should have been on legitimate interests, and the acquirer reprices accordingly. None of these costs make headlines. All of them show up on the P&L. Our piece on the real business impact of ignoring GDPR - beyond fines covers the wider cost picture.
Real-World - Meta €390M
Meta Fined €390M for Processing Behavioural Ads Under the Wrong Basis
Meta processed user data for behavioural advertising and argued the basis was "contract" - that personalised ads were part of the service users had signed up for. The Irish Data Protection Commission, after a binding decision from the EDPB, disagreed. Behavioural advertising, the regulator said, is not necessary for the performance of a Facebook or Instagram contract - users sign up for a social network, not for ads tailored to them. The correct basis would have been consent, freely given.
The fines: €210M against Facebook, €180M against Instagram. Total: €390M. Meta was given three months to bring processing into compliance. The lesson is not that contract is a bad basis - it is that stretching contract to cover something users would not expect is exactly the move regulators are now penalising. Pick the basis that actually matches the purpose, not the one that is easiest to defend on paper.
Final Thought
The legal basis question looks small from the outside. A dropdown. A line in a privacy notice. A field in a record nobody reads. In practice, it is the load-bearing wall of your entire privacy programme. Get it right and everything downstream - RoPA, DPIA, data subject rights, vendor contracts - has a foundation to attach to. Get it wrong and the whole structure is rebuilt the day a regulator asks the first question.
Most teams do not pick the wrong basis because they do not care. They pick the wrong basis because they were never asked to think about it as a per-purpose decision. The fix is not more legal review. It is a habit - every new processing activity, every new vendor, every new feature, the basis question gets asked and the answer gets written down before the code ships. Once that habit is in place, the rest of the GDPR programme - covered in our practical six-step compliance roadmap - gets meaningfully easier to run.
Frequently Asked Questions
GDPR Article 6 lists exactly six lawful bases: consent, contract, legal obligation, vital interests, public task, and legitimate interests. You select one basis per processing purpose - not per company - and you must be able to justify the choice in your Record of Processing Activities.
Consent has the strictest conditions of any basis - it must be freely given, specific, informed, and as easy to withdraw as to grant. Building processing on consent hands users a switch that turns the activity off. Service delivery is usually contract; fraud prevention is usually legitimate interests; tax records are legal obligation. Consent should be reserved for genuinely voluntary processing such as marketing or optional cookies.
An LIA is a documented three-part test required when relying on legitimate interests under Article 6(1)(f). It covers the purpose test (what is the legitimate interest), the necessity test (is the processing actually needed), and the balancing test (do the data subject's rights override the interest). Without a written LIA, regulators treat the basis as never having been validly established.
Effectively no. The European Data Protection Board has been explicit that switching bases mid-flight is treated as unlawful processing of everything that came before, plus a transparency violation. The only legitimate move is to stop the original processing, notify users, and re-establish on the new basis going forward - usually with a fresh action from the user.
In January 2023, the Irish Data Protection Commission fined Meta €390M (€210M against Facebook, €180M against Instagram) for processing user data for behavioural advertising under the wrong legal basis. Meta argued personalised ads were necessary to perform the user contract. The regulator, after a binding EDPB decision, disagreed - behavioural advertising is not necessary to deliver a social network, and the correct basis would have been freely given consent.
Per processing activity in your Record of Processing Activities (RoPA), with the date selected, the rationale for the choice, and - for legitimate interests - the supporting Legitimate Interest Assessment. The privacy notice tells users; the RoPA tells regulators. Both need to be consistent and current.
The DPDP Act takes a narrower approach than GDPR - consent is the primary basis for most processing, with a small set of "legitimate uses" that operate similarly to legitimate interests but are more tightly scoped. Organisations subject to both regimes need a basis matrix that covers each processing purpose under both laws. Our comparison piece on GDPR vs DPDP Act covers the differences.