"Necessary" Is Not the Same as "Convenient." Your Product Team Is Getting This Wrong.

Part 3 of The Legal Basis Playbook

There's a word in Article 6(1)(b) that almost nobody reads carefully.

The contract basis applies where processing is necessary for the performance of a contract to which the data subject is party, or to take steps at their request prior to entering into a contract.

That word is necessary.

Not useful. Not helpful. Not standard practice in our industry. Not what our data architecture was built around. Not what makes our product work better.

Necessary.

And the gap between what "necessary" actually means and how most organisations apply the contract basis is where some of the most structurally embedded lawful basis errors live — quietly, in RoPAs that have never been reviewed, in product specs that were written without a privacy professional in the room, and in legal assessments that someone produced four years ago and nobody has touched since.

How the Contract Basis Gets Misread

The contract basis sounds intuitive. You have a contract with your customer. You process their data to deliver the service. What's complicated about that?

Quite a lot, as it turns out.

The first misread is scope. Organisations routinely list entire categories of processing activity under the contract basis: analytics, behavioural tracking, profiling, A/B testing, product improvement, because these activities relate to the product that the customer signed up for. The reasoning goes: we have a contract → the product is what the contract is about → therefore all processing that makes the product work is covered.

This is wrong. And it's wrong in a way that regulators have been explicit about for years.

The EDPB's Guidelines 2/2019 on the Article 6(1)(b) legal basis are unambiguous: the necessity assessment must be applied strictly. Processing is necessary only if it is objectively necessary to fulfil the contract, meaning, you cannot deliver the contracted service without it. The question is not whether the processing is convenient, standard, or commercially sensible. The question is whether the absence of that processing would make it impossible to perform the contract.

That's a much higher bar than most product teams realise.

The Necessity Test in Practice

Here's how I think about testing contract basis claims:

If you removed this processing activity, would the contracted service be impossible to deliver — or would it just be less capable, less personalised, or less profitable?

If the answer is "impossible," the contract basis may apply. If the answer is anything else, you need to find a different ground.

Let me make this concrete.

A SaaS company processes a customer's name, company email, and billing information to create and maintain their account and send invoices. Necessary? Yes. The service cannot be delivered without an account. The company cannot be paid without billing details.

The same SaaS company processes detailed behavioural clickstream data — which features the user opened, in what order, how long they spent on each screen, what they ignored — to feed into a product analytics platform. Necessary? No. The contracted service (access to the software) works without this. The analytics benefit the product team's roadmap decisions, not the customer's contractual entitlement.

The same company uses that clickstream data to train an internal ML model that predicts churn. Necessary? No. The customer didn't contract for churn prediction.

In the first case, contract works. In the second and third, you need another basis — legitimate interests, consent, or not at all.

Most RoPAs I've reviewed would list all three under "contract performance."

The B2B Trap Nobody Talks About

Here's where it gets particularly interesting for those of us working in B2B SaaS — and We sits squarely in this territory.

When a company purchases a SaaS licence, who is the contracting party?

The company. Not the individual employees who use the product.

Article 6(1)(b) requires a contract with the data subject. The data subject in most B2B scenarios is the end user — the employee, the sales rep, the support agent logging into the tool. But the contract is between the vendor and the company. The individual employee is not a party to that contract.

This matters because it means you cannot rely on Article 6(1)(b) to process the personal data of employees of your B2B customer on the grounds that you have a contract with their employer. The employee didn't contract with you. The legal relationship that Article 6(1)(b) requires simply doesn't exist.

What you have instead is a data processing agreement, a controller relationship sitting with the employer, and a processing basis that lives on the customer's side of the architecture — not yours. As the vendor, your legitimate processing grounds for employee data of your customers' users will typically be found elsewhere: in your DPA, in legitimate interests for fraud prevention and security, or in contractual obligations with the business customer that flow into your role as a processor.

This is a nuance that gets lost constantly. B2B SaaS companies routinely reference "contract" as their basis for processing end-user data without recognising that the contract in question doesn't involve the person whose data they're processing.

You cannot bootstrap a contract lawful basis from a contract that doesn't name the data subject as a party.

Pre-Contractual Processing: The Useful Extension That Gets Overextended

Article 6(1)(b) also covers pre-contractual steps, processing necessary to take steps at the request of the data subject before entering into a contract.

This is useful. A job applicant submits their CV and requests consideration for a role. Processing their CV to evaluate them is pre-contractual. A prospective customer fills in a product demo request. Processing their contact details to arrange the demo is pre-contractual.

But the "at the request of the data subject" qualifier is doing significant work here that often goes unnoticed.

If your sales team scrapes a prospect's LinkedIn profile, adds them to a CRM, and begins tracking their engagement with your marketing content, without any request from that person — that is not pre-contractual processing under Article 6(1)(b). The data subject has not requested you to take steps. You have taken unsolicited commercial steps toward them.

Similarly, if you're processing candidate data beyond what they submitted, pulling public information, cross-referencing against other data sources, running automated screening, you have moved outside what they requested and potentially outside what the basis permits.

The pre-contractual extension is genuinely valuable and genuinely limited. It covers the steps required to act on the data subject's request. It doesn't cover the steps you'd like to take on your own commercial initiative.

Where This Intersects With AI — and Why It Gets Harder

Here's the dimension that deserves explicit attention, and that most contract basis analyses I've seen completely ignore.

Modern product delivery increasingly involves AI features. Recommendations. Intelligent search. Predictive responses. Automated prioritisation. These features are now standard expectations in SaaS products, sometimes marketed as core features of the contracted service.

So the question becomes: if an AI feature is part of the contracted product, does processing personal data to power it qualify as contract-necessary?

The honest answer is: it depends on how the contract is written and what the AI feature actually does. And right now, most contracts are not written with enough specificity to answer that question cleanly.

If a contract promises "intelligent ticket routing powered by ML" and the customer signed up specifically for that capability, there is a credible argument that processing ticket data to enable the routing is contract-necessary. The customer contracted for intelligence; the data processing enables it.

But if the contract promises "a customer support platform" and your team added AI features to the product without amending the contract or re-noticing the customer, you're on shakier ground. The processing that powers the AI wasn't necessary to the original contracted service. It became part of the product — but it was never part of the agreement.

The EU AI Act adds a transparency layer that compounds this. For AI systems classified as high-risk — and some enterprise SaaS AI features will qualify — you have transparency and explainability obligations toward affected individuals that exist independently of your GDPR lawful basis. The data subject has a right to know they're subject to significant AI-driven decisions. That right doesn't evaporate because you have a B2B contract with their employer.

The intersection of Article 6(1)(b) and AI processing is territory that most privacy programmes have not yet mapped. If yours hasn't, this is the gap to address.

The Cross-Jurisdictional Dimension: GDPR vs. DPDPA

If you operate across the EU and India — and many of SaaS enterprise customers straddle both — the contract basis creates a genuine mapping problem.

The DPDPA 2023 does not enumerate a standalone "contract" basis the way GDPR does.

Under the DPDPA, lawful processing of personal data requires consent — or falls under the "deemed consent" provisions of Section 7. Section 7 includes scenarios where processing is necessary for the performance of a contract to which the Data Principal is party, or to take pre-contractual steps at their request.

So the functional equivalent exists. But the architecture is different.

Under GDPR, contract is one of six co-equal lawful bases. Under DPDPA, contract-necessary processing is carved out as a category of deemed consent — which means it operates within a consent framework, not as an independent ground. The data fiduciary still has notice obligations. The Data Principal still has rights that apply. The controller-processor distinction still matters.

What this means practically: you cannot simply re-label your GDPR "contract" basis entries as DPDPA-compliant without reviewing whether the processing that qualifies under Article 6(1)(b) also qualifies under Section 7's deemed consent conditions — and whether your notice obligations under the DPDPA have been satisfied for those processing activities.

Cross-jurisdictional lawful basis mapping is not a search-and-replace exercise. The underlying processing may qualify in both frameworks, but the operational requirements to maintain that qualification differ.

The Mistake You're Most Likely Making Right Now

If I had to name the single most common contract basis error in mid-to-large organisations, it would be this:

The contract basis was selected at product launch and has never been reviewed since.

Products evolve. Features are added. Integrations are onboarded. ML capabilities are introduced. Third-party data enrichment vendors are connected. The product that exists today is not the product that existed when the privacy notice was drafted and the RoPA was built.

But the lawful basis inventory? Often untouched. Still showing "contract" for processing activities that have expanded well beyond what the original contract required — or even described.

The GDPR's principle of purpose limitation under Article 5(1)(b) compounds this. Even if the contract basis was legitimately chosen at the outset, using data for new purposes that emerge from product evolution requires a fresh lawful basis assessment. You cannot rely on the original "contract" determination to cover new processing that the customer never agreed to and the original contract never contemplated.

This is the same structural problem I described in the consent post — the promise that was made at collection, and the processing that quietly exceeded it. The contract basis has its own version of this drift. And it's just as common.

For the Practitioner: A Necessity Test You Can Run This Week

Pull your RoPA. Identify every processing activity where the lawful basis is listed as "contract" or "performance of a contract."

For each one, ask these questions:

Document your answers. Even if everything checks out, the documentation is the defence.

Final Thought

The contract basis is not a safe default. It is not a catch-all for processing that happens to relate to a service a customer purchased. It is a narrow, specific, necessity-bound ground that requires active maintenance as products and relationships evolve.

The word "necessary" in Article 6(1)(b) is not decorative. It is the entire test.

Most organisations haven't applied it rigorously. Most RoPAs reflect convenience, not necessity. And most product teams have never been asked to justify their data processing against the question: is this actually impossible to do without this data?

That question is worth asking. Regularly. And the answers will probably surprise you.

Next up: Part 4 — Legal Obligation. How to trace your processing back to an actual law — not a policy, not an industry standard, and not a contractual obligation with a third party. The basis that sounds simple and isn't.

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.