Competing with so many complex functionalities and design requirements in today’s sophisticated applications means security and privacy are sometimes afterthoughts in product development. However, due to new and changing global and domestic privacy standards, developers must be more thoughtful about data collection, use, and handling in their development practices. Among other drivers, GDPR imposes the expectation of privacy and security built into the core of any system that involves personal information, and infringements come with heavy costs that mount significantly if organizations don’t approach privacy carefully. That is, they must weave privacy frameworks throughout the entire lifecycle of their products. It would behoove project managers to follow the guidelines Privacy by Design (PbD) has created.
The idea of PbD was born in 1995. Ann Cavoukian, who at the time served as the Information and Privacy Commissioner of Ontario, drew up the initial blueprint for the concept. She, along with the Dutch Data Protection Authority and Netherlands Organisation for Applied Scientific Research, developed a report outlining seven principles that still serve as the groundwork for PbD.
The PbD principles include: be 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. It’s clear that the intent of PbD is to urge organizations to make privacy an ingrained part of their products, rather than an add-on after rollout. 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.
Don’t design without consulting a privacy checklist
Software development teams typically break tasks into two different groups or subteams, in order to better coordinate. To mirror this common division of labor, organizations can divide a GDPR-related PbD checklist into two portions as they build their product: Front End (User Experience), and Back End (Functionality and Documentation). This list is not exhaustive; it should only serve as a guideline for developing product privacy features that comply with GDPR requirements. Consider the following sample questions suggestions of what to ask while building a system or application with privacy (and privacy compliance) in mind.
Front End (User Experience)
- 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?
- At each step of the user experience, is it clear to the user what is happening to his or her data and why?
- Does the user have enough context and information to make an informed decision about their privacy settings?
- 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?
Back End (Functionality and Documentation)
- Have involved third parties been adequately evaluated?
- Are data quality assurance measures taken both to prevent bad data coming into the system and detect inaccuracies in the system?
- Is there documentation that describes the process for how privacy has been considered at each step in the development process?
- Are there adequate measures to prevent unauthorized access of data?
- Can the user delete data, correct data, and stop or limit data from being processed further?
Treat this checklist as a guideline, not gospel
Just as any language changes over time, the privacy community now discusses PbD with more expansive meaning than its original seven principles. PbD, today, refers to any set of actions that help ensure privacy is built into software systems, applications, and even offline processes. It is this broader concept of PbD that has proven to be durable in the face of accelerating technology innovation. Changes to technology, such as the proliferation of data collection and services that essentially sell data as a product, were one impetus behind updates to European regulations and the creation of the European Union’s General Data Protection Regulation (GDPR).
Organizations can and should insert PbD into their process, even if they employ newer, faster development cycles that adhere to launch-and-learn and Agile philosophies. For example, each development sprint can examine potential PbD-enabling tactics like pseudonymization and encryption, privacy-friendly settings by default, and transparency of data practices built into the user interface design.
SEE ALSO: Why you should be thinking about data privacy and cyber liability
Consider PbD throughout the entire engineering process to mitigate risk
Though privacy is a nuanced topic and generally demands a lengthy, robust conversation across the entire development team, as well as other organizational teams, 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.
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.
The post Developers must consider privacy for the entire product lifecycle appeared first on JAXenter.
Source : JAXenter
