GDPR consent requirements are specific, technically demanding, and frequently misimplemented. Article 6 establishes consent as one of six lawful bases for processing. Article 7 sets the conditions that make consent valid. Article 9 imposes additional requirements for consent to process special category data. Together, they define a consent infrastructure standard that goes significantly beyond a checkbox on a registration form.
The most common implementation gap is the conflation of consent capture with consent management. Capturing consent means recording that a user clicked agree. Managing consent means maintaining a versioned, purpose-specific, withdrawable, auditable consent record per Data Subject that demonstrates ongoing lawful basis for every processing activity. GDPR requires the latter.
The accountability principle in Article 5(2) and Article 7(1) requires that controllers be able to demonstrate that consent was given. Demonstration requires structured records, not a database row indicating that a form was submitted. A supervisory authority examining consent compliance will ask to see the consent record for a specific Data Subject, the notice version under which consent was given, the specific purposes consented to, and whether any withdrawals have been recorded. A system that cannot produce this information per Data Subject per purpose per notice version is not a compliant consent management system.
This blog covers what Articles 6, 7, and 9 each require technically, how a compliant consent management infrastructure must be architected, and how Akku’s CIAM Consent Manager addresses each requirement. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.
Article 6 establishes six lawful bases for processing personal data. Consent is one of them. The others are contract, legal obligation, vital interests, public task, and legitimate interests. Organisations that rely on consent as their lawful basis for some or all processing activities must implement a compliant consent management infrastructure. Organisations that rely primarily on other lawful bases may have limited consent management requirements, but they must still be able to demonstrate which lawful basis applies to each processing activity.
Article 6(1)(a) permits processing where the Data Subject has given consent to processing of their personal data for one or more specific purposes. The specific purposes requirement is critical: a single consent covering all processing purposes does not satisfy Article 6(1)(a)’s specificity requirement. Each processing purpose requires its own consent record.
The specific purposes requirement also means that processing cannot extend beyond the purposes consented to. If a Data Subject consents to processing for service delivery but not for marketing, processing for marketing purposes without a separate consent is unlawful under Article 6.
Purpose-specific consent records are the core technical requirement. The consent management system must maintain a separate consent record per Data Subject per processing purpose. Each record must capture the Data Subject identity, the specific purpose, the notice version under which consent was given, and the consent timestamp.
The system must be capable of evaluating whether a valid consent record exists for a given Data Subject and processing purpose before processing occurs. Where no valid consent exists and no other lawful basis applies, processing must not proceed.
Akku’s CIAM Consent Manager maintains purpose-specific consent records per Data Subject. The consent record data model captures Data Subject identity, processing purpose, notice version, consent timestamp, channel, and withdrawal status. Each processing purpose has a separate record, allowing partial consent and partial withdrawal.
Article 7 sets four conditions for valid consent: freely given, specific, informed, and unambiguous indication of agreement. Each condition has a technical implementation requirement.
Article 7(4) provides that consent is not freely given if it is bundled with other agreements as a condition of service when the processing is not necessary for the performance of that contract. A terms-of-service acceptance that bundles consent to marketing processing with consent to service delivery processing, where the marketing consent is not necessary for service delivery, does not constitute freely given consent for the marketing purpose.
Technically, freely given consent requires that consent to non-essential processing purposes be separately captured from agreement to service terms. The consent management system must support distinct consent events for different processing purposes rather than a single agreement covering all purposes.
Article 7’s specificity requirement reinforces Article 6(1)(a)’s specific purposes condition. Consent must be given for a defined processing purpose. A consent to unspecified future processing or to a broadly-defined category of purposes does not satisfy the specificity requirement.
Technically, specificity requires that each consent record references a specific, defined processing purpose description. The purpose description must be sufficiently granular that the Data Subject can understand what they are consenting to.
Consent must be given with the benefit of a compliant notice as required by Articles 13 and 14. The Data Subject must have received information about the controller’s identity, the processing purposes, the legal basis, retention periods, Data Subject rights, and the right to withdraw consent before consenting. Consent obtained without a compliant preceding notice is not informed consent.
Technically, informed consent requires that the consent event is linked to a specific notice version. The consent management system must record which notice version was presented before consent was sought. When the notice changes, existing consents remain valid only for the purposes and notice content under which they were given. New or changed processing purposes require fresh consent under the updated notice.
Article 7 requires that consent be given through a clear affirmative action. Pre-ticked boxes, inactivity, or silence do not constitute unambiguous consent. The Data Subject must take a positive action to indicate agreement.
Technically, unambiguous consent requires that the consent capture mechanism records a positive action by the Data Subject, not an absence of objection. The record must capture the action taken, such as button click, form submission, or API consent event, not only the resulting consent state.
Article 7(3) requires that the Data Subject can withdraw consent at any time and that withdrawal must be as easy as giving consent. Processing must cease when consent is withdrawn. The right to withdraw must be communicated to the Data Subject before they give consent.
Technically, withdrawal requires a self-service interface accessible through the same channel as the original consent mechanism. Withdrawal must not require contacting support. On withdrawal, downstream processing systems must be notified to cease processing. The notification must be automated at scale.
Akku’s CIAM Consent Manager addresses Articles 5(1)(a), 5(1)(b), 5(1)(c), 5(1)(d), 5(2), 6(1), 7(1), 7(2), 7(3), 7(4), and 8(1) across 28 mapping points in Akku’s GDPR compliance documentation, the largest single-module count in the mapping.
Article 7(1) requires that where processing is based on consent, the controller must be able to demonstrate that the Data Subject has given consent. This is the accountability requirement for consent specifically.
Demonstration requires that for every Data Subject whose personal data is processed on the basis of consent, the controller can produce a structured consent record showing: the Data Subject identity, the processing purpose, the notice version under which consent was given, the consent timestamp, the channel through which consent was given, and whether the consent remains valid or has been withdrawn.
A supervisory authority examination may request consent records for a specific Data Subject or a sample of Data Subjects. The records must be producible from a structured, queryable system, not reconstructed from server logs or inferred from application behaviour.
The records must also be tamper-evident. A consent record that can be modified after the fact cannot satisfy Article 7(1)’s demonstration requirement because its accuracy is not verifiable. Append-only consent records where each event is logged without modifying previous entries constitute the tamper-evident standard.
Akku’s CIAM Consent Manager maintains a complete consent history per Data Subject per processing purpose. Every consent event, update, and withdrawal is added as a new record rather than overwriting the previous state. The history is append-only and tamper-evident. A supervisory authority examination request for a specific Data Subject’s consent history can be fulfilled from a structured query against the consent record database, producing a complete chronological record of every consent event with timestamps and notice version references.
Article 9 prohibits processing of special category data unless one of the listed exceptions applies. Article 9(2)(a) permits processing of special category data where the Data Subject has given explicit consent for one or more specified purposes.
Explicit consent for special category data is a higher standard than standard consent. The Data Subject must explicitly consent to the processing of a specific category of sensitive data for a specific purpose. Implicit or bundled consent does not satisfy the explicit requirement.
Special category data includes data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for the purpose of uniquely identifying a person, health data, and data concerning sex life or sexual orientation. For organisations processing any of these categories, explicit consent requirements must be implemented separately from standard processing consent.
A separate consent flow for each special category data processing purpose is required. The consent capture must make clear to the Data Subject that they are consenting to processing of a specific sensitive data category. The consent record must capture the special category data type alongside the processing purpose.
The higher standard of explicit consent means that the consent capture mechanism must produce clearer evidence of a deliberate, informed decision than standard consent mechanisms. Two-step confirmation flows, where the Data Subject first receives information about the special category data and then takes a separate explicit confirmation action, are a common technical implementation of the explicit consent standard.
Akku’s CIAM Consent Manager addresses Article 9(2)(a) through special category consent workflows within the consent management infrastructure.
Valid consent under Articles 6 and 7 requires a preceding compliant notice. Articles 13 and 14 define what the notice must contain. The notice infrastructure is therefore a prerequisite for the consent management infrastructure.
Every consent record must reference the notice version under which it was obtained. This requires that the consent management system maintains a versioned notice registry, with each version identified by a version number or effective date. When the notice is updated, the new version is added to the registry. Consent records reference the specific version presented before consent was sought.
Notice versioning is the mechanism that allows the controller to demonstrate that consent was informed: the consent record references the notice version, and the notice version record shows what information the Data Subject received before consenting.
When the notice changes in a material way, such as a new processing purpose being added or the retention period changing, Data Subjects who consented under the previous notice must be re-consented under the new notice for the affected purposes. The re-consent workflow must present the updated notice and capture a new consent event linked to the new notice version.
The controller must be able to demonstrate which Data Subjects are operating under which notice version at any point in time. This requires the consent record data model to capture notice version per consent record, not just per Data Subject.
Akku’s CIAM Consent Manager implements the technical infrastructure for GDPR consent management across Articles 6, 7, and 9 through six core capabilities.
Centralised consent record storage maintains versioned, timestamped consent records per Data Subject per processing purpose. Every consent event is stored with Data Subject identity, purpose, notice version, timestamp, and channel.
Versioned notice management maintains a notice registry with version history. Every consent record references the applicable notice version. Re-consent workflows support notice updates requiring fresh consent.
Purpose-specific consent capture supports separate consent events per processing purpose, satisfying Article 6(1)(a)’s specificity requirement and Article 7(4)’s freely-given condition.
Self-service withdrawal interface accessible through the same channel as original consent, with automated downstream processing cessation notifications, satisfying Article 7(3).
Special category consent workflows implement the explicit consent standard for Article 9(2)(a) processing purposes.
Append-only consent audit trail captures every consent lifecycle event in tamper-evident format, satisfying Article 7(1)’s demonstration requirement and Article 5(2)’s accountability principle.
For any Data Subject whose personal data you are processing on the basis of consent, can you produce a structured consent record showing the specific purposes consented to, the notice version under which consent was given, and the consent timestamp, without manual reconstruction?
Does your consent capture mechanism support separate consent events per processing purpose, or does it capture a single agreement covering all processing activities?
When your privacy notice changes materially, does your consent management system identify which Data Subjects require re-consent under the new notice and initiate a re-consent workflow automatically?
Is consent withdrawal achievable through a single self-service action in the same interface where consent was given, with automated processing cessation across all connected systems on withdrawal?
For Data Subjects whose data you process under special category consent, does your consent record capture the specific data category and purpose for which explicit consent was given, separately from standard processing consent?
See how Akku’s CIAM Consent Manager addresses GDPR Articles 6, 7, and 9 requirements across consent capture, record management, withdrawal, and audit trails.
Book a conversation with the Akku team to assess your current consent management infrastructure against GDPR’s technical requirements.
What is the difference between consent as a lawful basis and other lawful bases under Article 6, and when should organisations use consent?
GDPR Article 6 provides six lawful bases for processing. Consent is appropriate when the processing is genuinely optional, the Data Subject has a real choice, and the organisation does not have an existing contractual or legal basis for the processing. Consent is not appropriate as a substitute for other lawful bases when processing is necessary for contract performance or legal compliance. Relying on consent for processing that is actually necessary for a contract creates a practical problem: if the Data Subject withdraws consent, the organisation cannot use the contractual necessity basis retrospectively. Organisations should identify the most appropriate lawful basis for each processing activity rather than defaulting to consent for all processing.
What does Article 7(4) mean for organisations that bundle consent with service terms?
Article 7(4) provides that consent is not freely given if it is made conditional on a contract that is not necessary for the processing purposes bundled into the consent. If an organisation’s service terms include a checkbox that both accepts the terms of service and consents to marketing processing, the marketing consent is not freely given because it is bundled with the service agreement as a condition of access. The marketing consent must be separately capturable and refusable without affecting access to the service. Technically, this requires separate consent capture mechanisms for processing purposes that are not necessary for the core service.
How does Article 7(3)’s withdrawal requirement interact with processing that was lawfully conducted before withdrawal?
Article 7(3) requires that withdrawal of consent does not affect the lawfulness of processing carried out on the basis of consent before withdrawal. Processing that occurred while consent was valid is not retrospectively unlawful. The obligation is to cease processing from the point of withdrawal and, where requested, to erase the data. The consent management system must record the withdrawal timestamp precisely so that the lawfulness boundary between pre-withdrawal and post-withdrawal processing can be demonstrated.
What makes consent to special category data processing explicit under Article 9(2)(a)?
Explicit consent for special category data requires a higher standard of clarity than standard consent. The Data Subject must explicitly agree to processing of a specific category of sensitive data for a specific purpose. Implicit consent, such as providing health data on a form without a specific consent statement, does not satisfy the explicit standard. Two-step confirmation flows where the Data Subject first receives information about the special category data and then takes a separate explicit confirmation action, combined with a consent record that captures the specific data category and purpose, is the common technical implementation of the explicit consent standard.
Does GDPR require organisations to re-obtain consent when their privacy notice changes?
Re-consent is required when the notice changes in a material way that affects the basis on which consent was originally given. Adding a new processing purpose or changing the nature of processing that was previously described in the notice are examples of material changes requiring re-consent. Technical changes to the notice that do not affect the processing described, such as formatting updates or clarifications that do not change the substance, typically do not require re-consent. The controller must assess each notice change and determine whether the change is material enough to affect the validity of existing consents.
Can a single consent management deployment address both GDPR and DPDPA consent requirements?
Yes. GDPR Articles 6 and 7 and DPDPA Clauses 5 and 6 share substantial overlapping requirements. Both require purpose-specific consent. Both require that consent be withdrawable with equal ease to how it was given. Both require that the controller maintain records demonstrating that consent was obtained. Both require notice to precede consent. Akku’s CIAM Consent Manager implements the consent infrastructure that satisfies both frameworks from a single deployment. The consent record data model is extended to capture the specific fields each framework requires, and the notice versioning infrastructure supports compliance with both frameworks’ notice obligations simultaneously.
Introduction IRDAI ICS Annexure III Item 10 requires that user accounts inactive beyond a defined…
Introduction ISO 27001:2022 Annex A.5.18 requires that access rights be reviewed at regular intervals and…
Introduction SOC 2 Trust Services Criteria CC5.1 requires that the entity selects and develops control…
Introduction SEBI CSCRF applies to all regulated entities but differentiates requirements by entity tier. Market…
Introduction SEBI CSCRF PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold…
Introduction ISO 27001:2022 Annex A.8.2 requires that the allocation and use of privileged access rights…