Agile werken en denken in relatie tot ISO 27001 (of welke geformaliseerde certificering dan ook)

Als Scrum Master ben ik onlangs betrokken geweest bij het verkrijgen van een ISO 27001 certificering voor mijn eindklant.
Het hebben van een ISO 27001 certificering als organisatie betekent dat het voldoet aan de privacy- en securityrichtlijnen die zijn gedocumenteerd door ISO: https://www.iso.org/standard/54534.html.

De certificering omvat richtlijnen voor de volgende gebieden:

Kantoor toegangsbeveiliging
Werkplek beveiliging
Infrastructuur (netwerk & telefonie) beveiliging
Applicatie en data beveiliging

De richtlijnen concentreren zich vooral op de werkprocessen en minder op (technische) oplossingen. Het verwijst echter wel naar andere standaarden. Bijvoorbeeld op het gebied van applicatie & data beveiliging, verwijst het naar OWASP richtlijnen.

De perceptie van iedere vorm van certificering is dat het bureaucratie introduceert die wordt vastgelegd in uitgebreide documentatie die (bijna) niemand leest. Ik hoop met dit artikel te beschrijven dat deze perceptie enige nuance verdient.

De nuance wil ik aanbrengen door middel van het doorlopen van het ‘Agile Manifesto’ (https://agilemanifesto.org/iso/nl/manifesto.html). Hoewel het Manifesto al twee decennia geleden is opgesteld, is tegenwoordig het voor bedrijven nog steeds het handvat voor softwareontwikkeling. Het Manifesto heeft 4 kernwaarden:

Mensen en hun onderlinge interactie boven processen en hulpmiddelen
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan

Discussie over deze kernwaarden heb ik nogal eens waarbij het idee leeft dat zodra ‘agile’ wordt gewerkt, er anarchie is over de software implementatie en bewaking. Ook dit verdient nuance.

Mensen en hun onderlinge interactie

Het voorbereiden op een ISO-audit vereist een nauwe samenwerking tussen afdelingen en medewerkers om de processen in kaart te brengen. Deze ‘agile’ waarde komt juist tot zijn kracht op het moment dat processen worden beschreven die ondersteunend zijn aan de medewerkers. Een Scrum ritueel als bijvoorbeeld Sprint Review kan hierbij faciliteren. Doordat mensen samenwerken komen tekortkomingen en kansen boven drijven. ISO-richtlijnen geeft hierbij handvatten voor aandachtsgebieden. Kortom, als we deze kernwaarde beschouwen, versterken ISO en Agile elkaar.

Werkende software

Om tot werkende software te komen zijn nu eenmaal binnen een team afspraken noodzakelijk die beschrijven hoe code de ‘softwarefabriek’ doorloopt. Hierbij is cruciaal dat vooraf acceptatiecriteria zijn opgesteld en dat deze bij oplevering worden getoetst. ISO stelt geen voorwaarden welke stappen de ‘softwarefabriek’ moet bevatten. Echter, het stelt voorwaarden dat vooraf wordt nagedacht over de gevolgen voor de gebruiker of organisatie op het gebied van gegevens beveiliging. Het team heeft hiervoor velden in Azure DevOps geïmplementeerd om de gevolgen op beveiliging en privacy te documenteren (‘Security and privacy by design’). Het vooraf opstellen van de verwachte gevolgen voorkomt bevindingen later in de ‘softwarefabriek’.

Veel teams hebben een platform om hun software te documenteren. Vaak bevat dit platform ook een beschrijving van hun ‘softwarefabriek’. Het ontwikkelteam heeft ervoor gekozen de documentatie te borgen in hun ‘eigen’ omgeving; Azure DevOps. Deze heeft een Wiki. Op deze manier is de impact voor het team minimaal omdat het geen andere omgeving eigen hoeft te maken. Voor de softwareontwikkelaars is code eigenlijk de documentatie.

De Wiki die in het ontwikkelteam gebruikt bevat niet meer documentatie dan de samenhang van onderdelen in het landschap. UML-modellen worden niet vereist en ook niet gebruikt omdat deze te weinig actueel blijven. De Wiki helpt nieuwe teamleden tijdens het inwerkproces.

Daarnaast is de integratie met het volgen van de softwareontwikkeling naadloos. In de documentatie zijn gegevens als bijvoorbeeld openstaande bugs online beschikbaar bij de documentatie.

Samenwerking met de klant

Vooral op het gebied van vooraf nadenken over gevolgen op privacy en beveiliging komt het team nader tot de klant. Hierbij wordt het discussiëren over een wens met dubieuze gevolgen niet uit de weg gegaan. Het heeft de organisatie geholpen om voor grotere user stories (‘Epics’) een “Data Protection Impact Assessment” op te stellen. Net zoals bij de vorige kernwaarde, geeft dit eerder in het ontwikkelproces heldere verwachtingen over de gevolgen en daarmee de maatregelen die erbij horen.

Inspelen op verandering

ISO stelt geen eisen over het te volgen ontwikkelproces. Als Scrum Master faciliteer ik de werkvormen en rituelen van het Scrum Framework. Het is een kwestie van documenteren hoe deze werkvormen in dagelijkse operatie worden uitgevoerd. Uitkomst van een Retrospective worden opgenomen in de Product Backlog. Bevindingen en opmerkingen tijdens een demo worden als ‘bevinding’ opgenomen in de Product Backlog.

Zolang de werkvormen en de workflow van de organisatie zijn gedocumenteerd, is deze kernwaarde eenvoudig te beschrijven conform ISO-richtlijnen. Het is eigenlijk niet meer dan ‘prove what you have written down’. Azure DevOps biedt hiervoor uitstekende tracking gereedschappen waarbij vanaf user story tot en met productie oplevering alles is te herleiden.

Conclusie

Eerlijk is eerlijk, vooraf was ik sceptisch over het te volgen traject. Echter, juist de kernwaarden van het Agile Manifesto hebben de organisatie geholpen om pragmatisch en gestructureerd zich voor te bereiden op de ISO-certificering. Als Scrum Master had ik het belang dat de gevolgen voor het ontwikkelteam werden beperkt. Dat is gelukt; geplande opleveringen en kwaliteit hebben geen nadelige gevolgen ondervonden.

Ik kan melden dat de organisatie met vlag en wimpel het ISO 27001 certificaat heeft gehaald. Wil je meer weten hoe ik dit het met de organisatie en het team heb aangepakt? Ik ben bereikbaar via akraak@bergler.nl, 076 – 572 02 00 of info@bergler.nl.