Children's data in Cyprus online services: age 14 rule

Confirm whether the age-14 rule applies to the activity

Article 8 of the GDPR applies when processing is based on consent in relation to an information society service offered directly to a child. Member States can set a threshold between 13 and 16; Cyprus used that option in section 8 of Law 125(I)/2018 and selected 14. The Cyprus Commissioner's public material also describes the 14-year threshold for online services. This rule is narrower than a general statement that nobody under 14 can ever use an app, and narrower than a statement that a 14-year-old may consent to every type of data use.

Begin by describing the actual service and audience. Is it an information society service offered directly to a child, and is consent truly the legal basis for the specific processing operation? A school providing an essential educational service, an online game with optional social features and an adult-facing shop whose users may include minors present different questions. Do not rely on the age rule to replace the Article 6 lawful-basis analysis. If a contract, legal obligation or another basis is proposed, assess its actual conditions and the child's interests rather than assuming a parental checkbox is always required or always sufficient.

Article 8(3) also leaves national contract-law questions about the validity or effect of a contract with a child untouched. Treat account eligibility, payment and privacy-law consent as separate decisions. Document which features are aimed at children, which are optional, what data each feature collects and why. A single age gate at sign-up may not address an optional advertising feature added months later. When the product reaches other EU states, check the relevant national age rules and the service's establishment and targeting; do not automatically export the Cyprus threshold to every jurisdiction.

For the broader lawful-basis and documentation programme, see the Cyprus GDPR compliance guide.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; Cyprus Law 125(I)/2018, section 8, consolidated Greek text (CyLaw, Cyprus Bar Association); Cyprus Commissioner for Personal Data Protection: Protection of the child; European Data Protection Board: Process personal data lawfully, children's consent

Map purposes before asking anyone for consent

Split the service into purposes: account creation, age assurance, core gameplay or content delivery, safety reporting, analytics, personalisation, targeted marketing and disclosure to other users or partners. Record the data, lawful basis, optionality, recipients and retention for each. A consent request is not specific if one click covers core service, public profile, advertising identifiers and third-party marketing together. The EDPB explains that consent must be freely given, specific, informed and unambiguous; a purpose change may require a fresh choice. A child's situation makes a bundled, confusing consent flow especially hard to defend.

Test whether refusing an optional purpose genuinely leaves the relevant service available. For example, a child may need an account identifier to save progress, but the service should not imply that ad profiling is necessary to save progress unless that claim withstands a real necessity analysis. Avoid the opposite mistake of labelling every technical operation 'consent' even when withdrawal could not be honoured while the service continues. Select the lawful basis on the facts and design the feature around it, rather than writing a privacy notice after the interface is complete.

When personal data could reveal health, religion or another special category, Article 9 introduces additional conditions beyond an Article 6 basis. When a feature uses location, camera, contacts or communications data, review whether each permission is needed and whether the default setting exposes more than the child expects. Keep a dated record of the scope decision and the notice shown at the point of collection. A later feature team should be able to see why a particular data field was collected and whether the original choice covered the new use.

Assess high-risk combinations through the GDPR DPIA screening guide.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; European Data Protection Board: Process personal data lawfully, children's consent; European Data Protection Board: Guidelines 05/2020 on consent under the GDPR

Build age and parental-authorisation checks proportionately

For consent-based processing within section 8's scope, a child who is at least 14 can provide their own GDPR consent under the Cyprus rule. For a child younger than 14, the holder of parental responsibility must give or authorise that consent. Article 8(2) requires the controller to make reasonable efforts to verify parental authorisation, taking available technology into account. It does not prescribe one universal identity-document collection method. Choose a method appropriate to the service's risk and explain why it provides reasonable assurance without collecting excessive family data.

Map the likely evasion and error cases. A free-text birth-date field may be easy to bypass; an indiscriminate demand for passport images may create a high-risk store of identity documents that the service never needed. Consider whether a parent-controlled account, controlled confirmation step or another risk-based measure fits the service. Keep evidence of the verification event and its scope, but minimise raw documents and delete temporary verification material when it is no longer needed. Test what happens when an authorisation fails, is abandoned or is withdrawn.

Do not silently convert parental authorisation into permission for every future feature. Record the particular purpose, notice version and parent or child action. Design a review when a child reaches the Cyprus threshold, changes country or moves to a different service tier; determine what existing choices remain valid and how the young person can manage them. A parent may have account-management privileges under the product, but that does not remove the child's own data-protection interests. Resolve disputes about who may exercise a particular right by looking at the facts and applicable law, not a blanket help-centre statement.

The separate assessment of consent for non-essential browser storage is in the Cyprus cookie-consent guide.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; Cyprus Law 125(I)/2018, section 8, consolidated Greek text (CyLaw, Cyprus Bar Association); European Data Protection Board: Process personal data lawfully, children's consent; European Data Protection Board: Guidelines 05/2020 on consent under the GDPR

Explain the service in language a child can use

Article 12 requires transparent information in concise, intelligible and easily accessible language, particularly when addressed to a child. A privacy policy written for corporate procurement will not meet that practical need merely because a parent can find it. Put a short, concrete explanation at the moment a child chooses a feature: what is collected, who can see it, whether it is optional and how to change the choice. Use examples that match the product rather than vague labels such as 'improve your experience'. Link to fuller Articles 13 and 14 information for parents and other readers.

Separate the child's choice from parental authorisation where both interfaces exist. The adult should see enough to understand what is being authorised, while the child should not be left with a false message that a parent has approved something different. Avoid preselected switches, confusing colours and a button that makes refusal look like failure. The EDPB's small-business guidance says the information provided where children can consent should be adapted to their age. Test the wording with the actual target age range and supported languages; legal accuracy that children cannot understand is not effective transparency.

A clear notice also names recipients and consequences. If a profile is public by default, tell the child who can view it before publication; if a game uses other players' messages, explain the moderation and reporting controls. Describe how long information will be kept in terms that can be understood and provide a route to seek deletion or help. Update both short and full explanations when a new vendor or purpose is added. Keep archived versions so the service can reconstruct what a user saw when a choice was recorded.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; European Data Protection Board: Process personal data lawfully, children's consent; Cyprus Commissioner for Personal Data Protection: Protection of the child

Limit collection, visibility and retention by design

Article 5's data-minimisation and storage-limitation principles apply to children's data as they do to other personal data. Ask whether a feature needs a full legal name, precise birth date, contact list or permanent location history. Use an age band or yes/no eligibility result where that is enough for the purpose, and do not keep more precise proof simply because it was available during verification. The technical team should be able to state each data field's purpose and deletion trigger. An optional feature should not create a permanent record after the child leaves it.

Review privacy defaults under Article 25. A new user's location, profile, contact discoverability and posts should not automatically be visible to the widest audience if the service can operate with narrower settings. Test default behaviour after reinstalling the app, joining a group and changing devices. A toggle buried in settings is not a good substitute for a safe initial state. If a public feature is genuinely central to the service, make that consequence clear before account creation and provide controls appropriate to the child's age and the feature's risk.

Define deletion separately for inactive accounts, chat content, parental-verification records, safety reports and backups. Safety evidence may require a different retention assessment from ordinary gameplay data, but 'we might need it someday' is not a retention rule. Restrict access to reports involving children and test removal from third-party tools. If a child or parent withdraws consent for an optional feature, stop the consent-based use and assess what underlying data must be erased or kept for a separate lawful purpose. Record the resulting action so support can answer accurately.

For retention decisions and an evidence trail, use the GDPR retention-schedule guide.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; European Data Protection Board: Process personal data lawfully, children's consent; Cyprus Law 125(I)/2018, section 8, consolidated Greek text (CyLaw, Cyprus Bar Association)

Check tracking, profiling and every third-party integration

Children merit specific protection, particularly in relation to marketing and the creation of personality or user profiles, as GDPR Recital 38 recognises. Do not assume that an age gate makes behavioural advertising acceptable. Map SDKs, analytics tools, ad networks, login providers and social-sharing functions; identify what each receives and for what purpose. If a vendor acts as a processor, Article 28 terms and actual instructions matter. If it decides an independent purpose, analyse that controller relationship and what the child or parent was told before any transfer.

Cookie and device-identifier permission is a separate legal layer from Article 8's consent rule for an online service. A parent authorising an under-14 child's account does not automatically authorise non-essential tracking by every third party. Check the Cyprus electronic-communications position for storage or access on a device and keep the choice distinct in the interface. Marketing communication rules are another layer. A service can satisfy one consent flow and still fail the other. For a child-facing service, avoid preloading unnecessary tracking before the appropriate choice is made.

Build a vendor change review. A harmless-looking analytics update may add an advertising identifier, broaden data sharing or change retention. Require the product owner to identify each new recipient, compare it with the recorded purpose and update notices and choices if needed. Disable an integration if the team cannot establish its data flow. Where a platform feature also falls under the Digital Services Act, assess its distinct child-protection duties separately; do not present the GDPR age-14 rule as a complete platform-safety programme.

For non-essential site technologies, review the cookie-consent implementation guide.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; European Data Protection Board: Process personal data lawfully, children's consent; Cyprus Law 125(I)/2018, section 8, consolidated Greek text (CyLaw, Cyprus Bar Association); Cyprus Commissioner for Personal Data Protection: Protection of the child

Make rights and safety requests practical for the family

Provide a reachable route for access, correction, withdrawal, objection and erasure. A child should be able to understand how to ask for help without navigating a legal complaint form. At the same time, do not disclose a child's private messages or location to anyone claiming to be a parent without a proportionate assessment of identity, parental responsibility and the child's rights. The GDPR rights belong to the data subject; the way a representative may act requires care in the actual context. Record the request, scope, verification performed and decision rather than treating every family request as an ordinary support ticket.

Test withdrawal of consent. Can a parent revoke authorisation for an optional feature, and can a child who can consent under the applicable rule change their own preference? Does the change reach all connected systems, or only a front-end toggle? Article 7 requires withdrawal to be as easy as giving consent. Explain the service consequence of withdrawal without turning it into a penalty for refusing optional processing. If information must remain for safety or a legal obligation, distinguish that from continuing the withdrawn purpose and tell the requester what remains.

Prepare incident handling for exposed child profiles, unauthorised account access and leakage of parental-verification material. Restrict access, preserve evidence and assess the GDPR notification duties under Articles 33 and 34 on the actual risk. A breach involving children may have different practical consequences from one involving ordinary analytics data. Rehearse how the service will communicate in age-appropriate language while giving parents the necessary facts. A generic breach email that sends families to a broken support address compounds the original problem.

For the incident decision process, see the Cyprus GDPR breach-response guide.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; European Data Protection Board: Process personal data lawfully, children's consent; Cyprus Commissioner for Personal Data Protection: Protection of the child

Run four launch tests before relying on the age gate

Test a Cyprus child aged 13 entering a feature that relies on consent. The service should apply the under-14 parental-authorisation path and record the specific purpose, not just accept a birth date. Test a 14-year-old entering the same feature: the service should present a clear, age-appropriate choice for that consent-based processing. Then test a user who refuses optional tracking. Verify that core functionality behaves as described and that non-essential tags or SDK events do not activate before the relevant permission is established.

Test a failed or withdrawn parental authorisation. Confirm that the child's optional data use does not continue, that temporary verification material is handled under its retention rule and that an appropriate message reaches the account. Test a request to delete or access the child's data across the app, moderation tool and cloud backup process. These tests reveal whether the privacy choices are real or only cosmetic. Keep dated evidence of results, defects and fixes; screenshots of the consent screen alone cannot prove the backend respected a choice.

Assign a product owner to review new features, SDKs, markets and age-assurance technology. The age-14 rule is a specific legal threshold, not a certification of the whole service. Record the purpose map, lawful bases, age and parental checks, notices, retention, processor terms and risk assessment in a controlled release file. Revisit the file when the audience or product changes, and check the current Cyprus law and EDPB guidance before changing the threshold or interface. A defensible launch is one where the actual child journey matches the legal explanation at each step.

Basis and guidance: Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25; Cyprus Law 125(I)/2018, section 8, consolidated Greek text (CyLaw, Cyprus Bar Association); European Data Protection Board: Process personal data lawfully, children's consent; Cyprus Commissioner for Personal Data Protection: Protection of the child

Primary sources and scope

Sources checked: October 7, 2026. This guide concerns the Republic of Cyprus. Examples are hypothetical, not client case studies. Check current official requirements before making a filing.

• Regulation (EU) 2016/679, GDPR, Articles 5, 6, 7, 8, 12, 13, 14 and 25
• Cyprus Law 125(I)/2018, section 8, consolidated Greek text (CyLaw, Cyprus Bar Association)
• Cyprus Commissioner for Personal Data Protection: Protection of the child
• European Data Protection Board: Process personal data lawfully, children's consent
• European Data Protection Board: Guidelines 05/2020 on consent under the GDPR
• Cyprus Commissioner: Law 125(I)/2018, unofficial English translation