How can a modern software development organization deal with setting up and maintaining an ISO27001 Information Security Management System and its certification in an Agile way?
Without disrupting the existing (Agile) processes and its core values (such as self-organization).
A field of tension with which many a person struggle. After all, Agile development methods are frequently used and are based on a number of empirical processes, while Information Security in general tends to describe and implement measures for risks up front that are estimated using a predetermined model.
Typical of this is that one of the best practices of Agile development is “Just In Time Documentation”, and the the agile manifesto describes: “Working software over comprehensive documentation”. While information security, and ISO27001 in particular, is more based on “Just In Case Documentation”.
Implementing both an ISMS and the reference measures from the standard that are relevant for software development need not be very complicated. Especially not in an Agile software development organization. There are many common grounds. Just like Agile development methods, the system (ISMS) as it needs to be set up is based on a continuous improvement cycle (Plan-Do-Check-Act). Many of the relevant reference measures are often already in place; and if not, they can be implemented quickly.
Support within the teams helps in this respect. Support is created when the need for information security is indicated. One of the exercises I once initiated for this is holding a “Horror Headline” session. Invite all major stakeholders and let them know which newspaper headline is their worst nightmare with regard to the product and why. Or do, possibly unannounced, simulated hacking attempts. Often these exercises are great fun to do and they also provide interesting insights from the teams.
For the establishment of an ISMS itself, it is a matter of setting up a security team and setting up a number of (mandatory) procedures and documents. This can be achieved well by means of a Scrum process with the Security Officer as Product Owner. Management involves carrying out a number of mandatory audits on a regular basis, carrying out a management assessment and identifying risks by means of a set procedure. These risks must then be mitigated by implementing the reference measures in Annex A to the standard.
Because in a software development organization many of the relevant measures in Annex A of the standard have an impact on – or have to be realised by – the development teams, it is recommended that they be actively involved in setting up and managing an ISMS. This can be done, for example, by making the Product Owners of the various development teams’ part of the security team.
Unfortunately, various traditional (checkbox) software management processes have to be set up from ISO27001, Annex A. Make smart use of existing resources. The average modern development organisation I come across has nowadays stuffed walls with yellow Post-its that contain all kinds of information about which changes are done when, by whom; for automated deployments the necessary information is recorded. Also various related agreements are made in the Definition Of Ready and Definition Of Done. It is only a matter of structured recording; photos are often enough for this!
The most important thing is: apply the ISO27001 process as it suits your organization and start simply by using the most important aspect of your (agile) organization: teams that are able to organize themselves (and therefore enjoy responsibility).
As a Security Officer or CxO primarily work on the basis of the ISMS, create awareness and facilitate that necessaries from the standard or Annex A can easily be obtained and recorded… But most of all: help the team to understand the need for various ISO27001 controls.