Op basis van de BIO dien je als gemeente een Information Security Management System, ofwel ISMS, te implementeren, bij te houden en continu de verbeteren. Een ISMS borgt risicomanagement op basis van de plan-do-check-act-cyclus en helpt zo het onderwerp informatiebeveiliging op de agenda van bestuur en management te krijgen/houden. In deze blog ga ik niet in op het proces zelf, maar wil ik graag de focus leggen op het selecteren van een ISMS-tool (software) om dit proces te ondersteunen.

ISMS binnen de gemeente

In het licht van gemeentelijke informatiebeveiliging wordt er veel geschreven en gepraat over ISMS. Zo schreven wij al eerder de blog ‘ISMS & GRC, wat kun je er eigenlijk mee?’ en de blog ‘ISMS conform ISO 27001’, waarin je meer kunt lezen over het ISMS-proces zelf. Vaak zie je dat bij ISMS de nadruk ligt op het proces zelf. Zo moet je stappen (en uitkomsten) documenteren, die weer dienen als bewijslast. Maar documenten moet je bijhouden, papier is geduldig en een plan verdwijnt al gauw in de la. Daarnaast is ISMS niet alleen gericht op het opslaan van documenten, maar ook op de processtappen (workflow) die je moet nemen. Daarbij is het handig als je zicht hebt op waar je in het proces bent en wie aan zet is (óf bij wie werk blijft liggen). De oplossing? Een ISMS-tool. In de praktijk zien we vaak de volgende redenen om zo’n tool te implementeren:

1. Er is nog geen ISMS-proces geïmplementeerd, en men wil de tool gebruiken om dit te bewerkstelligen.
2. Er is een ISMS-proces geïmplementeerd, maar deze werkt nog niet zoals het zou moeten en men hoopt met een tool dit beter te kunnen faciliteren.
3. Of, er is een ISMS-proces geïmplementeerd wat goed blijkt te werken, maar er is ondersteuning nodig om dit allemaal te stroomlijnen.

Zoals je ziet is het dus ook mogelijk een succesvol ISMS-proces te implementeren zonder dat hier tooling bij komt kijken.

Keuze van een ISMS-pakket

Wanneer je besluit een ISMS-tool te willen aanschaffen, waar moet je dan opletten? Het lijkt vaak gemakkelijk om zelf een pakketselectie te maken, maar in praktijk blijkt dit toch vaak complexer dan gedacht. Het is belangrijk om vanaf het begin goed na te denken over wat je met het ISMS-pakket wilt bereiken. Indien je dit namelijk goed doet, dan plukt de gemeente hier nog jarenlang de vruchten van. Anderzijds kan een verkeerde selectie ertoe leiden dat je het pakket niet (goed) gebruikt, wat zonde is van de investering. En alles daartussenin zijn uiteraard gemiste kansen.

Bepalen behoefte

Vaak zie je dat gemeenten beginnen met het uitnodigen van allerlei leveranciers die flitsende presentaties geven over wat hun pakket allemaal kan. Door deze mooie verhalen kun je het mogelijk te groot maken en het systeem te uitgebreid implementeren, terwijl de gemeente daar nog helemaal niet aan toe is. Het is daarom beter om eerst de focus te leggen op het bepalen van wat de gemeente nu écht nodig heeft (en mogelijk in de toekomst) en pas daarna te kijken naar welke leverancier hier het beste bij past.

De allereerste en belangrijkste stap is dan ook het in kaart brengen van de behoefte: Wat wil je met de ISMS-tool bereiken? Wat moet het resultaat zijn? Wat moet het kunnen doen? Welke eisen stel je aan de software? Om een goed beeld te krijgen van wat je nodig hebt, zul je daarnaast de processen die je wilt laten ondersteunen door een ISMS-tool in kaart moeten brengen: Welke processen zijn er? Wie zijn hierbij betrokken? Wat hebben alle gebruikers van het systeem nodig? Et cetera. Indien je dit in kaart hebt, kun je zorgvuldig het traject doorlopen voor het kiezen van een ISMS-tool.

De toolselectie

De stappen in een toolselectie zien er globaal als volgt uit:

Stap 1: Bepalen programma van eisen en wensen

Hierbij gaat het om de functionele eisen en wensen met betrekking tot wat het softwarepakket moet kunnen doen, denk hierbij aan ondersteuning die je nodig hebt tijdens en na de implementatie, eventuele conversies wanneer je al informatie in een ander systeem hebt staan die overgezet moet worden, eventuele interfaces met andere systemen (bijv. datawarehouse), maar ook niet-functionele eisen en wensen (o.a. SLA eisen, on-site, proven technology). Bijvoorbeeld: een eis zou kunnen zijn dat er bij updates automatische notificaties richting de CISO gaan en een wens dat er een mogelijkheid is voor het printen van diagrammen en dashboards. Tip: neem de BIO als normenkader voor het opstellen van de knock-out (eisen) en nice-to-have (wensen) criteria.

Stap 2: Maak een longlist

Met het programma van eisen en wensen in het achterhoofd kun je een eerste selectie van potentiële leveranciers en pakketten maken die in aanmerking komen. Stel een lijst op van maximaal 8 potentiële leveranciers en pakketten.

Stap 3: Stel een Request for Information (RFI) op

Dit is een document waarin je leveranciers vraagt om meer informatie omtrent hun dienst of product. Met een RFI maak je dus uitgebreider kennis met de potentiële leveranciers die je hebt opgenomen in je longlist. Hoe scherper je RFI is opgesteld, hoe beter de match. Een RFI kan bestaan uit de volgende onderdelen:

• Een korte vragenlijst (bijv. de knock-out-criteria).
• Vraag om algemene leveranciersinformatie (o.a. grootte bedrijf, financiële cijfers).
• De mate waarin het product binnen gemeenten gebruikt wordt (penetratiegraad).

Op basis hiervan kun je je initiële longlist terugbrengen tot circa 3 tot 5 leveranciers.

Stap 4: Doe een Request for Proposal (RFP)

Na de RFI volgt een RFP. Een RFP is een offerteaanvraag bij de overgebleven leveranciers en bedoeld om een gedetailleerd inzicht te verkrijgen in de leverancier en het pakket. Een RFP kan bestaan uit:

• Een uitgebreide vragenlijst met daarin een situatieschets en toelichting op de functionele scope.
• Vraag naar meer informatie over de prijsstelling van het te leveren ISMS-tool (o.a. initiële kosten, terugkomende kosten (jaarlijks), advieskosten).
• Opvragen beheer inrichting (o.a. SLA, contracten). Het is ook mogelijk om een eigen conceptcontract mee te sturen.
• Evaluatiecriteria: waar moeten de offertes aan voldoen en waarop worden ze beoordeeld?

Stap 5: Maak een shortlist

Op basis van de ontvangen antwoorden en een eerste prijsindicatie, kun je een selectie maken van de leveranciers die op inhoud en volledigheid het best scoren. Zij blijven over op je shortlist.

Stap 6: Proof of Concept (PoC)

Met de leveranciers van de ISMS-tool die op je shortlist zijn overgebleven kun je afspreken dat ze een PoC gaan opleveren. Hiermee kunnen zij hun deskundigheid aantonen en laten zien dat ze voldoen aan de verwachtingen. Dit doen zij door middel van het uitwerken van een casus voor de gemeente. Op basis van deze casus worden demonstraties georganiseerd. Zorg dat vanuit de gemeente de juiste mensen zijn aangehaakt om een beoordeling van de PoC te kunnen doen. Het gaat hierbij niet alleen om de CISO maar ook vertegenwoordiging van lijnmanagers en de IT-afdeling. Ik zou voorstellen hier een officieel beoordelingsteam voor samen te stellen, die vanaf de start (opstellen eisen en wensen) tot het eind meeloopt in het selectietraject. Tevens kun je in deze fase meer informatie opvragen bij referenties van de leverancier.

Stap 7: Definitieve gunning

Tot slot volgt de definitieve gunning. Op basis van de resultaten van de PoC, en deels ook additionele overwegingen, maak je een keuze voor een leverancier waar je de ISMS-tool aanschaft. Zorg ervoor dat je van tevoren een duidelijk overzicht maakt van de selectiecriteria zodat je de leveranciers per onderdeel kunt beoordelen.

Meer informatie over inkoop software

Om professioneel inkopen te stimuleren en leveranciersafhankelijkheid te beperken heeft PIANOo, Expertisecentrum Aanbesteden van het ministerie van Economische Zaken en Klimaat, enkele geleerde lessen geformuleerd specifiek voor de inkoop van software. Je vindt deze hier.

Heb je naar aanleiding van deze blog vragen of hulp nodig om binnen jouw gemeente een ISMS-pakket aan te schaffen, neem dan gerust contact met ons op.