2

Assume, there's a model called CustomerDetails, which contains the following properties:

  • ContactEmail - an email address for contacting purposes,
  • ContactAddress - a postal address for contacting purposes,
  • DefaultDeliveryAddress - default address for delivery when creating orders,
  • DefaultInvoiceAddress - default address to be printed on invoice, when creating orders,
  • and other properties.

All entities in the system are by default audited, ie. they contain change log / revisions history.

Any user can change own CustomerDetails data by himself/herself.

If user changes that information via web-interface, then what is correct:

  • there can be no trace of previous information: no revisions history for the CustomerDetails entity, or
  • there must be a possibility to delete own revisions for user: extra user interface to view+delete revisions, or
  • there is only obligation to delete revisions of CustomerDetails, if Right to erasure (‘right to be forgotten’) is exercised?

1 Answer 1

6

The GDPR does not mandate specific features, but that any processing is lawful and transparent etc.

So what would be the purpose of storing a revision history? Once that is clear you can work out an appropriate legal basis (e.g. a legitimate interest) and then figure out which data subject rights apply.

For example, let's assume that there is a security interest in keeping a revision history, so that (a) mistaken edits can be rolled back, and (b) the user can be notified of possibly unauthorized changes. This would be a legitimate interest primarily of the account holder, secondarily of you as the system operator. Of course, such security requirements have to be proportional, but I'd see that as given when there's a payment method on file.

You are required to apply appropriate safety measures and to apply the data minimization principle. E.g. is it necessary to store this revision history for all eternity? No, one or two months will likely be sufficient. Who should have access to this data? If the purpose is to defend against unauthorized access, it could make sense to only give out this data on request, and otherwise only make it available to support and security staff.

Now we can discuss how this interfaces with rectification or deletion.

That the user is able to rectify their data themselves is very good. However, that doesn't imply a prohibition on keeping a revision history: the revision history indicates what data was stored at what point in time, and is by definition correct. This assumes that you are not using the revision history for any other purposes.

When the legal basis is a legitimate interest, a request for erasure has to be preceded by (or implies) an objection (opt-out) to further processing. The objection must weighed against the legitimate interest: the objection can be denied when there are overriding grounds to continue processing. This might be the case for a security purpose: if someone with unauthorized access can just erase their traces, the purpose cannot be achieved. But perhaps the user could opt out when they create their account? Or opt-out later, but with some delay to still achieve the security purpose at the time of opt-out?

In any case, erasure is required when the data is no longer necessary for its purpose – this ties back to picking an appropriate retention period, as discussed above.

So it's not really possible to provide a general answer, and it really depends on the specific purpose you are trying to achieve.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .