Article 7 Conditions for consent: requirements and evidence

What Article 7 requires for consent records and withdrawal

Article 7 asks your systems to do four things when processing relies on consent: let you demonstrate that each person consented (Article 7(1)), present the request separately from other terms and in plain language, let people withdraw at any time, and make withdrawal as easy as giving consent (Article 7(3)). Consent must not be bundled with access to a service, so a person should not be refused an account or feature because they declined a processing purpose that the service does not need. The fine ceiling for breaching these conditions is EUR 20 million or 4% of total worldwide annual turnover, whichever is higher (Article 83(5)(a)). The GDPR requires no audit or certificate, and certification under Article 42 would not transfer responsibility away from you. The controller remains accountable for every consent flow it runs.

The difficulty is usually architectural. Consent is often captured by a banner, a preference center or a sign-up checkbox built by a front-end or marketing team, while the backend stores only a flag, or nothing. When a regulator or customer asks for proof, nobody can show the wording shown on a given date, the version of the notice the person saw, or the path that recorded the choice. The EDPB's Guidelines 05/2020 on consent (version 1.1) expect a record of each consent statement showing how and when consent was obtained, the information presented at that time and the workflow used. Pointing to a correctly configured website is not enough. Before you rely on consent, map every consent point to its wording version, store that record alongside the processing purpose, and confirm the export format with your legal team.

Start with three checks. First, list each purpose that depends on consent and confirm that no access to the core service is conditional on accepting it, since the EDPB treats cookie walls as inconsistent with freely given consent. Second, test withdrawal end to end: if giving consent takes one click, withdrawal should not require a letter, a call or a longer journey, and the change must reach every downstream system, including analytics and marketing tools. Third, confirm retention for consent records themselves, because they are personal data too. Self-hosted platforms can help keep these records in your own environment. Audit logs and version history can show who changed a notice and when, but you should confirm each product's behavior in your configuration before treating it as evidence.

Which consent-based processing Article 7 covers

Article 7 applies only where consent is the lawful basis, so the first scoping step is confirming which processing actually relies on it. Once that is settled, the work spreads across front-end collection points, the records that prove consent, the processors that hold those records, and any special category data that needs explicit consent.

Web and app consent banners

Cookie and tracking banners on websites and inside mobile apps are where most consent requests are made. Each banner must show the choice before any non-essential storage or tracking starts, and each accept, reject and settings action must be logged with the banner version and the text shown at that moment. Check that rejecting is as simple as accepting, and that no access to content depends on accepting. Ask engineering to confirm which scripts load before the choice is recorded.

Preference and consent centers

Preference centers let people change or withdraw consent after the first decision, so they are the main place where Article 7(3) withdrawal is tested. Each purpose should appear as a separate toggle with plain wording, and withdrawing should take no more steps than giving consent did. Confirm that a change in the center updates every downstream system, not only the screen the user sees, and that the change itself is recorded.

Marketing and newsletter sign-ups

Newsletter forms, event registrations and marketing opt-ins are consent-based in most organizations, and they often sit in separate tools from the core customer database. Each form needs its own unticked, specific request, and the consent statement should be stored with the form version and timestamp. Review whether a single sign-up form bundles marketing consent with a purchase or account, because bundling undermines whether consent is freely given.

Research and pilot programs

Surveys, user studies and pilot programs often rely on consent that is requested inside a product or through a recruitment form. Participants should receive information about the purpose, the data kept and the right to withdraw before they agree, and withdrawal should stop further collection and trigger the defined handling of data already gathered. Ask who owns the consent form for each study, since these are often created outside the main platform team and never reviewed.

Third-party tags and consent-dependent integrations

Analytics, advertising pixels and embedded widgets may read or write data on a user's device only after consent. Tag managers and consent management tools must block these scripts until the relevant choice is recorded, and they must stop them when consent is withdrawn. Confirm which vendors act as processors and which as independent controllers, and whether each vendor receives the consent signal in a form it can act on.

Lawful basis, special category data and record holders

Before any of the above is built, confirm with counsel that Article 6 points to consent for each purpose, since other bases carry different rights and evidence duties. If health, biometric or other special category data is involved, Article 9 generally requires explicit consent, which raises the bar for the request and its record. Map every processor and sub-processor that stores consent records, because the controller still has to produce them on request.

How an assessor tests consent records and withdrawal

This table sets out the test steps a supervisory authority or independent assessor typically follows for consent-based processing, the evidence each step asks for, and the findings that most often fail. Read each row as a question the assessor will put to the system team, and use the last column to prepare the matching evidence before any review starts.

Assessor test	What the assessor checks	Evidence requested	Common findings
Sample consent records	Draws a sample of consents and matches each one to the notice text, version and purpose shown at the time of consent	Consent log entries with timestamp, notice version, purpose and collection channel	Records hold only a yes flag with no link to the wording shown
Match notice to record	Confirms the stored notice text is the text the person actually saw in that journey and period	Versioned notice archive and release history for consent screens	Notice text overwritten in place, so past versions cannot be reproduced
Separate request check	Confirms consent is asked separately from terms of service, marketing acceptance and other agreements	Screenshots or staging captures of each consent screen and its position in sign-up flows	Consent bundled into general terms or a single accept-all button
Plain-language review	Reads the request as a data subject would and checks it names purpose and controller in clear terms	Copy deck with reading level notes and sign-off by the controller	Long, technical or vague wording that hides the purpose
Default state check	Confirms no box is pre-ticked and the person takes a clear affirmative action	Interface configuration and test recordings of the opt-in step	Pre-ticked boxes or consent inferred from scrolling or continued use
Withdrawal path walkthrough	Follows the withdrawal route from the start and counts the steps and screens needed	Recorded walkthrough of the withdrawal path with step count and entry points	Withdrawal buried in account settings, or available only by email or post
Timing comparison	Compares the time and effort to withdraw with the time and effort to give consent	Side-by-side timed test of giving and withdrawing consent, using the same account type	Giving consent takes one click while withdrawal needs several screens or a support call
Access not conditional on consent	Checks that refusing consent does not block the service, or block functions the service does not need	Test cases for refusal paths, including cookie or tracking refusal	Cookie walls or features locked until consent is given
Withdrawal effect check	Confirms that withdrawal stops the processing and the system records it	Logs showing the withdrawal event and downstream processing stopped	Withdrawal recorded in the interface but processing continues in batch jobs
Consent workflow record	Reviews the documented workflow that shows how consent was obtained, recorded and withdrawn	Workflow diagrams, change history and access logs for consent records	Only a reference to a correct website configuration, with no record of the workflow

How to build consent capture and withdrawal in order

This sequence turns Article 7 into working system behavior: each consent purpose is inventoried, its wording is versioned, a demonstrable record is stored, processing is gated on that record, and withdrawal is built and tested as carefully as consent itself.

Inventory every consent-based processing purpose
The privacy lead and product owners list each processing purpose that relies on consent rather than another Article 6 basis, and record the systems, data stores and processors involved in each. Consent only applies where the controller has chosen it as the basis, so the inventory must come first and must be checked against the record of processing. Output: a consent register with one row per purpose, the owning system and the named accountable owner. Confirm the list with legal review before any build work starts.
Define the consent statement and notice version
For each purpose in the register, legal and product write the consent statement and the information shown beside it, including the controller's identity, the purpose, the data involved and the right to withdraw. The wording must be specific, plain and separate from terms of service. Each approved text receives a notice version identifier. Output: final notice texts stored in source control or a wiki with version history, so you can show exactly what a person saw on a given date.
Design the separate request and affirmative action
Designers and developers build a request for each purpose that is unticked by default, does not bundle purposes together, and requires a clear active step such as a button press or a checkbox the user sets. The request must not be a precondition for an unrelated service, and it must not be hidden in a cookie wall. Output: approved interface mock-ups and a test checklist confirming that each purpose has its own control and that declining does not block access to features that do not need that purpose.
Build the consent record store
Engineers create a consent store that writes one record each time consent is given or withdrawn. Each record holds a pseudonymous subject identifier, the purpose, the decision, a timestamp, the notice version, the workflow or interface version that displayed the request, and the channel used. Records are append-only so history is not overwritten. Output: a documented record schema, the database or service migration files, and a sample export that shows an audit trail for one test subject.
Gate processing on the consent record
Developers make each consent-based processing job check the consent store before it runs, using the most recent record for the subject and purpose. If no valid record exists or the latest decision is a withdrawal, the job must skip that data. Gating belongs in code paths that are reviewed and tested, not in a front-end flag alone. Output: code review records and automated tests showing that processing is blocked without consent and resumes only after a new valid record is written.
Build withdrawal with the same number of steps
Developers add a withdrawal control next to each consent control, reachable from the same settings area or notice, and require no more steps than giving consent. Withdrawal writes a new record to the consent store, stops the gated processing, and shows the user a confirmation. The information about the right to withdraw must appear before consent is given. Output: a side-by-side click path comparison for each purpose, and a confirmation screen text approved by legal.
Propagate withdrawal to processors and sub-processors
Operations and integration owners map every system and processor that received data on the basis of consent, then define how a withdrawal reaches each one, such as a message on an internal queue, a scheduled sync or a deletion request under the processing agreement. Each propagation path has an owner and a confirmation step. Output: a propagation map with the mechanism, owner and last successful test for each downstream system, kept with the processor contracts.
Test the workflow and retain the evidence
QA and privacy staff run scripted tests for each purpose: giving consent, declining, withdrawing, checking that gated processing stops, and confirming that downstream systems received the withdrawal. They also review the stored records against the notice versions. Failed tests are logged and fixed before release, and the test runs repeat after changes to interfaces or notices. Output: dated test reports, the reviewed record samples and a sign-off by the accountable owner. An independent assessor would review this evidence, but the organization owns the controls and the conclusions.

Which consent evidence passes and how to keep it current

Article 7(1) puts the burden on the controller to demonstrate consent, and the EDPB's guidance on consent expects the record to show how, when and under which wording consent was given. The cards below cover the artifacts an assessor or supervisory authority is likely to ask for, and the open-source tools that can hold them inside your own infrastructure.

Consent record per data subject

Each consent event should be stored with the data subject identifier, the purpose covered, the timestamp, the method used and the version of the notice shown. The EDPB guidelines describe this as a record of how and when consent was obtained. Check that the record survives account changes and that it can be exported for a single person without exposing other people's data. Consent records are personal data themselves, so confirm where they are stored and who can read them.

Archived text and layout of each request

Keep a copy of the exact consent text, checkbox labels, links and layout as displayed for every version that went live. A description of the intended design does not show what a user saw. Store screenshots or rendered templates alongside the version identifier so that an assessor can match a consent record to the wording in force on that date. Confirm that the archive captures the information provided before consent, as Article 7(3) requires for the withdrawal right.

Version history of the consent workflow

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back. That gives you a change history for notice and workflow text. Pair it with a documented approval step so that each published version traces to a named approver. Confirm with your team that wording stored in the wiki is the wording deployed in production, since version control in the wiki does not prove what the live banner showed.

Role-based approval of consent wording

BookStack derives each user's abilities from assigned roles, and permissions can be overridden per role at shelf, book, chapter or page level. Use this to separate who drafts consent wording from who may approve and publish it. Restricting edit rights on the approved notice pages limits unreviewed changes. Test the permission model with a sample user from each role before relying on it, and confirm that the chosen override levels match your approval design.

Administrative event logs

The Nextcloud admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Use it to show who changed consent-related settings or shared folders that hold consent exports. Set the log path deliberately and restrict access to it, because the log itself contains personal and administrative data. Confirm that the events you need to evidence are covered by the app's logging before you treat it as the audit trail for consent administration.

API audit logs for the consent service

If a secrets store or consent service sits behind an API, OpenBao audit devices keep a detailed JSON log of every request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This records who called the service and when, which supports withdrawal evidence. Confirm that the hashing covers every field you would otherwise have to protect, and that the log destination is itself protected and retained for the period your policy sets. Check the MPL-2.0 license terms against your distribution plans.

Withdrawal and change records

Withdrawal must be as easy as giving consent under Article 7(3), so the evidence should show that a withdrawal was recorded, when it took effect and that processing stopped. Keep a withdrawal log linked to the original consent record, and a change record for each banner or form release that explains why it changed. Test withdrawal end to end with a timed walkthrough, and retain the test result. Check the licence terms for each open-source component you use, including LGPL-2.1-or-later for XWiki, MIT for BookStack and AGPL-3.0-only for Nextcloud, with your legal team.

What Article 7 consent compliance costs in money and effort

This table breaks down the cost components of building and running consent-based processing under Article 7, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a written quote and to see where open-source components save license spend without removing engineering effort. No figures are given because none were supplied; request them from each provider and from your own scope.

Cost component	Who is paid and for what	One-time or recurring	What drives it up or down
Consent management tooling or self-hosted licenses	Commercial vendor license, or none for open-source components; you still pay for hosting and operations	Licenses usually recur; open-source removes license spend only	Number of processing purposes and channels; a single consent service keeps this lower
Engineering to build capture, records and withdrawal	Internal developers or an implementation partner building consent screens, consent logs and withdrawal paths	One-time build, with recurring fixes	Number of products and channels; reuse of one consent service across products lowers it
Legal and product time to write notices	Counsel, privacy lead and product owners drafting plain-language requests and withdrawal text	One-time drafting, recurring revision	Number of purposes and languages; versioned notices make revisions cheaper
Ongoing evidence upkeep as wording changes	Engineering and compliance staff keeping consent versions, timestamps and the information shown at the time of consent	Recurring	Frequency of copy changes; each change needs a new recorded version, so fewer, planned changes lower effort
Third-party tags and scripts review	Engineering and privacy staff checking that vendor tags do not load before consent	One-time review, recurring on every new tag	Number of third-party tags and marketing integrations; fewer tags lower review load
External review of consent flows	Independent privacy or legal reviewer testing flows, wording and withdrawal in practice	Typically periodic	Scope of flows reviewed; a defined scope in a fixed-scope written agreement keeps it bounded
Auditor or assessor sampling time	Independent auditor or certification body sampling consent records during an assessment, where one applies	Recurring per assessment cycle	Number of consent records sampled and how easily records are retrieved; complete, indexed logs shorten sampling
Ongoing support and retainers	Implementation partner or internal team for upgrades, fixes and monitoring of consent components	Recurring	Frequency of platform upgrades and the number of components; a written support scope defines what is covered

Where consent implementations usually fall short

Consent failures under Article 7 rarely come from a missing banner. They come from how the system stores the choice, where the request sits in the user journey, and whether a withdrawal actually reaches the systems that keep processing. The cards below cover the gaps assessors and regulators most often find, with the fix for each.

Single boolean with no notice version

A user table column such as marketing_consent set to true tells you nothing about what the person saw. Article 7(1) requires the controller to demonstrate consent, and the EDPB's guidance on consent expects records showing how and when consent was obtained and the information presented at the time. Store each consent event with the purpose, the wording or notice version, the timestamp, the collection channel and the workflow version. Check that you can reproduce the exact text shown to any given user.

Consent bundled into terms of service

Forms that accept the terms and the optional marketing or profiling purpose in a single tick box do not give consent that is specific or freely given. Article 7(2) requires the request to be clearly distinguishable from other matters and in plain language. Split each optional purpose into its own unticked control, keep acceptance of the terms separate, and confirm that declining an optional purpose does not block account creation.

Withdrawal requiring a support ticket

If giving consent takes one click but withdrawing it means emailing support and waiting, Article 7(3) is not met. Withdrawal must be as easy as giving consent, and the person must be told this before consenting. Put a withdrawal control in account settings and any consent banner, use the same interaction pattern as the grant, and test the path end to end. Record the withdrawal as its own event with a timestamp.

Cookie walls blocking service access

Making a site or feature unavailable unless the visitor accepts storage on the device is a cookie wall. The EDPB's guidance says consent obtained this way is not freely given. Review each entry point, including login, checkout and downloads, to confirm that refusing non-essential storage still lets the user reach the core service. Document which storage is strictly necessary and which requires consent.

Withdrawal not propagated downstream

A withdrawal that only updates the consent flag leaves processing running. Analytics tags, marketing platforms, email tools and processors may keep receiving the person's data. Article 7(3) gives the person the right to withdraw, and the controller must then stop the processing that relied on consent. Maintain a map of which systems and processors rely on each consent purpose, send withdrawal events to each one, and retain evidence that each downstream system acknowledged the change.

No record of consent workflow changes

Forms, wording and default settings change over time, often through a release that no one logs. When a consent journey changes, earlier consents may no longer match the information shown. Keep the consent wording, layout and logic under version control with a named owner and approval step, so you can show which version applied to which consent period. Review access to the consent configuration and log who changed it.

In-house or partner: who does what for consent

Your organization owns the decisions that make consent lawful in the first place. That starts with the processing purposes, the lawful basis for each purpose under Article 6, and the decision to rely on consent rather than another basis. It also covers the consent wording, the layout of each request, and which services, if any, depend on the choice. These are legal and business judgments, and they belong to the controller because the controller answers to supervisory authorities for them.

Purpose and basis decisions: Record which purposes need consent and why other bases do not fit.
Consent wording: Approve plain-language text, separate requests per purpose, and the information given before consent.
Withdrawal design rules: Decide that withdrawal must be as easy as giving consent and that no service is bundled with consent.
Retention of consent evidence: Set how long consent records are kept and who may access them.
Sign-off: Keep a dated approval of each consent flow and each change to its wording.

Before relying on consent, confirm internally that someone with authority has approved every purpose and its text in writing.

Questions buyers ask about Article 7 consent work

How much effort does a consent workflow take, and what drives it?

The effort depends on how many processing purposes rely on consent, how many channels collect it, and how many systems store or act on it. Each consent-based purpose needs its own request, a stored record of what the person saw and agreed to, a way to withdraw that is as easy as giving consent, and a check that processing stops after withdrawal. Costs come from three places: the discovery work to find every consent point, the build or configuration of the consent and preference store, and the testing that proves withdrawal works across systems. Ongoing costs come from changes to wording, new purposes and periodic evidence reviews. Ask any quote to list each consent purpose, each collection point and each downstream system in writing, because those lists set the size of the work.

Can our team build Article 7 consent controls in-house?

Yes, many teams can, provided they have engineers who can change the collection points and a legal owner who signs off on the wording and the purposes. The harder part is usually not the code but the evidence: showing what a person was told at the time, which version of the notice applied, and how withdrawal propagated. Internal teams often underestimate the number of places consent is read, such as marketing tools, analytics, support platforms and backups. An outside implementation partner can help with discovery, configuration and testing of self-hosted systems, but the organization remains responsible for its consent decisions and wording. Only an independent auditor or certification body issues reports, so an outside partner cannot certify the result.

How long does the Article 7 consent work take?

The schedule is set by the scoping and testing steps rather than a fixed duration. A typical sequence runs through inventory of consent purposes and collection points, mapping of data flows to downstream systems, design of the consent record and withdrawal path, implementation, and then testing that withdrawal stops processing in every system in scope. Each step depends on how many systems are involved and how quickly decisions are made about wording. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for a written timeline that names each step, the owner of each decision and the test evidence that closes the work.

What do legal, product and engineering each need to contribute?

Legal owns the lawful basis analysis for consent, the wording of each request and the information given before consent, including the right to withdraw. Product owns the user journeys, such as where the request appears, whether a service is bundled with consent and how preferences are managed. Engineering owns the consent record, the storage of version and timestamp, the withdrawal mechanism, and the propagation of withdrawal to processing systems. Security and privacy leads should review access to consent records and how they are logged. Confirm early who signs off on each decision, because unclear ownership is a common cause of delay. A partner can prepare the technical side, but the decisions on wording and purposes stay with the organization.

Can open-source tools hold the evidence for consent?

Open-source tools can hold parts of the evidence, but no single tool proves Article 7 compliance on its own. Wiki and document platforms such as XWiki keep version history of a page, recording what changed, when and by whom, which helps show which version of a notice was in force. Nextcloud's admin_audit app writes additional event information to audit.log, which can support review of access to systems that store consent data. OpenBao audit devices keep a detailed JSON log of API requests and responses with most sensitive values hashed, which can help show who changed consent-related secrets or configuration. Confirm each platform's logging scope and retention in your environment, and design the consent record itself so it captures the wording, the version, the time and the method of collection.

Does any certificate prove that we comply with Article 7?

No certificate proves Article 7 compliance. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities. Even where a certification exists, it does not reduce the controller's responsibility for compliance. Supervisory authorities judge consent on the facts, including whether the consent was specific, informed and freely given, and whether the organization can demonstrate it. Ask any provider which evidence they will produce for your own consent flows and how a supervisory authority would be able to review it. Any quote should follow a written scope that names the purposes, systems and deliverables covered.

How DeployOpen works on this

DeployOpen plans and builds the technical side of consent evidence for Article 7 Conditions for consent inside your own infrastructure, on self-hosted open-source platforms. We prepare systems and records; your organization owns the consent decisions, and an independent auditor or assessor reviews them.

How we scope

Map every processing activity that relies on consent and confirm which systems store the consent records.
Agree in writing which consent statements, versions and withdrawal paths are in scope before work starts.
Confirm with your legal and privacy team which consent wording and information must be shown at the time of consent.

How we build

Configure wiki and documentation platforms to keep versioned copies of consent wording and policy pages.
Set role-based access so only authorized staff can change consent texts and withdrawal procedures.
Enable audit logging for consent-related administrative actions and store logs in a location you control.

How we hand over

Deliver a written evidence pack showing how each consent workflow records when and how consent was obtained.
Document the withdrawal procedure step by step so staff and reviewers can reproduce it.
Provide test records and runbooks so your team can repeat the checks after handover.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask us for a quote based on your written scope, since DeployOpen does not publish a price list.