Article 6: Lawfulness of processing

GDPR Article 6 requires you to ensure every processing activity has a valid legal basis and that you can prove it with consistent, repeatable records. Operationalize it by mapping each processing purpose to one Article 6 basis, documenting the decision, aligning notices and contracts to that basis, and enforcing it through intake and change controls. ¹

Key takeaways:

• Every processing purpose needs an explicit Article 6 legal basis, recorded and kept current. ¹
• “We process personal data” is not a basis; your basis must match the purpose, context, and role (controller vs. processor). ²
• Build evidence once, then keep it alive through workflow gates: new product intake, marketing launches, data sharing, and retention changes. ¹

Article 6 is the gateway control for GDPR compliance: if you cannot show why a specific processing activity is lawful, downstream controls (privacy notices, DSAR handling, retention, DPIAs, third-party agreements) become harder to defend and easier to challenge. Article 6 does not ask you to “pick one basis for the company.” It forces a per-processing-purpose decision: for each purpose you pursue with personal data, you must be able to point to at least one lawful ground and keep that mapping accurate as products, vendors, and data flows change. ¹

For a CCO or GRC lead, the fastest path is to treat Article 6 like a requirements-to-controls translation exercise. You want (1) a role-and-scope register that clarifies when you act as controller or processor, (2) a legal-basis decision record per processing purpose, and (3) operational gates so teams cannot introduce new processing without a recorded basis and aligned disclosures. ²

This page gives requirement-level implementation guidance you can execute: who owns what, how to structure a legal-basis register, what artifacts auditors ask for, and how to avoid common pitfalls like overusing consent or relying on “legitimate interests” without documenting the balancing logic. ¹

Regulatory text

Regulatory excerpt: “Processing shall be lawful only if and to the extent that at least one of the following applies:” ¹

Operator interpretation: You must be able to show, for each processing activity (and specifically for each purpose), which Article 6 condition makes it lawful, and you must not process beyond that scope. This becomes an operational requirement to (a) select a lawful basis, (b) document it, (c) communicate it where required (for example, via privacy information and contractual terms), and (d) keep it updated when the processing changes. ¹

Plain-English requirement

• You cannot collect, use, share, or keep personal data “because it’s useful.” You need a specific lawful basis that fits what you are doing and why you are doing it. ¹
• The lawful basis is not a slogan; it is a control point. It must match the purpose, the data subjects, and the processing context. ¹
• If your purpose changes, your basis may need to change, and you need a controlled process to reassess. ¹

Who it applies to

Entity scope

• Controllers: You decide the purposes and means of processing. Article 6 mapping is primarily your responsibility because you choose the lawful basis for the purposes you pursue. ²
• Processors: You process on behalf of a controller. You still need role clarity because your operational reality (sub-processors, support access, telemetry, cross-border routing) can create extra processing that must be justified under the controller’s instructions and contract. ²

Operational contexts where Article 6 shows up immediately

• Product analytics, telemetry, and behavioral tracking
• Direct marketing and lead enrichment
• HR processing (recruiting, benefits administration, performance management)
• Customer support tooling (ticketing, call recording, screen sharing)
• Fraud detection and security monitoring
• Third-party sharing (SaaS tools, ad platforms, payment processors, background check providers) ²

What you actually need to do (step-by-step)

Step 1: Establish role and processing scope (controller vs. processor) per system and dataset

Goal: remove ambiguity before you assign legal bases.
Actions:

1. Inventory systems that touch EU personal data and identify business owners.
2. For each system/flow, record whether you act as controller, processor, or both depending on context.
3. Capture data categories and data subject types at a workable level (customers, prospects, employees, end users). ²

Practical control: Maintain a GDPR role-and-scope register that ties role, data categories, and affected systems to Article 6 decisions. This prevents “shadow controller” situations where teams set purposes without realizing the compliance impact. ²

Step 2: Build a legal-basis register mapped to “purpose statements”

Goal: one row per purpose, not per database table.
Actions:

1. Define a standard purpose statement format: “We process [data categories] about [data subjects] to [purpose] via [systems/recipients].”
2. Map each purpose to an Article 6 lawful basis and document why that basis fits.
3. Record key constraints: collection sources, sharing recipients, retention trigger, and whether the purpose is optional or necessary for service delivery. ¹

Tip: Avoid “kitchen sink” purposes like “service improvement.” Break them into operationally testable purposes such as “detect account compromise,” “measure feature adoption,” or “respond to support tickets.” Auditors can test those. ¹

Step 3: Align your external-facing disclosures and internal rules to the chosen basis

Goal: prevent mismatches like “consent” in the notice but “legitimate interests” in the register.
Actions:

1. Cross-check privacy notice language against the legal-basis register.
2. Ensure your intake forms, preference centers, cookie banners (if applicable), and unsubscribe handling match the basis you rely on for each purpose. ¹
3. For processor scenarios, confirm your data processing terms reflect instructions and do not introduce unscoped controller purposes through generic clauses. ²

Step 4: Put Article 6 into workflow gates (so decisions stay current)

Goal: stop “basis drift” as products change.
Actions:

1. Add a required field in your privacy intake (new feature, new third party, new dataset): “Purpose + lawful basis + approver.”
2. Define trigger events that force reassessment: new data category, new recipient, new geography, new purpose, or material change in retention.
3. Require sign-off from Privacy/Legal and the business owner before production release when personal data is involved. ¹

Practical control: Define a requirement-specific operating procedure with named owners, triggers, and approvals. If your auditors only see a policy, they will ask where the workflow enforcement lives. ²

Step 5: Make third-party sharing provable

Goal: show that onward sharing stays within the lawful basis and the stated purpose.
Actions:

1. For each third party receiving personal data, link the transfer to a purpose row in the legal-basis register.
2. Validate that the third party’s use is limited to your defined purpose (controller disclosures or processor terms, depending on role).
3. Maintain a living list of recipients by purpose. This is often where evidence breaks during diligence. ¹

Step 6: Package evidence on a recurring cadence

Goal: be able to answer “why is this lawful?” without scrambling.
Actions:

1. Capture the decision record (basis selected, rationale, approver, date).
2. Store control outputs (intake tickets, DPIA links if applicable, notice update PRs, contract addenda, preference logs).
3. Track exceptions and remediation with closure evidence. ¹

Practical control: Retain auditable evidence packets: decision record, control outputs, exceptions, and remediation. Build a predictable folder structure so you can respond to regulators and customers fast. ²

Required evidence and artifacts to retain (audit-ready)

Use this as your “Article 6 evidence checklist”:

Artifact	What it proves	Owner
Role-and-scope register	Where you act as controller/processor; what systems and data are in scope	Privacy + Enterprise Architecture 2
Legal-basis register (by purpose)	Each purpose has an Article 6 basis and documented rationale	Privacy/Legal 1
Intake and change-control tickets	New/changed processing went through review and approval	Product/IT + Privacy 1
Privacy notice mapping	External disclosures match internal basis decisions	Privacy/Legal 1
Third-party data sharing map	Recipients are tied to purposes and controlled	Procurement/Vendor Mgmt + Privacy 2
Exception log + remediation	You identify and fix gaps rather than letting them persist	GRC/Privacy 2

Common exam/audit questions and hangups

Expect these questions from regulators, internal audit, and enterprise customers:

1. Show me the lawful basis for this specific processing activity. They will pick an app feature, a report, or a third-party integration. ¹
2. How do you prevent teams from adding new processing without review? Policies do not answer this; workflow gates do. ¹
3. Where is your controller vs. processor determination documented? Role confusion is a frequent finding because it breaks responsibility chains. ²
4. Prove your notice and your practice match. Auditors compare your public statements to actual telemetry, sharing, and retention behaviors. ¹
5. Show evidence you reassess when the purpose changes. Feature expansion often creates a new purpose that needs a new basis. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Picking one basis for an entire product

Fix: Force “purpose rows.” A single app can have multiple purposes with different bases. Your register must reflect that granularity. ¹

Mistake 2: Treating consent as the default

Fix: Use consent only when you can meet consent operational requirements consistently (capture, withdrawal, proof, and downstream propagation). If you cannot run those controls cleanly, choose a different basis that matches the purpose and context. ¹

Mistake 3: “Legitimate interests” without a documented rationale

Fix: Document why the interest exists and why the processing stays within that purpose boundary. Make the decision traceable to an approver and a versioned record. ¹

Mistake 4: Third parties added through IT spend without privacy review

Fix: Tie procurement intake to the legal-basis register. No third party receives personal data without a linked purpose, basis, and owner approval. ²

Mistake 5: Evidence scattered across inboxes and chat

Fix: Require a standardized evidence packet per purpose and per material change. A tool like Daydream can centralize the register, approvals, and recurring evidence collection so you do not rebuild proof during every diligence cycle. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not cite specific decisions. Practically, Article 6 failures tend to surface through complaints, investigations triggered by transparency gaps, or customer audits where teams cannot explain why a processing activity exists, who approved it, and whether it matches disclosed purposes. Your risk increases when you add tracking, marketing enrichment, or broad third-party sharing without a tight purpose-to-basis mapping and workflow gates. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and create the minimum viable evidence set)

• Stand up the role-and-scope register across key systems handling EU personal data. ²
• Create the legal-basis register template and populate the highest-risk purposes (marketing, analytics, profiling-like activities, third-party sharing). ¹
• Implement a basic intake gate: no new third party or new data flow without purpose + lawful basis + approver recorded. ¹

Days 31–60 (operationalize across teams)

• Expand the register to remaining business processes (HR, support, finance ops). ¹
• Reconcile privacy notice content to the register and open a tracked remediation list for mismatches. ¹
• Train product, marketing, procurement, and IT on trigger events that force reassessment. ²

Days 61–90 (make it durable and auditable)

• Convert the intake gate into a consistent workflow with required fields, approvers, and evidence attachments. ¹
• Start recurring evidence packets: decision records, exceptions, remediation closures, and third-party recipient mapping by purpose. ¹
• If you use Daydream, configure it as the system of record for Article 6 decisions and evidence so you can answer “show me the basis” with a link instead of a spreadsheet hunt. ²

Frequently Asked Questions

Do we need a legal basis per “processing activity” or per “purpose”?

Operationally, document per purpose and link activities/flows to that purpose. Article 6 is about lawfulness “to the extent” a condition applies, which maps cleanly to purpose boundaries. ¹

We are mostly a processor. Do we still need an Article 6 register?

You still need role clarity and a map of what you process for each controller instruction set. Processor operations often expand beyond the obvious (support access, logging, sub-processing), and you need documented scope to stay within instructions. ²

Can different regions use different lawful bases for the same feature?

They can, but it increases operational complexity and the chance of inconsistent notices and controls. If you do this, keep region-specific purpose rows and ensure the product enforces the correct behavior per region. ¹

What is the minimum evidence an auditor will accept for Article 6?

A current purpose-based register with lawful basis selections, a clear owner/approver, and proof that new processing changes must go through review. You also need alignment evidence to notices and third-party sharing records where applicable. ¹

How do we handle “product improvement” without creating an overly broad purpose?

Break it into specific, testable purposes (e.g., “measure feature usage to prioritize roadmap”) and tie each to defined datasets, recipients, and retention triggers. That structure makes it easier to reassess when a feature or data source changes. ¹

What should we do when we discover processing with no documented lawful basis?

Treat it as an exception: document the gap, assign an owner, decide whether to stop the processing or establish a defensible basis, and record the remediation outcome. Preserve the evidence trail so you can show governance rather than ad hoc decisions. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 6

2. Regulation (EU) 2016/679