Making Sense of the Dates in the OneTrust Data Subject Profile Updated Event

A customer recently asked me a deceptively simple question: what do the dates in the Data Subject Profile Updated event payload actually mean, and when are they populated? It is a fair thing to ask, because the payload carries several date fields, they interact with consent state in ways that are not obvious, and OneTrust does not document the behaviour anywhere I could point them to.

So I did some testing to make sure I could articulate exactly what each one is set to. This is the write-up I wish had existed when the question came in. It covers the three dates that cause the most confusion, ConsentDate, ActivationDate and WithdrawnDate, and how each behaves across re-consent, withdrawal and double opt-in (DOI).

ConsentDate

ConsentDate signifies when the purpose was last consented to.

• If the data subject consents again, it is updated to the most recent time they provided consent.
• If the data subject withdraws their consent, ConsentDate stays set to the last time they had consented. It does not clear. Withdrawal is reflected elsewhere: the transactionStatus becomes WITHDRAWN and the WithdrawnDate is populated.
• For DOI purposes, ConsentDate is only populated after the confirmation has been received. Until the double opt-in is confirmed, there is no consent date to report.

The mental model that helps: ConsentDate always points at the latest affirmative consent event. Withdrawal never rewrites it; only a new consent does.

ActivationDate

ActivationDate is the one that trips people up, because most of the time it is blank.

• It is blank unless the consent was collected through a DOI collection point. And even then, it stays blank until the confirmation has been received.
• When the confirmation is received for a DOI purpose, ActivationDate is set to the same value as ConsentDate at that moment.
• After that, the two dates diverge. If the data subject provides new consent later, ConsentDate is updated but ActivationDate remains as it was. It captures the first activation, not the latest consent.
• For non-DOI purposes, ActivationDate is never populated.

So ActivationDate is effectively “when this DOI consent was first confirmed and became active”, and it is frozen at that point. If you see it populated, you are looking at a double opt-in purpose that has been confirmed at least once.

WithdrawnDate

WithdrawnDate is the most straightforward of the three.

• It is only ever populated if the data subject has withdrawn consent.
• If a data subject re-consents after previously withdrawing, WithdrawnDate remains populated. It is not cleared. As with ConsentDate on withdrawal, the state change is carried by the other fields: transactionStatus returns to ACTIVE and ConsentDate is updated to the new consent.

In other words, WithdrawnDate records the last withdrawal that happened, and it persists even once the subject is active again. To know the current state you have to read it together with transactionStatus, not on its own.

Reading them together

No single date tells you the current consent state. The dates are a history; transactionStatus is the current state. Read them as a pair:

Field	What it records	Cleared on re-consent?	Cleared on withdrawal?
ConsentDate	Last affirmative consent (DOI: only after confirmation)	Updated to the new date	No, stays at last consent
ActivationDate	First DOI confirmation; blank for non-DOI	No, frozen at first activation	No
WithdrawnDate	Last withdrawal	No, stays populated	Set/updated

A worked example makes the interaction concrete. Take a DOI purpose that a subject opts into, confirms, later withdraws, then opts back into:

1. Opt-in submitted (not yet confirmed). All three dates blank. transactionStatus reflects a pending state.
2. Confirmation received. ConsentDate and ActivationDate are both set, to the same value. WithdrawnDate blank. transactionStatus ACTIVE.
3. Consent withdrawn. ConsentDate unchanged, ActivationDate unchanged, WithdrawnDate now set. transactionStatus WITHDRAWN.
4. Re-consents (and re-confirms). ConsentDate updated to the new consent, ActivationDate still frozen at step 2, WithdrawnDate still holds the step 3 value. transactionStatus back to ACTIVE.

By the end, all three dates are populated and they point at three different moments. That is by design, and it is exactly why reading any one of them in isolation is misleading.

The takeaway

If you are building an integration off the Data Subject Profile Updated event, treat the dates as an append-mostly history rather than live flags. ConsentDate moves forward with each new consent, ActivationDate is a one-time DOI marker, WithdrawnDate sticks once set, and none of them clear on the state change you might expect them to. Whenever you need the current position, branch on transactionStatus and use the dates for the “when”, not the “what”.