Challenges to implementing continuous delivery and data protection by design and by default
In a series of articles, I will present a way of continuously delivering software while protecting the privacy of natural persons by design and by default.
First of all. I am not a lawyer. I am a developer who is interested in national and international privacy and data security regulations and their implications on the software development process. If you want legal advice and/or are looking for an interpretation of how the regulations apply to your organization, don’t read further and contact your lawyer instead, but if you want to know the practical implications of GDPR on continuous delivery, you have come to the right place. I know of cases where it’s some times done the other way around, but I wouldn’t recommend it.
When building a house, you need to have an overview of all the laws and regulations that govern the design and construction of a house. The design must adhere to the building code to obtain planning permission, usually from a local council. There are the construction laws which regulates the contract negotiations and arbitration, planning and employment and so on. Historically, with some notable exceptions, that has not been the case for software builders. When the software architect and developer refer to laws, It’s usually through anecdotes like Murphy’s law or Conway’s law and so on. None of them has anything to do with the laws of man or the laws of nature. They are just meant to be funny with a touch of wisdom.
This is no longer the case.
Doing software development lawfully is more than just abiding by anecdotes. Banks and hospitals have known this for years, but for many of us, the reality is just starting to sink in.
GDPR adds requirements in regards to the software development process, which make automation and continuous delivery much more challenging to implement. Due to our history and culture, it’s easy for us, software builders, to quickly distance ourselves from these requirements as they often are derived or a consequence of regulatory articles like: «data protection by design and by default». art. 25 or “Security of processing” art. 32 and therefore lacking in context and concrete examples.
Most standardization schemes like the ISO 9001, ISO 19600 and ISO 27001 have had a bad reputation being associated with “waterfall” development meaning that they introduce too much unnecessary documentation, bureaucracy, and ceremony to be useful.
No wonder, it’s all too easy to implement laws and standards in ways that make continuous delivery more difficult. But, with the right security and automation mindset, that is not necessarily so. In fact, these constraints force the leaders of our companies to take automation and continuous delivery seriously considering that iterative, incremental delivery is the key not only to effective risk management, but also to implement data protection by design and by default.
Data protection by design and by default requires the controller and processor to take an active and continuous approach to risk management. Control mechanisms to protect the privacy of the natural person needs to be designed up front and continuously reviewed and monitored during development and production operations to make sure the rights and freedom of natural persons are upheld according to the design. What better way to incorporate your approach to risk management, design, review, and monitoring than by embedding them into your continuous delivery strategy?
That said. Easier said than done. Automating privacy testing, review and monitoring are difficult to do as it often isn’t data alone, but connections between data that reveal whether the data is personal identifiable or special category in nature.
Maybe you want to scale your development efforts by leveraging microservices. Finding these connections when you are developing 50–200 independent services are impossible without automation, but the need for data flow testing and analysis and privacy review makes automation difficult.
Even when manually doing privacy testing and reviews, being able to identify PII or SPI data structures requires a high degree of privacy awareness among the developers and/or architects doing the review.
So how can we continue to deliver software at the same pace we used to while abiding by the law?
I believe you can do so and want to share with you a set of points that I am using myself and which I believe you need to extend your continuous delivery strategy with in order to succeed.
- Build a culture for Continuous delivery and Data protection by design and by default.
- Repair broken windows.
- Set the stage for organizational change
- Lead from behind, build alliances and team collaboration - Restrict access to privileged environments.
- Managing access control risk for compliance
- Secure your privileged environments
- Prevent unauthorized processing by ensuring both the integrity and the confidentiality of the system - Automate for traceability, visibility, and approval
- Ensure traceability and visibility through your whole application life-cycle.
- Create a change management process for making changes to privileged environments.
- Create a continuous process for review and release approval. - Quality assurance and approval of tools and third-party software
- Take into account the data subject's right to protection when developing and designing” applications and services.
- Show due regard to the state of the art.
- Maintain an approval process for new tools, and third party software.
- Conduct regular tools and libraries reviews.
- Read the security and privacy documentation of potential service providers and partners carefully before selecting and approving new cloud providers and development partners. - Security and privacy test your system
- Adopt a “Security by design and by default” approach to security during development and testing.
- Automate all your security tests and run them against your CI environment.
- Test your third party components as if they were your own.
- Test your incident response procedures and review, and possibly test, all configuration changes for security concerns.
- Load test the system to confirm a certain level of availability.
- Test your privacy. - Conduct security and privacy reviews
- The tools and library review.
- The security review.
- The privacy review.
- Automating your privacy and security review process - Customer satisfaction and incident response plans
- Notify the controller and supervisory authority on security and privacy breaches.
- Conduct regular fire drills.
- Empower your incident response team
- Apply “force multiplication” to your incidence response strategy.
- Give exceptional service.
This is all for now, but I will come back to each point In the following series of articles. I will explain how you can address each of the points in the list and share my experiences with and address challenges in regards to implementation while keeping the amount of documentation, bureaucracy, and ceremony to a minimum. You’ll hear from me soon.
