Legal Basis for Processing Personal Data: What's NOT Allowed Under GDPR

Let's cut straight to the point. If you're processing someone's personal data, you need a legal reason, a "lawful basis," to do it. Get this wrong, and you're not just making a mistake—you're breaking the law. The General Data Protection Regulation (GDPR) gives you six, and only six, possible justifications. Anything outside those six is illegal. I've seen too many businesses, especially in finance, trip up on this fundamental concept, leading to hefty fines and shattered trust. The confusion often isn't about what is allowed, but about what definitely is not.

What You'll Learn in This Guide

The Six Lawful Bases: Your Only Options
What Is NOT a Lawful Basis (The Critical List)
The #1 Pitfall: Misusing "Consent"
Legitimate Interest: Powerful but Misunderstood
Contract vs. Legal Obligation: A Common Mix-Up
A Real-World Scenario: Where Companies Go Wrong
Your GDPR Basis Questions, Answered

The Six Lawful Bases: Your Only Options

Before we talk about what's illegal, you must know the legal playing field. Under Article 6 of the GDPR, you can process personal data if one of these applies:

Consent: The individual has given clear, affirmative permission.
Contract: Processing is necessary to fulfill a contract with the individual.
Legal Obligation: Processing is necessary to comply with a common law or statutory law (not your own terms).
Vital Interests: Processing is necessary to protect someone's life.
Public Task: Processing is necessary to perform a task in the public interest or for official functions.
Legitimate Interests: Processing is necessary for your interests or a third party's, unless overridden by the individual's rights.

That's it. Your justification must fit neatly into one of these boxes. The UK's Information Commissioner's Office (ICO) and the European Data Protection Board (EDPB) have extensive guidance on each, but the core list is non-negotiable.

What Is NOT a Lawful Basis (The Critical List)

Here’s where experience matters. In my work advising fintech startups and banks, I hear the same invalid justifications repeatedly. These are not legal bases, no matter how much you wish they were.

"Because it's in our business interest" alone. This is the biggest red flag. Your commercial desire is not a basis. It only becomes one if you can frame it as a Legitimate Interest and pass the three-part test (purpose, necessity, balancing). Simply wanting to make more money doesn't cut it.

"Because we've always done it this way." Legacy practices are a compliance nightmare, not a defense. If you were processing data without a valid basis before GDPR, you're still doing it illegally now.

"Because the data is already public." This is a subtle one. Just because someone posted their email on LinkedIn doesn't give you carte blanche to add it to your marketing database. You still need a lawful basis (like legitimate interest) for your specific processing activity. Public availability is a factor in the balancing test, not a standalone basis.

"Because we anonymized the data." If the data is truly anonymous and cannot be re-identified, GDPR doesn't apply. But the keyword is "truly." Many firms perform weak pseudonymization (replacing a name with an ID) and call it anonymous. That's still personal data, and you still need a basis for the initial processing and the pseudonymization itself.

"Because it's easier for our systems." Technical convenience is irrelevant to the legal assessment. The law asks "is it necessary?" not "is it convenient?"

Consent feels like the safe choice, right? Ask for permission. It's not. In the finance sector, it's often the wrong choice, and misusing it invalidates your entire basis.

GDPR consent must be freely given, specific, informed, and an unambiguous indication. Let me walk you through a real audit finding I dealt with last year.

A loan comparison website had a sign-up form: "Create an account to compare rates." Below, pre-ticked, was: "I consent to receive marketing emails about financial products from you and our 50+ partners."

Three fatal errors here. First, bundling consent with the contract. You can't make opening an account conditional on accepting marketing. That's not "freely given." Second, pre-ticked boxes are not consent. Third, the description was vague—"financial products" and "50+ partners" isn't specific.

The lawful basis for sending those marketing emails was non-existent. They thought they had consent, but legally, they had nothing. Their basis was invalid, making every email a violation.

For core banking activities—processing a transaction, running a credit check—consent is usually inappropriate. You're doing it because it's necessary for the contract (to provide the bank account) or to comply with a legal obligation (anti-money laundering laws). Relying on shaky consent for these opens a huge risk.

Legitimate Interest: The Misunderstood Giant

This is the most flexible basis, and consequently, the most abused. It's not a free pass. It's a three-step test you must document.

Purpose Test: What's your legitimate interest? (e.g., fraud prevention, network security, direct marketing).
Necessity Test: Is the processing necessary for that purpose? Could you achieve it in a less intrusive way?
Balancing Test: Do your interests override the individual's rights and freedoms?

Where companies fail is skipping the balancing test. Say you're a payment processor. You want to analyze transaction data to develop a new fraud detection model. Legitimate interest seems perfect.

But you must balance it. What's the impact on the individual? The processing is largely invisible and enhances their security. The balance likely tips in your favor. Now, take that same data and use it to infer customer life events for cross-selling insurance without transparency. The intrusive nature likely overrides your interest. That processing lacks a valid basis.

You can't just say "legitimate interest" and move on. You have to do the homework and write it down in a Legitimate Interests Assessment (LIA).

Contract vs. Legal Obligation: A Common Mix-Up

This trips up even seasoned professionals. The difference is crucial.

Contractual Necessity: This is about what you and the individual agreed to. You need their address to deliver a card you promised in your terms. The necessity is defined by the contract's substance.
Legal Obligation: This is about an external law forcing you to do something. A law says you must verify a customer's identity and keep a record for five years. The necessity is defined by the statute.

The messy part? An activity can sometimes be justified under both. But you must pick one primary basis. I've seen firms try to claim "legal obligation" for everything to sound more robust, but then struggle when asked to cite the specific law. If you can't point to the exact statute, it's not a legal obligation.

A Real-World Scenario: Where Companies Go Wrong

Let's apply this to a concrete example. Imagine "FinTech Innovations Ltd.," a company offering a budgeting app linked to your bank accounts.

Processing Activity	Common (Wrong) Justification	Valid Lawful Basis (If Applicable)	Why the Wrong One Fails
Aggregating user's bank transaction data to show spending charts.	Consent (in the app's T&C).	Contractual Necessity. This is the core service the user signed up for.	Bundling it with the contract makes consent not freely given. It's not consent at all.
Using transaction data to train a general AI model for sale to other banks.	Legitimate Interest (business development).	None. This is highly likely to be unlawful.	Fails the balancing test spectacularly. The user's reasonable expectations and privacy rights override this secondary, commercial interest.
Sharing user data with a cloud hosting provider in the US.	"The provider is GDPR compliant."	Same as the underlying activity (e.g., Contract). Must ensure adequate safeguards (SCCs).	GDPR compliance of a processor doesn't establish your lawful basis. You need your own basis for the sharing act.
Sending emails about a new premium subscription feature.	"They are an existing customer."	Legitimate Interest (for direct marketing) or Consent, with soft-opt-in rules checked.	"Existing customer" is not a basis. You must fit it into a proper category and offer an opt-out.

See the pattern? The invalid justifications are vague, business-centric assumptions. The valid ones are precise and tied directly to the GDPR's framework.

Your GDPR Basis Questions, Answered

My company needs to process employee data for performance reviews. Which lawful basis should we use?

This is a classic case where legal obligation and legitimate interest often intertwine, but one is cleaner. Employment law may impose certain record-keeping obligations, but the actual evaluation process is more squarely under legitimate interests. The employer has an interest in managing its workforce, and the employee has an expectation of this. However, you must be transparent about how the data is used in your employee privacy notice. Relying on consent is dangerous here due to the power imbalance—an employee's consent is rarely "freely given."

We bought a marketing list. Can we use legitimate interest to email those people?

In most cases, no, and this is a huge source of fines. The EDPB has been clear that using bought lists for cold email marketing under legitimate interest is very unlikely to pass the balancing test. Those individuals have no relationship with you and no reasonable expectation of hearing from you. Their right to privacy outweighs your commercial interest. For B2B marketing, the rules can be slightly more nuanced, but for B2C (or emails to individual employee addresses), you generally need prior consent. Buying a list that claims to have consent is also extremely risky—you are responsible for verifying its quality, which is nearly impossible.

What's the single biggest mistake you see businesses make with lawful bases?

Picking one basis and sticking it on every processing activity like a universal label. You must map your bases to each distinct purpose. Sending a transaction receipt? That's contractual. Sending a monthly newsletter? That's legitimate interest or consent for marketing. Using data for fraud detection? That's a separate legitimate interest. The granularity is what most miss. Your Record of Processing Activities (ROPA) should reflect this detailed, purpose-by-purpose mapping, not just one blanket justification for "customer data."

If we realize we've been using the wrong lawful basis, what should we do immediately?

Stop the processing that lacks a valid basis. Then, conduct a proper assessment to identify the correct basis. If it's legitimate interest, document your LIA. If it's consent, design a compliant method to obtain it. You may need to communicate this change to affected individuals. Crucially, you cannot retroactively apply a new lawful basis to past processing. The past processing was unlawful. You'll need to consider whether this triggers a need to report a breach to your supervisory authority, depending on the risk to individuals. It's a serious situation that requires urgent legal review.

The bottom line is this: the legal basis for processing isn't a checkbox or a line in your privacy policy you set and forget. It's the foundational justification for every single thing you do with personal data. Getting it wrong means everything built on top of it is illegitimate. In the finance world, where trust is currency, that's a risk you simply cannot take. Scrutinize your purposes, match them precisely to the six pillars, and document your reasoning. That's not just compliance; it's sustainable business practice.