Je moet IT-afspraken opnieuw toetsen zodra een wijziging of incident de aannames achter je dienstverlening, beveiliging of continuïteit verandert. Denk aan nieuwe werkplekken, aangepaste processen, een migratie of een securityincident dat laat zien dat een afspraak in de praktijk anders uitpakt dan op papier.
Voor organisaties met gevoelige dossiers en strakke beschikbaarheidseisen is dit extra belangrijk, omdat kleine wijzigingen grote impact kunnen hebben op toegangsbeheer, logging, back-ups en supportafspraken.
Hieronder lees je wanneer je moet herijken, welke SLA- en securityonderdelen prioriteit hebben, en hoe je dat doet zonder onrust in de operatie.
Wanneer moet je IT-afspraken opnieuw toetsen na een wijziging of incident?
Toets IT-afspraken opnieuw wanneer een wijziging of incident invloed heeft op risico’s, verantwoordelijkheden of meetbare prestaties zoals beschikbaarheid en hersteltijd. In de praktijk betekent dit: na grote changes, na terugkerende incidenten, na securitymeldingen en bij organisatorische veranderingen. Zo blijft IT-governance actueel en blijven afspraken aantoonbaar werkbaar.
Een goede vuistregel binnen wijzigingsbeheer IT is: als de change een nieuw risico introduceert, een bestaand risico vergroot of de manier van werken verandert, dan hoort daar een hertoetsing bij. Bij incident management geldt: als een incident een zwakke plek blootlegt in proces, configuratie of communicatie, dan is het moment daar om afspraken te herzien.
- Na majeure wijzigingen zoals migraties, nieuwe Microsoft 365-inrichting, netwerksegmentatie, nieuwe back-upoplossing of nieuwe identityprovider.
- Na proceswijzigingen zoals hybride werken, nieuwe onboardingflow of andere autorisatieprocedures.
- Na securityincidenten zoals accountmisbruik, phishing met mailboxregels of datalekmeldingen waarbij logging en respons ter discussie staan.
- Bij groei of reorganisatie zoals nieuwe vestigingen, fusies of veel nieuwe collega’s in korte tijd.
- Bij signalen uit de praktijk zoals structurele tickets over traagheid, onduidelijke escalaties of herhaalde verstoringen buiten kantooruren.
Plan daarnaast een vaste periodieke check, zodat SLA-herziening en securityafspraken niet alleen reactief gebeuren maar ook voorspelbaar blijven.
Welke onderdelen van SLA’s en security-afspraken moet je als eerste herzien?
Herzie eerst de onderdelen die direct bepalen of je organisatie door kan werken en of toegang en data beheersbaar blijven. Prioriteit ligt bij verantwoordelijkheden, meetpunten en de keten rondom identity, back-ups en incident management. Daarmee voorkom je dat een SLA op papier klopt, maar in de praktijk niet aansluit op je werkdag.
Begin met de afspraken die het vaakst misgaan bij veranderingen: wie doet wat, hoe snel, met welke informatie en hoe toon je achteraf aan wat er is gebeurd. Dit zijn meestal de snelste verbeterpunten binnen IT-governance.
- Scope en verantwoordelijkheden inclusief wat wel en niet onder beheer valt en wie eindverantwoordelijk is bij ketenproblemen.
- Beschikbaarheid en supportvensters inclusief escalatiepad, prioritering en communicatie bij verstoringen.
- Herstelafspraken zoals doelstellingen voor herstel en dataverlies, plus de praktische haalbaarheid daarvan.
- Toegangsbeheer onboarding, offboarding, rollen, MFA-beleid, break-glassaccounts en periodieke review van rechten.
- Logging en monitoring wat je logt, hoe lang, wie meekijkt en hoe je alerts opvolgt.
- Back-ups en hersteltests inclusief testfrequentie, restoreprocedures en verantwoordelijkheden bij mislukte restores.
- Wijzigingsbeheer IT changeclassificatie, goedkeuring, rollbackplan en documentatie-eisen.
Als je Microsoft 365 gebruikt, toets dan extra scherp op conditional access, mailboxbeveiliging, device compliance en dataretentie, omdat die instellingen vaak stilletjes meeschuiven met nieuwe werkwijzen.
Hoe voer je een hertoetsing uit zonder de operatie te verstoren?
Voer een hertoetsing uit met een korte impactanalyse, een beperkte set controles en duidelijke besluitmomenten. Je combineert documentreview met een paar gerichte technische checks en een tabletopoefening voor incident management. Zo toets je IT-afspraken snel, zonder grote changes of langdurige interviews die de werkdag onderbreken.
Werk in kleine stappen en maak het concreet: wat is er veranderd, welke afspraak raakt dat en wat moet er aangepast worden om weer voorspelbaar te werken. Dit proces past goed binnen volwassen IT-governance, omdat je beslissingen traceerbaar maakt.
- Trigger vastleggen beschrijf de wijziging of het incident in één alinea, inclusief impact en betrokken systemen.
- Afspraken mappen koppel de trigger aan SLA-onderdelen, securitypolicies, runbooks en escalatieafspraken.
- Reality check controleer een paar kritieke punten zoals toegangsrechten, logging, back-uprestoremogelijkheid en monitoringalerts.
- Tabletopscenario loop een realistisch incident door met IT en business, inclusief communicatie en beslissingen.
- Besluiten en eigenaars leg vast wat je wijzigt, wie eigenaar is en wanneer je opnieuw toetst.
- Communicatie light informeer eindgebruikers alleen over wat zij merken, zoals nieuwe MFA-stappen of aangepaste supportroute.
Houd de scope klein door te starten met de toprisico’s en de meest bedrijfskritische processen, en breid pas uit als de basis weer klopt.
Hoe X helpt met IT-afspraken opnieuw toetsen na wijzigingen of incidenten?
Wij helpen organisaties IT-afspraken toetsen op een manier die rust brengt in plaats van extra werkdruk. We combineren wijzigingsbeheer IT, incident management en IT-governance tot één samenhangende aanpak, zodat afspraken niet alleen netjes zijn vastgelegd maar ook echt werken in de dagelijkse praktijk.
- Snelle hertoetsing op SLA, securityinstellingen en verantwoordelijkheden, gericht op de grootste impactpunten
- Praktische verbeterlijst met prioriteiten, eigenaarschap en heldere opvolging zonder ruis
- Beheerbare documentatie zoals runbooks, escalatiepaden en changeafspraken die teams daadwerkelijk gebruiken
- Ondersteuning bij Microsoft 365 configuratie en toegangsbeheer passend bij jouw manier van werken
Wil je dit goed en voorspelbaar inrichten met Mr Blocks? Bekijk onze aanpak op Mr Blocks of neem direct contact op via contact opnemen.
Veelgestelde vragen
Hoe bepaal je of een wijziging “majeur” genoeg is om IT-afspraken te herijken?
Gebruik een simpele impactscore: raakt de change (1) identiteit/toegang, (2) data/backup, (3) beschikbaarheid/prestatie, of (4) ketenpartners/leveranciers? Als één van deze punten “hoog” scoort of als er nieuwe compliance-eisen ontstaan, plan dan een hertoetsing. Leg dit vast als beslisregel in je changeproces zodat het voorspelbaar wordt.
Wie moet er betrokken zijn bij een hertoetsing (en wie juist niet)?
Houd het klein: betrek service owner/IT-manager, security (of CISO/FG waar relevant), applicatie- of platformeigenaar en een business vertegenwoordiger van het kritieke proces. Eindgebruikers betrek je alleen als er merkbare wijzigingen komen (bijv. MFA, nieuwe supportroute). Zo voorkom je ruis maar borg je eigenaarschap.
Welke bewijsstukken (evidence) heb je nodig om aan te tonen dat afspraken echt werken?
Kies praktische evidence: een actueel runbook, een recente restore-test met resultaat, een export van logging/retentie-instellingen, een overzicht van break-glassaccounts en MFA-status, en een incidentrapport met lessons learned. Bewaar dit centraal (bijv. in SharePoint/Confluence) met datum, eigenaar en volgende reviewdatum.
Hoe vaak moet je periodiek toetsen als er géén incidenten zijn?
Als basis: elk kwartaal een lichte check op de top-5 risico’s en jaarlijks een volledige review van SLA/securityafspraken. Bij organisaties met gevoelige dossiers of 24/7 afhankelijkheid is halfjaarlijks volledig herijken realistischer. Koppel de cyclus aan je audit- of begrotingsmomenten zodat het geen los project wordt.
Wat zijn snelle ‘quick wins’ na een incident die vaak direct waarde opleveren?
Begin met: (1) escalatiepad en contactlijst actualiseren, (2) monitoring-alerts afstemmen op echte prioriteiten, (3) MFA/conditional access aanscherpen voor risicovolle accounts, (4) back-up restoreprocedure testen op één kritieke workload, en (5) duidelijke communicatie-templates voor verstoringen. Dit zijn kleine ingrepen met groot effect op voorspelbaarheid.
Hoe ga je om met leveranciers als een ketenprobleem de SLA onderuit haalt?
Maak ketenafspraken expliciet: definieer wie de regie voert bij multi-vendor incidenten, welke responstijden gelden per schakel en hoe je end-to-end beschikbaarheid meet. Leg een gezamenlijke war-room procedure vast en spreek af welke logs/telemetrie gedeeld mogen worden. Voeg dit als addendum toe aan contract/SLA zodat het afdwingbaar is.
Welke metrics zijn het meest bruikbaar om te zien of de herijking werkt?
Kies een klein dashboard: MTTR (hersteltijd), aantal P1/P2-incidenten, change failure rate (changes die rollback vereisen), restore-succespercentage en tijd tot detectie (MTTD). Combineer dit met één kwalitatieve metric: ‘duidelijkheid van verantwoordelijkheden’ uit een korte evaluatie na incidenten.
