Tag: acceptatie

Ontwikkel, test, acceptatie en productie

  door

De afgelopen dagen zijn we ingegaan op de eisen die we stellen aan de informatievoorziening en de onderliggende informatiesystemen. Daarna zijn we ingegaan op de risicoanalyses voor die informatiesystemen. Allemaal heel erg belangrijk, maar helaas zijn we er niet met het eenmalig uitvoeren van dergelijke stappen. Onze omgeving, de dreigingen maar ook de componenten zijn continue aan ontwikkeling en wijziging onderhevig. Een patch of een update van een component is van groot belang om dat component up-to-date te houden, maar een dergelijke update kan ook weer risico’s met zich meebrengen.

We willen niet dat een patch of update onze informatievoorziening platlegt en stellen daarom de volgende vraag:

Vindt de ontwikkeling/wijziging van informatiesystemen plaats conform de stappen: ontwikkel, test, acceptatie en productie (OTAP procedure, change management)?

Ontwikkeling van nieuwe informatiesystemen of wijziging van bestaande informatiesystemen doen we niet in de productie omgeving. We weten immers nooit zeker hoe dit zal samenwerken met de andere componenten in ons netwerk. We werken daarom met verschillende stappen om een wijziging doorgevoerd te krijgen.

We beginnen uiteraard met het ontwikkelen van de systemen en zodra we denken dat die systemen een vorm van leven beginnen te krijgen gaan we onze ontwikkelingen testen. Werkt het, doet het wat het moet doen, beïnvloedt het andere componenten, voldoet het aan de eisen van beschikbaarheid, integriteit en exclusiviteit en ga zo nog maar even door. Dat doen we niet in de productie omgeving omdat we te weinig zekerheid hebben over de werking van het systeem. Nee, we doen dat in een afgescheiden testomgeving zodat er niets met de productie gebeurt als het fout gaat.

Zijn we er eenmaal zeker van dat het systeem aan alle (technische) eisen voldoet dan gaan we over naar de acceptatie van dat nieuwe systeem. Niet dat we nu pas in overleg gaan met de gebruikers trouwens, want als het goed is ontwikkelen we omdat daar een behoefte aan is. Die behoefte wordt juist gesteld door de gebruikers. Zij hebben echter minder zicht op de achterliggende techniek (en dat hoeft ook helemaal niet) maar zij kunnen wel de functionaliteiten bekijken. Is dit systeem inderdaad wat ze willen? Moet het nog bijgeschaafd worden?

We zitten nog steeds niet in de productieomgeving. Het kan best zijn (en dat is meestal zo) dat we de stappen ontwikkelen, testen en accepteren verschillende malen moeten doorlopen voordat het systeem of de wijziging doorgevoerd kan worden in de productieomgeving.

Hier ontstaat natuurlijk altijd een spanningsveld. De gebruikers willen het nieuwe systeem zo snel mogelijk gaan gebruiken en patches willen we zo snel mogelijk doorvoeren omdat we anders wellicht grote risico’s lopen. Toch is het van belang om goed zicht te houden op de OTAP-stappen. Het middel mag immers niet erger zijn dan de kwaal.

Grootste bedreigingen en restrisico’s

  door

In stap 5 hebben we het risicomanagement framework opgetuigd en ingezet. Nu zijn we aanbeland bij de vraag waar we nog wat nader ingaan op de grootste bedreigingen en de restrisico’s. Daarmee kunnen we vraag 7 beantwoorden.

De zevende vraag die we moeten stellen is:
Is inzichtelijk welke risico’s de continuïteit van de organisatie kunnen bedreigen en zijn er eventueel restrisico’s door het topmanagement geaccepteerd?

En het antwoord? Ja, nee of weten we het eigenlijk niet?

Het lijkt misschien logisch dat we zoveel mogelijk risico’s af willen dekken omdat dat ons nu eenmaal een lekkerder gevoel geeft, een gevoel van schijnveiligheid overigens in veel gevallen. Toch moeten we kijken naar het risicogedrag van de onderneming. Zijn we nu juist meer risicomijdend, risicodragend of toch risiconeutraal? Dat leiden we af uit de totale strategie van de organisatie en laten dat bekrachtigen door het hoogste management. We moeten daarbij overigens niet vergeten dat per business unit of per proces een andere risicostrategie gehanteerd kan worden.

Processen die bijvoorbeeld helemaal niet zo belangrijk zijn voor de organisatie kunnen een heel andere risicostrategie vereisen dan processen die bedrijfskritisch zijn. Zijn we er eenmaal uit welke risicostrategie het best past voor onze risicoanalyse dan kunnen we de beheersingsmaatregelen daar op aanpassen. De restrisico’s laten we dan bekrachtigden door het juiste managementniveau, die kan daar immers over besluiten. Wij, als beveiligingsadviseur, manager of weet ik veel hoe we ons noemen, kunnen dat niet. Nee, wij kunnen alleen maar ondersteuning verlenen en ze adviseren, maar de lijn blijft verantwoordelijk…maar goed, dat hadden we vorige week al gezien.

Risicoanalyse, risicomanagement en nu ook nog zicht op de grootste dreigingen waarbij we de restrisico’s laten accepteren op het juiste niveau. Op papier allemaal niet zo ingewikkeld, in de praktijk helaas een stuk weerbarstiger, maar we moeten de moed niet verliezen want we zijn al zover. Ver genoeg in ieder geval om naar vraag 8 te gaan.

Nogmaals, voor diegene onder jullie die echt niet 10 dagen willen wachten, je kunt de quickscan zelf ook al doorlopen door hier te klikken of door me snel uit te nodigen voor die bak koffie.