Store the agreed-to-privacy-policy date/timestamp to help prove GDPR compliance

[johnstonphilip]

Anytime a customer agrees to a privacy policy, should that be stored in some way? Perhaps the version of the privacy policy they agreed to, the date they agreed to it, and the user who agreed should be stored so that it could be used to prove that they agreed to any specific privacy policy, should a GDPR audit happen to anyone in the future.

If so, I'm not sure if it should be stored as user meta, or if it should be stored in a unique table so that the agreement of a guest commenter could also be stored.

[swissspidy]

The way I understood it is that the privacy policy is not a "contract" that needs to be accepted / agreed upon. It's merely an information for the user what data the site collects etc. So there's no need to store anything in that regard.

But I'll let the people working on that topic handle that :-)

[desrosj]

Moving to the new Privacy component.

[johnstonphilip]

Another thought on this: I'm not sure if revisions stay around forever or not, but perhaps in the case of a Privacy Policy they should. And if so, when storing their agreement timestamp, you could store the revision ID that the customer agreed to. This would save needing to store the complete text they agreed to with each agreement timestamp.

[summoner]

IMHO storing at least if the user has ever given their consent is a must. Just read Article 7 where it stands:

1. Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.

I think beyond that storing even the timestamp of the consent is desirable, as it is possible to compare that to the timestamp of the publication of different Privacy Policies and thus it is possible to tell which version of the policy has been accepted by the subject. To go even further, maybe i would store an array of the timestamps of the consents, that way the controller can clearly demonstrate which different versions of the policy has been and exactly when has been accepted by the subject. These infos might be crucial before the authorities or court.

[desrosj]

Related: #44043, #43797.

[dejliglama]

The privacy policy itself is not a thing users should consent to, so we don't have this problem.

Asking for this ticket to be closed.

[johnstonphilip]

@dejliglama Is there a specific section of the GDPR that has clarified that to you? Personally, I'm still in a state of confusion on it. It would be great to have a lawyer chime in.

[dejliglama]

Bringing @Idea15 (Heather Burns) in on this...

[idea15]

Hi everyone

The comments above are correct. The privacy policy is not a contract - it is a transparent statement of data use and a means for the user to clarify their options and rights.

I think you may be conflating the consent requirements of granular aspects of data collection and processing - e.g. the user consented to this use of their data, or that cookie - with the presentation of the document used to inventory that information. We're certainly going to be looking at granular consent logging and UX as part of the second roadmap.

For now, though, there is no timestamp consent required to be provided or captured for the privacy notice itself.

(IANAL but you don't need lawyers for GDPR - that's another Americanism!)

[johnstonphilip]

Thanks for clarifying. As long as there's a place to store agreements somewhere I think that will be very helpful.

If there's a separate ticket where those general agreements will be stored, can that be linked here to help point people there who might end up here looking for it?

P.S. Why don't you need a lawyer for GDPR?

P.P.S. I'm Canadian...so maybe "Americanism" is a "Europeanism"? lol

[desrosj]

Closing this out based on the feedback above. Consent is not required for a privacy policy because it is not a contract.

@johnstonphilip moving forward, I recommend following these two tickets for the consent logging and opt-in concepts: #44043, #43797.