With the advent of the GDPR and other privacy regulation the way developer thinking needs to adjust to the new paradigm.

Common criticism against the move to more privacy-centric development commonly include difficulty, time and cost as factors.  However, this does not have to be the only conclusion. If done right, the GDPR and the Privacy-By-Design software principles will strengthen your organizations IT infrastructure while being more responsive to customer needs.

GDPR Is Important Outside the EU

First off, let’s dispell the myth that you do not have to care for privacy-by-design if you are developing outside the EU. Even when assuming for a moment that no other regulation is on its way, this does not hold true. 

The reach of the GDPR goes beyond the EU borders:

The GDPR will also apply to the processing of personal data of data subjects in the EU by a controller or processor not established in the EU, where the activities relate to: offering goods or services to EU citizens (irrespective of whether payment is required) and the monitoring of behavior that takes place within the EU. Non-EU businesses processing the data of EU citizens will also have to appoint a representative in the EU.

Thus, implementation of Privacy-By-Design software philosophy will ensure that developers can create software that meets the spirit of the law and has a good chance of being compliant with the legal requirements in general.

Let’s look a little more into the basic tenants of the Privacy

Basic Tenants of Privacy-by-Design

Privacy must be proactive

Privacy must be proactive, not reactive, and must anticipate privacy issues before they reach the user. Privacy must also be preventative, not remedial.

If you can foresee a problem, like a table accumulating user data in plain text, you should design your system in such a fashion that that table has proper encryption, data is split in different normal form, and/or check whether you need to store that data in the first place.

You can also opt for hosted mode data processing, where the data never is in your system and only retrieved when you need to process it. 

For example, you could achieve this by using the XcooBee data network secure remote hosted data option.  User data is encrypted specifically for your consumption. XcooBee Network is not able to read it but, nonetheless, be able to deliver it to your systems on demand. 

The use case for this extends to a few places, including systems that only support a promotional campaign or limited life project efforts.

Privacy must be the default

Privacy must be the default setting. The user should not have to take actions to secure their privacy, and consent for data sharing should not be assumed.

Beside the obvious element of not signing up users by default, user consent is a key element here. You should be able to trace all uses of data to clear user consent obtained in a transparent easy to understand way.

Using XcooBee, this is possible for new and old systems easily. Obtaining consent is at the core of anything the XcooBee Privacy Network does on your behalf. Users are presented with electronic consent for data every step of the way. They can as easily give as take away consent. We communicate with the user and, in turn, you do not need to build extensive and repetitive communication UI and UX for each of your systems. Reducing your cost and improving your time to market. 

Your systems can trace consent via the blockchain or directly from XcooBee at any time and are able to have a better privacy stance by default.

In case where there are problem, you can refer to history and documented interactions. And, you can also use the built in XcooBee tools for problem resolutions.

 

Privacy must be embedded

Privacy must be embedded into design. It must be a core function of the product or service, not an add-on.

This is where the element of retrofitting is difficult to do. A cost/benefit analysis will need to take place to see whether existing system need to rewritten. 

However, you can use the collection of XcooBee services to handle privacy related matters and limit the use of rewrites and redesigns to existing systems. This may be a higher value alternative to a complete rewrite.

Privacy must be a positive sum

Privacy must be positive sum and should avoid dichotomies. For example, Privacy-by-Design sees an achievable balance between privacy and security, not a zero-sum game of privacy or security.

A system that has good privacy practices tends to be a safer and harder to breach system. Both privacy and security go hand-in-hand.

Privacy must have end-of-life

Privacy must offer end-to-end lifecycle protection of user data. This means engaging in proper data minimization, retention and deletion processes.

Besides the overall end-of-life of a system, there is operational data that expires during the use of the system.

Using a XcooBee connection, the XcooBee event system will inform your systems of any expiring data and data that needs to be deleted. You can have XcooBee monitor every expiration point for you and respond to API events to confirm deletions during the regular operational period as well as at the end of life situations.

Privacy must be user-centric

Privacy must be user-centric. This means giving users granular privacy options, maximized privacy defaults, detailed privacy information notices, user-friendly options and clear notification of changes.

Creating a solid and easy privacy UI is hard. Inventing it for every one of your systems only adds cost. XcooBee is built from the ground-up with end user experience in mind. It can be your bridge to your legacy systems. Rather than retro-fitting you can have a Privacy Network work for you to make user experience a key deliverable.

Application Lifecyle Impact

In general, you should think about all life cycle stages of your application and ask yourself whether you are applying the basic tenants of the Privacy-by-Design framework. Let’s look at common stages of application construction:

• initial design stage
• throughout application lifecycle regular user’s engagement with your app
• after the user’s engagement has ended
• and after the app is discontinued

Initial Design State

• Create a privacy-impact assessment template for your business to use for all functions involving personal data.
• Review contracts with partners and third parties to ensure the data you pass on to them is being processed in accordance with Privacy by Design and GDPR.
• Don’t require unnecessary app permissions, especially those that imply privacy invasion, such as access to contacts or to the microphone.
• Audit the security of your systems.
• Check whether you need to store data in the first place
• Can you use pre-build component blocks from a Privacy Network like XcooBee

New Lifecyle Tasks

• Minimize the amount of collected data.
• Minimize the amount of data shared with third parties.
• Where possible, pseudonymize personal data.
• Revisit contact forms, sign-up pages and customer-service entry points; check whether you can use XcooBee consents instead.
• Enable the regular deletion of data created through these processes; check whether you can you use XcooBee data lifecycle management

User Engagement

• Provide clear privacy- and data-sharing notices.
• Embed granular opt-ins throughout those notices.
• Don’t require social media registration to access the app.
• Don’t enable social media sharing by default.
• Separate consent for essential third-party data sharing from consent for analytics and advertising.
• All of these have XcooBee components you can plug-in 

End of Life

• Periodically remind users to review and refresh their privacy settings. Encourage XcooBee based user data management for this purpose.
• Allow users to download and delete old data. You can use XcooBee Subject Access Request support to automatically fulfill such requests.
• Delete the data of users who have closed their accounts.
• Delete all user data when the app’s life comes to an end.

Detailed Questions and Tasks for Developers

All this seems interesting but what does it really mean for developers what questions do we need to ask to make better Privacy-By-Design decisions.

You can certainly use many of the XcooBee building blocks (APIs, SDKs, Bees, Consents, etc.) to create the solutions, but you should have clarity over the scope by answering and documenting questions like these:

Data Collection and Retention

Here is a list of questions that you should consider clarifying:

• What personal data is processed?
• How is that data collected and retained?
• Is the data stored locally, on our servers, or both?
• For how long is data stored, and when is the data deleted?
• Is the data collection and processing specified, explicit, and legitimate?
• What is the process for granting consent for the data processing, and is consent explicit and verifiable?
• What is the basis of the consent for the data processing?
• If not based on consent, what is the legal basis for the data processing?
• Is the data minimized to what is explicitly required?
• Is the data accurate and kept up to date?
• How are users informed about the data processing?
• What controls do users have over the data collection and retention?

Technical Security Measures

• Is the data encrypted?
• Is the data anonymized or pseudonymized?
• Is the data backed up? Where?
• What are the technical and security measures at the host location?
• Is data moved for storage outside legal boundaries?

Personnel

• Who has access to the data?
• What data protection training have those individuals received?
• What security measures do those individuals work with?
• What data breach notification and alert procedures are in place?
• What procedures are in place for government requests?

Subject Access Rights

• How does the data subject exercise their access rights?
• How does the data subject exercise their right to data portability?
• How does the data subject exercise their rights to erasure and the right to be forgotten?
• How does the data subject exercise their right to restrict and object?

Legal

• Are the obligations of all data processors, including subcontractors, covered by a contract?
• If the data is transferred outside the European Union, what are the protective measures and safeguards?

Risk Assessment

• What are the risks to the data subjects if the data is misused, mis-accessed, or breached? XcooBee has a nice breach cost calculator you can use.
• What are the risks to the data subjects if the data is modified?
• What are the risks to the data subjects if the data is lost?
• What are the main sources of risk?
• What steps have been taken to mitigate those risks?

Summary

The Privacy-by-Design philosophy touches all aspects of programming and even goes beyond. We can see this as cumbersome, or as a force for good that makes the software we create for our users better.

We at XcooBee clearly see the effort involved but believe that in the future developers and companies that implement these principles will be the winners in the privacy battles.

We offer many tools to help get your systems aligned and make the conversation to Privacy-by-Design principles easier so you don’t have to re-invent everything.

Regardless of building blocks you use, we hope you will consider creating improved software with Privacy-by-Design principles built-in.