Stappenplan voor het kiezen van een ISMS-pakket


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.

Erna Havinga

Lees ons boek

Gemeenten. Bewustzijn. Privacy.

Het handboek voor informatiebewustzijn bij de lokale overheid.

Bijeenkomsten

Alleen voor CISO’s van de (lokale) overheid!

Bekijk wanneer de volgende bijeenkomst is.

Alleen voor Privacy Officers van de (lokale) overheid!

Bekijk wanneer de volgende bijeenkomst is.

Meer blogs lezen

Hoe bescherm ik mij als gemeente tegen ransomware-aanvallen?

Het kan gebeuren dat je als gemeente urenlang (of in het ergste geval dagen) niet kunt werken vanwege ransomware. In deze blog geef ik tips voor preventieve maatregelen die je kan treffen om besmetting te voorkomen. Toch getroffen? Dan vind je hier ook een handig stappenplan om de schade zoveel mogelijk te beperken.

Agenda Digitale Veiligheid 2020-2024: oude wijn in nieuwe zakken?

In februari publiceerde de VNG de Agenda Digitale Veiligheid 2020-2024 voor een veilige (digitale) gemeente. Biedt deze nieuwe agenda daadwerkelijk een nieuw handelingsperspectief? Of is het oude wijn in nieuwe zakken…

Tijdig betrokken worden als FG

In het kader van de dag van de FG een blog speciaal voor de Functionaris Gegevensbescherming. Formeel is meestal wel vastgelegd dat je als FG ‘tijdig en behoorlijk’ betrokken moet worden, maar in de praktijk word je nog weleens vanuit de flanken verrast. Herkenbaar? Lees dan snel verder!

Update: CISO, Privacy Officer en FG; wie doet en mag wat?

Activiteiten op het gebied van informatiebeveiliging en gegevensbescherming binnen gemeenten behoren te worden gecoördineerd door de CISO, de Privacy Officer en de FG. Maar wie is waarvoor verantwoordelijk? En hoe verhouden deze functies zich tot elkaar?

Praktische (privacy)tips voor thuis én op het werk

Hoe zorg je ervoor dat je medewerkers zowel thuis als op locatie veilig werken én veilig zijn? Zonder afbreuk te doen aan het fundamentele recht op privacy? Dat zijn de vragen die ik in deze blog ga behandelen.

Datalek melden: Hoeveel tijd heb je eigenlijk?

Als een datalek is ontstaan bij een verwerker, wanneer start dan de 72-uurstermijn voor het melden bij de toezichthoudende autoriteit? In onze nieuwe blog onderzoeken we twee visies.