Privacy Debt and How to Deal with It

In the era of GDPR and heightened need of handling private data better, I’ve been thinking about privacy quite often. As a conclusion I propose a new concept to assess and understand the effects of privacy in software architectures: privacy debt.

Most of you are probably familiar with the term “technical debt”. Wikipedia defined technical debt as follows:

Wikipedia article also states that unaddressed technical debt increases software entropy. This is the very key facet of privacy debt.

Privacy is a New Feature

As there has not been any standard or even recommended way to handle private data in software, everyone has designed their solutions from their own standpoints – resulting in numerous ways how the private data is managed inside and between the systems.

Some of these ways are compatible with new stipulations in GDPR, some of them are not. Currently, most companies are focusing on understanding what is their systems’ and codebases’ state – whether or not they are in violation with GDPR. This is, of course, the crucial first step and should be executed swiftly to avoid the risk of sanctions.

Forward-looking or otherwise quick companies are now facing the second challenge that can roughly be split into two parts:

• 1

  How to maintain the compliance with GDPR?

• 2

  How to reduce the cost and risk associated with managing private data?

The first sub challenge has to do with developer mindset shift, trainings, better processes, audits, and so forth. And it is worth its own blog post in the future. The second challenge, however, is where privacy debt could be used to assess proposed changes and new solutions.

The Concept of Privacy Debt

I’ve formulated privacy debt as:

The difference to technical debt can be seen subtle, but it is actually profound. Privacy debt is not about taking shortcuts – at least per se – but handling private data in a non-uniform or non-centralised way in a subsystem that is part of a larger architecture.

The solution itself might add or reduce technical debt. But as GDPR requires companies to honor the end users’ rights – such as right of access, right of rectification, or right to erasure – every new way of handling private data causes extra work in the processes designed for answering these requests of rights.

A new database, a new log file, a new user repository, and so forth, increases the places that the company needs to take a look at when a person’s data needs to be removed or rectified.

In other words, the entropy of the architecture – from the privacy point of view – increases. Managing this more fragmented environment requires more documentation, more items on checklists, longer processes, or more scripting.

A single new addition might not sound bad, but they do accumulate. And your privacy debt keeps increasing without you noticing. Until someone comes to you and asks you to honor their rights.

How to deal with Privacy Debt?

To overcome this problem, I propose the following solutions:

• Uniformity: Define and apply uniform ways to handle private data. The data itself is typically mostly the same in most of the systems, and it can be handled using the same procedures. If possible, define the data uniformly and use that definition in all systems applicable.

• Reduction: Move data outside of the systems, such as using SSO solution, and minimise the personal data stored in a business system.

• Encapsulation: Require all new systems to expose APIs to ensure the users’ rights on that system.

• Create a centralised system that handles all – or the bulk of – users’ rights. Connect all your systems, one by one, to this centralised private data management platform.

First and foremost, keep privacy debt concept in discussion when you are adding or replacing systems to your enterprise architecture. It is a valuable tool to understand how your privacy management gets easier or more complicated with each architectural change. And it is a good way to convince business owners to take privacy into account.

Thoughts by