Europe’s new data privacy law, the General Data Protection Regulation (GDPR), will be enforced from May 2018. This law obliges all companies with consumers based in the EU to enable new data privacy protection. For websites and apps whose audience is primarily kids, additional requirements apply, commonly known as GDPR-Kids (GDPR-K).
Part Six of our comprehensive GDPR-K Toolkit covers collecting data and obtaining verifiable parental consent.
If you genuinely need to collect personal information from users of your service – say because you want to allow kids to create an account to use your location-based services, or to enable in-app purchases, or to create a social community – then you have to comply with Article 8 of the GDPR to get permission.
On the face of it, Article 8 (now known as GDPR-K) says the same thing as COPPA: obtain verifiable parental consent before collecting personal data from children. Under the hood, however, there are important differences.
First, the threshold for children providing their own consent under GDPR-K is 16 rather than 13, though individual countries can lower the age of consent to any age down to 13. Currently the UK, Ireland, Spain and most Scandinavian countries have chosen 13, whilst Germany, the Netherlands and Italy have chosen 16, with France still debating between 15 and 16. You can see the latest map of EU consent ages in Part Two.
Second, the mechanism for ‘verifying’ consent is more flexible under GDPR-K than it is under COPPA. In the US, it has become standard practice to use a credit card transaction to verify the identity of the parent prior to collecting personal data. Credit card is also a valid verification method under GDPR-K, but – taking into account the GDPR’s data minimisation principle – it should only be used if the sensitivity of the data you are collecting merits it.
How do I know which verification method to use?
Unlike COPPA, GDPR-K is not prescriptive when it comes to methods of verification. The onus is on you to determine a reasonable approach to match the risk of proposed data processing. For example, if you want to collect a child’s email address for the sole purpose of allowing them to reset a forgotten password, it is likely sufficient to email the parent for their consent and to confirm, via a tick-box, that they are the holder of parental responsibility.
If, on the other hand, your app needs to continuously track a device’s GPS coordinates to enable a location-based game, then the verification threshold is higher. For example, you should verify the parent’s identity by asking them to confirm they are the parent and to complete a credit card transaction to prove they are an adult. Note that any time you are sharing data with third parties, the risk level is considered to increase substantially, requiring a higher level of verification.
GDPR-K asks us to take a measured approach to match verification levels to risk, whilst minimising data collection. Guidance from the regulators has been limited to date, so best practices will evolve over time, but here is one way to think about it:
Minimising user flow disruption
Just as you would for permissions with grown-ups, the best user experience is only to ask for consent at the point in the flow where the purpose of collecting data is obvious and of value to the user.
For example, if you want to enable push notifications, you should ask for permission only at the point that the user chooses to enable them. Similarly, if you are running a competition with a physical prize giveaway, don’t ask every user that enters for their mailing address, just ask the winners. If your game has multiple features that require data collection, consider revealing these in stages, so that users are accessing new features and giving new consents as their commitment to your service grows.
But that’s not all
Once the parent or guardian has been notified or has granted consent, there are further GDPR-K obligations you need to be aware of: new purposes, re-consents, and subject data access rights.
Under GDPR-K, if your business comes up with an awesome new product idea, and you would like to use personal data you’ve collected in a new way, you must obtain a new consent for the new purpose.
Also, when a user reaches the age of digital consent in their country, you’ll need to obtain consent directly from them in order to continue processing their data. Acceptable user flows for this re-consent process are still being debated, but it should be possible to comply whilst avoiding interruption of the service. The simplest solution is to present the user with an alert or notification the next time they access your app or service, informing them that their parents’ consent has expired and they need to provide direct consent themselves. Don’t forget to provide clear and transparent privacy notices in a language the user can understand, in keeping with the core principles of GDPR. For more on notices, see Part Three.
Finally, bear in mind that the law requires you to allow your users (or their parents) to access, revoke or modify their consent at any time. This means at a minimum providing a contact they can reach to communicate their wishes, or (better yet) giving them access to a parent portal (like this one) where they can review and modify their consents.
Managing the complexity
If this all sounds somewhat onerous and complex, consider using a compliance platform like our Kids Web Services, which manages the entire kid and parent registration flow, handles the verification and opt-in/out flows automatically, understands and automatically applies the correct legal requirements in whatever country your users are in, and enables parents to manage consent through our parent portal.
Kids Web Services can be fully self-service, and provides mobile and web SDKs and APIs to allow you to integrate our platform directly into your apps and sites.
That brings us to the end of our GDPR-K readiness series. If there are other topics you would like us to write about, please reach out directly on [email protected]. And, as always, you can follow our blog posts by subscribing above.
The GDPR-K Toolkit for Kids Publishers Part One: Audit your technology partners
The GDPR-K Toolkit for Kids Publishers Part Two: Defining your audience
The GDPR-K Toolkit for Kids Publishers Part Three: Revise your privacy notices
The GDPR-K Toolkit for Kids Publishers Part Four: Safely monetise your site or app
The GDPR-K Toolkit for Kids Publishers Part Five: Kid-safe user acquisition
The GDPR-K Toolkit for Kids Publishers Part Six: Obtaining verifiable parental consent
Mike Hutchinson is Head of Product (Kids Web Services) at SuperAwesome.
