.jpg)
Whether you are building new software for businesses or for customers, you cannot know in advance the privacy requirements applicable to your product.
Maybe you will need to expand into a new geographical market. But since the laws around the world are not uniform, you face the risk that your solution will not fit a particular jurisdiction. This may hold up your advance into markets in these jurisdictions in the future.
Another problem is that your solution may become popular among companies which work in a particular sector that is subject to strict regulations, like healthcare.
Each expansion of business will of course require some fine-tuning and improvements from your side. It is, however, crucial to design the software products and services so that they don’t have to be remade from scratch for new markets, sectors, or jurisdictions.
Luckily, this is where international standards come into play. Namely, there is an international standard for privacy called ISO 27701. The standard is an expansion of the ISO 27001 cybersecurity standard which is the gold standard for security around the globe and works in conjunction with it.
This guide will definitely not be enough to get your company certified in compliance with ISO 27701. But it will help you lay the foundation that is in line with it, meaning you will not have to rebuild from scratch.
Privacy compliance for ISO: what you need to do
There are certain principles that you have to abide by:
It is common wisdom that you are better able to serve the customer if you know them better. It is also true that you never know which data you will need in the future. It is therefore a common strategy to collect any data that is available. This is especially true for android devices which allow you to gather quite of lot of data about the user device, ranging from screen resolution to carrier name.
But this approach may lead to cybersecurity and privacy risks. Under privacy principles, you may only gather and retain data that is required and proportionate to your tasks.
How to de-risk your work with PII
This means it is good practice to sit down and link each piece of information you gather to a specific purpose. It often turns out that a huge portion of the data is not required.
If you are a B2C business, you should decide whether to continue collecting this data. In case of doubt, it is better to err on the side of caution. If you are designing a B2B solution that will hold personal data of your client’s customers, you should provide options on how to turn off the collection of data.
Storage is dirt cheap. But it is a pain to manage data structures where random pieces of data may disappear from time to time.
The typical approach among engineers is to mark the data as hidden rather than delete it outright. Interestingly, this is somewhat similar to how operating systems delete files: they mark files as deleted rather than erase all the ones and zeroes.
The flip side of this is that in case of breach, the leaked data will be used to harm all your customers, not just the active ones. It is an especially bad surprise for those who asked you to delete their data.
The solution to this is to build resilience into your systems so that they can handle possibly missing data. It is also wise to build the data storage solution so that you are able to set rules that data X shall be deleted Y days after capturing it.
Privacy and cybersecurity go hand in hand. The main goal of cybersecurity is to protect valuable business information. The main goal of privacy is to protect the rights of individuals whose data is processed.
These two areas overlap in that a data breach is a catastrophic event for both. Information security people therefore often work with privacy professionals to determine the appropriate security measures to prevent data breaches.
Data security and data privacy for PII: what's the difference
In most jurisdictions, security measures are determined following a risk-based approach. In essence, you have to think of what can go wrong and then decide how to fix it. Among other risks, you have to consider the discomfort that use of data can cause to individuals.
For example, if you use social authentication and do not allow your users to post reviews anonymously, there is a risk that other users may find the original poster in facebook based on the profile photo and harass them.
It is a common theme across new privacy laws around the world to provide consumers with the right to request the removal of their data. Additionally, customers are provided with the right to download a copy of their data stored by your solution.
This requirement has started to transcend from a purely legal one to the level of information infrastructure. A great example to illustrate this are the Shopify rules for developers. If you are a developer who wants to provide services to Shopify’s clients, you are mandated to install several webhooks that will allow Shopify’s clients to download their data and delete the data of the client and/or their customers.
Building such endpoints available by default will save you lots of time trying to collect all the scattered data in your data storages.
The privacy guidelines for developing software products and services which I have outlined here may not be exhaustive, but are a great foundation from which you can build privacy by design into your product from the ground up.
