After a ransomware attack, GDPR auditing helps

Following a ransomware attack, the logging required by the GDPR plays a key role in assessing the resulting damage. “In a large number of typical ransomware attacks, it must now be assumed that personal data has been stolen by attackers in the context of the ransomware and is being misused. (…) Consequently, this means that in such cases, the data subjects – e.g. employees, suppliers, customers, clients or patients – must usually also be notified of the incident in accordance with Article 34 of the GDPR,” states the Bavarian State Office for Data Protection Supervision¹, adding: “In particular, the question of whether there is a reasonable likelihood that no data flows to the attackers have taken place must be adequately addressed (e.g. a web proxy blocked suspicious server requests, the volume of data during the analysis period is not strong enough). Evidence of this kind must be included as part of a notification under Article 33 of the GDPR.”

Unfortunately, as a developer, I have already implemented the auditing of accesses to tables containing customer data and bank details for several online shops. As I was unaware of the link to ransomware attacks, I implemented it incorrectly. In all cases, the log was stored on the same database as that of the shop. In the event of the database being encrypted, it is impossible to assess the extent of the data flows.

Nowadays, I can only recommend storing GDPR logs, as well as other security-related logs, on a separate server. The machine must use a hardened operating system with a different authentication method in order to withstand an attack.

Do you see room for improvement in the storage of audit data in accordance with the GDPR? What other mistakes must developers avoid when it comes to audit requirements?

Image by Pete Linforth from Pixabay