Skip to main content
Cookie Gate
Promotional banner for the pentest readiness checklist
Category: Consent Records

Consent Timestamp

Also known as: consented_at, consent date/time
Simply put

A consent timestamp is the recorded date and time at which a user gave (or updated) their consent, for example the moment they clicked "Accept" on a cookie banner. It helps an organization show when consent was obtained and whether it is still current. On its own, a timestamp does not prove that the consent was valid; it is one part of a broader consent record.

Formal definition

A consent timestamp is a data point within a consent record capturing the exact time a user performed a consent-related action, such as accepting, refusing, or modifying their choices. It is typically stored alongside other evidence in a consent log (for example the choices made, the user or session identifier, and the applicable policy version) to support the accountability and demonstrability expectations associated with valid consent under the GDPR and comparable frameworks. Consent timestamps also underpin operational functions such as tracking the age of consent against internal renewal or re-consent policies, and may be exposed programmatically (for example via an API field like "consented_at"). The timestamp itself records only when an action occurred; whether that consent was freely given, specific, informed, and unambiguous depends on the surrounding facts and is out of scope for the timestamp field alone. Requirements around what must be logged, and for how long, differ across jurisdictions and evolving regulatory guidance.

Why it matters

Under the GDPR and comparable frameworks, organizations relying on consent are expected to be able to demonstrate that consent was obtained. A consent timestamp is one of the core pieces of evidence supporting this accountability expectation: it records when a user performed a consent-related action, such as clicking "Accept" on a cookie banner. Without a reliable record of when consent was given or updated, an organization may struggle to show a data protection authority, or the individual concerned, that a lawful basis existed at the relevant time.

The timestamp also plays an operational role in keeping consent current. Consent is not necessarily valid indefinitely, and many organizations set internal policies governing how long they treat a given consent as active before seeking renewal or re-consent. As one practitioner discussion illustrates, tracking the beginning of the consent period is what allows a business to apply such an internal retention or renewal policy and to determine when a fresh consent action is needed. The timestamp is the anchor point for that calculation.

It is important not to overstate what a timestamp proves. Recording the moment of a click does not, by itself, establish that consent was freely given, specific, informed, and unambiguous; those qualities depend on the surrounding circumstances, such as the design of the banner and the choices actually presented. The ICO notes, for example, that where an individual has no real choice, consent is not freely given and will be invalid. A timestamp is therefore best understood as one component of a broader consent record rather than as standalone proof of valid consent. What must be logged, and for how long, varies across jurisdictions and continues to evolve with regulatory guidance.

Who it's relevant to

Privacy and data protection officers
Consent timestamps are a key element of the consent records DPOs rely on to demonstrate accountability under the GDPR and similar frameworks. They should treat the timestamp as one input into a fuller record and confirm that supporting details, such as the choices made and the policy version in force, are captured alongside it, since the timestamp alone does not establish that consent was valid.
Legal and compliance counsel
Counsel advising on consent-based processing may need to assess whether logged timestamps, together with the rest of the consent record, are sufficient to show consent existed at a given time. They are also best placed to define how long a recorded consent should be treated as current before renewal, recognizing that logging and retention requirements differ across jurisdictions and evolving regulatory guidance.
Web developers and engineers
Developers implement the capture and storage of the timestamp at the point of the consent action and may expose it through API fields such as "consented_at" for use by other systems. Accurate, consistently recorded timestamps are essential so that downstream logic, such as renewal calculations, and any transparency features shown to users operate on reliable data.
Marketing compliance teams
Teams responsible for tracking and advertising technologies depend on consent records to confirm that a valid, current consent underpins their activities. The timestamp helps them identify when consent may have aged past internal renewal thresholds, though they should coordinate with legal and privacy colleagues rather than treat the presence of a timestamp as confirmation that consent remains valid.

Inside Consent Timestamp

Date and time value
The core element of a consent timestamp is a recorded date and time marking when a user gave, refused, or withdrew consent. It is typically stored in a standardized format (such as an ISO 8601 datetime or a Unix epoch value) to support consistent interpretation across systems.
Time zone or UTC reference
To be meaningful, the timestamp should include or be normalized to a reference such as Coordinated Universal Time (UTC), avoiding ambiguity that can arise from local time zones and daylight saving changes.
Association with a consent record
A consent timestamp is generally not stored in isolation. It typically forms part of a broader consent record that links the time to the specific user or device identifier, the consent choices made per cookie category or purpose, and often the version of the consent notice or CMP configuration in effect.
Event type context
The timestamp is usually tied to a particular event, such as initial consent, an update to preferences, a renewal, or a withdrawal. Distinguishing which event a timestamp refers to is important for reconstructing the history of a user's choices.
Role in accountability and record-keeping
Under the GDPR's accountability principle, controllers are generally expected to be able to demonstrate that valid consent was obtained. A reliable timestamp supports this by evidencing when a clear affirmative action occurred, though it is one element among several and does not by itself prove that consent met all validity requirements.

Common questions

Answers to the questions practitioners most commonly ask about Consent Timestamp.

Does recording a consent timestamp by itself prove that valid consent was obtained?
No. A consent timestamp records when a consent action occurred, but it does not, on its own, demonstrate that the consent met the GDPR standard of being freely given, specific, informed, and unambiguous. To evidence valid consent, the timestamp generally needs to be stored alongside other elements of the consent record, such as what the user was shown, which purposes or categories they agreed to, the consent mechanism used, and the applicable consent text or version. The timestamp is one component of a defensible record, not proof of compliance in itself.
Is a consent timestamp the same thing as a full consent record or consent log?
No. A consent timestamp is a single data point marking the moment of a consent action. A consent record or consent log is the broader set of information typically maintained to support accountability, which may include the timestamp along with details such as the identifier for the user or session, the choices made per purpose, the version of the notice or CMP configuration presented, and any subsequent changes or withdrawals. The timestamp is an element within that record rather than a substitute for it. Exactly what a complete record should contain is not fully prescribed and can depend on the applicable regime and regulator expectations.
How should a consent timestamp be formatted and stored to be useful for accountability?
As a general practice, a consent timestamp is recorded in a precise, unambiguous format, and using a standardized time reference such as UTC can help avoid confusion across time zones. Storing the timestamp together with the other components of the consent record supports the accountability principle under the GDPR in the EU. The specific format and storage approach are technical and organizational choices; this entry does not prescribe a particular standard, and requirements may vary by jurisdiction and by the guidance applicable to your circumstances.
Should a new timestamp be created when a user changes or withdraws consent?
Because withdrawing consent must generally be as easy as giving it under the GDPR, and because records should reflect the current state of a user's choices, it is common practice to capture a new timestamp each time a user grants, modifies, or withdraws consent rather than overwriting the original. Retaining the history of consent actions with their respective timestamps can help demonstrate when a given state took effect. The appropriate retention period and level of detail depend on your accountability needs and applicable rules, which this entry does not determine.
Do consent timestamps interact with consent expiry or re-consent intervals?
A consent timestamp can serve as the reference point for determining how long a recorded consent has been in place, which is relevant where an organization chooses to refresh or re-request consent after a defined period. Some regulators in EU jurisdictions have expressed views on appropriate intervals for seeking consent again, but expectations vary and are not uniform. This entry does not state a specific required interval; whether and when re-consent is needed depends on the applicable guidance and the facts of a given deployment.
Are consent timestamps relevant when using a CMP or the IAB Transparency and Consent Framework?
Yes. Consent management platforms typically generate and store consent timestamps as part of the consent records they maintain, and frameworks such as the IAB TCF include time-related fields within their consent signal structures. However, the presence of a timestamp from a CMP or framework does not by itself guarantee compliance; the underlying consent must still meet the applicable legal standard, and the tool supports rather than replaces legal judgment. The precise fields captured differ between platforms and framework versions, which is outside the scope of this definition.

Common misconceptions

A consent timestamp on its own proves that valid consent was obtained.
A timestamp evidences only when an interaction was recorded. Valid consent under the GDPR must additionally be freely given, specific, informed, and unambiguous through a clear affirmative action. The timestamp is generally most useful when combined with records of what the user was shown, the choices they made, and the applicable notice version. Whether the underlying consent was actually valid depends on facts beyond the timestamp itself.
Once a consent timestamp is recorded, the consent remains valid indefinitely.
Consent is not necessarily permanent. In many EU jurisdictions, guidance from data protection authorities suggests consent may need to be refreshed periodically, though there is no single universally fixed expiry period across all regimes. The timestamp helps determine when consent was last obtained so an organization can assess whether re-consent may be appropriate; it does not extend the lifespan of the consent.
The same timestamping approach satisfies obligations everywhere.
Record-keeping and consent expectations vary between the EU, the UK, and individual US state regimes such as those in California, some of which rely on opt-out rather than opt-in models. A timestamp practice designed for EU opt-in consent may need to capture different events (for example, opt-out or preference-signal choices) to be useful under other frameworks. Scope should be assessed per applicable law.

Best practices

Store timestamps in a standardized, unambiguous format normalized to UTC (for example ISO 8601) so records can be interpreted consistently across systems and over time.
Link each timestamp to the fuller consent record, including the user or device identifier, the specific purposes or cookie categories consented to, and the version of the consent notice or CMP configuration in effect at that moment.
Record a timestamp for each distinct consent event, including initial consent, preference updates, renewals, and withdrawals, so the history of a user's choices can be reconstructed for accountability purposes.
Retain consent logs securely and for a period appropriate to demonstrating compliance, while applying data minimization and consulting applicable retention guidance in the relevant jurisdiction.
Use timestamps to support re-consent workflows by identifying records that may be aging, recognizing that any refresh interval should reflect applicable data protection authority guidance rather than a single universal rule.
Treat timestamping as one component of a defensible consent posture supported by a CMP, and confirm through legal review that the surrounding consent mechanism actually meets validity requirements for the jurisdictions you operate in, since a tool does not replace legal judgment.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps