AA privacy breach -- policy update?

According to a Radio New Zealand news report today:

"Hackers have taken names, addresses, contact details and expired credit card numbers from the AA Traveller website used between 2003 and 2018. AA travel and tourism general manager Greg Leighton said the data was taken in August last year and AA Traveller found out in March. He said a lot of the data was not needed anymore, so it should have been deleted, and the breach "could have been prevented"."

The disclosure prompted the acting NZ Privacy Commissioner to opine that companies 'need a review policy':

"Acting Privacy Commisioner Liz Macpherson told Midday Report that if data was not needed it should be deleted ... Companies needed a review policy in place to determine if the data stored was neccessary, or could be deleted, Macpherson said."

So I've looked through our SecAware information security policies to see whether we have it covered already, and sure enough we do - well, sort-of. Our privacy compliance policy template says, in part:

"IT systems, cloud services and business processes must comply fully with applicable privacy laws throughout the entire development lifecycle from initial specification though testing, release, operation, management and change, to final retirement.  For example, genuine (as opposed to synthetic) personal information used during the development process (e.g. for testing) must be secured just as strongly as in production, and securely erased when no longer required."

The final clause in that paragraph refers to 'secure erasure' without specifying what that really means, and 'when no longer required' is just as vague as determining whether the data remains 'necessary'. That said, the remainder of the paragraph, and in fact the rest of the policy template, covers other relevant and equally important issues - including compliance with applicable privacy laws and regulations - such as GDPR.

Digging deeper, article 28 of GDPR requires that (in part):

"[the data processor] at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data".

Article 28 doesn't appear to say what the controller must do with any personal data returned by the processor [although I am NOT a lawyer!]. GDPR recital 39, however, says (in part):

"The personal data should be adequate, relevant and limited to what is necessary for the purposes for which they are processed. This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum."

So, if GDPR applies, there appears to be a legal obligation to restrict the storage period of personal data to a 'strict minimum' ... and compliance with GDPR is covered by our privacy compliance policy template.

That said, I'm wondering now whether to update the SecAware policy statement above, expanding on the bold final phrase to give more explicit direction.

One approach might be to associate expiry dates with all personal data records, using periodic automated system functions or manual procedures to erase expired personal data. The expiry date might be pre-loaded when the data are originally loaded and updated as appropriate (e.g. if the service is extended or the principal re-confirms their permission to continue storing and using their personal data), and further controls might be helpful (e.g. validation checks for personal data records without valid expiry dates within a defined, reasonable period; additional pre-deletion checks that personal data that appear to have expired are truly redundant; plus various controls associated with 'secure deletion').

There are doubtless other approaches, too.

I'm not convinced, however, that it is worth elaborating on the policy in such detail, particularly as (a) the controls would be quite costly, and (b) the practical implementation details are context-dependent whereas all our policy templates are deliberately generic. I think we'll leave this to the discretion of our valued customers and their legal experts!