Article 7: Conditions for consent

To meet the article 7: conditions for consent requirement, you must be able to prove—at any time—that a specific person gave valid consent for a specific processing purpose, and that your systems honor that consent state across collection, downstream sharing, and retention. Operationalize this by implementing consent capture, immutable logging, and auditable reporting tied to each processing activity. (Regulation (EU) 2016/679, Article 7)

Key takeaways:

• Consent is not compliant unless you can demonstrate it with reliable records linked to the data subject and the processing purpose. (Regulation (EU) 2016/679, Article 7)
• The control is operational: consent needs to flow into your systems as an enforceable status, not a screenshot in a ticket. (Regulation (EU) 2016/679, Article 7)
• Audits focus on “show me” evidence: logs, timestamps, versioned notices, and end-to-end propagation to third parties.

Article 7 is where many consent-based programs fail during audits: teams can describe their banner, but cannot produce defensible evidence that a given data subject consented to a given processing use. The article 7: conditions for consent requirement is narrow but sharp: if you rely on consent as your legal basis, you must be able to demonstrate that consent exists for the personal data processing in question. (Regulation (EU) 2016/679, Article 7)

For a CCO, Compliance Officer, or GRC lead, the practical problem is governance and traceability. You need an answer to: “Which processing is consent-based, where is consent captured, where is it stored, how is it updated, and how do we prove it later?” You also need to ensure the organization does not default to consent in places where it cannot run strong operational controls (for example, offline collection channels, inherited datasets, or complex downstream sharing). (Regulation (EU) 2016/679, Article 7)

This page gives requirement-level implementation guidance: who must comply, how to build the operating procedure, what artifacts to retain, and how to be ready for regulatory inquiries and customer diligence.

Regulatory text

Excerpt (Article 7(1)): “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 interpretation (what you must be able to do)

If your record of processing (or real-world behavior) indicates that consent is the legal basis for a processing activity, you must be able to produce evidence that:

1. the data subject consented, and
2. the consent covers the specific processing you performed. (Regulation (EU) 2016/679, Article 7)

“Demonstrate” is an evidentiary standard. In practice, you need system records that survive staff turnover, tool migrations, and third-party handoffs.

Plain-English requirement summary

The article 7: conditions for consent requirement means: if you say consent is your permission to process personal data, you must be able to prove it with records that link a person to a consent choice and to what they agreed to. (Regulation (EU) 2016/679, Article 7)

Consent evidence should be:

• Specific: tied to a purpose or processing use, not a vague “marketing: yes.”
• Attributable: tied to an identifier you can map to the data subject record.
• Time-bound: includes when consent was captured and what notice/version was shown.
• Operationalized: drives actual system behavior (send, share, profile, retain) based on the current consent state.

Who it applies to

Entities

• Controllers: This is a controller obligation: the controller must demonstrate consent when consent is the legal basis. (Regulation (EU) 2016/679, Article 7)
• Processors (operationally impacted): Even when you are a processor, you will often be asked to support the controller’s demonstration with logs, configuration evidence, and data lineage. Your contracts and technical design should anticipate this support need. (Regulation (EU) 2016/679)

Operational contexts where Article 7(1) gets tested

• Web and mobile consent flows (cookie/SDK toggles, preference centers, account sign-up checkboxes).
• Lead capture and events (QR codes, badge scans, partner lists).
• Customer communications (email, SMS, push notifications) where consent is used as the justification.
• Sharing with third parties (adtech, analytics providers, CRM platforms) where consent must be passed and respected.

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

Use this as a build plan for a consent-based processing inventory and evidence program.

Step 1: Decide scope and roles for each processing activity

Create a role-and-scope register for consent-based processing:

• Processing activity name
• Controller vs. processor role
• Data categories
• Systems involved (collection, storage, activation)
• Consent capture points (UI, API, offline)
• Purposes requiring consent
• Downstream recipients (including third parties) (Regulation (EU) 2016/679)

Why auditors care: you cannot “demonstrate consent” consistently if you cannot point to where consent is captured and where it must be enforced.

Step 2: Define what counts as acceptable consent evidence in your environment

Write a requirement-specific operating procedure that sets minimum evidence fields. A practical “consent receipt” record typically includes:

• Data subject identifier (internal ID, email hash, device ID, or another stable link)
• Purpose(s) consented to (use a controlled list)
• Consent status (granted/denied)
• Timestamp and time zone
• Capture channel (web, app, call center, event import)
• Notice/version shown at capture
• Source system and record ID
• If applicable, the mechanism (checkbox, toggle, API parameter) (Regulation (EU) 2016/679, Article 7)

Your procedure should also assign owners:

• Product/marketing owner for UX and copy changes
• Engineering owner for logging and propagation
• Privacy/compliance owner for purpose taxonomy and approvals
• Vendor management owner for third-party enablement

Step 3: Implement consent capture controls at the point of collection

Operational controls you can test:

• Consent choices are affirmative and recorded (no silent defaults in the data model).
• Consent cannot be created without required fields (purpose, timestamp, notice version).
• Back-end validation rejects malformed “consent granted” events.
• Consent capture works for anonymous and logged-in states, with a documented reconciliation method when identities merge.

Practical test: pick a single user journey (signup + newsletter). Walk it end-to-end and confirm you can retrieve the consent record without asking an engineer to “query prod manually.”

Step 4: Centralize consent state and propagate it to processing systems

Consent must be enforceable. Implement one of these operating models:

• Central consent service (preferred): systems call a single source of truth.
• Event-driven replication: consent events publish to downstream systems, with monitoring for failures.
• Hybrid: central store plus limited replication for latency-sensitive channels.

Minimum operational requirements:

• Downstream systems must be able to block processing when consent is absent or withdrawn.
• You must be able to reconstruct which consent state was in effect at the time of processing (audit replay).

Step 5: Build “demonstrate consent” reporting for audits and investigations

Create an audit-ready report template:

• Data subject ID
• Purposes and current state
• Full consent event history
• Evidence of notice/version
• Systems that consumed consent signals
• Any exceptions (manual overrides, system outages) and remediation ticket references (Regulation (EU) 2016/679, Article 7)

This is where Daydream often fits naturally: teams use Daydream to standardize the operating procedure, track the role-and-scope register for consent-based processing, and keep a recurring evidence packet that is ready for regulator or customer diligence requests.

Required evidence and artifacts to retain

Maintain an “Article 7 evidence packet” on a recurring cadence (monthly or per release cycle, based on your change velocity). Include:

• Role-and-scope register entries for consent-based processing (system list + purposes)
• Consent data model/schema documentation (required fields, purpose taxonomy)
• Screenshots or exports of consent UI states with versioning mapped to release tags
• Consent logs (sample records) showing timestamps, notice version, and purpose
• Data flow diagram showing where consent is enforced and where it is merely stored
• Third-party data sharing list showing how consent state is transmitted/contracted
• Exception log: incidents where consent enforcement failed and corrective actions (Regulation (EU) 2016/679, Article 7)

Retention period: align to your regulatory risk posture and internal retention policy; the key is consistency and retrievability.

Common exam/audit questions and hangups

Auditors and regulators tend to ask for concrete demonstrations:

• “List all processing activities where consent is the legal basis. Show the system of record.” (Regulation (EU) 2016/679, Article 7)
• “For this specific individual, show the consent record and what text/version they saw.”
• “Show how consent status flows to your email/SMS/ad platform tooling.”
• “What happens if consent is withdrawn? Show evidence the state changes everywhere.”
• “Who can change consent copy or purposes, and what approvals are required?”
• “Show monitoring for failed consent event propagation.”

Hangups that slow teams down:

• Consent captured in one place, but processing happens in another with no linkage.
• Multiple “sources of truth” across products or regions.
• Old datasets imported without consent provenance.

Frequent implementation mistakes (and how to avoid them)

1. Storing only a boolean (“consented: true”)
   Fix: store purpose, timestamp, and notice/version at minimum. (Regulation (EU) 2016/679, Article 7)

2. Consent evidence lives in screenshots, not systems
   Fix: require machine-readable logs and an exportable audit report.

3. No mapping from consent to identity
   Fix: implement a documented identity resolution rule and show it in the evidence packet.

4. Consent doesn’t control downstream sharing with third parties
   Fix: add contractual and technical requirements for third parties to receive and honor consent state; document the mechanism in your data flow map.

5. Policy says “we do it,” but no operating procedure
   Fix: publish a requirement-specific SOP with owners, triggers, and change approvals.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this section is omitted by design.

Practically, the risk is straightforward: if you cannot demonstrate consent, you lose the ability to defend consent as your legal basis for that processing activity. That can force rapid operational changes (campaign pauses, data deletions, third-party suspensions) under regulatory or customer pressure. (Regulation (EU) 2016/679, Article 7)

Practical 30/60/90-day execution plan

Use these phases as an operator’s rollout plan; tailor sequencing to where consent-based processing is highest risk.

First 30 days (triage and scoping)

• Build the role-and-scope register for consent-based processing (start with customer/marketing data).
• Identify consent capture points and systems that act on the data.
• Freeze uncontrolled changes: require approvals for consent copy/purpose changes.
• Define the minimum consent evidence schema and success criteria for “demonstrate consent.” (Regulation (EU) 2016/679, Article 7)

Next 60 days (control build and instrumentation)

• Implement or harden consent logging (required fields, validation, error handling).
• Stand up a consent reporting workflow that can answer one-person/one-purpose audit tests quickly.
• Map third-party touchpoints and define how consent state is transmitted or enforced.
• Create the first evidence packet and run an internal tabletop audit with sampling. (Regulation (EU) 2016/679, Article 7)

Next 90 days (operationalize and scale)

• Expand coverage to all products/regions and offline channels.
• Add monitoring and alerting for consent event failures or drift across systems.
• Build a recurring review cadence (release-based) to keep notice/version mappings current.
• Operationalize exception handling: documented remediation steps and sign-off for any manual processing outside standard consent flows.

Frequently Asked Questions

Do we need consent for all GDPR processing to satisfy Article 7?

No. Article 7 applies when you choose consent as the legal basis for a processing activity. If consent is your basis, you must be able to demonstrate it with records tied to the data subject and the processing. (Regulation (EU) 2016/679, Article 7)

What is the minimum “proof” auditors expect for the article 7: conditions for consent requirement?

Expect to produce a record that links a person to a consent decision, a timestamp, and what they agreed to (purpose and notice/version). A vague “opted in” flag without context is hard to defend. (Regulation (EU) 2016/679, Article 7)

Can we keep consent evidence in our CRM notes or support tickets?

You can, but it usually fails at scale because it is not reliably queryable, versioned, or enforceable downstream. Treat tickets as supplemental evidence; keep the primary consent record in a system designed for audit retrieval. (Regulation (EU) 2016/679, Article 7)

How do we handle consent when identities merge (anonymous user becomes logged in)?

Document the identity resolution rule (what identifier becomes authoritative) and preserve event history so you can show continuity. Your audit report should show both the original capture context and the merged identity link.

What if a third party processes data based on our consent signals?

You still need to demonstrate consent as a controller when consent is your legal basis. Contract and technically enforce how consent state is shared, and keep evidence that the sharing mechanism exists and is monitored. (Regulation (EU) 2016/679, Article 7)

What evidence should we keep after we update consent language or purposes?

Keep the mapping from consent notice/version to deployment date, plus sample logs that show the new version is recorded at capture. Version drift is a common audit gap because teams can’t prove what text was shown at a past point in time.