Article 8: Conditions applicable to child's consent in relation to information society services

To meet the article 8: conditions applicable to child's consent in relation to information society services requirement, you must block consent-based processing for users under the applicable age threshold unless you obtain (and can prove) consent given or authorised by a holder of parental responsibility. Operationally, that means age-screening, consent routing, verification, and durable records tied to each processing purpose.

Key takeaways:

• If your lawful basis is consent and your service is offered directly to children, you need an age gate and a parent-consent path for underage users. (Regulation (EU) 2016/679, Article 8)
• “Consent given or authorised by the holder of parental responsibility” requires a defensible verification method and evidence you can produce on request. (Regulation (EU) 2016/679, Article 8)
• Treat this as an end-to-end workflow control across product UX, identity, consent storage, and downstream data uses, not a checkbox on the signup form. (Regulation (EU) 2016/679)

Article 8 is narrow but operationally demanding: it only triggers where your lawful basis is consent under Article 6(1)(a) and you offer an information society service directly to a child. Then, processing a child’s personal data is lawful if the child is at least 16; below 16, processing is lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility. (Regulation (EU) 2016/679, Article 8)

For a CCO or GRC lead, the fastest path to “audit-ready” is to turn this into a decisioned scope statement plus a control set that engineers can implement without reinterpretation. Your two primary tasks are: (1) determine where you rely on consent in child-directed or child-accessible user journeys, and (2) build a repeatable, evidenced process to collect, verify, store, and enforce parental consent limitations across systems and third parties.

This page gives requirement-level implementation guidance you can hand to product, legal, and engineering: applicability, step-by-step controls, evidence to retain, common audit questions, and a practical execution plan to get to a defensible posture quickly. (Regulation (EU) 2016/679)

Regulatory text

Excerpt (Article 8(1)): When consent is the lawful basis under Article 6(1)(a) for offering information society services directly to a child, processing is lawful where the child is at least 16. If the child is below 16, processing is lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility. (Regulation (EU) 2016/679, Article 8)

Operator translation (what you must do):

1. Identify where you rely on consent for personal data processing in services offered directly to children. (Regulation (EU) 2016/679, Article 8)
2. Determine user age before activating consent-based processing (or design the flow so consent-based processing cannot occur until age status is known). (Regulation (EU) 2016/679, Article 8)
3. For underage users, obtain parental responsibility holder consent/authorisation and apply it purpose-by-purpose (“only if and to the extent that…”). (Regulation (EU) 2016/679, Article 8)
4. Be able to prove it: retain records showing age path taken, the consent/authorisation captured, and the scope of processing it permits. (Regulation (EU) 2016/679, Article 8)

Plain-English interpretation (requirement-level)

If your product relies on consent for any processing and it is offered directly to children, a child under the threshold cannot self-consent. You must route them to a parental consent/authorisation process and ensure your systems enforce that limitation downstream (analytics, marketing, profiling, sharing with third parties, and optional features). (Regulation (EU) 2016/679, Article 8)

Two phrases matter operationally:

• “Offer… directly to a child”: treat as a scoping trigger for child-directed services and child-focused onboarding flows. Your controls should not depend on informal assumptions about your audience; they should depend on product reality and user journeys. (Regulation (EU) 2016/679, Article 8)
• “Only if and to the extent that”: parental consent must be granular by purpose and enforced as a technical policy, not a one-time legal statement. (Regulation (EU) 2016/679, Article 8)

Who it applies to

In-scope entities

• Controllers offering information society services directly to children and relying on consent as a lawful basis for processing. (Regulation (EU) 2016/679, Article 8)
• Processors supporting those controllers, because the controller’s consent constraints must be carried into processor operations via instructions, configurations, and contractual terms. (Regulation (EU) 2016/679)

In-scope operational contexts (common examples)

• Consumer apps and websites with account creation
• Social/community features where users create profiles
• Games/education platforms with direct sign-up
• Services that run optional analytics/marketing tags based on consent
• Any flow where a child can provide personal data and you treat consent as the legal basis for at least one purpose (Regulation (EU) 2016/679, Article 8)

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

Use this as an implementation checklist you can assign to owners.

Step 1: Write a role-and-scope decision (controller/processor + systems)

Create a short “Article 8 scope memo” that answers:

• Are we controller, processor, or both for these features?
• What products/regions/user journeys are “offered directly to a child”?
• Which processing purposes rely on consent (Article 6(1)(a)) in those journeys?
• Which systems execute those purposes (app, web, identity, CRM, data warehouse, ad tech, support tooling)? (Regulation (EU) 2016/679, Article 8)

Control you can operationalize: Maintain a role-and-scope register specifically for this requirement, including controller/processor role, data categories, and affected systems. (Regulation (EU) 2016/679)

Step 2: Map consent-based purposes to data flows and third parties

Build a purpose-to-flow matrix:

• Purpose (e.g., account personalization, marketing emails, targeted ads, optional analytics)
• Data elements
• Systems
• Third parties receiving the data
• “Allowed if underage?” and “Requires parental authorisation?” (Regulation (EU) 2016/679, Article 8)

This avoids a common failure mode: parental consent is collected, but third-party tags fire before the consent state is known.

Step 3: Implement an age-screening and routing design

Design the user journey so that:

• You capture age (or age band) before any consent-based processing runs, including client-side tags and SDK calls. (Regulation (EU) 2016/679, Article 8)
• Users at/above the threshold can consent for themselves.
• Users below the threshold cannot proceed to consent-based processing until a parental responsibility holder gives or authorises consent. (Regulation (EU) 2016/679, Article 8)

Practical build note: Make the “default state” for unknown-age users equal to “no consent” for consent-based purposes; then allow after verification.

Step 4: Implement parental consent/authorisation collection and verification

Article 8 requires consent “given or authorised” by the parental responsibility holder. (Regulation (EU) 2016/679, Article 8) The regulation excerpt does not prescribe a specific verification method, so your job is to pick a method you can defend and evidence consistently.

Minimum operational expectations you should set internally:

• Identity binding: link the parental action to the child account (or pending account) through a traceable identifier.
• Purpose granularity: capture consent per purpose and store the permitted scope.
• Verification evidence: retain what you did to establish that the person providing consent is plausibly the holder of parental responsibility (method, timestamp, outcome). (Regulation (EU) 2016/679, Article 8)

Step 5: Enforce consent scope across downstream processing (technical control)

Translate consent/authorisation status into enforceable controls:

• Consent flag service (source of truth)
• Feature gates in application code (block optional features until allowed)
• Tag/SDK manager rules (prevent data export)
• Data pipeline filters (block ingestion or partition records)
• Third-party sharing controls (disable exports; suppress identifiers) (Regulation (EU) 2016/679, Article 8)

This is where teams fail audits: consent exists in a UI log, but warehouse tables and third parties still receive data.

Step 6: Create an operating procedure with named owners and triggers

Write a requirement-specific SOP that covers:

• Trigger events: new product feature, new third party, new consent purpose, changes to onboarding, new region launch
• Owners: product, engineering, privacy/legal, security, marketing ops
• Required approvals: privacy sign-off before release when child-directed + consent is involved
• Exception handling: what happens if age is unknown, verification fails, or records are missing (Regulation (EU) 2016/679, Article 8)

Control you can operationalize: Define an operating procedure with named owners, trigger events, and required approvals. (Regulation (EU) 2016/679)

Step 7: Build an “evidence packet” cadence

Auditors and regulators do not accept “we have a process” without records. Establish a recurring evidence pull from systems:

• Samples of consent records for underage accounts
• Verification outcomes
• Logs showing suppression of downstream processing when consent absent
• Third-party configuration snapshots (tag rules, ad settings, export jobs)
• Exceptions and remediation tickets (Regulation (EU) 2016/679, Article 8)

Control you can operationalize: Retain auditable evidence packets (decision record, control outputs, exceptions, and remediation) on a recurring cadence. (Regulation (EU) 2016/679)

Required evidence and artifacts to retain

Use this as your audit binder index:

1. Article 8 scope memo: in-scope services, lawful basis (consent), child-directed rationale, systems list. (Regulation (EU) 2016/679, Article 8)
2. Role-and-scope register: controller/processor role, data categories, systems, third parties. (Regulation (EU) 2016/679)
3. Purpose-to-flow matrix: processing purposes relying on consent and where data moves. (Regulation (EU) 2016/679, Article 8)
4. Consent records: timestamp, purposes, consent text/version, account identifier, jurisdiction if relevant, and method used. (Regulation (EU) 2016/679, Article 8)
5. Parental authorisation records: verification method, outcome, linkage to child account, and scope granted. (Regulation (EU) 2016/679, Article 8)
6. Enforcement proof: screenshots/config exports from tag manager, feature flag rules, API checks, and data pipeline filters. (Regulation (EU) 2016/679, Article 8)
7. Change management artifacts: release tickets showing privacy review for impacted features. (Regulation (EU) 2016/679)
8. Third-party due diligence outputs: DPAs/instructions and technical configuration confirmation that third parties honor consent flags. (Regulation (EU) 2016/679)

Common exam/audit questions and hangups

Expect these and prepare short, evidenced answers:

• Where do you rely on consent, and where is the service offered directly to children? Provide your scope memo and data map. (Regulation (EU) 2016/679, Article 8)
• How do you determine age before consent-based processing starts? Show the UX flow and logs demonstrating no data leaves before gating. (Regulation (EU) 2016/679, Article 8)
• How do you confirm the person consenting is the holder of parental responsibility? Provide your verification method definition, outcomes, and sample records. (Regulation (EU) 2016/679, Article 8)
• How do you enforce “to the extent that” across analytics/ads/data warehouse? Show technical enforcement and suppression evidence. (Regulation (EU) 2016/679, Article 8)
• What happens if a child lies about age? Show your control assumptions, monitoring signals, and remediation workflow. Your answer should focus on operational detect/respond, not speculation. (Regulation (EU) 2016/679, Article 8)

Frequent implementation mistakes (and how to avoid them)

1. Age gate after tracking tags fire. Fix: default tags/SDKs to off until age and consent state are resolved. (Regulation (EU) 2016/679, Article 8)
2. Single “I agree” covers everything. Fix: implement purpose-based consent and store the scope; enforce it in systems. (Regulation (EU) 2016/679, Article 8)
3. Parental consent collected but not linked to processing. Fix: one consent source-of-truth with deterministic account binding. (Regulation (EU) 2016/679, Article 8)
4. Processor blind spot. Fix: if you are a processor, require controller instructions for child consent handling and verify configurations that apply those instructions. (Regulation (EU) 2016/679)
5. No evidence packet. Fix: schedule recurring exports and sampling so you can respond quickly to inquiries. Daydream can help centralize these artifacts and keep a clean decision trail without turning your GRC program into a spreadsheet-only workflow. (Regulation (EU) 2016/679)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Your practical risk is still clear: if consent is your legal basis, missing parental authorisation for underage users makes the processing unlawful for those purposes and creates downstream exposure wherever that data is stored or shared. (Regulation (EU) 2016/679, Article 8)

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

You asked for speed and operationalization. Use phases, not calendar promises.

First 30 days (Immediate control foundation)

• Publish the Article 8 scope memo and role-and-scope register. (Regulation (EU) 2016/679, Article 8)
• Inventory consent-based purposes and identify any child-directed journeys. (Regulation (EU) 2016/679, Article 8)
• Implement “no consent by default” gating for unknown age and underage states in tag/SDK configuration. (Regulation (EU) 2016/679, Article 8)
• Draft the SOP with named owners and release triggers. (Regulation (EU) 2016/679)

Next 60 days (Workflow completion and enforcement)

• Build/ship age-screening and parental consent routing in the onboarding flow. (Regulation (EU) 2016/679, Article 8)
• Implement consent source-of-truth storage with purpose granularity and versioned consent language. (Regulation (EU) 2016/679, Article 8)
• Push consent state to downstream systems (CRM, analytics, warehouse) and block exports where not authorised. (Regulation (EU) 2016/679, Article 8)
• Update third-party data sharing controls and confirm they honor consent flags. (Regulation (EU) 2016/679)

Next 90 days (Audit-ready and resilient)

• Run evidence sampling: pull records for underage accounts and confirm end-to-end enforcement. (Regulation (EU) 2016/679, Article 8)
• Tabletop exceptions: failed verification, consent withdrawal, account age correction, data deletion/remediation steps. (Regulation (EU) 2016/679)
• Operationalize the recurring evidence packet. Daydream fits well here by tracking owners, approvals, and evidence artifacts per requirement so you can answer diligence requests without rebuilding history. (Regulation (EU) 2016/679)

Frequently Asked Questions

Does Article 8 apply to every service that children might access?

Article 8(1) applies where consent is the lawful basis under Article 6(1)(a) and the service is offered directly to a child. Confirm scope based on your actual onboarding and audience targeting, then document the decision. (Regulation (EU) 2016/679, Article 8)

If we use legitimate interests or contract, do we still need parental consent?

The excerpt provided here is specific to consent under Article 6(1)(a). If you are not relying on consent for the processing purpose, this specific Article 8 condition may not be the controlling requirement, but you still need to meet GDPR obligations for your chosen basis. (Regulation (EU) 2016/679, Article 8)

What does “only if and to the extent that” mean operationally?

Treat it as purpose limitation enforced by code and configuration. If a parent authorises some purposes but not others, your systems must block the unapproved purposes across all data flows and third parties. (Regulation (EU) 2016/679, Article 8)

What evidence should we expect to produce during an audit?

Expect to show the age-screening flow, parental authorisation records linked to child accounts, and proof that downstream processing and sharing respects the consent scope. A policy alone rarely satisfies reviewers. (Regulation (EU) 2016/679, Article 8)

We’re a processor. What should we do if the controller hasn’t specified child-consent handling?

Escalate and obtain written processing instructions that cover child consent and parental authorisation constraints, then implement configurations that enforce those constraints. Retain the instruction and change records as evidence. (Regulation (EU) 2016/679)

Can we store the child’s data while waiting for parental consent?

Article 8 ties lawfulness to consent/authorisation for consent-based processing. Design the flow so consent-based collection and processing does not occur until authorisation is captured, or restrict what you collect to what you can justify under a different lawful basis and document that decision. (Regulation (EU) 2016/679, Article 8)