Article 7: Conditions for consent

To meet GDPR Article 7 (Conditions for consent), you must be able to prove—on demand—that each person actually consented to the specific processing you rely on consent for, and that your process captures auditable records of that consent. Operationalize this by standardizing consent capture, logging, retention, and retrieval across every system and third party touchpoint where consent is your legal basis. (Regulation (EU) 2016/679, Article 7)

Key takeaways:

• Build a consent evidence trail: who consented, to what, when, how, and what they were shown at the time. (Regulation (EU) 2016/679, Article 7)
• Scope first: map the processing activities where consent is the legal basis and identify every system that collects or stores those signals. (Regulation (EU) 2016/679)
• Treat consent like an audit domain: controls, owners, testing, exceptions, and a fast retrieval path for regulators and DSARs. (Regulation (EU) 2016/679, Article 7)

Article 7 is a proof requirement. If you choose consent as your legal basis, you inherit an operational burden: you need defensible records that demonstrate the data subject consented to the processing of their personal data. Regulators and auditors do not accept “our website has a banner” or “our app has a checkbox” as evidence by itself; they look for traceability between the individual, the notice presented, the action taken, and the downstream processing that followed. (Regulation (EU) 2016/679, Article 7)

For a CCO or GRC lead, the fastest path is to treat consent like a controlled system of record with clear ownership: (1) scope all processing that depends on consent, (2) standardize how consent is collected, (3) centralize or federate consent logs with consistent fields, and (4) validate that every downstream system and third party respects those consent states. The practical risk is simple: if you cannot demonstrate consent, your legal basis can fail for that processing activity, which cascades into DSAR friction, customer trust issues, and supervisory scrutiny. (Regulation (EU) 2016/679, Article 7)

Regulatory text

Text (excerpt): “Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.” (Regulation (EU) 2016/679, Article 7)

Operator meaning (what you must be able to do)

You must be able to produce evidence—for a specific person and a specific purpose—that:

• you relied on consent for that processing, and
• the person took an affirmative action that you can link to the processing that followed, and
• you can retrieve that proof efficiently from the systems involved. (Regulation (EU) 2016/679, Article 7)

This is not a policy-only requirement. It is a system design and recordkeeping requirement that spans product UX, marketing ops, CRM, analytics, data engineering, customer support, and third party integrations. (Regulation (EU) 2016/679, Article 7)

Plain-English interpretation of the requirement

If you say “we process this data because the user consented,” you need receipts. Those receipts must survive real-world complexity:

• multiple collection channels (web, app, call center, in-person),
• consent that changes over time,
• different purposes (marketing vs. personalization vs. sharing),
• multiple systems and third parties that receive the data. (Regulation (EU) 2016/679, Article 7)

A practical test: can you pick any EU data subject in your environment and show a complete consent timeline that explains why you processed, shared, and retained their data for each consent-based purpose? If not, your Article 7 control is weak. (Regulation (EU) 2016/679, Article 7)

Who it applies to (entity and operational context)

Entities

• Controllers: This obligation is explicitly on the controller; the controller must demonstrate consent. (Regulation (EU) 2016/679, Article 7)
• Processors (operational impact): Even if the legal duty is on the controller, processors typically must support it contractually and technically by passing consent signals, honoring restrictions, and providing logs when requested. (Regulation (EU) 2016/679)

Operational contexts where Article 7 becomes “real”

• Consent-driven marketing (email/SMS, targeted ads, remarketing audiences)
• Optional product features (profile enrichment, personalization)
• Sensitive workflows where teams default to consent because it “feels safer”
• Data sharing to third parties where consent is used as permissioning logic
• Multi-tenant SaaS where your customer is the controller and you must preserve their consent instructions (Regulation (EU) 2016/679, Article 7)

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

Step 1: Decide and document scope (role-and-scope register)

Create a register that answers, per processing activity:

• Are you acting as controller or processor?
• What data categories are in scope?
• Which systems collect consent (web/app forms, CMP, preference center, call center tooling)?
• Which systems consume consent (ESP, CRM, CDP, analytics, data warehouse, ad platforms)?
• Which third parties receive personal data under a consent-based purpose? (Regulation (EU) 2016/679)

Deliverable: a role-and-scope register tied to your RoPA and system inventory. This prevents the classic failure mode: “we thought consent was handled by the banner.” (Regulation (EU) 2016/679)

Step 2: Define “consent evidence fields” as a minimum schema

Standardize the fields you will store for each consent event. Keep it simple and auditable:

• Data subject identifier (and identifier type)
• Purpose (specific processing purpose; avoid vague “marketing” if you operate multiple marketing purposes)
• Status (granted/withdrawn/updated)
• Timestamp (with time source)
• Collection channel (web/app/call center/import)
• Mechanism (checkbox, toggle, recorded call script, signed form)
• Notice/version presented (privacy notice ID and version, or consent text version)
• Source system and event ID
• If applicable: jurisdiction/locale and language presented (Regulation (EU) 2016/679, Article 7)

This schema is how you make “demonstrate consent” operational across heterogeneous tooling. (Regulation (EU) 2016/679, Article 7)

Step 3: Implement a consent system of record (SoR) and propagation pattern

Pick one of two defensible patterns:

• Centralized SoR: one service stores consent and downstream systems read from it.
• Federated with governance: multiple systems store consent, but all must conform to the schema and reconcile conflicts with a defined precedence rule.

Minimum control expectations:

• Immutable or tamper-evident logging for consent changes
• A clear “current state” per purpose per user
• An export/report function for audits and DSAR support
• Monitoring for integration failures (e.g., ad platform still receiving data after withdrawal) (Regulation (EU) 2016/679, Article 7)

Step 4: Translate consent into downstream enforcement

For each consent-based purpose, specify:

• What processing is allowed when consent = granted
• What must stop when consent = withdrawn
• What data must be deleted vs. suppressed vs. retained for other legal bases (where applicable)
• Which teams own enforcement in each system (marketing ops, data engineering, product) (Regulation (EU) 2016/679, Article 7)

Practical mechanism examples:

• CRM/ESP suppression lists driven by consent state
• Event collection gating in SDKs based on consent
• Data warehouse views that exclude non-consented data for certain analytics pipelines
• Third party audience sync jobs that check consent state at runtime (Regulation (EU) 2016/679)

Step 5: Create a requirement-specific operating procedure (SOP)

Write a short SOP that answers:

• What triggers a consent record creation/update (form submit, preference center update, support ticket)
• Who approves changes to consent text, UI, or preference flows
• How you test the end-to-end flow after product releases
• How you respond to “prove consent” requests (regulator inquiry, customer diligence, DSAR support escalation)
• How exceptions are handled (data imports with missing provenance; legacy systems) (Regulation (EU) 2016/679, Article 7)

This is where many programs fail: policy exists, but no one owns the workflow. (Regulation (EU) 2016/679, Article 7)

Step 6: Build an “evidence packet” cadence (audit-ready by default)

On a recurring cadence, generate and store an evidence packet:

• Sampled consent records showing required fields
• Change log of consent UI/text versions and approvals
• Integration test results (consent granted and withdrawn paths)
• Exception log and remediation tickets
• Third party data sharing list mapped to consent-based purposes (Regulation (EU) 2016/679, Article 7)

Tools like Daydream help by turning this into a repeatable control: assign owners, attach evidence, track exceptions, and answer diligence requests with a consistent packet instead of scrambling across systems.

Required evidence and artifacts to retain

Maintain these artifacts in an audit repository:

1. Consent inventory: list of consent-based processing purposes and systems in scope. (Regulation (EU) 2016/679)
2. Consent schema and data dictionary: required fields and definitions. (Regulation (EU) 2016/679, Article 7)
3. Consent logs (exportable): per-user, per-purpose event history with notice/version. (Regulation (EU) 2016/679, Article 7)
4. UI/notice versioning records: screenshots or rendered templates, release IDs, approval records. (Regulation (EU) 2016/679, Article 7)
5. SOP and RACI: named owners for capture, storage, propagation, and audit response. (Regulation (EU) 2016/679, Article 7)
6. Third party mapping: where consent-based data flows externally and how withdrawals propagate. (Regulation (EU) 2016/679)

Common exam/audit questions and hangups

Auditors and regulators tend to press on:

• “Show me proof of consent for this user for this purpose” and “show me what they saw.” (Regulation (EU) 2016/679, Article 7)
• “Is consent purpose-specific or bundled?” If you cannot separate purposes, you create defensibility issues for “specific” consent claims. (Regulation (EU) 2016/679)
• “How do you ensure third parties stop processing after withdrawal?” Expect follow-ups on technical enforcement, not contract language alone. (Regulation (EU) 2016/679)
• “What happens with legacy records where you lack provenance?” Your exception handling will matter. (Regulation (EU) 2016/679, Article 7)
• “Who can change consent text and what approvals exist?” (Regulation (EU) 2016/679, Article 7)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails Article 7	Fix
Treating the cookie banner/CMP as the only consent system	You may still collect consent elsewhere (forms, call centers), and you may not retain proof that ties to processing purposes. (Regulation (EU) 2016/679, Article 7)	Build a consent inventory and unify the consent evidence schema across channels.
Storing “consented = true” without notice version or purpose	You cannot demonstrate what the user agreed to. (Regulation (EU) 2016/679, Article 7)	Store purpose + consent text/notice version + timestamp + channel.
No withdrawal propagation testing	Data keeps flowing to downstream systems and third parties. (Regulation (EU) 2016/679)	Add release tests and monitoring for “withdrawn” events through critical integrations.
Using consent because the lawful basis decision wasn’t made	Consent becomes a crutch and expands evidence obligations. (Regulation (EU) 2016/679)	Force a lawful basis decision per processing activity; document it in the role-and-scope register.
Evidence scattered across teams and tools	You cannot respond quickly to “demonstrate consent” requests. (Regulation (EU) 2016/679, Article 7)	Maintain an evidence packet in a GRC system like Daydream with clear owners and retrieval steps.

Enforcement context and risk implications

No specific public enforcement cases were provided in the source catalog for this page, so this guidance focuses on what Article 7 requires and what supervisory reviews commonly test: demonstrability, traceability, and operating evidence. The risk is practical: if you cannot demonstrate consent, you may be unable to defend consent as your legal basis for that processing activity. (Regulation (EU) 2016/679, Article 7)

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

You asked for speed, but fixed timelines are rarely realistic across different stacks and org sizes. Use phased execution with clear exit criteria.

First 30 days (Immediate stabilization)

• Assign a single accountable owner for consent evidence (often Privacy + GRC jointly).
• Build the role-and-scope register for consent-based processing and identify “systems of truth” gaps. (Regulation (EU) 2016/679)
• Define the consent evidence schema and required fields; publish a data dictionary. (Regulation (EU) 2016/679, Article 7)
• Stand up an audit response playbook: where evidence lives, who pulls it, internal SLA.

Days 31–60 (Control build-out)

• Implement or formalize the consent system of record and propagation rules.
• Update collection points to capture notice/version and purpose.
• Add downstream enforcement in highest-risk destinations (marketing platforms, ad syncs, analytics).
• Draft the requirement-specific SOP and RACI; route for approval. (Regulation (EU) 2016/679, Article 7)

Days 61–90 (Operationalize and prove)

• Run end-to-end tests (grant and withdraw) and store results as evidence. (Regulation (EU) 2016/679, Article 7)
• Create the first recurring evidence packet and schedule the cadence in Daydream (or your GRC tool).
• Close legacy data exceptions: quarantine or document rationale and remediation plan.
• Train support and privacy ops on how to retrieve proof of consent for a specific user quickly.

Frequently Asked Questions

What does “demonstrate consent” mean in practice?

It means you can produce records linking a specific person to a specific consent decision for a specific purpose, including when and how it was captured. You also need enough context (like notice/version) to show what they agreed to. (Regulation (EU) 2016/679, Article 7)

Do we need a single consent database?

Not strictly, but you need a reliable system of record or a governed federated approach with consistent fields, reconciliation rules, and easy retrieval. If consent evidence is fragmented and inconsistent, you will struggle to demonstrate it on demand. (Regulation (EU) 2016/679, Article 7)

What if we have older users where consent history is missing?

Treat missing provenance as an exception that requires documented handling: stop using consent as the legal basis for that processing until you can re-collect consent or switch to another lawful basis after review. Keep an exception log and remediation plan as part of your evidence. (Regulation (EU) 2016/679, Article 7)

How detailed does the “purpose” need to be?

Detailed enough that you can connect the consent to the actual processing activity you perform and avoid ambiguity in audits. If one toggle covers multiple materially different processing activities, your ability to demonstrate consent for each one weakens. (Regulation (EU) 2016/679)

Does this apply to processors too?

The Article 7 obligation is on controllers, but processors commonly need to support it by preserving consent signals, honoring restrictions, and providing logs to the controller. If you are a processor, build your controls so you can evidence what instructions and consent states you received and applied. (Regulation (EU) 2016/679)

What evidence do auditors ask for first?

Usually a small sample: pick a user, show the consent event, show the notice/version, then trace that consent state into downstream systems and third parties. Prepare a repeatable “consent proof packet” so the answer is consistent across requests. (Regulation (EU) 2016/679, Article 7)