Agile working and privacy go hand in hand
By Geert Eggens
Since the introduction of the GDPR, privacy has never been so prominent. The GDPR requires by law that privacy has been considered in advance when realizing new services, processes and systems. This is called “Privacy by Design” (hereinafter PbD). Agile working, such as scrum, is delivered per sprint of 2-4 weeks, with a focus on rapid implementation of new functions. Privacy is often still regarded as a side issue or final element. I also repeatedly hear talk about the “privacy ballast” that would hinder Agile working and would also be contradictory to Agile principles. With this blog I want to emphasize that “Privacy by Design” fits perfectly into Agile working and that the two even reinforce each other.
In practice, I see that privacy compliance comes across as imposing, because it would hinder Agile working and would not respect the Agile principles. Agile working has been a successful software development method for decades. Absolutely against the Agile working method is the subsequent testing of the privacy aspects of the delivered designs and products, via a separate so-called “data privacy impact assessment” (DPIA) required by the GDPR. An alternative to this, drawing up a privacy design prior to the sprints, not only goes against the Agile frameworks, but also hinders the implementation of the delivered functionalities. Even if privacy measures are designed in advance, it may still happen that these measures still have to be built in after the product has been delivered.
The required privacy measures must be designed and built in together with the features of the products they apply to. So hand-in-hand, to strengthen each other.
How can Agile working and privacy reinforce each other?
Precisely by embracing Agile working and also applying privacy based on the Agile principles. This proactively ensures that every product delivered in the sprints follows the PbD principles. This is a concrete approach within the framework of Agile working.
In Agile working there are three logical moments at which design choices are made for the functionality and products to be delivered. These are the so-called sprint 0, the sprint planning and the sprint review. Privacy should also be reflected in these three moments.
Examples of privacy “compliance” user story
- For each user story to be realized, the possible impact on privacy has been assessed in advance by the data protection officer.
- Every processing of personal data is included in the processing register.
- The privacy/security test (carried out automatically) has been completed successfully and has not yielded any issues with the categories “critical and high”.
The sprint planning meeting decides before a sprint which user stories will be worked on, which therefore directly influences the scope of the design work. It is possible to draw up user stories from the perspective of the data protection officer that need to be realized.
Examples of privacy user stories
- User story: right to be forgotten
If the personal data are no longer used for the purpose for which they were obtained, as a data protection officer I want them to be deleted from our systems and the systems of our suppliers in accordance with the stated retention periods.
- User story: anonymize personal data
As data protection officer, I want all personal data recorded and collected within our systems for analysis purposes to be anonymized so that we can use valuable and non-personal information.
- User story: security
As a data protection privacy officer, I want the personal data in the log files to be encrypted, so that no personal data can become available.
The sprint review marks the end of a sprint and is where deliverables are shown and accepted or rejected. The sprint review also includes the privacy-related user stories and assesses whether they have been sufficiently realized or can actually be considered "done".
By seizing these three logical moments, PbD and Agile reinforce each other excellently.