1.7 KiB
This note relates to the ISO27DIY Business model
Probleem: de GRC software wordt aangekocht om een operationeel probleem van de compliance officer op te lossen.
De software komt meestal pas later (en wordt pas gevuld als de kennis van wat ISO is en van het proces er al is, als het jargon al is ingesleten)
Eerst komt de consultant uitleggen hoe ISO werkt en wordt hulp geboden bij Wat je Waar moet documenteren, en Hoe (denk aan de risico-identificatie en de stakeholder-analyse: wat is een in-scope risico, hoe verwoordt je het precies. Wat is een stakeholder, wat is zijn in-scope belang, etc.). Dan ontstaat de documentatie, meestal in Excel en Word documenten. Dan de realisering dat het onhandig is en niet schaalt. Dan wordt software geselecteerd en geïmplementeerd. Pas dan wordt de software daadwerkelijk gebruikt, en meestal door een deskundige staffunctionaris.
Inmiddels staat het dan zover af van de dagelijkse praktijk op de werkvloer, dat de heilige graal van security by design en in de haarvaten van de organisatie, niet gehaald kan worden. Voor iedere (interne) audit is extra effort nodig om te graven in de operationele documentatie om de audit documentatie naar boven te krijgen.
Wat nu als je de documentatie kun genereren op het moment dat relevante feiten (identificatie en weging van risico’s, keuze van maatregelen, bewaken van de implementatie, monitoren van de resultaten en bijsturen) plaatsvinden? Door ze voorafgaand aan een SCRUM, Team- of afdelingsoverleg of ontwerpmeeting te agenderen, en ze in de notulen te ‘marken’? Door operationele reports en logs te koppelen naar de ISO-administratie?