Privacy legislation around the world is different in its technicalities but has a lot in common. The most famous recent laws are GDPR (EU but with extra-territorial effect) and CCPA (California, but practically affects the US and even services outside the US).
The Accountability Aspect of GDPR and CCPA
We have discussed in depth how to cover GDPR and CCPA requirements. Now we’d like to focus on one particular aspect of both regulations – accountability. In both cases, the data controller has to demonstrate that they follow the rules set out in the regulation and that they have promptly executed any data subject/consumer requests.
The data subject/consumer rights differ slightly, but in all cases include erasure/deletion, access/disclosure, and restriction/opt-out. And any business should be able to demonstrate (and prove to regulators) that they duly handle consumer requests. For that reason, it’s mandatory to log each such request as well as the result of its execution (e.g. whether the request was denied and on what grounds, how long did it take, were there any issues with executing the request). For each request, one should also store details about the user that requested it, so that they can later be properly identified.
The Accountability Aspect: Technical Implementation
How to implement that technically is the next important question. If a business has few requests by users, the requests can be tracked using a spreadsheet or even through the email history. However, with any business of significant volume, there should be a proper dedicated mechanism for tracking these requests. CCPA, for example, requires that the business provides at least two different ways of receiving the request, so a centralized register of the requests becomes an obvious solution.
Such a register can be implemented in the web application that serves the user itself, as normally such requests are made through web forms. However, many organizations run multiple web applications, and also the option to request these rights via phone calls or regular mail, so a central register, outside of particular applications, is the more viable options in many cases.
The ticketing/customer support system is one possible option for tracking all these requests. However, it may need customizing in order to accommodate the particular requirements of the legislation. And even then, there’s the question of the integrity of the data in the ticketing system. Many such systems allow for backdating or modifying entries, which regulators may see as insufficient in terms of demonstrating compliance. For example, if a user complains that their request was not handled, the service provider can just backdate an entry that the request was handled and claim that communication issues are the reason for the user has not been notified. That’s just one hypothetical scenario, but there are many more.
The ability to prove compliance is one of LogSentinel’s strong suits, and that’s why in both our products (SentinelDB and SentinelTrails) we offer the ability to store such data rights requests in a secure and tamper-protected way, utilizing our cryptographically protected, blockchain-backed audit trail.
For GDPR and CCPA, in particular, we even expose dedicated API endpoints which can be used by any third party system (a custom application or a ticketing system that allows extending with webhooks) to leave a secure and compliant trail of all requests as well as their results, using legislation-specific terminology. You can view these endpoints here or contact us to discuss how we can integrate them into your GDPR or CCPA processes.
Accountability is about having an overview of all processes mandated by a given regulation. Proving compliance is about being able to present regulators with guarantees that your accountability solution is not just a spreadsheet on a shared drive. On the other hand, this process should not be complex and a burden to the organization. That’s why we believe that an organization-wide, legislation-specific secure audit trail is the proper way to handle that.