Bouw een risicoregister dat beslissingen verandert

Een risicoregister bewijst zijn waarde wanneer het prioriteiten, middelen of implementatie verandert. Het moet een engineeringleider helpen beslissen of een release wordt uitgesteld, een bevoegdheid wordt ingeperkt, herstelwerk wordt gefinancierd of een blootstelling voor een bepaalde periode wordt geaccepteerd. Een lijst met rode, oranje en groene regels is daarvoor niet genoeg.

Begin met scenario’s die de organisatie herkent, niet met labels als ‘cyberrisico’. Verbind elk scenario vervolgens met de betrokken dienst, het beoordelingsbewijs, de beheersmaatregelen, het behandelwerk en de verantwoordelijke beslisser. Het register wordt bruikbaar wanneer iemand die keten kan volgen en kan uitleggen waarom de volgende actie ertoe doet.

Bepaal de beslissingen voordat u het register ontwerpt

Begin met één product, bedrijfsproces of beheerde dienst. Breng de kritieke afhankelijkheden, belangrijke informatie, externe leveranciers en operationele randvoorwaarden in kaart. Een afgebakende grens maakt het gemakkelijker de methode te testen voordat u die in de hele organisatie toepast.

Vraag de mensen die het register gaan gebruiken welke beslissingen zij moeten nemen. Een platformlead moet misschien kiezen tussen het verbeteren van herstel en het vervangen van een verouderd component. Een supportmanager moet misschien beperktere toegang goedkeuren zonder de klantenservice te verstoren. Een CTO moet misschien beslissen of een lancering door kan gaan terwijl het behandelwerk nog niet af is.

Leg de beoordelingsmethode en de goedkeuringsregels vast voordat u scores verzamelt. Als praktische aanbeveling documenteert u:

• De beoordelingshorizon, bijvoorbeeld de blootstelling over de komende twaalf maanden.
• Definities van waarschijnlijkheid en impact, inclusief hoe tegenstrijdige impactdimensies worden behandeld.
• Drempels voor risicobereidheid en operationele tolerantie.
• Wie behandeling mag goedkeuren en restblootstelling mag accepteren.
• Reviewintervallen en gebeurtenissen die een herbeoordeling vereisen.

Risicobereidheid (risk appetite) drukt uit welke soorten en niveaus van risico de organisatie bereid is aan te gaan of te behouden. Tolerantie vertaalt dat standpunt naar bruikbare grenzen, zoals een maximaal aanvaardbare storing of beperkingen op ongecontroleerde exports van klantgegevens.

Voor een ISMS dat aansluit bij ISO/IEC 27001 gaan de clausules 6.1.2 en 6.1.3 over risicobeoordeling en -behandeling. Clausule 8.2 vraagt om beoordelingen op geplande momenten en wanneer significante wijzigingen plaatsvinden of worden voorgesteld. De norm schrijft geen universeel jaarschema of scoringsmatrix voor. Uw methode moet werken binnen de werkelijke scope van het ISMS.

Geef elke regel genoeg structuur om actie te ondersteunen

Een register kan beginnen in een spreadsheet. Zijn bruikbaarheid hangt af van relaties, eigenaarschap en onderhoud, niet van het bestandsformaat. Sterker gekoppelde tooling wordt waardevol wanneer handmatig afstemmen die relaties onbetrouwbaar maakt.

Gebruik een stabiele identificatie en een klein aantal velden die praktische vragen beantwoorden. Bewaar uitgebreid technisch bewijs in gekoppelde registraties in plaats van het in elke regel te kopiëren.

Maak onderscheid tussen risicostatus en taakstatus. ‘Behandeling loopt’ betekent niet dat de blootstelling is afgenomen. ‘Geaccepteerd’ betekent niet dat het scenario is verdwenen. Reserveer afsluiting voor situaties waarin bijvoorbeeld de betrokken activiteit is beëindigd of het scenario niet meer van toepassing is, en bewaar de redenering.

Evenzo zijn een kwetsbaarheid, een falende beheersmaatregel en een risico verwante maar verschillende registraties. Een ontbrekende patch is een zwakte. Een mislukte deploymentcontrole is een probleem met een beheersmaatregel. Het risico beschrijft wat er door die omstandigheden kan gebeuren en waarom dat ertoe doet. Koppel gedetailleerde bevindingen aan dat scenario in plaats van voor elk scannerresultaat een apart organisatiebreed risico aan te maken.

Ontdek scenario’s vanuit de manier waarop de dienst werkt

Gebruik architectuur en operationeel bewijs om risico’s te identificeren. Breng engineering, security, service-eigenaren, support en relevante bedrijfsfuncties samen in een gericht gesprek. Beleidsdocumenten alleen laten zelden zien waar bevoegdheden ruimer zijn dan bedoeld, waar herstel van één persoon afhangt of waar een leverancier een kritieke afhankelijkheid is geworden.

Bruikbare input zijn onder meer dataflowdiagrammen, toegangsreviews, incidentregistraties, hersteltests, leveranciersbeoordelingen, kwetsbaarheidsbevindingen, wijzigingsvoorstellen en openstaande auditobservaties. Threat modeling kan teams helpen vertrouwensgrenzen en plausibele faalpaden te onderzoeken.

Een bruikbaar scenario volgt dit patroon: een gebeurtenis treft een bepaalde dienst via een aanwijsbare zwakte en leidt tot benoemde gevolgen.

Bijvoorbeeld: een gecompromitteerd supportaccount maakt export van klantgegevens mogelijk omdat de bevoegdheden te ruim zijn, met ongeautoriseerde openbaarmaking en responswerk als gevolg. Dat is beter bruikbaar dan ‘accountcompromittering’. Het benoemt zowel een aanvalspad als beheersmaatregelen die het kunnen onderbreken.

Kijk verder dan vertrouwelijkheid. Neem storingen, beschadigde registraties, mislukt herstel, verstoring bij leveranciers, misbruik van beheerrechten en onbeschikbare expertise mee. Denk bij functies met AI aan onjuiste uitvoer waarop wordt gehandeld, gevoelige informatie die in een ongeschikte dienst terechtkomt of een agent die buiten zijn beoogde bevoegdheid handelt.

Ontdubbel scenario’s zorgvuldig. Twee diensten kunnen een identiteitsprovider delen en toch verschillende gevolgen en behandelopties hebben. Omgekeerd kunnen meerdere bevindingen bijdragen aan één exportscenario. Voeg samen waar besluit en eigenaar gedeeld zijn; houd gescheiden waar de bedrijfsgevolgen of behandelbesluiten verschillen.

Leg hiaten in de inventarisatie vast als werk. Als niemand weet welke klanten een exportfunctie gebruiken, moet die onzekerheid tot een onderzoekstaak leiden, niet tot een verzonnen impactschatting.

Beoordeel blootstelling zonder schijnprecisie

Spreek een gemeenschappelijke scoretaal af

Waarschijnlijkheid en impact hebben definities nodig die beoordelaars consistent kunnen toepassen. Maak bij waarschijnlijkheid onderscheid tussen dreigingsactiviteit en de kans dat het hele scenario slaagt. Frequente phishingpogingen betekenen niet automatisch frequente grootschalige openbaarmaking: authenticatie, bevoegdheden, sessiemaatregelen en exportbeperkingen beïnvloeden het pad.

Impact moet de uitkomst voor de organisatie weerspiegelen. Denk aan onderbreking van de dienst, openbaarmaking, verlies van integriteit, responskosten, contractuele gevolgen en, waar relevant, schade voor betrokkenen. Documenteer de aggregatieregel. Als de methode de hoogste materiële impactdimensie gebruikt, zeg dat dan; een gemiddelde kan anders een ernstig gevolg voor de vertrouwelijkheid verbergen achter kleinere operationele effecten.

Een eenvoudige ordinale matrix kan helpen bij triage. Het vermenigvuldigen van twee categoriegetallen levert echter een index op, geen gemeten kans of financieel verlies. Tel die scores niet op over diensten heen om het resultaat vervolgens de totale blootstelling van de organisatie te noemen. Gebruik de beoordeling samen met de onderbouwing, urgentie, onzekerheid en afhankelijkheden in de behandeling.

Kalibreer beoordelingen gezamenlijk. Laat eigenaren een paar representatieve scenario’s onafhankelijk scoren, vergelijk hun redeneringen en los verschillen op aan de hand van de definities. Dat is nuttiger dan elke afdeling een eigen interpretatie van ‘hoog’ te laten ontwikkelen.

Scheid inherent risico, huidig restrisico en beoogd restrisico

Definieer de basislijn voor het inherente risico expliciet. Die kan het scenario beschrijven zonder de gekozen beveiligingsmaatregelen, maar moet nog steeds vermelden welke dienstarchitectuur en bedrijfsactiviteit worden verondersteld. Anders stellen beoordelaars zich onverenigbare versies van ‘geen maatregelen’ voor.

Het huidige restrisico weerspiegelt maatregelen die zijn geïmplementeerd en worden ondersteund door relevant bewijs van effectiviteit. Het beoogde restrisico is de verwachte blootstelling na de voorgestelde behandeling. Houd beide zichtbaar: een geplande toegangsbeperking mag de beoordeling van vandaag niet verlagen.

Niet elke maatregel verandert beide dimensies. Sterkere authenticatie kan de waarschijnlijkheid verlagen. Beperktere exportbevoegdheden kunnen de blootgestelde hoeveelheid beperken. Geteste responsprocedures kunnen de gevolgen na detectie indammen. Beschrijf het mechanisme in plaats van een algemene procentuele verlaging toe te passen omdat er een maatregel bestaat.

Behoud onzekerheid en gebruik kwantitatieve analyse selectief

Leg aannames, data van het bewijs, hiaten in de dekking en de mate van zekerheid vast. ‘Geen eerdere incidenten’ is zwak bewijs als de logging de gebeurtenis niet kan detecteren. Lage zekerheid moet tot onderzoek leiden; ze mag niet automatisch de hoogste score afdwingen.

Vul bij dure behandelbesluiten de kwalitatieve beoordeling aan met een scenariogebaseerde financiële analyse. Gebruik bandbreedtes voor de frequentie en de gevolgen van gebeurtenissen, benoem de belangrijkste kostendrijvers en test hoe het besluit verandert onder verschillende aannames. Simulatie kan helpen die bandbreedtes te verkennen, maar kan ononderbouwde input niet repareren.

Stel, als illustratieve berekening, een gebeurtenisfrequentie van 0,05 tot 0,2 per jaar en verliezen van € 100.000 tot € 400.000 per gebeurtenis. Het vermenigvuldigen van de uitersten geeft een ruwe jaarlijkse bandbreedte van € 5.000 tot € 80.000. Dit is input voor de discussie, geen voorspelling en geen rechtvaardiging om zeldzame, ernstige uitkomsten te negeren. Leg uit welk aanvullend bewijs de bandbreedte zou verkleinen.

Verbind beheersmaatregelen met het faalpad

Het mappen van beheersmaatregelen moet causaliteit verklaren. In het scenario met het supportaccount pakt authenticatie accountovername aan, beperkt autorisatie welke registraties toegankelijk zijn, beperken exportrestricties de extractie en ondersteunt monitoring de detectie. Een beleid waarin verantwoordelijkheden voor toegang worden erkend is relevant, maar bewijst niet dat die technische beperkingen werken.

Onderhoud veel-op-veelrelaties: één identiteitsmaatregel kan meerdere risico’s ondersteunen en één risico kan van meerdere maatregelen afhangen. Neem scope en afhankelijkheden mee. Een authenticatiemaatregel die medewerkers dekt maar leveranciersaccounts uitsluit, kan niet voor beide populaties dezelfde conclusie onderbouwen.

Beoordeel drie afzonderlijke vragen:

• Opzet: zou de maatregel het scenario onderbreken of indammen als hij werkt zoals bedoeld?
• Implementatie: is hij uitgerold over de relevante systemen, identiteiten en workflows?
• Werking: laat actueel bewijs zien dat hij blijft werken?

Bij toegangsbeperkingen kan bewijs bestaan uit roldefinities, werkelijke toewijzingen, negatieve autorisatietests en afgeronde verwijderingen. Bij herstel bewijst een back-upconfiguratie minder dan een hersteltest met integriteitscontroles en een gemeten hersteluitkomst. Toon bij exportmonitoring aan dat de gebeurtenis wordt vastgelegd, dat de melding een behandelaar bereikt en dat die behandelaar haar kan onderzoeken.

Bewaar de herkomst bij het bewijs: bron, verzameltijdstip, scope, beoordelaar en beperkingen. De ouderdom van bewijs is contextafhankelijk. Een configuratie-export kan na een deployment verouderd zijn; het resultaat van een oefening kan bruikbaar blijven totdat de architectuur of de verantwoordelijkheden veranderen.

Verlaag het restrisico niet evenredig met het aantal afgeronde taken. Drie van de vier afgeronde tickets betekenen geen vermindering van 75%. Het ontbrekende ticket kan juist de enige maatregel implementeren die openbaarmaking beperkt. Beoordeel het scenario opnieuw na geverifieerde wijzigingen en leg vast waarom de conclusie is veranderd.

Kies een behandeling en maak de afweging expliciet

De gebruikelijke behandelopties zijn vermijden, verminderen, delen of overdragen, en accepteren. Ze kunnen worden gecombineerd, maar elke optie heeft een benoemd doel nodig.

Vermijden beëindigt of wijzigt de activiteit die de blootstelling veroorzaakt. Het neemt niet per se elk verwant risico weg. Het verwijderen van een functie kan handmatige processen introduceren die zelf beoordeeld moeten worden.

Bij verminderen moet u zowel preventieve maatregelen als maatregelen die de gevolgen beperken overwegen. Vergelijk engineeringinspanning, operationele frictie, afhankelijkheden, verwacht voordeel en de tijd tot effect. Een directe beperking kan de voorkeur hebben boven een sterkere architectuurwijziging die pas over enkele maanden kan worden opgeleverd; het register moet beide fasen vastleggen.

Contractuele overdracht en verzekering nemen niet elk operationeel gevolg weg. Een vrijwaring door een leverancier herstelt uw dienst niet, en een verzekering draait openbaarmaking niet terug. Waar persoonsgegevens worden verwerkt, blijven bij uitbesteding bovendien rolspecifieke verplichtingen onder de AVG bestaan; de artikelen 28 en 32 blijven relevant voor verwerkersafspraken en beveiligingsmaatregelen.

Acceptatie is een bewust besluit, niet het ontbreken van budget of een achterstallig ticket. Leg de bedrijfsmatige onderbouwing, het actuele bewijs, de resterende blootstelling, de goedkeurende autoriteit, de duur en de voorwaarden die een review vereisen vast. Kosten zijn relevant, maar niet het enige criterium: wettelijke verplichtingen, klantafspraken en gevolgen kunnen een anders gunstige optie uitsluiten.

Geef elke behandelactie een implementatie-eigenaar, een toezegging van middelen, een streefdatum, een afhankelijkheid en een afrondingstest. De risico-eigenaar blijft verantwoordelijk voor de totale beoordeling en respons; taakeigenaren leveren de afzonderlijke wijzigingen. Een geautoriseerde beoordelaar keurt het behandelbesluit en eventuele resterende blootstelling goed volgens de regels van de organisatie.

Leg escalatie vast voordat het werk stokt. Een gemiste mijlpaal die een aanstaande lancering raakt, moet bijvoorbeeld tot een lanceringsbesluit leiden, niet alleen tot het verschuiven van de deadline. Leg ook afgewezen alternatieven vast, vooral wanneer die verklaren waarom voor een tijdelijke behandeling is gekozen.

Uitgewerkt voorbeeld: een exportrisico via een supportaccount

Het volgende voorbeeld is illustratief. Stel dat een softwaredienst twintig supportgebruikers heeft, klantgegevens die toegankelijk zijn via een supportconsole en een bulkexportfunctie die is overgebleven uit een eerder werkmodel. Single sign-on is geïmplementeerd, maar bulkexportrechten zijn ruim toegekend. Bestaande logs registreren exports, maar er is geen melding getest.

Het scenario luidt: een aanvaller compromitteert een supportsessie en gebruikt te ruime bevoegdheden om klantgegevens te exporteren, met ongeautoriseerde openbaarmaking en werk richting klanten als gevolg.

De service-eigenaar is verantwoordelijk voor het risico. De identity lead is eigenaar van authenticatiewijzigingen, het applicatieteam van autorisatie en security operations van het testen van detectie.

Volgens de vijfpuntsmethode van deze hypothetische organisatie is de inherente beoordeling waarschijnlijkheid 4 en impact 4. De huidige restbeoordeling is waarschijnlijkheid 3 en impact 4: de bestaande authenticatie biedt enige bescherming, maar ruime bevoegdheden laten een substantieel pad naar openbaarmaking open. De zekerheid is gemiddeld, omdat sessiewaarborgen en het maximale exportvolume nog niet zijn getest. Deze getallen zijn illustratieve categoriebeoordelingen, geen kansen.

Het team vergelijkt drie opties: bulkexports verwijderen, ze beperken tot goedgekeurde gebruikers, of de bestaande toegang behouden met sterkere monitoring. Support toont een legitieme behoefte aan beperkte exports aan. De eigenaar kiest voor vermindering door beperkte toegang, sterkere authenticatie voor de overgebleven gebruikers met verhoogde rechten en geteste exportmeldingen.

Stel dat de oplevering twaalf engineeringdagen verspreid over vier weken vergt. Die cijfers zijn planningsaannames, geen marktbenchmarks. Het register koppelt het werk aan het opleveringsplan en legt tussentijdse beperkingen vast zolang de implementatie onvolledig is.

De beoogde restbeoordeling is waarschijnlijkheid 2 en impact 3, onder voorbehoud van verificatie. Ze blijft een doel totdat de tests slagen. Na de deployment ontdekt de beoordelaar dat een ouder endpoint de nieuwe volumebeperking omzeilt. De impactbeoordeling blijft daarom 4 en de omzeiling wordt een blokkerende behandeltaak.

Na correctie en hertest beoordeelt de eigenaar het volledige pad opnieuw. Eventuele resterende blootstelling krijgt expliciete goedkeuring en een reviewdatum. Een nieuwe exportintegratie, een mislukte toegangsreview of een wezenlijke toename van toegankelijke registraties leidt tot een eerdere herbeoordeling. Het register heeft nu implementatie, volgorde en goedkeuring veranderd, en niet alleen een zorg gedocumenteerd.

Bouw een monitoringlus die tot besluiten leidt

Geplande reviews blijven nuttig, maar wijzigingen tussen reviews moeten de eigenaar bereiken. Verbind operationele signalen met de scenario’s die ze raken. Relevante aanleidingen zijn onder meer mislukte intrekkingen van toegang, nieuwe leveranciers, architectuurwijzigingen, incidenten, mislukte tests van beheersmaatregelen en nieuwe dreigingsinformatie.

Leg voor elke aanleiding de bron, de betrokken scope, de routering, de verwachte reactietijd en de beoordelaar vast. Maak als praktische aanbeveling onderscheid tussen een urgente blootstelling die directe operationele actie vereist en een routinematige verversing van bewijs. Wacht niet op een risico-overleg om een actief incident in te dammen.

De monitoringfrequentie moet weerspiegelen hoe snel een maatregel verandert en hoe ingrijpend falen zou zijn. Geautomatiseerde configuratiecontroles kunnen vaak draaien; een hersteloefening of leveranciersreview vraagt om een ander ritme. ‘Continu’ moet een doorlopend operationeel proces beschrijven, niet suggereren dat elke maatregel elke seconde wordt getest.

Richt ook foutafhandeling in voor de monitoring zelf. Een losgekoppelde bron of een verouderde inventaris moet verschijnen als onbekende dekking, niet als een geslaagde maatregel. Ontdubbel herhaalde meldingen en groepeer gedeelde fouten, zodat eigenaren bruikbare context krijgen in plaats van tientallen identieke notificaties.

Leg bij een binnenkomend signaal vast wat er veranderd is, welke scenario’s zijn bekeken, wat de directe actie is en of de herbeoordeling het behandelbesluit heeft veranderd. Een mislukte toegangsreview kan onderzoek rechtvaardigen zonder automatisch elke gekoppelde score te wijzigen. Omgekeerd kan bevestigde te ruime toegang tot gevoelige registraties de bestaande restbeoordeling direct ongeldig maken.

Continue monitoring van beheersmaatregelen is het waardevolst wanneer de resultaten zowel de uitvoerders van maatregelen bereiken als de eigenaren die verantwoordelijk zijn voor de bijbehorende blootstelling.

Gebruik AI om beoordelingen voor te bereiden, niet om ze goed te keuren

AI kan helpen bij het opstellen van scenario’s, het afstemmen van bewijs, het samenvatten van wijzigingen, het voorstellen van mogelijke mappings van beheersmaatregelen en het voorstellen van prioriteiten. De uitvoer moet controleerbaar conceptwerk blijven.

Begin met een smalle workflow waarvan de resultaten te controleren zijn. Eis bronverwijzingen en maak onderscheid tussen geëxtraheerde feiten en afgeleide conclusies. Controleer op ontbrekende dekking, tegenstrijdige registraties, verouderde documenten en ononderbouwde aannames. Een gepolijste samenvatting is geen bewijs dat de onderliggende bronnen het met elkaar eens zijn.

Gebruik bij het prioriteren van kwetsbaarheden bedrijfscontext naast externe signalen. Ernst beschrijft mogelijke technische gevolgen; de waarschijnlijkheid van misbruik en bevestigd misbruik geven verschillende aspecten van dreigingsactiviteit aan. Geen van beide vertelt u of het betrokken component is uitgerold, bereikbaar is, verhoogde rechten heeft of deel uitmaakt van een kritieke dienst. AI kan helpen bij correlatie, maar controles van de inventaris en de blootstelling blijven essentieel.

Informatie over leveranciers vraagt om dezelfde discipline: maak onderscheid tussen feiten over uw gecontracteerde leverancier en dienst en speculatie over een gelieerd bedrijf. Ook gedragsanalyse vraagt om zorgvuldigheid, omdat ongebruikelijke activiteit niet automatisch kwaadwillend is en het monitoren van medewerkers privacy- en arbeidsrechtelijke vragen kan oproepen.

Bestuur ook de AI-workflow zelf. Pas least privilege toe, beperk gevoelige input, bewaar een controleerbare geschiedenis van uitvoer en bepaal wanneer een wijziging van model of prompt hertesten vereist. Historische incidentgegevens kunnen blinde vlekken bevatten: slecht gemonitorde diensten kunnen veiliger lijken alleen omdat er minder gebeurtenissen zijn vastgelegd.

Voorspellende uitvoer moet een hypothese zijn met een eigenaar en validatietaken. Een gegenereerde score moet een voorstel blijven totdat die is getoetst aan de afgesproken methode. De verantwoordelijke eigenaar keurt de beoordeling en behandeling goed.

Het gebruik van AI voor risicowerk maakt het systeem niet automatisch een AI-systeem met een hoog risico onder de AI-verordening van de EU. De classificatie hangt af van de toepassing en de rol; de eisen voor risicobeheer in artikel 9 gaan over systemen met een hoog risico. Raadpleeg het actuele overzicht van de Commissie voor toepasselijkheid en tijdpad. Het NIST AI RMF biedt vrijwillige richtlijnen voor governance, geen compliancegarantie.

Rapporteer het besluitspoor en test of het register werkt

Engineering heeft betrokken systemen, blokkerende afhankelijkheden, verificatiecriteria en aanstaande besluiten nodig. Het management heeft materiële blootstelling, behandelopties, verzoeken om middelen en wijzigingen sinds de vorige review nodig. Beide weergaven moeten uit dezelfde onderliggende beoordeling komen.

Bewaar de beoordelingsgeschiedenis in plaats van haar te overschrijven. Behoud de vorige conclusie, het nieuwe bewijs, gewijzigde aannames, de beoordelaar, de goedkeuring en de datum. Houd geaccepteerde risico’s zichtbaar, inclusief naderende vervaldata en voorwaarden die niet langer gelden.

Bruikbare operationele kengetallen zijn onder meer de ouderdom van risico’s die op een besluit wachten, achterstallige mijlpalen in de behandeling, de tijd tussen een wezenlijke wijziging en de herbeoordeling, en het aandeel significante scenario’s dat wordt ondersteund door actueel bewijs van beheersmaatregelen. Vergelijk metingen met uw eigen basislijn. Aantallen regels of gegenereerde aanbevelingen beschrijven vooral activiteit, geen betere besluiten. ISMS-kengetallen moeten helpen vastgelopen eigenaarschap en ononderbouwde conclusies zichtbaar te maken.

Secani verbindt risico’s, eisen, beheersmaatregelen en bewijs in een ISMS-werkruimte. Modelleer voor een eerste, afgebakende scope de ondersteunende systemen en leveranciers, koppel bestaand bewijs aan de maatregelen of besluiten die het ondersteunt en zet hiaten om in taken met een eigenaar. Toets door AI ondersteunde suggesties aan hun bronnen en bewaar menselijke goedkeuringen, opmerkingen en tijdstempels. De documentatie beschrijft die op bewijs gerichte werkwijze.

Begin met vijf significante scenario’s. Bevestig voor elk de eigenaar, de onderbouwing van de huidige beoordeling, het behandelbesluit, het verificatiebewijs en de volgende aanleiding voor een review. Neem er vervolgens één mee naar een echt planningsoverleg en vraag wat er moet veranderen. Als het antwoord een bevoegdheidsgrens, een opleveringsvolgorde, een gefinancierde taak of een expliciet acceptatiebesluit is, doet het register nuttig werk.