If you have not audited your source code for how it handles personally identifiable data, you are officially past the deadline. The European Union’s General Data Privacy Regulation came into effect on May 25, 2018, and it places extensive demands and restrictions on how you make use of users’ private data.
While there’s no need to panic, your team should immediately begin reviewing how your code accesses, stores, alters, copies, transfers or otherwise touches personal data in any way. Keep in mind that GDPR only concerns data that can be used to reveal part or all of a person’s identity – known as personally identifiable data (PID). That provision includes times when you may access PID and anonymize it.
The good news is that documentation and data handling practices can be adapted to comply with the new rules. You will also be prepared for any future legislation that could apply to non-EU citizens, such as the privacy measures being considered in California. Most likely, all new software will inevitably treat data privacy as the default option in light of ongoing regulatory development. Applications developers will also likely minimize the frequency with which they access PID in the first place.
To help your organization prepare its own code for GDPR compliance, here are four standard practices you can adopt immediately.
Understand the Scope of GDPR
GDPR doesn’t apply to every possible use of every possible source of PID. Instead, it expects handling of that data to be transparent and secure. Users must also be informed of exactly how your application generates and handles PID. In many cases, users must explicitly opt in to specific data practices before you can make use of them.
We cannot begin to cover every aspect of the GDPR here, but you can review frequently asked questions and excerpts on the official English EU site.
Disclose Each Specific Use Case for PID
Transparency is the biggest goal for the GDPR. As such, your user agreements must spell out each specific use case for how your application will generate, copy, transfer, or alter their PID. Vague or blanket permissions may be deemed unacceptable.
Users now expect to know exactly how their data is being used and what the purpose of each use is. They also want to know how long that data is stored and who has access.
Documentation is key to accounting for all of these use cases so that they can be disclosed to end users.
Users Likely Want Access to and Control of Their Own Data
As a solution to GDPR compliance, many applications and platforms have moved towards giving every user access to a portal for their own PID. These portals allow users to erase their data, review it, export it, correct it, or alter access permissions at will.
Apple has implemented this solution, for instance, and many other large tech companies are expected to follow suit.
Assume Privacy by Default
Far too many applications create, store, and share PID by default – especially web-based ones. These practices proliferated thanks to the marketplace that has grown up around third-party data collection.
However, they must come to an abrupt end for companies that comply with GDPR. Instead, developers must assume privacy as a default setting.
“Privacy by default means a lot of things,” explains this post on InfoQ, “but it essentially aims to protect personally identifiable data and its privacy, with suitable controls. This typically requires, for example, clear audit trails in the form of who did what when, including and especially read access of personally identifiable information.”
Note that privacy also includes acceptable security measures, such as encryption and tightly controlled access. GDPR will examine situations where breaches occur, and the EU may assign penalties if they determine that inadequate security was in place.
These measures are just the tip of the iceberg when it comes to GDPR compliance, but they illustrate the radical new change in approach that developers and designers must adopt. The effort may be great, but the result is a world where people can trust institutions more and know that their valuable information isn’t being abused.
More Blog Posts for Programmers
