Embedding data protection by design into system development life cycles

Start adding items to your reading lists:
Sign in
or
Create your account
Save this item to:
This item has been saved to your reading list.

Corporate initiatives to get ready for the landmark EU General Data Protection Regulation (GDPR) are running into a conundrum: a lack of detailed GDPR guidance coming out of Brussels is hindering corporate attorneys from providing operational legal advice. As a result, GDPR workstreams involving information technology (IT) systems are stalling, waiting for the privacy engineering translation layer between the legal advice and the business requirements documents (BRDs) they need.

What should GDPR program management offices (PMOs) do to break this logjam? PMOs should consider prioritizing their workstream that addresses GDPR’s Article 25 on data protection by design and default, and embedding these requirements into their system development life cycles (SDLCs).

Get started with PwC's preference center

Our insights. Your choices.

Connect with our ideas everyday

Download the 365 app

A principles-based approach to GDPR’s Article 25

The GDPR’s Article 25 establishes the world’s first explicit requirements for data protection by design and by default. It states:

1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimization, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this regulation and protect the rights of data subjects.

2. The controller shall implement appropriate technical and organizational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.

3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this article.

Data protection design principles

A first step to translate these broad mandates into functional requirements is to define the translation layer between them: data protection design principles. Below are five of these principles as a starting point.

1. Privacy and data protection should be embedded into the design

  • Protection is embedded into the design and architecture of IT systems, technology infrastructure and business practices.
  • Privacy therefore is an integral part of any initiative from the outset.

Example: Creating a corporate culture where privacy and data protection are tone-at-top.

2. Privacy and data protection should be the default setting

  • Protection is built into IT systems, technology infrastructure or business practices by default.
  • This increases the likelihood that personal data will be automatically protected.

Example: Automatically setting consent choices to opt-out so a data subject doesn’t have to do anything to opt-out manually.

3. Support accountability

  • “Data Protection by Design and by Default” calls for the organization to assign, document and communicate accountability for its policies and procedures.

Example: Conduct routine reviews of privacy and data protection compliance.

4. Maintain transparency

  • This approach also calls for all practices to be operated in compliance with the organization’s privacy practices, and that individuals receive proper notice of privacy practices.

Example: Notices must identify the purposes for which personal data is being collected, used, retained and disposed of across the data lifecycle.

5. Put safeguards in place

  • This approach puts in place security safeguards to protect personal data from unauthorized use, access, disclosure, fraud, etc.

Example: Technical measures such as data minimization, pseudonymization and encryption.

Adding privacy by design into the waterfall model

The next step is to adapt these principles into a company’s chosen SDLC model. There are two commonly accepted models: waterfall and agile.

The Waterfall Model of the SDLC process uses a linear series of phases in which the output of each phase becomes the input for the next phase. Each phase has a hard stop, there is no going back once a phase has reached completion. The six phases typically include: (1) Requirements (2) Design (3) Develop (4) Test (5) Deploy and (6) Maintenance.

Requiring that Privacy Threshold Analysis (PTA), Privacy Impact Assessment (PIA), and Data Protection Impact Assessment (DPIA) processes are conducted during the first two phases of the Waterfall Model will increase the likelihood that “Data Protection by Design and by Default” requirements—and thus privacy and data protection requirements—are embedded into projects at the outset. Projects with personal data should have strong change-management controls and in effect not advance to the next phase until privacy and data protection requirements are approved. 

Six phases of the SDLC waterfall model

Phase 1: Requirements

  • Perform an initial PTA, PIA or DPIA
  • Review privacy and information security policies, standards, and controls to ensure they are following requirements for collection, use, retention and disposal of personal data
  • Define baseline and custom privacy system requirements

Phase 2: Design

  • Minimize data
  • Perform a formal PTA, PIA or DPIA
  • Analyze the relevant privacy controls to ensure they are designed, developed and implemented
  • Design and implement feedback to control privacy mechanisms into system

Phase 3: Develop

  • Obtain initial data subject consent on personal data collection, use, disclosure and retention
  • Ensure data subjects understand systems and process (transparency)
  • Ensure data subjects are informed on how to access their personal data and ensure it is up to date and accurate
  • Implement security measures to ensure protection of personal data
  • Perform ongoing testing and evaluation

Phase 4: Test

  • Monitor and report privacy controls through periodic testing and evaluation

Phase 5: Deploy

  • Integrate any new privacy protection methods or controls into systems for improved privacy
  • Analyze privacy policies, standards and procedures and system performances for irregularities

Phase 6: Maintenance

  • Ensure proper management of new applications and technology in production 

Agile model 

The agile SDLC model consists of an iterative approach to software development in which software is developed in incremental, rapid cycles often called sprints. Agile development is ad-hoc and continuous, while adhering to project documents as guiding principles. During the agile SDLC process, the privacy office must work with the business and technology teams to increase privacy-awareness. A pivotal step is ensuring agile teams consider privacy when deciding on which working rules and project documents to incorporate privacy principles throughout the lifecycle. The following asks are recommended to increase privacy awareness during Agile sprints:

  • Provide developers—designers, coders, testers, release managers—with a playbook
  • Provide access to domain experts 
  • Conduct workshops with developers and privacy subject matter experts

Key roles and responsibilities

A final step in the translation layer is to define roles and responsibilities for executing the SDLC tasks for data protection.

Project Management Office (PMO)

Responsible for embedding “Data Protection by Design and by Default” into projects at the outset by including deliverables such as contributing PTA/PIA/DPIA during the appropriate phases of the SDLC process, promoting accountability across projects and ensuring appropriate oversight of vendors/service providers.

View more

Information Technology (IT)

Responsible for considering privacy issues at all phases of the design and development of products and systems and ensuring the organization maintains comprehensive data management procedures, including providing relevant privacy and security training to employees and regularly assessing the privacy and security impact of projects. These responsibilities may be shared with Information Security (IS).

View more

Information Security (IS)

Responsible for and implementing privacy and security measures, such as pseudonymization and encryption and contributing to PTA/PIA/DPIA during the appropriate phases of the SDLC process. These responsibilities may be shared with IT.

View more

Business Representatives

Responsible for defining the business requirements with privacy in mind at the outset. Responsible for complying with the organization’s privacy policies, standards and procedures regarding the collection, use, retention and disposal of personal data.

View more

Privacy Office

Responsible for overseeing the Privacy Program, including embedding “Data Protection by Design and by Default” into the design and operation of an organization’s IT operational infrastructure and business practices.

View more

Related content

Contact us

Jay Cline

Privacy Leader, Principal, PwC US

Tel: +1 (612) 596 6403

Email

Alison Brunelle

Director, Cybersecurity and Privacy, PwC US

Tel: +1 (512) 867 8339

Email
Follow us
Audit and assurance Consulting Tax services Newsroom Alumni US offices Contact us

© 2017 - Mon Feb 18 22:58:33 UTC 2019 PwC. All rights reserved. PwC refers to the US member firm or one of its subsidiaries or affiliates, and may sometimes refer to the PwC network. Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details.