Een model is een softwareartefact. Dat is de stelling waarop dit template rust: een rekenbestand dat een beslissing voedt, verdient dezelfde disciplines als een CRM-systeem, ook al staat het niet in de applicatieportefeuille en heeft het geen leverancier. De onderbouwing staat in het artikel Model Risk en EUC, van blinde vlek naar beheersing. Dit is het instrument dat erbij hoort.
Het template doet drie dingen die een normenkader bruikbaar maken. Het bepaalt eerst de risicoklasse, zodat de zwaarte meeschaalt met wat er misgaat als de uitkomst niet klopt. Het stelt vervolgens per discipline de toetsvragen die bij die klasse horen, met het bewijs dat u mag verwachten. En het levert aan het eind een dekkingsbeeld en een lijst openstaande punten die u in een rapport of in de opvolging kunt zetten.
Gebruik het per artefact. De beoordeling blijft in uw eigen browser staan; er gaat niets naar een server. Exporteer naar Word als u het dossier wilt bewaren of delen.
Vul het artefact in dat u beoordeelt
Stap 1. Bepaal de risicoklasse
De zwaarte van het kader hoort te schalen met wat er misgaat als de uitkomst niet klopt. Zes vragen bepalen de klasse; die klasse bepaalt vervolgens welke van de 35 toetsvragen van toepassing zijn.
Stap 2. Het normenkader
Zeven disciplines, 35 toetsvragen. Per vraag staat welk bewijs u mag verwachten en vanaf welke risicoklasse de vraag van toepassing is. Een vraag die bij uw klasse niet geldt, blijft zichtbaar maar telt niet mee; zet hem alsnog op voldaan als u strenger wilt zijn dan de klasse voorschrijft.
Wijzigingsbeheer
Zonder wijzigingsbeheer weet niemand welke versie de waarheid was op het moment dat de beslissing viel. Dat is niet in de eerste plaats een controleprobleem maar een reconstructieprobleem: de uitkomst van vorig kwartaal is niet meer na te rekenen.
Documentatie
De toets is niet of er documentatie bestaat maar of iemand anders het model kan overnemen. Modellen die op een persoon staan, vallen om zodra die persoon vertrekt, en dat gebeurt gemiddeld eerder dan het model wordt vervangen.
Functiescheiding en toegang
Bij een rekenbestand valt de functiescheiding vrijwel altijd weg: dezelfde persoon bouwt, vult in, rekent en presenteert. Dat is aanvaardbaar zolang het bewust is besloten en zichtbaar gecompenseerd wordt, en onaanvaardbaar zolang niemand het heeft opgemerkt.
Stamgegevens en parameters
Een tarief dat in een formule is getypt, is onvindbaar op het moment dat het verandert. De stille fout in deze discipline is niet een verkeerde som maar een verouderd getal dat jaren blijft staan.
Invoer
Bijna elke reconstructie van een modelfout eindigt bij de invoer, niet bij de formule. Een model dat verkeerde invoer stilzwijgend verwerkt, is gevaarlijker dan een model dat rekenfouten maakt, omdat de uitkomst plausibel blijft.
Uitvoer
De uitkomst reist verder dan het model. Zodra het getal in een presentatie staat, zijn de aannames eraf gevallen. Wat u hier borgt, bepaalt of de ontvanger het getal kan wegen of alleen kan geloven.
Validatie
Dit is de discipline die buiten de financiële sector vrijwel altijd ontbreekt, en het is de enige die de andere zes kan opsporen. Validatie is niet narekenen of de som klopt maar vaststellen of het model nog het juiste antwoord geeft op de juiste vraag.
Stap 3. De uitkomst
De dekking telt alleen de vragen die bij uw risicoklasse van toepassing zijn. Vragen op n.v.t. tellen niet mee in de noemer; onbeoordeelde vragen wel, omdat een niet gestelde vraag geen dekking oplevert.
| Discipline | Van toepassing | Voldaan | Deels | Niet | Nog open | Dekking |
|---|---|---|---|---|---|---|
| 1. Wijzigingsbeheer | 0 | 0 | 0 | 0 | 0 | |
| 2. Documentatie | 0 | 0 | 0 | 0 | 0 | |
| 3. Functiescheiding en toegang | 0 | 0 | 0 | 0 | 0 | |
| 4. Stamgegevens en parameters | 0 | 0 | 0 | 0 | 0 | |
| 5. Invoer | 0 | 0 | 0 | 0 | 0 | |
| 6. Uitvoer | 0 | 0 | 0 | 0 | 0 | |
| 7. Validatie | 0 | 0 | 0 | 0 | 0 | |
| Totaal | 0 | 0 | 0 | 0 | 0 |
Openstaande punten
Nog niets beoordeeld.
Bijlage A. Vier normsporen en het dekkingsgat
Waar komen de normen vandaan waarop dit kader steunt, en waarom is er toch een gat? Klik in het kader hierboven op een chip voor de uitleg per norm.
| Spoor | Kaders | Dekt | Dekt niet |
|---|---|---|---|
| Toezicht | ECB-gids interne modellen, Solvency II artikel 120 tot en met 125, PRA SS1/23, SR 11-7 en SR 26-2 | Alle zeven disciplines, inclusief onafhankelijke validatie en een verplichte modelinventaris. | Geldt alleen voor banken en verzekeraars met een vergunning voor een intern model. Daarbuiten bestaat geen equivalent. |
| Spreadsheet en EUC | ICAEW Twenty principles (herzien 2024), FAST Standard 02c (2019), EuSpRIG | Bouwkwaliteit tot op celniveau: scheiding van invoer, bewerking en uitvoer, toelichtingsblad, niets hardcoden, versiebeheer en back-up, testen, ingebouwde controles, beschermde delen. | De organisatorische helft: wie keurt goed, wie valideert, wie is eigenaar. |
| Generiek software en IT | ISO/IEC/IEEE 12207:2017, ISO/IEC 25010:2023, COBIT, ITGC | Precies die organisatorische helft: levenscyclus, configuratiebeheer, wijzigingsbeheer, logische toegang, IT-operations. | Wordt in de praktijk niet op een rekenbestand losgelaten. Het bestand staat niet in de applicatieportefeuille en valt dus buiten de scope van de IT-auditor. |
| Kunstmatige intelligentie | ISO/IEC 42001:2023, NIST AI RMF 1.0, AI-verordening (onder meer artikel 10) | Dezelfde zeven disciplines, maar alleen voor systemen die leren of afleiden. | Deterministische rekenmodellen vallen er per definitie buiten, hoe zwaar de uitkomst ook weegt. |
De conclusie is geen normvacuum maar een dekkingsprobleem. De strengste eisen liggen bij de sector die het risico toch al zag, de scherpste bouwvoorschriften missen een eigenaar, de breedste kaders kijken langs het bestand heen, en de nieuwste kaders sluiten juist het meest voorkomende modeltype uit. Buiten de financiële sector beheerst u een model niet omdat het moet, maar omdat het verstandig is. Dit template is de brug: de zeven disciplines van een softwareartefact, toegepast op een model, met per discipline de verwijzing naar het kader dat het al regelt.
Bijlage B. De modelinventaris
Dit kader beoordeelt een artefact. De vraag die daaraan voorafgaat is welke artefacten u eigenlijk heeft. Zonder inventaris beoordeelt u de modellen die u toevallig kent, en dat zijn zelden de riskantste. Tien kolommen volstaan om te beginnen.
| Kolom | Wat legt u vast |
|---|---|
| Modelnaam en versie | De geldende versie, zoals die ook in het bestand staat. |
| Doel en beslissing | Welke vraag beantwoordt het model en voor welke beslissing dient de uitkomst. |
| Eigenaar | Wie is verantwoordelijk voor de uitkomst. Een functie, geen afdeling. |
| Beheerder | Wie mag wijzigen en wie is de aangewezen vervanger. |
| Risicoklasse | A, B of C, met de datum van de laatste classificatie. |
| Invoerbronnen | Welke systemen of rapporten voeden het model. |
| Afnemers van de uitvoer | Wie krijgt het getal, en gaat het de organisatie uit. |
| Laatste validatie | Datum, uitvoerder en de status van de bevindingen. |
| Volgende toetsing | Afgeleid van de risicoklasse. |
| Vindplaats | Waar staat het bestand, en waar staat het versiearchief. |
Begin bij de uitkomsten en niet bij de bestanden: loop de rapportages en besluiten van het afgelopen jaar langs en vraag bij elk getal waar het vandaan komt. Wat u dan vindt, is de werkelijke portefeuille.
Een kader per model is te doen. Honderd modellen niet.
Dit template beoordeelt een artefact en levert u een dossier per model. Wilt u de inventaris, de classificatie, de toetsplanning en de opvolging van bevindingen op een plek, dan doet Modelio in de Audirium-suite dat. Modelio zit in het betaprogramma.