“Wij hebben geen invloed op wijzigingen die doorgevoerd worden in de SAAS-applicaties die we gebruiken.” Als ik als auditor de norm Wijzigingsbeheer bespreek tijdens een audit of pre-audit bij een gemeente hoor ik dit vaak. Toch is er in de norm sprake van verantwoordelijkheden van de ‘gebruikersorganisatie’. Dit geldt ook als de leverancier van een SAAS-applicatie een nieuwe release doorzet, zonder te wachten op goedkeuring van de gebruikers. Kennelijk ligt er toch een stukje bij de gemeente. Welk stukje is dit dan?
Voordat ik die vraag beantwoord, sta ik eerst stil bij de waarom-vraag. Als je er als gemeente geen invloed op hebt, waarom geldt er dan wel een gedeeltelijke verantwoordelijkheid? Dit heeft alles te maken met het (tijdig) ondervangen van risico’s ten aanzien van informatiebeveiliging. Wijzigingen in of aan applicaties kunnen impact hebben op de informatiebeveiliging. Door wijzigingen te testen en te beoordelen, kunnen risico’s voor informatiebeveiliging ondervangen worden. Een groot gedeelte van het testen en beoordelen is onderdeel van het wijzigingsbeheerproces van de leverancier. Voor een leverancier is echter niet altijd goed te beoordelen welke impact wijzigingen in of aan applicaties op de gebruikersorganisatie hebben. Dat is het deel waar je als gemeente zelf verantwoordelijk voor bent. Welk deel het is, hangt bij DigiD af of het gaat om wijzigingen aan de applicatie of wijzigingen in de applicatie.
Wijzigingen aan de applicatie
Denk hier aan bug fixes, nieuwe releases en volgende versies. In de praktijk zie ik hier drie varianten, waarbij elke variant iets anders vraagt van de gebruikersorganisatie.
1. Wijzigingen op verzoek van gebruikers
Soms worden DigiD-applicaties in samenwerking met de gebruikersorganisatie ontwikkeld. Een gemeente dient een wijzigingsverzoek in, de applicatieleverancier neemt dit verzoek mee in de volgende release of versie. Het testen van de ‘techniek’ ligt dan grotendeels bij de leverancier, gebruikers voeren een gebruikersacceptatietest uit in een test- of acceptatieomgeving. Pas na formeel akkoord van de gemeente (als gebruiker) kan de nieuwe versie live.
Welke verantwoordelijkheden heeft een gemeente als gebruikersorganisatie in deze situatie? De gebruikersacceptatietest kan een gemeente alleen goed uitvoeren aan de hand van een goed ingericht wijzigingsbeheerproces. Dat is een wijzigingsprocedure waarin de stappen en verantwoordelijkheden beschreven zijn, er een testscript ligt dat gebruikt wordt voor de beoordeling van de risico’s en de uitvoering van de testwerkzaamheden. Dit moet blijken uit de ENSIA-verantwoording. Bovendien moeten de uitgevoerde testwerkzaamheden en de formele goedkeuring zichtbaar vastgelegd zijn. Bijvoorbeeld in een ticketsysteem.
2. Wijzigingen aan SAAS-applicaties met testmogelijkheden
Iets vaker zie ik dat de leverancier de releases volgens planning doorvoert, maar een gemeente vóór die tijd in de gelegenheid is om de nieuwe release in een acceptatieomgeving te testen of uit te proberen. Afhankelijk van de afspraken met de leverancier moet de gemeente dan of formele goedkeuring geven of problemen doorgeven.
De wijzigingsprocedure en ook het testscript is in dit soort gevallen beknopter. Het testscript kan dan bijvoorbeeld beperkt blijven tot het beoordelen van de mogelijke impact van de wijzigingen en vervolgens een controle op keyfunctionaliteit. Het is in dit soort situaties ook belangrijk om te testen of webformulieren nog werken.
3. Wijzigingen aan SAAS-applicaties zonder testmogelijkheden
In de meeste gevallen voert de leverancier de releases volgens een eigen planning door, doet daarvan een aankondiging en levert releasenotes op.
Welke verantwoordelijkheden hebben gebruikersorganisatie in deze situatie? Die verantwoordelijkheden blijven dan beperkt tot het beoordelen van de impact van de inhoud van de releasenotes. Ik raad aan om een eenvoudig logboek aan te leggen van de doorgevoerde releases, de beoordeling van de releasenotes door de applicatiebeheerder en de eventuele opvolging. De opvolging kan onder andere bestaan uit het informeren van collega’s ten aanzien van nieuwe releases of informatie opvragen bij de leverancier ter verduidelijking. En denk van te voren na waar op gelet moet worden bij de beoordeling van de releasenotes.
Conclusie: beoordeel de impact en onderneem actie
Het maakt niet uit of je er voor kiest om in de reguliere beschrijving van het wijzigingsbeheerproces onderscheid te maken tussen de verschillende type wijzigingen of een voor DigiD specifiek wijzigingsbeheerproces op te stellen. Samengevat komt het er in elke situatie op neer dat je als gemeente, afhankelijk van het deel wat bij de gebruikersorganisatie belegd is, de risico’s van de wijzigingen ondervangt door de impact daarvan te beoordelen en daar actie op te ondernemen.
Wijzigingen in de applicatie
Wijzigingen in de applicatie hebben meestal betrekking op webformulieren in de DigiD-applicatie. Het aanmaken of wijzigen van webformulieren moet volgens een gecontroleerd proces verlopen. Bij een aantal DigiD-applicaties kun je niet zelf webformulieren ontwikkelen, maar alleen een formulier aan of uit zetten en hooguit tekstueel toevoegingen doen of wijzigingen doorvoeren. Vanuit informatiebeveiligingsperspectief worden dan alle risico’s binnen de applicatie zelf afgedekt. In dat geval is ten aanzien van de norm C.08 geen aanvullend proces nodig.
Voor het zelf aanmaken of wijzigen van webformulieren moet een wijzigingsbeheerproces ingericht zijn. In dit proces moet beschreven zijn wie (proces)eigenaar is van de webformulieren, wie verantwoordelijk is voor de aanvraag, het bouwen, het testen en het live zetten van het webformulier. Ook adviseer ik na te denken wat de diepgang is van de testwerkzaamheden en waarop gelet dient te worden. Als auditor kijk ik naar of er een overzicht is van de webformulieren die live zijn gegaan. Of het wijzigingsproces zichtbaar is vastgelegd en of er een aanvraag is, een test is gedaan en een akkoord is voor de wijziging(en).
Een laatste tip: vergeet niet om bij het aanmaken van nieuwe webformulieren ook aandacht te besteden aan dataclassificatie.
Dit bericht is meer dan zes maanden geleden gepubliceerd. Omdat wet- en regelgeving continu in beweging is, raden wij u aan met uw Baker Tilly adviseur te bespreken of de informatie in dit bericht actueel is en gevolgen heeft (of mogelijkheden biedt) voor uw situatie. Uw adviseur praat u graag bij over de laatste stand van zaken.
