Article 6: Lawfulness of processing

To meet the article 6: lawfulness of processing requirement, you must ensure every personal-data processing activity has a documented, valid legal basis under GDPR and that your operations only process data within the scope of that basis. Operationalize this by mapping each processing purpose to a lawful basis, embedding checks into intake/change workflows, and retaining evidence that the decision is correct and consistently followed. ¹

Key takeaways:

• Every processing activity needs an explicit lawful-basis decision tied to a specific purpose and scope. ¹
• Your control objective is operational: prevent “no legal basis” processing at launch and after changes. ¹
• Auditors will ask for repeatable decision records and proof your systems and teams follow them, not just a policy statement. ¹

Article 6 is the gating requirement for GDPR processing: if you cannot point to at least one lawful basis for a specific processing purpose, the processing is not lawful. ¹ For a CCO or GRC lead, the fastest path to operational coverage is to treat lawful basis as a control you can test, not a one-time legal memo. That means two things: (1) a clear, searchable inventory of processing activities with purpose, role (controller vs. processor), and legal basis, and (2) workflow gates so new products, marketing campaigns, data sharing, analytics, and retention changes cannot go live without a reviewed lawful-basis decision.

In practice, Article 6 breaks when teams “inherit” data and assume legitimacy (“we already had it”), repurpose it (“we’ll also use it for growth analytics”), or expand access to third parties without re-checking scope. A workable program makes lawful basis visible at the moment decisions are made: intake forms, privacy reviews, engineering change management, procurement, and data governance. This page gives you requirement-level steps, evidence to retain, and audit-ready questions so you can implement quickly and defend the program with documentation grounded in Article 6. ¹

Regulatory text

Excerpt (GDPR Article 6(1)): “Processing shall be lawful only if and to the extent that at least one of the following applies:” ¹

Operator meaning (what you must do):

• For each processing activity (collection, use, sharing, storage, deletion), confirm you have at least one lawful basis and process only within its scope. ¹
• Treat “purpose + lawful basis + scope” as a controlled decision that must be reviewed when the processing changes (new purpose, new data category, new recipient, new geography, new system). ¹
• Be able to show your decision record and that the organization follows it in day-to-day workflows. ¹

Plain-English interpretation (requirement-level)

Article 6 requires that every way you process personal data has a lawful justification. You do not get “a lawful basis for the dataset.” You get a lawful basis for a defined purpose and defined operations. If a team wants to reuse the data for a different purpose, expand the audience, or change how long you keep it, you must reassess whether the same lawful basis still applies and whether the scope is still “to the extent” permitted. ¹

For execution, think in three units:

1. Processing activity (what happens, where, by whom, using which system)
2. Purpose (why you do it, in business terms)
3. Lawful basis (which Article 6 condition makes it lawful), plus any constraints you impose to keep operations within scope (data minimization, access, retention, sharing limits). ¹

Who it applies to

Entities

• Any organization acting as a controller or processor for in-scope personal data. ²

Operational contexts where Article 6 shows up immediately

• Product registration and account management (collection, authentication, support).
• HR and talent operations (candidate pipelines, employee data).
• Marketing operations (email, profiling, audience building).
• Analytics and data science (event data, model training features).
• Third-party sharing (processors, sub-processors, affiliates, partners).
• Retention and deletion (archiving, backups, legal holds).

Role nuance you must operationalize

• If you are a processor, your lawful basis posture often depends on controller instructions and your contract position, but you still need internal clarity on what processing you perform and why. The fastest control win is to document the role per processing stream and link it to what your systems actually do. ²

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

1) Stand up a “lawful basis register” tied to real processing

Build a register that is auditable and operationally useful. Minimum columns:

• Processing name and owner
• Controller/processor role for that activity
• Data categories and data subjects (customer, employee, prospect)
• Purpose statement (plain business language)
• Lawful basis (Article 6 condition selected)
• Systems involved (source, storage, downstream consumers)
• Sharing/recipients (including third parties)
• Retention rule and deletion trigger
• Review triggers (what changes require reassessment)

This implements the “role-and-scope register” control pattern recommended for this requirement. ²

2) Create a decision standard (so teams pick bases consistently)

Write a short internal standard that tells reviewers how to decide and what “good” looks like:

• Each processing purpose must map to at least one lawful basis. ¹
• The purpose statement must be specific enough to test. “Business operations” is not testable.
• Scope constraints must be explicit (who can access, what is shared, how long stored).
• Exceptions require a named approver and a remediation plan.

Make this standard usable inside intake tooling (privacy review form, ticket templates) so people follow it without reading a memo.

3) Put lawful basis into intake and change management gates

Add mandatory checks at the points where unlawful processing is introduced:

• New product / feature privacy review: require purpose + lawful basis + systems + recipients before launch approval. ¹
• Marketing campaign intake: require lawful basis decision, suppression rules, and any consent dependencies before sending.
• Data-sharing approvals (APIs, SFTP drops, data clean rooms): block until a lawful basis exists for the sharing purpose and the recipient relationship is documented.
• Engineering change management: if a change adds a new event, new identifier, new downstream consumer, or new retention period, force a lawful-basis reassessment ticket.

This is the “requirement-specific operating procedure with named owners, trigger events, and required approvals” control pattern. ²

4) Operationalize “to the extent” with technical and procedural controls

Article 6 is violated when teams exceed scope. Common scope controls:

• Access control: restrict personal data access to teams tied to the documented purpose.
• Data minimization at collection: only collect fields needed for the approved purpose.
• Purpose-based tagging: tag datasets/events with the approved purpose and enforce in analytics tooling (for example, restricted tables or projects).
• Retention enforcement: automate deletion/archiving rules to match the approved processing scope.

You do not need perfect tooling to start. You need a consistent mechanism that prevents obvious scope drift and produces evidence.

5) Create an “evidence packet” per processing activity (audit-ready)

For each material processing activity, keep a packet that includes:

• Lawful basis decision record (who approved, when, what purpose/scope)
• Data flow or system diagram (even a simplified one)
• List of recipients/third parties and the sharing mechanism
• Control outputs: screenshots, logs, tickets, or reports that show the gates ran and were approved
• Exceptions and remediation records

This follows the “retain auditable evidence packets” control pattern. ²

6) Run a periodic revalidation cycle

Define revalidation triggers and cadence based on change:

• Trigger on new purpose, new recipients, new sensitive processing patterns, or material system changes.
• Trigger on incidents and complaints that involve unexpected data use.
• Trigger on third-party onboarding where processing expands.

Keep it simple: revalidate what changed, confirm lawful basis still fits, update the register, and retain the delta evidence.

Required evidence and artifacts to retain (practical checklist)

• Lawful basis register (exportable, versioned)
• Standard operating procedure for lawful-basis determination and approvals
• Completed intake records (privacy reviews, campaign requests, data-sharing approvals)
• Decision records for lawful basis (including approver identity and date)
• Data maps/flows linked to systems and recipients
• Technical enforcement evidence (access control configurations, retention job configs, deletion tickets)
• Exception log and remediation tracking (who accepted risk, what timeline, closure proof)

Common exam/audit questions and hangups

Expect these questions and prepare the artifacts above:

1. “Show me your lawful basis for this processing activity, and who approved it.” Provide the decision record and link it to the register entry. ¹
2. “How do you prevent teams from reusing data for a new purpose without review?” Show intake gating and change triggers in tickets/workflows. ¹
3. “How do you know your records match reality in systems?” Show data flow mapping plus a sampling approach (compare register entries to actual pipelines/tables/tools).
4. “Where is the evidence that controls operate?” Show completed reviews, approvals, and system configurations, not a policy PDF.

Frequent implementation mistakes (and how to avoid them)

• Mistake: One lawful basis per dataset. Fix: document at the processing-purpose level; one dataset can support multiple purposes, each with its own basis and scope constraints. ¹
• Mistake: “Consent” becomes the default answer. Fix: require a rationale in the decision record and document operational dependencies (capture, withdrawal handling, suppression, auditability). ¹
• Mistake: No controller/processor role clarity. Fix: add a role field in the register and force a role decision during intake. ²
• Mistake: Policy exists, controls don’t. Fix: embed gates into the workflows where data is created, shared, and retained; collect evidence automatically from those systems.
• Mistake: Scope drift through third parties. Fix: treat new recipients and new sharing methods as a trigger event; require a fresh review and update the evidence packet.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance focuses on defensibility through controls and evidence. Article 6 failures tend to be high-risk because they challenge the legality of the processing itself, which can cascade into remediation work (pausing processing, deleting data, re-contacting individuals) and heightened regulator scrutiny. Anchor your program on provable decisions and operational gates tied directly to processing change points. ¹

Practical execution plan (30/60/90-day)

Use phases rather than calendar promises. The intent is fast operational coverage first, then depth.

First 30 days (Immediate foundation)

• Appoint owners: Privacy/Legal for basis standard; Security/Data Governance for system mapping; Product/Marketing Ops for intake gates.
• Build the first version of the lawful basis register for the highest-risk processing areas (marketing, analytics, third-party sharing, HR).
• Publish a 1–2 page decision standard and approval RACI.
• Add lawful-basis fields to existing intake forms and tickets (product privacy review, marketing requests, data sharing).

Next 60 days (Controls that block bad launches)

• Turn intake fields into hard gates: no launch/no send/no share without an approved entry.
• Create evidence packets for the most material processing activities and store them in a single system of record.
• Implement at least one technical scope control per critical stream (access restrictions, retention enforcement, or tagging).

By 90 days (Operational maturity and repeatability)

• Expand coverage across all processing activities in scope.
• Add revalidation triggers tied to engineering change management and third-party onboarding.
• Run an internal audit-style sample: pick several activities, trace from register to systems to evidence, and document gaps with remediation owners.
• If you use Daydream, operationalize this as a requirement workflow: register + SOP + recurring evidence packets with exception tracking so you can answer diligence requests quickly and consistently.

Frequently Asked Questions

How granular does the lawful basis documentation need to be for Article 6?

Granular enough to test. Document lawful basis per processing purpose and link it to the systems and recipients involved, so you can prove the organization processes “only to the extent” approved. ¹

Do we need a new approval for every small product change?

Not for every change, but you need defined trigger events. If a change introduces a new purpose, new data category, new recipient, or new retention behavior, route it through lawful-basis reassessment. ¹

What should we show an auditor if we’re still building a full data map?

Provide a lawful basis register for your highest-impact processing, plus evidence packets that tie decisions to real systems and completed intake approvals. Auditors typically accept phased maturity if controls are operating and gaps are tracked.

How does controller vs. processor role affect Article 6 execution?

Your role affects what decisions you make directly and what you inherit via instructions. Operationally, you still need an internal role decision per processing stream and evidence of what your systems do with the data. ²

What evidence is strongest for “to the extent that” in Article 6?

Technical constraints and logs beat narratives. Access controls, retention automation, data-sharing approval tickets, and system configurations show that processing stays within the approved scope. ¹

Can we treat Article 6 as “done” once we pick a lawful basis?

No. The control has to survive change. Build reassessment triggers into product, marketing, procurement, and data engineering workflows so lawful basis stays current as processing evolves. ¹

Footnotes

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

2. Regulation (EU) 2016/679