Privacy by design is a new buzzword in designing tech products. Even though the idea seems intuitively easy to grasp, it is hard to put it into concrete action points. Here’s where we can help.
The term “privacy by design” dates back to 2010 when it was coined by Ann Cavoukian, Information and Privacy Commissioner of Ontario. In her manifesto, Ann Cavoukian stated 7 principles that became the bedrock of privacy by design today. In essence, she postulated a design philosophy that compounds growth and privacy. In Ann’s words “Full Functionality – Positive-Sum, not Zero-Sum”.
Since then, privacy by design has gradually become part of data controllers’ legal obligations. For example, Europe’s GDPR mandates in its Article 25 that controllers implement privacy by design.
In short, privacy by design is a shift in development planning. While privacy was (and, regrettably, is) often slapped on top of a finished product, privacy by design requires that considerations for privacy are integrated into the normal development process, even before the first piece of real data hits your servers.
It is this development cycle that is “privacy by design” rather than a checklist of features to implement, such as strong encryption, a privacy policy etc.
The exact measures will, of course, very much depend on your business, industry and target audience. There are, however, certain tips which will always come in handy.
Back to school! Privacy is a tricky thing. On the one hand, it guards people’s right to control their data. Accordingly, it is the layman’s view on data practices that counts. On the other hand, there are certain hardcoded legal restrictions that are hard to foresee, such as heightened requirements towards processing health data.
Book an appointment with a CIPP/US-certified privacy professional to provide you with a Privacy-101 course.
At one point of development, sit down and try this thought exercise. Imagine that you are 1 year in the future and a data breach has happened. Try to reverse engineer the reasons why it happened. Write down your guesses, grade them by probability and impact.
Where the likelihood and/or impact are above moderate, design security measures that would lower the risk below moderate to low or very low. Implement them.
Mapping where you store your data and which data you store is core to ensuring compliance. Simply put, you cannot ensure that data practices are followed if you do not know where to apply them to.
In today’s rapidly changing product designs, creating snapshots can be inefficient as they become outdated too fast. A good solution is to establish wiring that constantly self-updates and shows you changes and highlights problems. We at Soveren are building one such solution.
Under most privacy regimes, data subjects have the right to correct inaccurate information about them, request a copy of the data you hold and to delete data upon certain events.
Accordingly, you should design your systems in a way that deletion of data does not mess up your workflows and you don’t run into exceptions. Retrieval can also be complicated, but you should have it sorted out thanks to data mapping and inventory.
In addition to reacting to user requests to delete their data, companies are also obliged to delete or anonymize data upon reaching certain processing time thresholds. These are commonly referred to as retention schedules.
Your systems should be able to self-sanitize after a certain time has passed since the data was inserted. Note that anonymous data can be handled indefinitely, such as aggregated analytics. Trust me, you’ll want to build a cool chart showing your exponential growth over the years!
