The data controller is responsible for demonstrating compliance with consent requirements. That means retaining proof that consent was obtained, showing what the person agreed to, and recording the consent status and timestamps. In practice, accountability sits with the controller because consent is only defensible when the organisation can evidence the full consent lifecycle.
Who must prove consent under the PDPL?
The controller bears the evidentiary burden. If a person challenges consent, the organisation must be able to show that consent was obtained lawfully, what was disclosed at the time, and when the consent state was recorded. That proof has to be durable enough to survive audits, complaints, and later disputes about scope or revocation.
What “valid consent” means in practice
Valid consent is not just a checkbox or a stored yes/no flag. It is a defensible record of a real choice, tied to a specific notice, purpose, and consent state. The practical test is whether the controller can reconstruct the full consent event, including the wording shown to the individual and the conditions under which they agreed.
That matters because consent can fail even when a system says “consented” if the notice was unclear, bundled with unrelated terms, or not linked to the exact processing activity. A robust consent record therefore needs enough context to prove that the agreement was informed, specific, and captured before processing began.
What evidence the controller should retain
The controller should keep evidence that supports the whole consent lifecycle, not just the final status. That usually includes the notice text presented to the person, the purpose or purposes covered, the timestamp of the affirmative action, the current consent state, and any later withdrawal or change. Without those elements, the record is weak under challenge.
The record also needs consistency. If consent was collected through a web form, app flow, call centre, or delegated channel, the evidence should still identify which version of the notice was used and which processing activity depended on it. For organisations that manage personal data at scale, the operational control is less about storage and more about traceability.
For privacy governance, the same principle is reflected in the broader accountability expectations in EU General Data Protection Regulation (GDPR), which is why consent evidence should be treated as a control record, not a convenience log.
Risk and Threat Considerations
When consent evidence is weak, the organisation can end up processing personal data without a defensible lawful basis. The practical risk is not only regulatory exposure, but also the inability to prove scope, timing, or withdrawal status when a complaint or investigation arrives. Good faith is not enough if the controller cannot reconstruct the consent event.
Failure mechanism: Organisations lose the original notice text, fail to capture the timestamped choice, or cannot link the consent record to the processing purpose. That breaks the evidentiary chain and makes later claims of consent hard to defend.
Impact: The controller may have to stop processing, re-collect consent, remediate records, or answer enforcement and complaint inquiries without reliable proof. At scale, the larger risk is silent non-compliance across many records, not a single obvious failure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 5 — Principles relating to processing of personal data | Consent evidence must support lawful, accountable personal-data processing. |
| Art. 7 — Conditions for consent | The controller must be able to demonstrate valid consent when relying on it. | |
| Art. 25 — Data protection by design and by default | Consent capture should be engineered to preserve notice versioning and evidence lifecycle. | |
| Recommendation — Retain proof that consent was informed, specific, and traceable to the exact processing purpose. Store timestamped consent records and withdrawal history for each consent event. Design consent flows so the notice text, purpose, and state are recorded by default. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | PII processing needs accountable handling of consent and related records. |
| Recommendation — Maintain privacy records that prove lawful basis and consent status over time. | ||
| NIST SP 800-53 Rev 5 | AU-10 — Non-Repudiation | Consent disputes require audit evidence that a specific action occurred at a specific time. |
| Recommendation — Log consent events with enough detail to support non-repudiation and later review. | ||
Practitioner Guidance
What to verify: Check that the consent record is reconstructable from the stored data alone. A reviewer should be able to see the notice version, purpose, timestamp, and withdrawal state without relying on tribal knowledge or application memory.
What good looks like: The controller can demonstrate, for any sampled record, exactly what the person saw, what they agreed to, and when that agreement was captured. The consent record should remain usable even after UI changes, template updates, or system migrations.
Common mistake: Treating a live “consented” status as proof in itself. A current flag is only defensible when it is backed by immutable history that shows how the consent was obtained and whether it still applies.
Practitioner takeaway: The strongest consent programme is the one that can prove itself after the fact, even when the original interface, campaign, or workflow no longer exists.
Related resources from NHI Mgmt Group
- What do organisations get wrong about proving valid cookie consent after the fact?
- Why do misleading consent statements present significant risks?
- What is the difference between valid consent and implied consent under GDPR for charities?
- How should organisations design explicit consent workflows so they remain valid under privacy regulations?
