GDPR Consent — essence, requirements and obtaining consent

What is GDPR Consent?

GDPR Consent is a legal basis for processing personal data, defined in Article 4(11) and Article 7 of the General Data Protection Regulation of the European Union. The regulation came into force on May 25, 2018 and replaced the outdated Directive 95/46/EC, establishing uniform data protection standards for all EU member states.

According to GDPR, consent must be freely given — the user must have a real choice without negative consequences for refusal. If refusal of consent results in denial of access to a service that does not require data processing, such consent is considered coerced and invalid. Article 7(4) directly states that related contractual terms cannot condition contract performance on consent to process data that is not necessary for that contract.

Informed — the second key element: the data subject must understand what specific data is collected, for what purpose, who will process it and how long it will be stored. The European Data Protection Board (EDPB) in guidelines 05/2020 emphasizes that information must be provided in plain language, without complex legal wording. Practice shows that consent is deemed invalid if the privacy policy contains ambiguous or general wording.

Unambiguous means that consent must be expressed by an active action — checking a box, clicking a button or signing a form. Inaction, silence or pre-ticked checkboxes do not meet the requirement of unambiguity. In the Planet49 GmbH case (C-673/17), the Court of Justice of the European Union confirmed that consent cannot be implied from user inaction.

What data falls under GDPR

Personal data under GDPR means any information relating to an identified or identifiable natural person. This includes not only obvious identifiers — name, address, email, phone — but also IP addresses, cookie identifiers, advertising device identifiers (IDFA, GAID), biometric data, geolocation and genetic information.

Article 9 GDPR highlights special categories of data whose processing is prohibited without explicit consent: racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic and biometric data, health data and sexual orientation. For such categories, the strictest form of consent is required — separate, detailed and not implied from the general context.

When GDPR Consent is mandatory

GDPR Consent is required when data processing cannot be based on other legal grounds: contractual necessity (Article 6(1)(b)), legitimate interest (Article 6(1)(f)) or compliance with a legal obligation (Article 6(1)(c)). In practice, consent is necessary for marketing communications, tracking for advertising purposes, collecting non-mandatory data and using cookies that are not strictly necessary for the service to function.

According to the IAPP-EY Annual Governance Report (2024), 67% of companies use consent as the primary legal basis for data processing in mobile apps, despite a growing trend toward relying on legitimate interest where possible. This is because consent provides the most transparent relationship with the user, but simultaneously imposes the greatest obligations for record-keeping and consent management.

Basic GDPR Requirements for Consent

Article 7 GDPR establishes six conditions for valid consent, each of which must be met simultaneously. Violation of at least one condition renders consent invalid and data processing unlawful. Let us examine each condition in detail, taking into account EDPB guidelines and case law.

Freedom of consent is violated when there is an imbalance of power between the controller and the data subject. EDPB directly states that employers cannot rely on employee consent due to dependency in employment relationships. Similarly, public authorities cannot require consent from citizens when providing public services.

Specificity requires separate consent for each processing purpose. If an app collects data for analytics, ad personalization and service improvement — each purpose requires a separate checkbox. Combining multiple purposes into a single consent violates the specificity requirement and renders the consent invalid.

Accountability is the most technologically challenging requirement. Article 7(1) directly states that the controller bears the burden of proving that consent was obtained. In practice, this means maintaining a log of all user actions: who, when, for which purposes gave consent, which version of the privacy policy was shown and how the user withdrew it.

How to Implement Consent Collection in a Mobile App

Implementing GDPR Consent in a mobile application requires a comprehensive approach, combining legal requirements with technical implementation. The main tool is a Consent Management Platform (CMP) that manages the consent lifecycle: displaying the request, recording the choice, storing data and synchronizing with advertising and analytics SDKs.

Using Google UMP SDK

Google provides the User Messaging Platform (UMP) SDK for Android and iOS, which integrates with AdMob, Google Analytics and other Google services. UMP SDK automatically determines whether consent display is needed based on the user's geolocation and GDPR requirements. Let us look at the integration in Kotlin for Android:

val requestParams = ConsentRequestParameters
    .Builder()
    .setTagForUnderAgeOfConsent(false)
    .build()

ConsentInformation
    .getInstance(this)
    .requestConsentInfoUpdate(requestParams, { @Override
        fun onConsentInfoUpdateSuccess() {
            if (ConsentInformation
                    .getInstance(this@MainActivity)
                    .isConsentFormAvailable()
            ) {
                loadConsentForm()
            }
        }
    }, { @Override
        fun onConsentInfoUpdateFailure(error: FormError) {
            Log.e("UMP", error.message)
        }
    })

After loading the consent form, it must be displayed to the user. UMP SDK supports two types of forms: for obtaining consent to personalized advertising and for managing choices later. The result handling must account for all possible outcomes — the user may give consent, refuse or close the form without making a choice.

Storing and verifying consent

To meet the accountability requirement, it is necessary to store not only the fact of consent but also the context of its obtaining. The minimum dataset for storage includes: user or device identifier, timestamp with timezone, version of the privacy policy, specific processing purposes and the consent mechanism used.

data class ConsentRecord(
    val userId: String,
    val timestamp: Long,
    val privacyPolicyVersion: String,
    val purposes: List<String>,
    val consentGiven: Boolean
)

class ConsentRepository(
    private val dao: ConsentDao
) {
    suspend fun saveConsent(record: ConsentRecord) {
        dao.insert(record.toEntity())
        AnalyticsManager.logConsentEvent(record)
    }
}

The European Data Protection Board (EDPB) in recommendations 01/2023 emphasizes that consent records must be kept for the entire data processing period and up to three years after its termination. For mobile apps, this means the need for server-side storage of records, not just local storage, since the user may reinstall the app or change devices.

How GDPR Differs from Other Privacy Regulations

GDPR is not the only privacy regulation in the world, but it has become a model for many national data protection laws. Understanding the differences between GDPR and other regulations is critically important for developers of international applications working with users from different jurisdictions.

CCPA (California Consumer Privacy Act) fundamentally differs from GDPR: it operates on an opt-out model rather than opt-in. Under CCPA, companies must provide users with the right to opt out of the sale of their data, but are not required to obtain prior consent for collection. However, with the adoption of CPRA (California Privacy Rights Act) in 2023, consent requirements for sensitive data have become closer to GDPR.

ePrivacy Directive (Directive on Privacy and Electronic Communications) supplements GDPR regarding cookies and electronic marketing. Unlike GDPR, which regulates all personal data, ePrivacy focuses on communications data. The requirement to obtain consent for non-essential cookies stems specifically from ePrivacy, not from GDPR, although the consent mechanism is the same.

LGPD of Brazil almost completely mirrors the GDPR structure with minor changes: the age of consent is raised to 18, and processing data of deceased persons requires consent from heirs. PIPL of China, on the contrary, introduces stricter requirements: mandatory data localization, data protection impact assessment (DPIA) for all automated decisions and notification of cross-border data transfer.

Common Mistakes in Implementing GDPR Consent

Analysis of fines and orders from European supervisory authorities for 2018-2024 shows recurring violations in consent implementation. According to Enforcement Tracker (CMS Law, 2024), more than 40% of all GDPR fines are related to improper consent collection and management. Let us look at the most common mistakes.

Pre-ticked checkboxes and passive consent

The most common mistake is using pre-ticked checkboxes to obtain consent. The EU Court of Justice ruling in Planet49 GmbH (C-673/17) unequivocally established that consent cannot be implied from user inaction. Despite this, many applications continue to use pre-ticked options, especially for cookie banners, leading to direct fines and orders.

In 2024, the French National Commission on Informatics and Liberty (CNIL) fined a major RTB advertising holding company 250 million euros for using pre-ticked checkboxes and insufficiently transparent user information. This is the largest fine related to consent, demonstrating the priority of consent oversight for European regulators.

Combining purposes into a single consent

Many applications request a single blanket consent for all types of processing: analytics, personalization, advertising, transfer to third parties. This directly violates the specificity (purpose limitation) requirement. EDPB in guidelines 05/2020 emphasizes: if one purpose can be achieved without another, the user must be able to consent to each purpose separately.

The Irish Data Protection Commission (DPC) in its decision on Meta Platforms Ireland (2023) stated that combining ad personalization and service improvement into a single consent is a violation. Meta was required to implement separate consent mechanisms for different processing purposes in Facebook and Instagram.

Difficult or impossible withdrawal of consent

GDPR requires that withdrawal of consent be as easy as giving it. If the user gave consent with a single button click, withdrawal cannot require filling out a form, sending an email or calling support. In practice, many applications hide the withdrawal mechanism deep in settings or require multiple steps to complete it.

Recommended practice — adding a dedicated consent management screen in the app settings with the ability to withdraw each consent separately with a single toggle. Google's UMP SDK provides a built-in mechanism for re-displaying the consent form, which the user can invoke from the app settings at any time.

Lack of evidence of consent

Many developers rely on verbal consent or do not keep records of consent obtained. This makes it impossible to meet the accountability requirement under Article 5(2) GDPR. During an inspection, the supervisory authority will request not only the privacy policy but also logs of consent obtained for the entire data processing period.

The solution is using a Consent Management Platform (CMP) with automatic logging of all events: form display, user choice, document version, timestamp. Popular CMPs for mobile apps include Usercentrics, OneTrust and ConsentManager — all of them support automatic consent audit recording.