Building for Privacy: a How-to Guide for Application Developers

DZone 's Guide to

Building for Privacy: a How-to Guide for Application Developers

Need help building privacy and security into your apps? Check out this guide for helping app devs build more secure applications.

· Security Zone ·
Free Resource

The concept of Privacy-by-Design (PbD) is not a new one. In 1995, Ann Cavoukian, the then Information and Privacy Commissioner of Ontario, developed — along with the Dutch Data Protection Authority and the Netherlands Organisation for Applied Scientific Research — a report that outlined seven principles that served as the foundation of PbD. Other global organizations have since adopted this framework.

Just as any language changes over time, the privacy community now discusses PbD with more expansive meaning than its original seven principles. Today, we talk about PbD as any set of actions that help ensure privacy is built into our systems, applications, and even offline processes. In fact, this broader concept of PbD has proven to be durable in the face of accelerating technology innovation, which was one impetus behind changes to European regulations and the creation of the European Union’s General Data Protection Regulation (GDPR).

Today, compliance with the GDPR requires end-to-end privacy sensitivity. Moreover, it demands demonstrable compliance, which additionally requires forethought in order to design proof of compliance into systems and processes. With compliance in mind, organizations today have an even stronger reason to use the tools that PbD provides to help them consider privacy through their entire development process.

Privacy-by-Design Standards Offer Guidelines for Product Development

The development of GDPR-compliant products, systems, and processes offer a perfect example of how a broader meaning of PbD can help structure thoughts — and resulting requirements — during product or services creation. Even newer and enormously fast development cycles that adhere to launch-and-learn and Agile philosophies can and should insert PbD into the process. For example, each development sprint can consider tactics like pseudonymization and encryption, privacy-friendly settings by default, and transparency of data practices built into the user interface design. User stories can include privacy considerations and lead to privacy-related requirements, such as privacy-sensitive information collection experiences. Moreover, GDPR-compliant development may require architecture considerations, like the ability to delete and correct data, track actions and access, and potentially provide to a third-party, machine-readable data on a data subject request.

On a broader scale, organizations should consider the PbD principles throughout the entire engineering process. Those principles include: being proactive and preventative on privacy rather than reactive and remedial; include end-to-end security for the entire lifecycle of your product; ensure that you maintain visibility and transparency for your customers; and respect user privacy by keeping your privacy policies user-centric.

Follow a Checklist to Remain Compliant

Though privacy is a nuanced topic and generally demands a rich conversation across the development team, a PbD checklist can help make sure that no topics are missed along the way. This checklist can be used at each stage of the development lifecycle as a reminder. As the GDPR demands demonstrable compliance, organizational leaders can also use completed checklists to document GDPR-compliant actions and explain reasons behind decisions the team makes.

To mirror the common division of labor on software development teams, organizations can divide a GDPR PbD checklist into two portions: Front End (User Experience), and Back End (Functionality and Documentation), as the below list proposes. This list is not intended to encompass all GDPR requirements, but it rather suggests questions to ask while building a system or application with privacy (and privacy compliance) in mind. These questions can be inserted into requirements, user stories, standup sprint discussions, QA, and user testing.

Front End (User Experience)

  • At each step of the user experience, is it clear to the user what is happening to his or her data and why?
  • Are the data collected and/or used in a way that is absolutely necessary for the activities the end user would expect and is that usage disclosed to the end user?
  • If there are any uses for secondary data, are clear explanations provided as to what they are? Can the user easily refuse any of these use cases without impacting the primary service? Does the user have enough context and information to make an informed decision? Is the experience designed so that the user understands the implications of the choices and is not manipulated into making a particular one?
  • If the user is not forced to make a choice, does the default apply the highest privacy setting?
  • If a data use might not be expected in the normal course of the customer/company relationship or might cause customer consternation or concern, is the offered choice an explicit opt-in (rather than an implicit opt-out)?\
  • Can the user easily ask privacy and security questions, or make related requests and complaints?

Back End (Functionality and Documentation)

  • Are data quality assurance measures taken both to prevent bad data coming into the system and detect inaccuracies in the system?
  • Are there adequate measures to prevent unauthorized access to data?
  • Does the current documentation describe all data fields used/collected, all use(s) for each data field, who is responsible for the system or data, how the data flows through the organization, what third parties are involved in the system, and the data retention period that applies?
  • Is it possible to identify for a requesting user what data the organization has about the individual and with whom the data have been shared? Can the user delete data, correct data, and stop or limit data from being processed further?
  • Is there documentation that describes the process of how privacy has been considered at each step in the development process?
  • Have involved third parties been adequately evaluated?

Thoughtfulness Will Go a Long Way to Mitigating Privacy Mistakes

Due to global and domestic privacy standards, developers must be more thoughtful in their development practices. For example, GDPR infringements come with heavy costs that can quickly add up if organizations do not approach privacy carefully and consider it throughout the entire lifecycle of their products. By maintaining a thoughtful checklist and adhering to PbD principles, organizations can effectively meet today’s new wave of privacy and data protection standards and limit organizational risk.

app security ,application developer ,back end ,front end ,gdpr compliance ,privacy by design ,security ,ui

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}