With the advent of the GDPR and other privacy regulation the way developers need to think about developing components and software overall needs to shift.
Some common outcry here is that it is difficult and costly to do this. However, this does not have to be the only lesson learned. 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
Even if you develop software outside the EU you should still may be impacted by it.
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.
A good implementation of Privacy-By-Design software philosophy will ensure that what you create meets the spirit of the law and has a good chance of being compliant with the legal requirements.
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.
For example using the XcooBee data network store, user data is never stored insecure and only retrieved when needed. You can use the XcooBee API or SDK to retrieve data on demand.
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.
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.
However, you can use the XcooBee services to monitor your software and interact with old software as a governor on privacy issues.
Privacy must be a positive sum
Privacy must be positive sum and should avoid dichotomies. For example, PbD sees an achievable balance between privacy and security, not a zero-sum game of privacy or security.
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.
A XcooBee connection will inform your systems of any expiring data and data that needs to be deleted. You can XcooBee monitor every expiration point for you and respond to API events to confirm deletions.
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.
XcooBee is built from the ground up with end user in mind. It can be your bridge to 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.
- initial design stage
- throughout lifecycle
- throughout the user’s engagement with your app
- after the user’s engagement has ended
- and after the app is mothballed
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.
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.
- Enable the regular deletion of data created through these processes.
- 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.
End of Life
- Periodically remind users to review and refresh their privacy settings.
- Allow users to download and delete old data.
- 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. Many of these have support in the XcooBee Privacy Network through our API and SDK tools.
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?
- What are the technical and security measures at the host location?
- 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?
- 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?
- What are the risks to the data subjects if the data is misused, mis-accessed, or breached?
- 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?
The Privacy-by-Design philosophy touches all aspects of programming and even goes beyond. We can see it as cumbersome, or as a force for good that makes the software we create for our users that much 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.