Audit logs and trails are a key requirement for GDPR and HIPAA compliance. In this blog, we examine what data you need to log and why.

Privacy and data protection are becoming ever more important concepts, especially for digital health companies. GDPR and HIPAA both impose strict penalties for non-compliance. But your company’s reputation also rests on how well you protect your users’ data. Data breaches become big news and can trigger widespread negative publicity.

One of the most important things you can do after a data breach is analyse exactly what happened. This means you need to store really detailed logs relating to the data you store and process. Moreover, you need to be able to construct an audit trail from these logs. This is your best defence against the damaging PR that goes alongside any such event. That was highlighted recently when it emerged the mental health records of thousands of Finns had been hacked.

In this blog, I will explain why you need logs, what you should log and how to ensure your logs result in a valid audit trail.

Why do you need audit logs?

GDPR is one of the strongest data protection laws in the world. It gives EU national data protection authorities the power to investigate any data breach and impose fines. If you suspect a data breach, you have an obligation to inform the authorities within 72 hours. You then have to provide all the information needed for them to audit what happened. You also should inform every user that was affected by the breach. In effect, this means GDPR requires you to store immutable audit logs and be able to create an audit trail. This is doubly important for digital health companies that store sensitive health data.

What should you log?

I am often asked what data a company should be logging. Basically, you need logs that can fully answer the following question:

If there’s a data breach, exactly what data was accessed, how, and when?

But what does this mean in practice? Specifically, you need to:

• Track all operations on user accounts and data: Creation, Alteration/Update, Deletion
• Monitor and log all accesses and access attempts to applications and data
• Log all metadata relating to user rights (e.g. consent, right to restrict processing, etc.)
• Be able to forensically rebuild the history in case of any data breach or legal dispute
• Demonstrate that you fully complied with the requirements of GDPR (including storing consents)

Examples

As an example, consider the following flow for a digital health app tracking blood sugar:

1. A user opens the app and logs in.
2. Backend sends an access token to the user.
3. The user enters their latest blood sugar level and uploads this.
4. The server stores the measurement and sends an acknowledgement.

Each of these steps should trigger a log entry. Likewise, consider the following flow:

1. A system admin logs into the backend.
2. They ask for an export of the health data of 100 users.
3. They then download this file.

Now, this may well be totally valid. Maybe this data is being used for internal research. However, unless you have good logging on the backend, you won’t know it even happened.

What requirements should audit logs meet?

Audit logs are a little different to typical system logs or analytics logs. Firstly, they exist for a different purpose. System logs are typically used to analyse performance issues or to understand user interactions. But audit logs are used for legal analysis of what happened in a data breach. Secondly, system logs are generally anonymised as far as possible. Analytics logs aren’t anonymised, but this makes them a frequent source of legal problems for companies. By contrast, audit logs need sufficient data in them to allow you to track which users were affected by any operation. Thirdly, system logs tend to be transient. You might keep them for a couple of months, but then they are no longer useful. Audit logs need to be immutable and permanent.

To summarise, this means that your audit logs need to be:

• Immutable. That is, the data cannot be changed after it has been written.
• Timestamped. You need to be able to reconstruct the history of what happened.
• Auditable. You must be able to provide access to the logs when and if needed. This should be in the form of an audit trail.
• Pseudonymised. Users should be referred to indirectly to ensure GDPR’s data minimisation requirement.

Achieving all these requirements can be tough.

Who can ask to see your audit logs?

Data protection authorities (DPAs) can request to see your audit logs at any time. You must provide them with full access on request. There are some jurisdictions where the DPA conducts regular audits (such as in Denmark). In the event of a data breach, you should proactively send a full audit trail to the authorities. There may be other cases where your logs can be inspected. For instance, if you are processing data on behalf of a hospital, they may ask for proof that you are compliant.

Are there any standards for audit trails?

So far, we’ve focussed on what GDPR says about logs and audit trails. These are mentioned in several places, including Articles 25, 30 & 32, as well as in the recitals. For instance, Article 30 of GDPR states:

“Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility.”

However, there are many other laws and standards relating to audit trails. In the US, HIPAA makes explicit recommendations about logging (see FDA 45 CFR 164.312(b)). There are also FDA rules for medical devices in  21 CFR ch. 1. Then there are a large number of international standards for specific use cases. For instance, ISO 27789 covers audit trails for electronic health records.

What can Chino do to help?

Chino.io offers tailored solutions to help your digital health application become compliant in any market. Our consultants can help answer any questions you might have about logging and audit trails. We also offer a platform and API for creating compliant audit trails. All log entries are immutable and are validated using Merkle Trees (a core technology underpinning blockchain and git).

The API is designed to be as flexible as possible. The following image shows all the possible log entries, with the ones in bold representing the minimum needed for compliant logs.

Conclusions

Deciding exactly what to log and how to store it is a challenge for any digital health company. Here at Chino.io, we have plenty of experience and are always happy to share our expertise. Use the link below to book a call to discuss how we can help you.