DPIA – How to assess projects in an Agile environment

August 2019

More than 50% of organisations have adopted Agile methodologies for technology projects – including those which involve the processing of personal data.

Agile methodology advocates an iterative planning process and an evolutionary ‘step-by-step’ development of software components via rapid sprint cycles. Changes to the design can be made throughout this evolutionary process.

From a data protection perspective Agile working presents some challenges. The full scope of data processing is often unclear at the start of a project. So how do you get Privacy by Design embedded into an Agile project?

Conducting a Data Protection Impact Assessment (DPIA) is a legal requirement for certain projects, as set out in the ICO’s guidance. Even when a DPIA is not mandatory it’s often prudent to consider the privacy impacts of any new processing.

Looking at a project through the ‘privacy lens’ at an early stage can act as a ‘warning light’, highlighting potential privacy risks before they materialise and whilst measures can be put in place to reduce the risks.

Conducting a DPIA and documenting the outcomes is an important method of demonstrating that privacy is being taken seriously – it is evidence of an organisation’s commitment to accountability – a core principle and requirement under GDPR.

If your organisation uses Agile, evolving your DPIA process to work for Agile projects has become more important than ever.

Working together to overcome challenges

It’s important that all areas of the business collaborate to ensure projects can proceed at pace, without unnecessary delays. Compliance requirements must be built into Agile solution designs alongside other business requirements – just as ‘Privacy by Design’ intended.

Therefore it’s vital for those with data protection responsibilities to engage business and project management stakeholders at an early stage, to get to grips with the likely scope of processing and start to identify potential privacy risks, whilst there’s still time to influence solution design.

Here’s just 2 common examples:

  • Many organisations with legacy data systems want to build a data warehouse to bring disparate data silos under one roof, gain new insights and drive new activity. It’s important to assess any privacy impacts this new processing could give rise to and using Agile new capabilities may be created over months or years. So it’s important to conduct an initial assessment at the start, but stay close to the project as it evolves and be ready to review again in line with sprints before data migrates, or before new components are designed.
  • Projects sometimes deliver significant new management information which includes the ability to view and/or interrogate personal data. So it’s important to review plans for access controls to ensure that access is restricted only to those who really need access.

This isn’t always easy. Given the fluid nature of Agile, there is often limited documentation available for review to aid the Compliance team.

Privacy questions often can’t be answered upfront, so there’s a need to agree what types of information is required and when it will be available for review – but crucially before designs are completed. Timings for assessment need to be aligned to feed into the appropriate sprints.

As many companies have found, embedding privacy awareness into the company culture is a big challenge and ensuring Privacy by Design is a key consideration for tech teams at the outset is an on-going task.

Top tips for ‘Agile’ DPIAs

Here are my top tips for a process that works for your teams;

  • DPIA guidance – ensure your teams know what a DPIA is in simple layman’s terms, why it’s important, the benefits of including privacy in scope from the start (i.e. ‘by Design’) and include a process flow showing the first steps in identifying if a DPIA is needed.
  • Initial screening – develop a quick-fire set of questions for the business owner or project lead which capture information around the personal data being processed, any special category data or children’s data, the purposes of processing, etc. Once it has been identified that there is personal data involved (as odd as this may sound, it is not uncommon for tech teams to be unsure at the beginning of a project whether or not personal data is actually being processed), you can assess the potential risks, if any.
  • DPIA ‘Lite’ – if there are potential risks, develop a series of questions to evaluate compliance against the key principles of the GDPR, lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality and accountability. As we have mentioned above, completing these will often need an iterative process.

The Agile environment can prove challenging, but by adopting a DPIA process that works in harmony with Agile methodology will foster a positive step forward for innovative companies and your business to continue to develop new solutions whilst complying with the GDPR.