Making Privacy Agile: Privacy Impact Assessments for an Agile IT Environment
By Waël Hassan, PhD
Current models for Privacy Impact Assessments (PIA) assume a staged, gated process for software development. With the increasing popularity of agile IT, a software development process in which programs are continually improved and revised, privacy assessors can find it difficult to keep track of changes and ensure that proper checks are in place. We propose an agile PIA model that can reduce confusion, increase compliance and improve relationships between privacy and IT.
Privacy Impact Assessments (PIAs), a best-practice risk assessment tool for initiatives involving the use of personal information, aim to identify, measure, and mitigate privacy risks. PIAs evaluate an initiative’s management of privacy by analyzing policies and processes for the collection, retention, use, and disclosure of information. This type of systematic, end-to-end analysis is most effective when it is integrated into the planning of a new initiative. A PIA during the design phase of a project can identify risks before they arise and enable the seamless integration of privacy best practices into design.
In an information technology (IT) context, a comprehensive PIA fits well into the traditional, waterfall method of software development. This method’s four stages, analysis, design, implementation, and testing, form a systematic and gated approach which allows for thorough quality assurance before software is launched. A PIA during the design phase forms part of this process.
However, the waterfall method has become less popular. Largely because of its deliberate and thorough process, projects usually end up behind schedule and over budget. The newer model of software development is the agile method: rather than designing, testing, and launching software packages as a whole, developers create a program prototype, set up the software interface, and develop and release features one at a time. Users start with a simple version of the software and add features as they are released. Each feature is developed in a development “sprint” of about two weeks. This flexibility not only allows for quicker release but also makes it easier to refresh programs by simply adding or replacing specific features rather than reworking the whole program.
Privacy officers have made efforts to adapt PIAs to an agile IT environment. Often, a generic PIA is conducted based on the software’s conceptual system design. The PIA is then typically refreshed with each major redesign or new feature, often at considerable expense. However, smaller changes or features are usually released without any evaluation from a privacy standpoint. These changes can nonetheless pose significant privacy risks, especially when numerous small changes together substantially alter the operation of a program. Because of the constantly evolving program design, privacy officers find it difficult to keep track of new developments and to discern what needs to be re-assessed from a privacy perspective. This challenge very often results in tensions between software developers racing to release a new feature and privacy officers arguing for checkpoints for compliance evaluation.
These difficulties can largely be addressed by an approach to privacy assessment that mirrors the distinct activities making up the agile IT development process. Three natural points of contact between privacy and agile software development are:
1. Development Process
One of the major difficulties in conducting privacy assessments during the software development process is that communication between privacy staff and IT staff can be fragmented and unproductive. A simple communication system can cut across confusion and inefficiency: when coding features, software developers tag each data variable in the program code that corresponds to data collection (entering data), retention (saving or storing data), use (processing, editing, managing, or linking data) and disclosure (sending data). Privacy staff then assesses the compliance of the actions represented by the tagged variables. When a feature is altered, privacy staff will only need to re-examine tagged variables which have been changed.
2. Application
Changes in user experience (software interface) are often overlooked from a privacy perspective. However, interface changes can make certain features easier or more difficult to access or change, which can affect privacy. For instance, an interface redesign that allows predictive name typing based on user input (i.e. once a few letters of a name have been entered, the interface suggests names beginning with these letters) is a major privacy risk. If the data management process has not changed, but the interface has been altered, privacy officers can refresh their assessment of the interface only without re-examining the process.
3. Release Management
Before new features or updates are released, privacy staff does a high-level review, checking that appropriate tests have been done, licensing is in place, and any design changes have been approved from a privacy standpoint. These due diligence checks constitute a final gate before release, ensuring that privacy staff has access to the most recent information when they refresh the privacy assessment.
The processes of agile IT and privacy assessment have often been at odds with each other, but this does not have to be the case. A modular approach to privacy assessment that mirrors the agile IT process can greatly improve communication between IT and privacy staff, leading to increased compliance and saving time, resources, and frustration. By clearly separating program areas that have and have not been assessed, an agile privacy assessment process eliminates both assessment gaps and duplication of work. In contrast to established PIA models better suited to a waterfall development process, an agile PIA model fits smoothly into an agile IT process of continuous change, turning privacy from a roadblock into an unobtrusive safety check.