The hype about GDPR is dying off, as apparently the world didn’t end on May 25th. However, best practices in data protection are still valid, and we’d like to focus on logging as one of them.
The Regulation isn’t explicitly talking about logs, however many data protection authorities consider logs to be a good way of demonstrating compliance – and “demonstrating compliance” is a key point of GDPR. Keeping logs of instances of processing activities is a best practice and can (and should) be done in the following scenarios:
- Tracking access to data – who accessed what and when. If access to data goes through a unified interface (UI and/or API), you can track all access to data and thus manifest that only the authorized personnel have read the data. That means, though, that search results in your CRM-like system should not contain too much information, otherwise tracking would be more complicated, as the back office user sees data about multiple data subjects on one page
- Tracking data modifications – one of the principles of GDPR is “integrity” – you have to keep the data correct, so any modification should be logged. That way, you can reconstruct an old state or prove the modifications that happened for a reason. This, again, relies on having a centralized interface.
- Logging GDPR-specific activities – e.g. when the data subject invokes their rights. Each request can be securely logged so that you can prove to authorities the exact sequence of events relating to the particular data subject
- Logging consent and the accompanying circumstances – date, time, IP address, etc. Then you can also log consent withdrawal, and the history of the consent of the data subject will be visible in one place and you will be able to prove to regulators when you had and when you didn’t have consent for processing.
Some of those scenarios can be handled by regular database entries, but having them securely logged in a tamper-evident way (e.g. with LogSentinel) gives further guarantees and no regulator can claim that you back-dated or modified a record.
Having proper GDPR-related logging requires some architectural decisions. Often companies opt to have a centralized personal data store that is accessed through a limited API, thus acting as a gate-keeper. That way every invocation of the datastore API would constitute an audit trail event.
LogSentinel, a SIEM and a secure audit trail software, offers both the generic logging functionality needed for tracking access and modifications, as well as GDPR-specific logging endpoints for data subject rights and consent. We figured that for even better visibility on data processing you can connect your audit logs to particular processing activities as per the Article 30 register. That way each log entry will be related to a processing activity and management can drill down into sequences of personal data events in order to better understand and analyze data access patterns.
We believe that GDPR compliance is not simply a list of boxes to tick – it’s a mindset that includes constant improvement of data processing visibility. Knowing what happens with your data, and being able to prove this is the only thing that happened to it, is not simply compliant – it’s a competitive advantage.
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
