GDPR Lawful Bases for Processing: A Practical Guide

Article 6 of the General Data Protection Regulation establishes a fundamental rule: every act of processing personal data must be grounded in one of six lawful bases. There is no default, no fallback, and no grace period. Before you collect a name, log an IP address, or send a marketing email, you must identify which lawful basis applies and document that decision. Processing without a valid basis is unlawful, regardless of how carefully you handle the data afterwards.

This requirement is not a formality. The lawful basis you select determines the rights available to data subjects, the obligations you must meet, and the regulatory risk you carry. Choose incorrectly and the entire processing activity is exposed — not just to enforcement action, but to reputational damage and the obligation to cease processing and potentially delete the data.

Article 6 at a glance — the six lawful bases

Article 6(1) lists exactly six bases. You must rely on at least one for every processing activity, and you should identify the most appropriate basis — not simply the most convenient. The six bases are:

1. Consent — the data subject has given clear, affirmative agreement
2. Contract — processing is necessary to perform or prepare a contract with the data subject
3. Legal obligation — processing is required to comply with a legal duty under EU or member state law
4. Vital interests — processing is necessary to protect someone’s life
5. Public task — processing is necessary for the exercise of official authority or a task in the public interest
6. Legitimate interests — processing is necessary for a legitimate interest pursued by the controller or a third party, provided it does not override the data subject’s rights and freedoms

Each basis has distinct conditions, limitations, and practical implications. None is inherently superior to the others; the correct choice depends on the nature of the processing, the relationship with the data subject, and the context in which data is collected.

Consent (Article 6(1)(a))

Consent is the most widely recognised lawful basis, but it is also the most demanding to implement correctly. Under the GDPR, consent must meet a high standard — significantly higher than many organisations realise.

Requirements for valid consent

For consent to be valid under the GDPR, it must satisfy four conditions simultaneously:

• Freely given. The data subject must have a genuine choice. Consent is not freely given if there is a clear imbalance of power (such as an employer–employee relationship), if consent is bundled as a condition of service where it is not necessary for that service, or if the data subject cannot refuse or withdraw without detriment.
• Specific. Consent must relate to a defined processing purpose. Blanket consent covering multiple unrelated activities is not valid. If you process data for several purposes, you need separate consent for each.
• Informed. Before giving consent, the data subject must know at minimum: who the controller is, what data will be processed, for what purpose, and that they have the right to withdraw consent at any time.
• Unambiguous indication. Consent requires a clear affirmative action — ticking an unticked box, signing a statement, choosing technical settings. Pre-ticked boxes, silence, and inactivity do not count. The burden of proof lies with the controller to demonstrate that consent was obtained.

Withdrawing consent

Data subjects have the right to withdraw consent at any time, and you must make withdrawal as easy as giving consent. If a user consented via a single click, you cannot require them to send an email or call a phone number to withdraw. You must inform data subjects of their right to withdraw before they give consent, and processing must stop once withdrawal occurs — though processing carried out before withdrawal remains lawful.

Children’s consent

Where consent is the lawful basis for offering information society services directly to a child, Article 8 imposes additional protections. The GDPR sets a default age threshold of 16, below which parental or guardian consent is required, though member states may lower this to a minimum of 13. Controllers must make reasonable efforts to verify that the person giving consent on behalf of a child does hold parental responsibility.

When consent works well — and when it does not

Consent is appropriate when you can offer genuine choice and the data subject retains meaningful control. It works well for marketing communications, newsletter subscriptions, cookie preferences, and optional data collection for product improvement. It works poorly in employment contexts, where power imbalances undermine the “freely given” requirement, and for processing that is genuinely necessary to deliver a service — where contractual necessity is a more honest and stable basis.

Contract (Article 6(1)(b))

Processing is lawful under this basis when it is necessary to perform a contract with the data subject, or to take steps at the data subject’s request prior to entering into a contract.

What “necessary” means

The word “necessary” is interpreted strictly. Processing must be objectively required to fulfil the contract — not merely useful, convenient, or standard practice. Delivering a purchased product to the data subject’s address requires processing their address: that is necessary. Profiling their purchase history to recommend additional products is not necessary for contract performance, even if your terms of service mention it.

Pre-contractual steps

This basis also covers processing carried out at the data subject’s request before a contract is signed. Providing a quote, running a credit check at the individual’s request, or processing an application form all fall within scope — provided the data subject initiated the steps.

Common applications

Contractual necessity is widely used for processing employee data under employment contracts, delivering purchased goods or services, managing subscriptions, and handling customer accounts. It provides a stable and straightforward basis that does not depend on ongoing consent and is not subject to withdrawal. However, you must not stretch its scope to cover processing that goes beyond what the contract genuinely requires.

Legal obligation (Article 6(1)(c))

This basis applies when processing is required to comply with a legal obligation imposed by EU law or the law of the member state to which the controller is subject. The obligation must be sufficiently clear and precise — a vague regulatory expectation is not enough.

Examples of legal obligations

Common examples include tax reporting, anti-money laundering checks, employment law requirements (such as reporting workplace injuries), financial regulatory disclosures, and retaining records where statute requires it. The obligation does not need to explicitly mention data processing, but there must be a clear legal requirement that cannot be met without processing personal data.

Limitations

This basis does not apply to contractual obligations — only to obligations imposed by law. It also does not cover processing carried out to comply with the laws of non-EU countries, unless those obligations are also reflected in EU or member state legislation. You should identify the specific legal provision that creates the obligation and record it in your processing records.

Vital interests (Article 6(1)(d))

Processing is lawful under this basis when it is necessary to protect the vital interests of the data subject or another natural person. In practice, “vital interests” means life-or-death situations — this basis exists primarily for medical emergencies and humanitarian crises.

Extremely narrow scope

The European Data Protection Board has made clear that this basis should not be used if another lawful basis is available. If you can reasonably obtain consent or rely on another basis, vital interests does not apply. Commercial organisations will rarely, if ever, rely on this basis. It may be relevant in limited scenarios such as emergency contact processing in a workplace incident, but even then, legal obligation or legitimate interests will typically be more appropriate.

Not a general safety basis

This basis does not cover general health and safety processing, security measures, or fraud prevention. The threshold is genuinely life-threatening circumstances. Using it for routine processing would be considered an abuse of the provision and would not withstand regulatory scrutiny.

Public task (Article 6(1)(e))

Processing is lawful under this basis when it is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. This basis is primarily relevant to public authorities, government bodies, and organisations exercising statutory functions.

Who can rely on this basis

Public task is the natural lawful basis for government departments, local authorities, regulators, law enforcement, public healthcare providers, state-funded educational institutions, and similar bodies. Private organisations may also rely on it where they exercise functions of a public nature — for example, utility companies exercising statutory powers or organisations carrying out public health surveillance.

The right to object

Unlike some other bases, processing under Article 6(1)(e) is subject to the data subject’s right to object under Article 21. The controller must stop processing unless it can demonstrate compelling legitimate grounds that override the data subject’s interests, rights, and freedoms.

Legitimate interests (Article 6(1)(f))

Legitimate interests is the most flexible lawful basis and, consequently, the most frequently misapplied. It permits processing where a legitimate interest is pursued by the controller or a third party, provided that interest is not overridden by the data subject’s rights and freedoms. It is not available to public authorities for the performance of their tasks.

The three-part test

Relying on legitimate interests requires you to pass a three-part test, which should be documented in a legitimate interests assessment (LIA):

1. Purpose test. Identify the specific legitimate interest. It must be real, current, and lawful — not speculative or hypothetical. Commercial interests, security interests, and public safety interests can all qualify, but you must articulate exactly what the interest is.

2. Necessity test. Demonstrate that the processing is genuinely necessary to achieve the identified interest. If you can reasonably achieve the same outcome with less data, less intrusive processing, or without processing personal data at all, the necessity test fails.

3. Balancing test. Weigh your legitimate interest against the impact on the data subject. Consider the nature of the data, the relationship between you and the data subject, whether the processing is within their reasonable expectations, and whether you can adopt safeguards (such as pseudonymisation or aggregation) to reduce the impact.

Conducting a legitimate interests assessment

A legitimate interests assessment is not a form to fill in once and forget. It is a substantive analysis that must reflect the specific processing activity and the specific context. Key questions include:

• What is the purpose and who benefits?
• Is the processing proportionate to the aim?
• Would the data subject expect this processing?
• What is the likely impact — and can it be mitigated?
• Are there vulnerable individuals (children, employees, patients) whose interests carry extra weight?

Record the LIA and review it periodically, particularly if the nature of the processing, the data, or the context changes. Supervisory authorities may request to see it at any time.

Common applications

Legitimate interests is widely used for network and information security, fraud prevention, direct marketing (with appropriate safeguards and opt-outs), intra-group data transfers for administrative purposes, B2B marketing to business contacts, website analytics, and processing necessary to enforce legal claims. It offers operational flexibility but demands genuine, documented analysis — not a rubber stamp.

B2B marketing and legitimate interests

In a business-to-business context, legitimate interests can provide a workable basis for contacting individuals in their professional capacity about products or services relevant to their role. However, you must still conduct a balancing test, ensure the marketing is targeted and proportionate, and provide a clear opt-out mechanism in every communication. The Privacy and Electronic Communications Regulations (PECR) impose additional rules on electronic marketing that apply alongside the GDPR — legitimate interests under the GDPR does not override the requirement for consent under PECR where it applies.

Special category data — Article 9

Article 9 identifies categories of personal data that are considered particularly sensitive and subject to additional protections. These include data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data concerning a person’s sex life or sexual orientation.

The general prohibition

Processing special category data is prohibited unless one of the specific conditions in Article 9(2) applies. These conditions operate in addition to — not instead of — the Article 6 lawful basis. You need both: a lawful basis under Article 6 and an Article 9 condition.

Key Article 9 conditions

The most commonly relied-upon conditions include:

• Explicit consent (Article 9(2)(a)) — a higher standard than ordinary consent, requiring a very clear and specific statement of agreement.
• Employment, social security, and social protection law (Article 9(2)(b)) — processing necessary for carrying out obligations in the field of employment law, authorised by EU or member state law.
• Vital interests (Article 9(2)(c)) — where the data subject is physically or legally incapable of giving consent.
• Substantial public interest (Article 9(2)(g)) — processing necessary for reasons of substantial public interest, on the basis of EU or member state law with appropriate safeguards.
• Health or social care (Article 9(2)(h)) — processing necessary for medical diagnosis, healthcare provision, or health system management.

Practical implications

If your processing involves any special category data, you must map both the Article 6 basis and the Article 9 condition in your records of processing activities. Failing to identify the Article 9 condition — even if you have a valid Article 6 basis — renders the processing unlawful.

Choosing the right lawful basis

Selecting the correct lawful basis is not a matter of preference. The GDPR expects you to identify the basis that most closely reflects the true nature and purpose of the processing. Here is a practical decision framework:

Start with the relationship

If the processing is necessary to deliver a service the data subject has requested or contracted for, contractual necessity is likely the right basis. If the processing is required by statute, legal obligation applies. These two bases are typically straightforward to identify because the trigger is external — a contract or a law.

Consider the data subject’s expectations

If the processing goes beyond what is strictly necessary for the contract or legal obligation, ask whether the data subject would reasonably expect it. Processing that is expected, low-risk, and proportionate may be suitable for legitimate interests. Processing that is unexpected, intrusive, or high-risk is better suited to consent, which gives the data subject direct control.

Assess power dynamics

In contexts where there is a significant power imbalance — employment, public services, dealings with children — consent is often inappropriate because it cannot be freely given. Consider whether contractual necessity, legal obligation, or legitimate interests provides a more honest and stable foundation.

Document early and clearly

Whatever basis you choose, document it before processing begins. Record it in your records of processing activities (ROPA), communicate it to data subjects in your privacy notice, and ensure your team understands which basis applies to each processing activity. Changing the basis after the fact is problematic and, in most cases, impermissible.

Comparison of the six lawful bases

What happens when the lawful basis is wrong

If you rely on an incorrect or invalid lawful basis, the consequences extend beyond regulatory fines. Processing carried out without a valid basis is unlawful from the outset, which means:

• The data subject’s rights were not properly communicated (because different bases trigger different rights).
• Any consent obtained may be invalid if consent was not actually the correct basis and was not collected to the required standard.
• A supervisory authority can order you to stop processing and, in some cases, to delete the data.
• Fines under Article 83(5) for infringements of the lawful processing principles can reach up to twenty million euros or four per cent of annual global turnover, whichever is higher.

Retrospective changes

The Article 29 Working Party (now the European Data Protection Board) has stated that controllers should not swap lawful bases. If you initially relied on consent and the data subject withdraws it, you cannot retrospectively switch to legitimate interests to continue processing. The lawful basis must be determined and documented before processing begins, and any change effectively requires you to treat the processing as a new activity — with fresh analysis, fresh documentation, and fresh communication to data subjects.

Documenting your lawful basis

Under Article 30, controllers must maintain records of processing activities that include the purposes of processing and the lawful basis relied upon. In practice, robust documentation means:

• Records of processing activities (ROPA) that map each processing activity to its lawful basis, purpose, data categories, recipients, and retention period.
• Privacy notices that clearly state the lawful basis for each type of processing, written in plain language that data subjects can understand.
• Legitimate interests assessments documented and stored for any processing relying on Article 6(1)(f).
• Consent records that capture what was consented to, when, how, and by whom — sufficient to demonstrate compliance if challenged.
• Internal guidance so that teams across the organisation understand which basis applies and do not inadvertently undermine it (for example, by requesting consent for processing that relies on contractual necessity).

Proper documentation is not merely a compliance exercise. It is the foundation that makes every other GDPR obligation — transparency, data subject rights, breach reporting, accountability — possible to fulfil consistently and at scale.