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

To comply with GDPR Article 8, you must ensure that when you rely on consent to provide an information society service directly to a child, consent is valid only if the child is at least 16; otherwise, you must obtain (and be able to prove) consent given or authorized by the holder of parental responsibility. Build an age-gating and parental authorization workflow, then retain audit-ready evidence. ¹

Key takeaways:

• Article 8 only bites when your lawful basis is consent and the service is offered directly to a child. ¹
• If the user is under 16, you need parental responsibility authorization, not “child-only” consent. ¹
• Your biggest operational risk is weak proof: implement verifiable flows and retain consent evidence tied to identity, time, and scope. ¹

Article 8 is a build-or-break requirement for any product team offering online services to minors in the EU when the business wants to rely on consent. It turns “consent” into a conditional control: you need a reliable way to determine whether the user is at least 16, and if not, you need a defensible method to collect consent from a parent or legal guardian and to link that authorization to the child’s account and the specific processing purposes. ¹

For a CCO or GRC lead, the fastest path to operationalizing Article 8 is to treat it as an end-to-end workflow requirement, not a privacy notice tweak. Map where consent is used as the lawful basis, identify which user journeys can be “directly to a child,” then implement (1) age screening, (2) parental authorization for under-16 users, (3) consent-record integrity controls, and (4) ongoing monitoring and exception handling. ¹

This page focuses on practical execution: who is in scope, how to design the workflow, what evidence auditors ask for, and how to avoid common implementation failures that make consent impossible to defend.

Regulatory text

Excerpt (Article 8(1)): Where consent is the lawful basis for offering information society services directly to a child, processing is lawful if 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 authorized by the holder of parental responsibility over the child. ¹

Operator meaning (what you must do):

1. Confirm Article 8 scope: You are relying on consent (Article 6(1)(a)) and the service is offered directly to a child. ¹
2. Implement an age threshold: Consent from the child alone is only valid if the child is at least 16. ¹
3. Collect parental authorization for under-16: For users below 16, you must obtain consent given or authorized by the holder of parental responsibility, and your processing must not exceed what was authorized. ¹

Plain-English interpretation

If your product asks a user to “agree” so you can process their personal data, and your product is the kind of online service a child can sign up for, you need a gate. Users who are old enough can consent for themselves; younger users can’t. For them, you need a parent/guardian to authorize the consent, and you need proof that stands up in a regulator inquiry or enterprise customer due diligence. ¹

Practically, Article 8 is less about drafting and more about identity, linkage, and evidence:

• Identity: who gave the consent (child vs parent/guardian).
• Linkage: which child account the authorization covers.
• Evidence: time-stamped records showing the scope of consent (purposes, data uses) and the authorization path. ¹

Who it applies to (entity and operational context)

Entities in scope

• Controllers offering online services into the EU where consent is used as the lawful basis for processing in the service. ¹
• Processors supporting those controllers will be pulled in operationally via contract and implementation work, even though Article 8’s “lawful processing” condition is primarily a controller-facing obligation. Keep your role boundaries explicit. ²

Operational contexts that typically trigger Article 8

• Consumer apps, games, e-learning platforms, social/community features, creator tools, or any self-serve signup where minors can register.
• Marketing features tied to consent (email/SMS marketing consent prompts inside the service) when presented directly to a child user.
• Any “free” online service monetized by ads or analytics if consent is your basis for those activities.

Quick scoping test (use this in intake)

Question	If “Yes”	What to do
Do we rely on consent for any processing in this product/feature?	Article 8 may apply	Inventory consent-based purposes and flows.
Can a child sign up or use it without an adult intermediary?	“Directly to a child” risk	Add age screening and underage handling.
Do we have proof of who consented and what was consented to?	Evidence gap	Implement consent logging + retention packet.

(Scope logic grounded in Article 8’s conditions. ¹)

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

1) Make the “role-and-scope” decision (fast, written, owned)

Create a short register entry for each in-scope product/feature:

• Controller or processor role for the activity.
• What personal data is collected at signup and during use.
• Which purposes rely on consent.
• Which systems store consent records and user age attributes. ²

Deliverable: Article 8 scope memo (one page per product line), signed by Product + Privacy/GRC.

2) Define the operational procedure (your “how we comply” SOP)

Write a procedure with:

• Trigger events: new signup, age change/correction request, consent withdrawal, parent challenge, account migration, new consent purpose.
• Named owners: Product (flow), Engineering (implementation), Privacy (requirements), Support (exceptions), Security (logging integrity).
• Approval checkpoints: privacy review before release, quarterly review of consent evidence completeness.

Tip from practice: Procedures fail when they don’t specify what happens when age is unknown. You need a defined “no age, no consent-based processing” branch.

3) Implement age screening that is enforceable

You need an age gate that:

• Collects age (or date of birth) at the right point in the journey.
• Stops consent-based processing if the user is under the threshold and parental authorization has not been completed. ¹

Design choices to document:

• Where the prompt appears (signup vs first use vs before data collection).
• What happens if the user abandons the flow.
• How you handle “obviously underage” signals (support tickets, moderation reports) and what corrective steps you take.

4) Build parental responsibility authorization for under-16 users

For users below 16:

• Collect parent/guardian contact method.
• Present the consent request to the parent/guardian with the same specificity you would present to the data subject.
• Record the parent/guardian’s affirmative authorization and link it to the child account. ¹

Operational minimums to make this defensible:

• Unique authorization token tied to child account ID.
• Time stamp, consent text version, and purposes accepted.
• Mechanism to revoke authorization and stop the associated processing.

5) Prove “to the extent that” (scope control)

Article 8 conditions lawfulness “only if and to the extent that” consent is authorized for under-16 users. ¹
That means you must enforce purpose scoping:

• If consent covers account creation but not marketing, your systems must reflect that difference.
• Downstream third parties (analytics, email providers) must only receive data permitted by the authorized purposes.

6) Add exception handling and support playbooks

Create playbooks for:

• Parent disputes: “I didn’t authorize this.”
• Child misrepresentation: reported underage user.
• Data subject requests (access/deletion) involving parent-child accounts.
• Consent withdrawal: how quickly systems stop processing based on consent.

7) Monitoring and recurring evidence packets

On a recurring cadence, compile an “Article 8 evidence packet”:

• Sample of consent records (adult and parental authorization flows).
• System logs showing gating works (blocked events for underage without authorization).
• Open issues and remediation items with owners and dates.

This is where Daydream fits naturally: use Daydream to maintain the role-and-scope register, attach SOPs, and package recurring evidence outputs and exceptions so you can answer customer diligence requests without rebuilding the story each time.

Required evidence and artifacts to retain

Keep artifacts in a form you can export quickly for an audit, regulator inquiry, or enterprise customer assessment:

Governance

• Role-and-scope register entry (controller/processor, systems, purposes).
• Article 8 SOP with owners and triggers.
• Privacy review/approval record for the age gate and parental flow.

Technical

• Consent log schema (fields for timestamp, account ID, purpose, text version).
• Evidence of gating logic (requirements, test cases, release notes).
• Data flow mapping showing which third parties receive data under which consent purposes.

Operational

• Support macros and escalation runbooks for parent/child disputes.
• Exception register (incidents where processing occurred without proper authorization) with corrective actions.

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your evidence packet:

1. Where do you rely on consent as the lawful basis, and is the service offered directly to children?
2. How do you determine whether the user is at least 16?
3. For under-16 users, what is your method to obtain parental responsibility authorization, and how do you link it to the child’s account? ¹
4. Show a consent record end-to-end: UI text shown, user journey, timestamped record, and downstream enforcement.
5. What happens on withdrawal or parent challenge?
6. How do you prevent “consent drift” when new purposes are added?

Hangup you’ll see in real audits: teams can show the UI screen, but not the back-end record tying consent to purposes and data flows.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating Article 8 as a policy statement. Fix: ship controls (age gate + parental authorization) and prove operation with logs.
• Mistake: Collecting a checkbox from the child for “my parent agrees.” Fix: route authorization to the parent/guardian and retain the parent authorization record. ¹
• Mistake: No linkage between parental authorization and specific processing purposes. Fix: purpose-granular consent records and downstream enforcement rules.
• Mistake: Age captured but not enforced. Fix: block consent-based processing events until the correct consent state is true.
• Mistake: Third-party sharing ignores underage status. Fix: enforce consent flags at the integration layer; document which third parties receive data under which consent purposes.

Enforcement context and risk implications

No public enforcement case references were provided in the source catalog for this page, so do not treat any specific penalty narrative as verified here.

Operationally, the risk is straightforward:

• If you cannot prove valid consent for children under the threshold, the processing that depends on that consent is vulnerable to being deemed unlawful. ¹
• Child-directed services draw scrutiny from privacy regulators and enterprise customers. Your defensibility depends on evidence quality, not intent.

Practical execution plan (30/60/90)

You asked for speed, but the playbook rules here prohibit unsourced duration claims in days. Use these phases instead.

Immediate (triage and scoping)

• Identify where consent is the lawful basis and where children can access the service.
• Create role-and-scope register entries for each in-scope product.
• Decide the product behavior for unknown age (block or restrict consent-based processing).

Near-term (build and document controls)

• Implement age screening and under-16 branch behavior.
• Implement parental responsibility authorization workflow.
• Add consent logging fields: timestamp, identity, purposes, consent text version, linkage to child account. ¹
• Update privacy notices and in-product consent language to match actual processing purposes.

Ongoing (assurance and continuous compliance)

• Run recurring evidence packets and sampling.
• Test that new features do not bypass gating or expand purposes without new consent.
• Review third-party integrations for purpose and consent alignment.
• Maintain an exception register and remediation tracking in Daydream so audit responses stay consistent.

Frequently Asked Questions

Does Article 8 apply to every online service that children might use?

Article 8 applies where you rely on consent as the lawful basis and the service is offered directly to a child. If you are not relying on consent for the processing in question, Article 8’s consent condition is not the controlling requirement. ¹

What if we don’t know a user’s age?

Treat unknown age as a control problem, not a legal footnote. Define a product rule that prevents consent-based processing until the user is confirmed as at least 16 or a parental authorization is completed for under-16 users. ¹

Is a child’s checkbox stating “my parent agrees” sufficient?

Article 8 requires consent to be given or authorized by the holder of parental responsibility for users below 16. A child-only attestation is hard to defend because it does not show parental authorization. ¹

Do we need to re-collect parental authorization when we add a new purpose?

If the new processing purpose relies on consent, you need consent that covers that purpose, and for under-16 users it must be authorized by the parent/guardian. Keep consent purpose-granular so you can see what is covered versus out of scope. ¹

How should processors support controllers on Article 8?

Processors should support age-gating and consent state enforcement as required by the controller’s instructions, and they should provide audit evidence (logs, data flow details, deletion/stop-processing actions) that helps the controller prove compliance. ²

What evidence do auditors usually want first?

They usually start with an end-to-end walkthrough: the UI/UX consent language, the age gate decisioning, parental authorization flow for under-16 users, and the underlying consent records with timestamps, purposes, and linkage to the account. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 8

2. Regulation (EU) 2016/679