Why GDPR Article 6 lawful basis is a system design question
Under Article 6(1), a controller may process personal data only where at least one of six lawful bases applies: consent, performance of a contract, a legal obligation, vital interests, a public task or official authority, or legitimate interests. The basis must be known for each processing purpose, not for the organization as a whole. When an auditor, customer or regulator asks which basis covers a given activity, the answer has to come from a record, not from memory or from a general statement in a privacy notice. The risk comes from how purposes multiply. A single customer record may feed billing, fraud screening, marketing analytics, support and a product improvement pipeline, and each of those uses may rest on a different basis. Bases tend to get assumed rather than recorded: a team reuses a dataset for a new feature and assumes the original basis still holds, or a legitimate interests argument is never written down. Inconsistent answers across systems then surface during an access request, a customer questionnaire or an investigation. Confirm with your legal or privacy lead which systems hold personal data for each purpose and whether the basis is written against each one.
The basis also decides which rights apply, which is why it belongs in the system design. Data portability under Article 20(1) covers processing based on consent or contract that is carried out by automated means, and the right to object under Article 21(1) covers processing based on Article 6(1)(e) or (f). A system that does not know the basis for a dataset cannot correctly route a portability export or an objection. Articles 13(1)(c) and 14(1)(c) require the purposes and legal basis to be stated in the information provided to data subjects, so the privacy notice and the system's purpose register must match. Where a new purpose is not based on consent or law, Article 6(4) asks for a compatibility assessment, and safeguards such as encryption or pseudonymisation are among the factors it lists. Ask your engineering owners to capture the purpose, basis and rights mapping as a field in each system's data inventory, and to review it when a new use is added.
Which processing activities need a recorded lawful basis
A single system usually serves several purposes, and Article 6 applies to each purpose separately. The cards below cover where personal data flows in a typical environment, so the processing inventory captures every purpose before any basis is assigned.
Production service delivery
The core application processes customer, staff and user records to deliver the service. Each feature that touches personal data is a purpose that needs its own basis, often contract performance for customer accounts and legal obligation for certain records. Check whether a feature such as a recommendation engine or optional profile field serves a different purpose that requires a different basis, and record it separately.
Analytics and product measurement
Usage analytics, funnel tracking and error reporting often reuse production data for a new purpose. Under Article 6(4), reuse for a purpose not based on consent or law requires a compatibility assessment, and safeguards such as pseudonymisation can support that assessment. Record whether analytics relies on legitimate interests, consent, or a compatible further purpose, and confirm which fields leave the production boundary.
Customer support and ticketing
Support tools copy names, contact details and free-text descriptions that may contain more personal data than the original record. Each support purpose, such as resolving a fault or handling a complaint, needs a basis that matches the contract or legitimate interest relied on. Ask whether agents can export tickets and whether attachments carry data that falls under a different purpose.
Backups, logs and audit trails
Backups and logs are processing activities in their own right, even when they hold no new data. Backup copies keep personal data for purposes such as restoration and continuity, and audit logs may record user identifiers and IP addresses for security monitoring. Assign a basis to each, and confirm that deletion requests and retention rules reach these copies.
Third-party integrations and sub-processing
Payment providers, email services, monitoring SaaS and identity federation each receive personal data for a purpose. Record which party acts as a processor on the controller's documented instructions, and which receives data as a separate controller for its own purpose, because the basis analysis differs. Confirm that every transfer to a recipient maps to a purpose listed in your inventory.
Public authority tasks
Public bodies cannot rely on legitimate interests under Article 6(1)(f) for processing performed in their tasks. Systems operated for a public task or official authority must record that basis and the legal provision behind it, and they should not offer legitimate interests as a fallback. Confirm this constraint with legal counsel before the inventory is finalized.
How each of the six lawful bases changes what systems must do
Every processing purpose needs one of the six bases in Article 6(1), and the system has to know which one applies. Consent requires the platform to capture a specific, recorded decision and to keep evidence of it that can be produced later, including the time, the wording shown and any withdrawal. Contract and legal obligation are easier to build but still need a documented source: the clause, order form or statute that makes the processing necessary. Engineers should store that reference alongside the purpose so a reviewer can trace why a field exists. Vital interests and public task are narrow. They rarely justify general-purpose data stores, so if a team proposes either, the reader should ask for the legal text that supports it before any schema is built. Public authorities also cannot rely on legitimate interests for tasks they carry out as authorities, which changes the design of any shared platform used across agencies.
Legitimate interests is the basis that most often lacks documentation. Relying on it means completing a written assessment covering a clearly articulated interest, necessity of the processing and a balancing test against the individual's expectations and rights. EDPB Guidelines 1/2024 on legitimate interest, issued for public consultation in October 2024, set out these cumulative conditions. Teams should confirm the current final version with their supervisory authority or counsel before relying on it. The basis also decides which rights apply: the right to object covers processing under Article 6(1)(e) or (f), and portability covers consent and contract processing carried out by automated means. A system that tags each purpose with its basis can route objection and portability requests correctly.
Further processing for a new purpose needs the Article 6(4) compatibility test unless it rests on consent or a law. The test weighs the link between the original and new purpose, the context of collection, the nature of the data, the possible consequences for individuals and the existence of appropriate safeguards. Encryption and pseudonymisation are named examples of safeguards, so they can make a secondary use easier to justify. Practically, the reader should check whether analytics, model training or reporting jobs reuse production data, record the compatibility assessment for each reuse, and confirm that the pseudonymised or encrypted copy is actually the one the new purpose reads. A safeguard that exists only in the policy document will not help the assessment.
Which data subject rights follow from the lawful basis
Article 20(1) gives a data subject the right to receive personal data they provided to a controller and to have it transmitted to another controller in a structured, commonly used and machine-readable format. The right applies only where the processing is based on consent or on a contract, and only where the processing is carried out by automated means. A system that holds personal data processed under a legal obligation or a public task therefore cannot treat that data as portable merely because it is stored electronically. The basis decides the answer, not the storage format.
- Two bases only: Portability covers consent under Article 6(1)(a) and contract under Article 6(1)(b). Data held under legitimate interests, a public task or a legal obligation falls outside this right.
- Automated processing is a separate test: Paper files or manual steps in a workflow may fall outside the right even when the basis is consent or contract.
- Provided data is the scope: Teams should confirm which fields count as data the person provided versus data the controller derived, since that boundary affects the export.
- Export format: The right calls for a structured, commonly used, machine-readable format. Confirm what your platform can export and whether the export includes the fields your records of processing list.
- Direct transmission: Where feasible, the data may be sent straight to another controller. Confirm this is technically possible for each system before promising it.
Check whether each system can filter records by lawful basis before generating a portability export, and whether the export log records the basis applied.
Article 21(1) gives a data subject the right to object, on grounds relating to their particular situation, to processing based on Article 6(1)(e) or (f). Those are the public task and legitimate interests bases. Once an objection is received, the controller must stop processing the data for those purposes unless it can demonstrate compelling legitimate grounds that override the person's interests, rights and freedoms, or the processing is needed for legal claims. The right does not apply in the same way to consent or contract processing, which is why the basis tag must be checked before any objection is handled.
- Public task and legitimate interests: Objection under Article 21(1) attaches to Article 6(1)(e) and (f) processing. Public authorities cannot rely on legitimate interests for tasks they carry out, so their objection analysis centres on the public task.
- Particular situation: The request must relate to the person's specific circumstances. Systems should capture the reason where the controller needs it to assess the request.
- Suppression lists: Stopping processing often means suppressing a record rather than deleting it, so the system must keep the person out of the affected purpose while retaining what is needed to honour the objection.
- Direct marketing: Objection to direct marketing has its own absolute effect under Article 21(2) and (3). Confirm which purpose tags trigger this path in your systems.
- Recorded decisions: Keep a record of the assessment, the outcome and the compelling grounds relied on, if any.
Confirm that each purpose in the record of processing names its basis, so the objection workflow can route requests to the correct analysis.
A system that does not tag data by lawful basis cannot answer portability and objection requests correctly. Without the tag, the team cannot tell whether a portability request is in scope, whether an objection triggers a stop, or whether consent must be checked before data is exported or used. The tag belongs to the purpose, not the whole record, because one customer record may serve a contract, a legal obligation and a marketing purpose at once. Each purpose needs its own basis, and the rights engine should read that basis before acting.
- Purpose-level field: Store the lawful basis against each processing purpose, with a reference to the record of processing entry.
- Consent linkage: Where the basis is consent, link the purpose to the consent record so withdrawal and evidence can be checked in one step.
- Change control: Changes to a basis must be versioned and approved. Keep the history so you can show which basis applied on a given date.
- Propagation to processors: Confirm that sub-processors receive the basis tag or an equivalent flag, so their deletion or export actions match the controller's decision.
- Testing: Build test cases that submit a portability and an objection request for each basis and check the outcome.
Ask your implementation partner or platform vendor how basis tags are stored, filtered and logged, and whether a request workflow can read them without manual lookup.
Assessors and data protection authorities look for evidence that a request was answered correctly, not only that a policy exists. For these two rights, that means showing the basis that was applied, the scope that was exported or suppressed, and the time taken. The evidence should come from the system itself, so the team can reconstruct a request months later. Where a request was refused, the reason must be recorded and tied to the lawful basis or an exemption.
- Request log: Record the request date, the right invoked, the bases found on the affected purposes and the decision taken.
- Export evidence: Keep a copy or hash of each portability export, with the fields and format used.
- Suppression evidence: Show that suppressed records are excluded from the affected purpose in downstream systems.
- Refusal reasoning: Document the compelling grounds or legal basis when an objection is declined.
- Periodic sampling: Test a sample of closed requests against the basis tags to catch errors early.
Confirm with your data protection officer or legal team how long request evidence is retained and whether it is held in a version-controlled wiki or case tool.
How an assessor tests the lawful basis for each purpose
This table compares what an assessor checks for each part of the lawful basis trail, what evidence they ask to see, and the findings that most often appear. Read it as a sequence: confirm the purpose inventory first, then check each basis against its justification, its records and the notices that describe it.
| Test area | What the assessor checks | Evidence requested | Common findings |
|---|---|---|---|
| Purpose inventory | Every processing purpose is listed and matched to systems, data categories and recipients in the record of processing | Record of processing extract, system inventory, data flow diagrams for each purpose | Purposes exist in code or marketing tools but are missing from the record |
| Basis per purpose | One Article 6(1) basis is identified for each purpose, and the basis is recorded before processing starts | Basis field in the record of processing, dated decision log, change history for the basis | Basis chosen after the fact to fit an existing process |
| Basis justification | The chosen basis fits the purpose and the processing actually performed | Written justification per purpose, linked to the contract, legal obligation or public task it relies on | One basis applied to many unrelated purposes without separate reasoning |
| Legitimate interest assessments | The interest is lawful, clearly articulated and real and present, the processing is necessary, and the balancing test favours the controller | Signed assessment per purpose, interest statement, necessity reasoning, balancing notes and safeguards such as opt-outs | Interest described in vague terms, no balancing record, or a public authority relying on Article 6(1)(f) |
| Consent records | Where consent is the basis, the system can show who consented, to what, when and through which notice, and that withdrawal is possible | Consent log entries, versioned consent text, withdrawal logs, sample records traced to the interface shown | Consent logs missing timestamps or notice versions, or consent bundled with service access |
| Notice consistency | Privacy notices name the same purposes and bases that the system follows (Articles 13(1)(c) and 14(1)(c)) | Current and archived privacy notices, mapping from each notice statement to the processing and basis record | Notice names consent or legitimate interest while the system processes on another basis |
| Further processing under Article 6(4) | Any new purpose compared with the original purpose is checked for compatibility, including safeguards such as encryption or pseudonymisation | Compatibility assessment, link between original and new purpose, safeguards applied, approval record | Data collected for one service reused for analytics or training with no compatibility check |
| Rights mapping | The basis is used to decide whether portability (Article 20) and objection (Article 21) apply, and the system supports them accordingly | Rights matrix per basis, configuration showing which requests are routed to which process | Objection handling offered for consent-based processing only, or portability ignored for contract-based data |
Implementing lawful basis recording in five steps
This sequence turns the Article 6 lawful bases into a working record that shows which basis applies to each processing purpose, which data subject rights follow from it, and where consent evidence must be kept. Each step produces a document or configuration that an assessor or regulator can inspect.
Inventory processing purposes across systems
Start by listing every purpose for which the organization processes personal data, not every system or database. Product, HR, finance, support and marketing teams usually each own purposes, so the inventory should be built with system owners and business owners together. Each purpose is recorded with the data categories involved, the data subjects, the systems that hold or move the data, and the teams accountable for it. The step is done when every system in scope maps to at least one named purpose and no purpose is left without an owner.
Select and justify a basis per purpose
For each purpose, the controller chooses one of the six bases in Article 6(1) and writes down why it fits. Where legitimate interests are chosen, the controller needs a documented legitimate interest assessment that applies the three cumulative conditions described in the EDPB Guidelines 1/2024 on legitimate interest: a lawful, clearly articulated and real interest, necessity, and a balancing test. Public authorities cannot rely on legitimate interests for tasks they carry out as authorities. The output is a justified basis entry for each purpose, reviewed and signed off by the person accountable for the processing, with the rights that follow from that basis noted alongside it.
Record the basis in a linked register
Store each purpose and its basis in a register that links to the systems, databases, data stores and backups where that data lives. The link matters because the basis decides which rights apply: portability covers consent and contract-based processing carried out by automated means, and objection covers processing based on Article 6(1)(e) or (f). A rights-handling team that cannot see the basis cannot answer a request correctly. Wiki or documentation tools with version history, such as XWiki, can hold the register if access is restricted and changes are logged. Confirm with your own engineers which systems can tag records by purpose, since that capability depends on how each platform is configured.
Align notices and consent flows
The purposes and legal basis from the register must match what data subjects are told. Articles 13(1)(c) and 14(1)(c) require the purposes and legal basis to appear in the information provided to individuals, so privacy notices are generated from or checked against the register. Where consent is the basis, the consent capture design must be built so that the organization can later show who consented, to what, when and under which notice version. Consent records should be separate from marketing or product flags that cannot be evidenced. The output is a current privacy notice version and a consent record design that matches each consent-based purpose in the register.
Review bases when purposes change
Any new purpose, new data category, new recipient or new use of existing data needs a fresh check of the basis. Article 6(4) sets compatibility factors for further processing that is not based on consent or law, and one of them is the existence of appropriate safeguards, which may include encryption or pseudonymisation. Changes should go through a change process that requires the register entry, the notice and any legitimate interest assessment to be updated before the change goes live. The output is a dated change log for each purpose showing the old basis, the new basis, the reason and the approver, which gives an assessor evidence that the register stayed accurate over time.
Evidence that satisfies an Article 6 review
An Article 6 review tests whether each processing purpose has a documented lawful basis that was chosen before processing started and still holds today. The records below connect that basis to the systems that carry out the processing, so the controller can show the decision and its history without rebuilding it after a complaint or inquiry.
Processing register with basis per purpose
The record of processing lists each purpose, the Article 6(1) basis relied on, the data categories, the systems holding them and the recipients. Assessors look for one row per purpose rather than one per system, because the basis attaches to the purpose. Keep the register in a tool with version history and role-based edit rights, so changes to the basis column need an owner's approval and leave a trace. Review it whenever a new system or feature touches personal data.
Legitimate interest assessments
Where the basis is legitimate interests under Article 6(1)(f), the controller needs a written assessment covering the interest, the necessity of the processing and the balance against the individual's interests. The EDPB's Guidelines 1/2024 set these three cumulative conditions. Store each assessment next to its register entry, record the date and the person who signed it off, and reopen it when the processing changes in scope or in the data involved.
Consent logs with versioned wording
Where consent is the basis, the system must show who consented, when, to which wording and through which interface. Keep the consent text itself under version control, so each log entry points to the exact version shown. Confirm that withdrawal is logged with the same detail and that processing stops in downstream systems. Ask vendors and integrators how consent records are exported and how long they are retained.
Privacy notices mapped to purposes
Articles 13 and 14 require the notice to state the purposes and the legal basis. Map each notice section to a register purpose, so a reviewer can trace a basis from the public statement to the processing record. Publish notices from a controlled repository where each edit is attributed and any earlier version can be restored. Re-check the mapping after every new purpose, because an unmapped purpose is a common gap in reviews.
Change history of basis decisions
A basis can change, for example when consent is replaced by a contract or a legitimate interest assessment is revised. Keep a dated log that records the old basis, the new basis, the reason, the approver and the systems affected. Assessors test whether past processing was lawful under the basis in force at the time, so the history matters as much as the current entry. Restrict who can change a basis and require a second reviewer.
Compatibility checks for further processing
When data collected for one purpose is reused for another not based on consent or law, Article 6(4) requires a compatibility check. The record should list the link between purposes, the context of collection, the data sensitivity, the possible consequences for individuals and the safeguards applied, such as encryption or pseudonymisation. Keep each check linked to the register entry for the new purpose, and confirm that the owner re-runs it when the reuse changes.
What meeting Article 6 costs in money and effort
This table compares the main cost components of recording and defending a lawful basis for each processing purpose, who is paid for each, and whether the cost is one-time or recurring. Read it to see where spend lands in legal, engineering and governance time, and what pushes each cost up. Open-source tooling mainly removes licence spend, so staff time remains the largest variable.
| Cost component | Who is paid or who spends time | One-time or recurring | Main drivers |
|---|---|---|---|
| Basis selection review | In-house privacy or legal staff, or an outside privacy adviser | One-time per purpose, then recurring on change | Number of processing purposes and how often products add new uses |
| Engineering work to tag data by basis | Platform and application engineers | One-time build, then recurring for new fields and services | Count of systems holding personal data and whether a purpose register already exists |
| Consent capture and evidence | Product and engineering teams | One-time build, then recurring maintenance | Number of consent-based products, consent versions and withdrawal paths |
| Legitimate interest assessments | Privacy team with business owners | Initial assessment, then periodic review | Number of legitimate interest purposes and how often their context changes |
| Register upkeep | Privacy operations and system owners | Recurring | Purpose changes, new vendors and the number of records to keep current |
| External legal or privacy review | Outside counsel or consultants, paid by engagement | Usually one-time, sometimes recurring | Novel bases, special category data, cross-border flows and regulator contact |
| Auditor sampling under a framework | Independent auditor or assessor, paid by the audited organization | Recurring at each audit cycle | Sample size set by the auditor, number of purposes and quality of records |
| Open-source tooling | Licence cost is usually nil, but integration, hosting and support are paid | One-time setup, recurring operation | Platform count, hosting model and whether tooling replaces spreadsheets |
Who owns the lawful basis decision and who prepares the evidence
The controller owns the lawful basis decision. Your organization must identify each processing purpose, select the Article 6(1) basis that fits it, and be able to justify that choice. This is an accountability duty, so it cannot be delegated to a vendor, a consultant or a software default. Your privacy, legal and business owners should agree the purposes and bases, record the reasoning, and revisit them when a processing activity changes.
- Purpose and basis selection: Decide the basis for each purpose, including whether legitimate interests requires a documented balancing test.
- Legitimate interest records: Write and approve the assessment that shows the interest, necessity and balancing for each relying purpose.
- Information to individuals: Make sure privacy notices state the purposes and legal basis, as Articles 13 and 14 require.
- Consent and rights design: Decide which processing depends on consent, since that choice also determines portability eligibility.
- Change control: Re-check the basis when a new purpose or recipient appears.
Before relying on any basis, confirm with your data protection officer or legal counsel that the chosen basis is documented and approved.
An implementation partner can prepare the systems and evidence that carry out your basis decisions. The partner does not choose the basis, decide whether a balancing test passes, or certify that processing is lawful. Work is normally scoped in writing before it starts, so the boundary between your decisions and the partner's technical work should appear in the statement of work.
- Processing register: Build and maintain a register that stores each purpose, its basis and its owner in a structured, queryable form.
- Tagging and metadata: Tag datasets, services and retention rules with the purpose and basis so downstream systems can enforce them.
- Consent flows: Implement consent capture, withdrawal and evidence logging where your decision requires consent.
- Evidence stores: Set up version-controlled repositories for assessments, notices and approvals, so changes are traceable.
- Operational support: Connect rights handling and portability workflows to the basis tags, and test that they behave as documented.
Ask the partner to name in writing which outputs are technical deliverables and which decisions remain with your team.
Independent assessment is not a GDPR requirement. The regulation requires no audit, attestation or certificate. Where a customer or contract asks for assurance, an independent auditor can test whether your records and systems match your stated bases. Supervisory authorities enforce the GDPR and may examine lawful basis decisions during an investigation. Certification under Article 42 is voluntary, is issued by accredited certification bodies or supervisory authorities for at most three years, and does not reduce the controller's or processor's responsibility.
- Voluntary certification: Article 42 schemes are optional and do not replace your own accountability.
- Assessor scope: Auditors test evidence against your stated bases; they do not set the bases for you.
- Regulator inquiries: Supervisory authorities can ask for records, assessments and notices during investigations.
- Contract assurance: Customers may request audit rights or independent reports, which should be defined in contracts.
- Cost and timing: Ask any assessor for a written scope, deliverables and fees before engaging.
Confirm with your legal counsel which assurance, if any, your customers or contracts actually require before commissioning an independent review.
Where lawful basis programs usually fall short
Most lawful basis problems are not legal puzzles. They come from defaults, missing records and notices that no longer match what systems do. The cards below cover the gaps assessors and regulators see most often, and each names the fix that closes it.
Consent used for everything
Teams often pick consent because it feels safest, then attach it to processing that has a stronger basis such as contract or legal obligation. Consent can be withdrawn, and withdrawal then has to be honored, which a payroll or invoicing process cannot easily do. The fix is to assign the basis per purpose and reserve consent for optional processing, such as marketing, where Article 7 conditions can be met. Check whether the consent banner covers processing that would continue regardless of the answer.
Legitimate interests claimed without assessment
Relying on Article 6(1)(f) requires a documented balancing exercise, not just a statement that the controller has a business reason. The EDPB's Guidelines 1/2024 on legitimate interest describe three cumulative conditions: a clearly articulated and real interest, necessity, and a balance against the individual's interests. The fix is a written legitimate interest assessment per purpose, kept with the record of processing. Ask whether anyone can show the test was done before the processing started.
Lawful basis not recorded in systems
A basis agreed in a policy document rarely reaches the database, the CRM or the analytics pipeline. Without a field that stores the basis for each processing activity, teams cannot tell which requests trigger portability under Article 20(1) or objection under Article 21(1). The fix is to tag each dataset, workflow or processing record with its purpose and basis, then use those tags to route rights requests. Confirm that a data subject request can be filtered by basis without manual review.
Privacy notices out of step with practice
Articles 13(1)(c) and 14(1)(c) require the notice to state the purposes and the legal basis. Notices often list a basis that no longer matches what the product does, for example stating consent when a new feature processes data under contract. The fix is to review notices whenever a feature ships and to compare the stated basis with the basis recorded in the system. Ask who signs off a notice change and whether it is tied to release management.
No review when a new purpose is added
A new use of existing data, such as training a model or sharing logs for fraud analytics, is further processing. Article 6(4) requires a compatibility check that considers the link between purposes, the context, the data's sensitivity and the safeguards available, including encryption or pseudonymisation. Teams often skip this because the data is already held. The fix is a change gate in product work that asks for a purpose and basis record before any new processing starts.
Public authorities relying on legitimate interests
Article 6(1)(f) cannot be used by public authorities for processing carried out in performing their tasks. Public bodies sometimes adopt it anyway for convenience, which leaves the processing without a valid basis for those tasks. The fix is to map each task to a public task or legal obligation basis under Article 6(1)(e) or (c), and to confirm that the legal foundation exists in national law. Vendors serving public bodies should ask customers which basis they have documented before building features on it.
Questions buyers ask about Article 6 before hiring help
How long does recording lawful bases take, and what drives the effort?
The effort depends mainly on how many processing purposes the organization runs and how many systems hold personal data for each one. Recording a basis for a single application with a handful of purposes is a small exercise, while a group with dozens of systems, shared databases and several legal entities needs an inventory first. The main drivers are the quality of the existing record of processing, whether purposes are already written down, how many legitimate interest assessments must be written, and how many consent flows need to be checked. Ask any provider to break the quote into inventory, mapping, legal review and engineering changes, and to say which of these the client's own staff must do.
Can our team record lawful bases in-house without outside help?
Often yes, provided someone accountable for privacy has the authority to decide the basis for each purpose and the engineers can show where data flows. The organization owns the decision, because only the controller can choose and justify a basis. Outside help is most useful for building the inventory quickly, challenging weak legitimate interest reasoning, or wiring the basis into systems and logs. Internal teams usually struggle with purposes that were never documented, with data reused across products, and with consent records that sit in a separate tool. An implementation partner can prepare the technical records, but a qualified legal or privacy function still decides the basis.
What does Article 6 work need from legal and engineering teams?
Legal and privacy staff need to define each processing purpose, select the lawful basis, and document why it applies. Engineering needs to show which systems process the data, which fields are involved, and how the basis can be stored and read by other services. The two teams must agree on a shared purpose identifier so that a request, export or deletion job can check the basis before acting. Engineers should also confirm how further processing is handled, since Article 6(4) compatibility checks depend on what the data is later used for. Expect legal time for the decisions and engineering time for the data map, the record schema and any changes to consent or objection workflows.
Does every processing activity need consent captured and evidenced?
No. Consent is one of six lawful bases in Article 6(1), and it is the right basis only for some purposes. Where the basis is a contract, a legal obligation, vital interests, a public task or legitimate interests, the organization does not need to collect a consent record. Systems should still record the basis for every purpose so that the organization can show which rule applies. Where consent is the chosen basis, the conditions in Article 7 apply, including the ability to demonstrate that consent was given and to withdraw it. Recording consent for purposes that rely on another basis can cause confusion and may imply a condition that does not exist.
How does the chosen lawful basis affect portability and objection?
The basis decides which rights a person can use. Data portability under Article 20(1) covers processing based on consent or contract that is carried out by automated means, so a system holding data under a legal obligation or a public task falls outside it. The right to object under Article 21(1) covers processing based on Article 6(1)(e) or (f), which means public tasks and legitimate interests. If the basis is recorded wrongly, a request may be refused when it should be honored, or accepted when no right applies. Engineers should therefore link each data store and export job to the recorded basis so that request handling follows the rule automatically.
Is a legitimate interest assessment mandatory when relying on legitimate interests?
The GDPR does not use the phrase legitimate interest assessment, but relying on Article 6(1)(f) requires the controller to show three cumulative conditions. The interest must be lawful, clearly articulated and real and present. The processing must be necessary for that interest. The controller must also show that the interests or rights of the individual do not override it. The EDPB Guidelines 1/2024 on legitimate interest describe these conditions, and the controller needs written evidence to show them. Practically, a written assessment is the normal way to meet this duty and to demonstrate accountability. Public authorities cannot rely on legitimate interests for tasks they carry out as public bodies.
Will an auditor certify Article 6 compliance for us?
No. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary and does not reduce the controller's responsibility. An independent auditor or certification body can test a control, but it does not issue a finding that the lawful basis is correct under Article 6. Supervisory authorities enforce the rule, and the organization must be able to demonstrate its choices if asked. Buyers should ask a provider to prepare the records, data maps and system evidence, and to state clearly that the organization's privacy function owns the decisions. Any statement that a vendor or consultant has certified the basis should be treated with caution.
What may change: pending GDPR amendments and enforcement rules
As of October 2026, the GDPR text has not been amended, so the lawful bases in Article 6 and the rights they trigger are the ones your systems must support today. Two proposals could change the surrounding rules. The Omnibus IV proposal (COM(2025) 501) has a text agreed in interinstitutional negotiations on 26 June 2026 and is waiting for Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837) is awaiting a committee decision. Neither has changed Article 6 as a binding rule, but a negotiated text can move before it becomes law, so treat any draft wording as provisional.
Regulation (EU) 2025/2518 is the more immediate change for enforcement. It sets additional procedural rules for complaints and investigations in cross-border cases and applies from 2 April 2027. It does not alter which lawful basis a processing purpose needs, but it affects how a supervisory authority will request evidence when a cross-border complaint concerns your legitimate interest assessments, consent records or the basis you stated in your privacy notices. Records that show which basis you chose for each purpose, and when, will matter more once those procedural rules apply.
Before you rely on any change, confirm its status yourself. Check the procedure files on the European Parliament Legislative Observatory) for Omnibus IV and the Digital Omnibus procedure, and read the adopted text of Regulation (EU) 2025/2518 on EUR-Lex. Ask your legal counsel or DPO to record the date you last checked and which version of the text your lawful basis register relies on. An implementation partner can help set up that review step, but the decision about which basis applies stays with your organization.
How DeployOpen prepares lawful basis evidence in your environment
This sequence turns the lawful basis decisions your organization makes into a recorded, versioned and retrievable set of evidence inside your own self-hosted platforms. Your organization owns each decision throughout, and DeployOpen prepares the systems and records that show them.
Agree the scope and ownership in writing
Your organization and DeployOpen agree in writing which systems, processing activities and business units are in scope, and who is responsible for each part. Your legal, privacy and business owners remain responsible for every lawful basis decision, and DeployOpen does not choose or validate bases on your behalf. The step closes when the signed scope lists the platforms, the processing purposes covered and the named decision owners.
Inventory processing purposes and current bases
Your privacy owners list each processing purpose handled by the in-scope systems and state the Article 6(1) basis they rely on, or flag where none has been decided yet. DeployOpen helps gather the purposes from system configurations, data flows and existing documentation so the inventory matches what the software actually does. The step closes when every purpose has a named owner and a basis status, even if some are marked as still under review.
Confirm the decision record for each basis
For each purpose, your organization records the basis decision, the reasoning behind it and the date it was made, with any supporting assessment such as a legitimate interests assessment where one applies. Where legitimate interests is relied on, the record should follow the three cumulative conditions in EDPB Guidelines 1/2024. The step closes when every decision has a documented rationale that an assessor can read without asking the author.
Implement basis tagging in self-hosted platforms
DeployOpen configures the self-hosted platforms in your infrastructure so each processing purpose carries its recorded basis as a field or tag in the system of record, and so that consent-based and contract-based processing can be identified for portability. Where a platform does not support this natively, the approach is agreed with you before build, and any custom code is documented and placed under version control. The step closes when a sample of records from each in-scope system shows the correct basis tag and the change history is retained.
Capture and evidence consent where it applies
Where your basis is consent, DeployOpen prepares the capture points, consent records and withdrawal mechanisms in the in-scope platforms so you can show who consented, to what purpose and when. Your organization owns the wording, the timing and the decision that consent is the right basis. The step closes when test records can be retrieved for a given data subject and purpose and withdrawal is reflected in downstream processing.
Link bases to notices and rights handling
DeployOpen checks that the purposes and bases recorded in your systems match the information given to data subjects, and that the rights workflows read the basis so that portability and objection requests are routed correctly. Your privacy team approves the notice text and the routing rules. The step closes when a walkthrough of sample purposes confirms the notice, the record and the request workflow agree.
Hand over evidence and set up upkeep
DeployOpen delivers the configuration records, change history, test results and operating notes that show how the bases are recorded and used, stored in a location you control. If you want continued support, a retainer can cover upkeep, reviews when processing changes and updates to the platforms. Independent auditors and supervisory authorities, not DeployOpen, assess this evidence, and DeployOpen does not issue reports or certificates. The step closes when you have accepted the handover in writing.
