Just FYI: “bases” in this context is the plural of “basis”. We know it reads strangely 🤷
At a glance
You need a legal basis every time you process personal data, and you’ve got six options.
One of the most common GDPR misconceptions is you just get consent for everything you need, and you’re off to the races. Consent is not the default, and using it when another basis applies can cause problems. Pick your basis before you start processing, and document it.
For every single pieces of personal information you collect, you need to choose the legal basis for its collection, and document that decision before you start processing. You can’t change your legal basis retroactively, so getting this right from the start is important.
Basis 1: Consent
When to use it: when you don’t have another valid basis, and the person has a genuine, free choice.
Consent under GDPR has to meet a high standard. It must be:
- Freely given: no bundling consent into terms and conditions, no coercion.
- Specific: separate consent for each purpose, not one blanket tick.
- Informed: people must know what they’re agreeing to.
- Unambiguous: a clear, active opt-in; no pre-ticked boxes.
Watch out
If you rely on consent, people can withdraw it at any time — and you must make withdrawal as easy as giving consent. That means unsubscribes must work immediately, and consent records must track withdrawals as well as sign-ups.
Watch out again!
Because consent is a broad and easily-understandable mechanism (“they agreed to it!”), many companies use it as their legal basis for everything. But this can create problems down the road due to a users’ right of withdrawal.
If you collect a customer’s name, address and billing details on a consent basis, they may choose to withdraw that consent. But you still need to keep that data for your financial records, which is a legal obligation basis. Now you’re in a pickle!
Basis 2: Contract
When to use it: when processing is necessary to fulfil a contract with the person, or to take steps before entering a contract at their request. For example:
- Processing a customer’s delivery address to ship their order.
- Collecting payment details to process a purchase.
- Storing account credentials for a SaaS subscription.
- Using an email address to send order confirmations.
The critical word here is “necessary.” The processing must be genuinely required to deliver what was agreed. You can’t tack on additional data collection and claim “contract”. It has to be directly linked to the contractual obligation.
Basis 3: Legal obligation
When to use it: when you’re legally required to process data by EU or national law. For example:
- Keeping financial records for tax purposes.
- Running anti-money laundering checks.
- Complying with employment law obligations.
- Reporting requirements to regulatory bodies.
The key point: this must be a specific legal obligation, not a vague sense that “we should probably keep this.” And it must be an obligation under EU or a member state’s law. If you’re unsure, every EU member state has a data regulator that can tell you your obligations.
Basis 4: Vital interests
When to use it: to protect someone’s life. Literally.
This basis is reserved for genuine emergencies: sharing medical data in a hospital when a patient is unconscious, processing data during a disaster to locate missing people, things like that. It’s a narrow exception for situations where obtaining consent isn’t possible and the stakes are that high.
If you’re reaching for “vital interests” to justify your newsletter signup or your analytics implementation, something has gone very wrong. This basis almost never applies to websites or standard business operations. Nice to know it’s there, but if you’re reading this, it’s almost definitely not for you.
Basis 5: Public task
When to use it: when processing is necessary for a task carried out in the public interest, or to exercise one of your duties in an official capacity in public office. This basis is limited to organisations like:
- Government bodies and local councils.
- Public-sector organisations.
- Universities.
- Regulators.
If you’re a private business with no official public function, this isn’t your basis. Although it’s nice to know that if you get investigated for a GDPR breach, your personal information will be processed under this basis!
Basis 6: Legitimate interest
When to use it: when you have a genuine business reason, the processing is necessary to achieve it, and it doesn’t unfairly override the individual’s rights and interests.
Legitimate interest is the most flexible of the six bases, which makes it appealing to simply bundle everything into this category. You’ve probably seen “Legitimate interest” as a cookie consent category, because some businesses mistakenly believe that tracking your activity across the web is vital to their business.
Due to that flexibility – and the potential for abuse – you can’t just declare an interest and collect whatever you like. You must carry out a Legitimate Interest Assessment (LIA) to document and balance the competing interests.
Legitimate Interest Assessments
A proper LIA involves three steps:
- Identify the legitimate interest: What’s your business reason? Is it real and specific?
- “To improve our website” isn’t nearly specific enough
- “To prevent fraudulent payments” is specific, and would pass this test
- Necessity test: Is the processing actually necessary to achieve that interest? Could you do it another way with less impact on privacy?
- Balancing test: Would the individual reasonably expect this processing? Would it surprise or upset them? Does your interest override their fundamental rights?
Some common legitimate use cases are things like:
- Website security and fraud prevention.
- Direct marketing to existing customers about similar products.
- Basic business administration.
- Network security monitoring.
Using legitimate interest as a basis for analytics tracking
Some argue you can rely on legitimate interest for basic website analytics.
You could feasibly make this argument under GDPR, however it doesn’t help you with the ePrivacy Directive: analytics cookies need consent regardless of your GDPR legal basis. The consent requirement comes from ePrivacy, not GDPR. So, if your analytics uses cookies, you need to get consent either way.
Comparison at a Glance
| Basis | Common uses | Consent needed? | Can user object? |
|---|---|---|---|
| Consent | Cookies, newsletters, optional profiling | Yes (it IS the consent) | Can withdraw anytime |
| Contract | Order processing, account management | No | Very limited |
| Legal Obligation | Tax records, compliance reporting | No | No |
| Vital Interests | Genuine emergencies | No | No |
| Public Task | Public sector organisations | No | Can object |
| Legitimate Interest | Security, fraud prevention, basic ops | No | Can object |
Common mistakes
- Not documenting your legal basis: You must be able to demonstrate your basis if asked. “We thought it was fine” isn’t documentation.
- Thinking you can change your basis later: You can, but only in very limited circumstances, and you must tell people about the change. Starting with the right basis is far cleaner
- Implied consent: “By continuing to use our service, you consent to analytics.” isn’t allowed. A clear, unambiguous opt-in is required.