procescheck

Business Impact Analyse en BIV-classificatie per bedrijfsproces, met de applicaties en infrastructuurcomponenten die eronder liggen.

Vier stappen achter elkaar. Je legt je processen vast en zegt welke kritiek zijn. Je koppelt de applicaties die ze dragen. Je beantwoordt per proces zes vragen over beschikbaarheid, integriteit en vertrouwelijkheid; daaruit volgen de BIV-scores, de procesklasse en de continuiteits- parameters RTO, RPO, WRT en MTPD. En je importeert je CI-landschap, waarna de blast radius laat zien wat er omvalt als een component uitvalt, en welke kritieke processen op maar een enkele applicatie steunen.

Het rekent in je eigen browser: geen server, geen account, geen telemetrie. Je dossier is een JSON-bestand dat je zelf opslaat en dat je apparaat niet verlaat.

Open de tool · uitleg en verantwoording

Status: prototype. Werkt en is te draaien, maar zonder belofte over volledigheid, onderhoud of ondersteuning. De vragen, de antwoordklassen en de rekenregels zijn woordelijk overgenomen uit de applicatie die procescheck tot september 2026 was (tag v0-applicatie) en staan getest in procescheck.json. Wat nog niet is beproefd: het gebruik in een echte BIA-ronde met meerdere proceseigenaren.

Voor wie

CISO's, informatiebeveiligers en proceseigenaren bij publieke organisaties die een BIA of BIV-classificatie moeten doen, en iedereen die wil weten welke processen omvallen als een component uitvalt. Je hebt niets nodig behalve een browser.

Snel starten

Open de tool. Wil je hem offline? Sla de pagina op met Ctrl+S; alles zit erin, ook de vragen en de rekenregels.
Vul bij Processen je organisatie in en voeg je processen toe. Zet het vinkje kritiek bij de processen waar de dienstverlening op stilvalt.
Voeg bij Applicaties de systemen toe en koppel ze aan de processen. Een object met industriele automatisering hoort er ook bij; voor de eisen aan zo'n object bestaat de CSIR Assessment Tool, en je kunt hier naar dat dossier verwijzen.
Beantwoord bij BIA en BIV de zes vragen per proces. De schaal loopt van 1 (Catastrofaal) tot 5 (Verwaarloosbaar): 1 is het ergst, en de zwaarste score telt.
Vul bij Businesscontext in waar het proces van afhangt en wie het raakt.
Importeer bij Blast radius je CI-landschap als JSON of CSV, of klik Voorbeeld laden om te zien wat de analyse doet. Het formaat staat in de verantwoording.
Kijk op het Dashboard wat als eerste aandacht vraagt en druk de Uitdraai af.
Heb je een procesoverzicht of een CMDB-export liggen? De AI-hulp zet die met je eigen API-sleutel (Mistral, een lokale Ollama, of een andere leverancier) om naar een voorstel; met Voorstel laden kies je per regel wat je overneemt. De tool zelf praat nooit met een leverancier.

Sla je dossier tussendoor op met Dossier opslaan. De browser onthoudt je werk ook zelf, maar een opgeslagen bestand is wat je deelt, archiveert en de volgende ronde terugzet.

De Uitdraai bevat een kroonjuwelenlijst: de kritieke processen met hun eigenaar en de systemen eronder. Dat is precies stap 1 van Risicoanalyse langs aanvalspaden.

Zelf bouwen

python instrument/haal_bron.py --check   # procescheck.json loopt gelijk met tag v0-applicatie
python instrument/bouw.py                # schrijft instrument/dist/index.html
python -m pytest instrument/tests -v     # 82 tests, inclusief een doorloop in Chromium
python ai/bouw.py                        # de AI-hulp, ai/dist/index.html
python -m pytest ai/tests -v             # 41 tests, de leverancier nagespeeld: geen sleutel nodig

Python 3.12 of nieuwer, alleen standaardbibliotheek. Voor de browsertests: pip install pytest playwright en python -m playwright install chromium. git fetch --tags is nodig voor de tag v0-applicatie, waar de bron uit komt.

Bijdragen

Zie CONTRIBUTING.md. Een vraag die niet klopt, een klasse die verkeerd valt of een landschapsformaat dat we niet lezen: open een issue. Wijzig procescheck.json niet met de hand; dat bestand komt uit instrument/haal_bron.py en CI controleert dat.

Licentie

EUPL-1.2. De vragen en antwoordteksten komen uit het sjabloon Template BIA & BIV-Classificatie.xlsx dat de oorspronkelijke applicatie gebruikte; zie de verantwoording.

Zo gebruik je procescheck

Een BIA is geen invuloefening maar een gesprek met de proceseigenaar. Deze tool is het formulier eromheen: hij stelt de vragen in een vaste volgorde, rekent de klasse uit en laat zien wat er nog ontbreekt. Wat hij niet doet is voor je bedenken hoe erg iets is.

Wat je ermee bereikt

De applicatie waar procescheck uit voortkomt had vijf doelen; die staan hier, vertaald naar het instrument.

Doel	Waar het zit
Processen en applicaties centraal vastleggen	Tab Processen en Applicaties; alles in een dossier
BIA en BIV-classificatie uitvoeren en herhalen	Tab BIA en BIV, zes vragen per proces
Continuiteitseisen expliciet maken	RTO, RPO, WRT en MTPD volgen uit de B-vragen
Zien wat af is en wat niet	Tab Dashboard: volledigheid, dekking, review, prioriteiten
Verantwoorden wat je hebt gedaan	Tab Uitdraai: een afdrukbaar dossier met de onderbouwing

De schaal loopt andersom dan je verwacht

1 is Catastrofaal, 5 is Verwaarloosbaar. De zwaarste klasse is dus het laagste getal, en de aggregatie is een minimum:

B (beschikbaarheid) = de zwaarste van B1 tot en met B4;
I (integriteit) = de score op I1; V (vertrouwelijkheid) = de score op V1;
procesklasse = de zwaarste van B, I en V.

Beantwoord je maar een deel van de vragen, dan rekent de tool met wat er staat. Een leeg antwoord telt niet mee en trekt de klasse dus niet omlaag.

De zes vragen en wat eruit volgt

Vraag	Gaat over	Levert
B1	Maximale uitvalduur voordat onaanvaardbare gevolgen optreden	RTO
B2	Maximale hoeveelheid dataverlies die acceptabel is	RPO
B3	Tijd om na herstel de achterstand in te halen	WRT
B4	Maximale tijd dat het proces stil kan liggen, alles bij elkaar	MTPD
I1	Impact als informatie onjuist, onvolledig of gemanipuleerd is	I-score
V1	Impact als informatie ongeautoriseerd wordt ingezien of verspreid	V-score

De antwoordtekst onder de keuzelijst is de omschrijving die bij die klasse hoort. Lees hem voor tijdens het interview; hij is preciezer dan het label. Bij V1 zijn de vijf antwoorden de rubriceringsniveaus Geheim, Confidentieel, Vertrouwelijk, Intern en Openbaar.

Vul de onderbouwing in. Het cijfer is over een jaar niet meer uit te leggen, de zin eronder wel. De uitdraai zet die zinnen achter de scores.

RTO en RPO met de hand

Onder de uitkomst staan losse velden voor RTO en RPO. Die zijn er voor een expliciete afspraak ("hersteltijd 4 uur, vastgelegd in het contract") naast de klasse die uit de vragen volgt.

Let op, en dit is met opzet zo gehouden: de volledigheidscontrole "RTO / RPO" kijkt naar de BIA-vragen B1 en B2, niet naar deze velden. Vul je alleen de handmatige velden in, dan blijft het proces als onvolledig staan. Dat is trouw aan hoe de applicatie het deed, en het is verdedigbaar: de klasse komt uit het gesprek met de eigenaar, het getal in het contract is een afgeleide daarvan.

Wanneer een proces compleet is

Tien controles per proces, in deze volgorde: beschrijving, doelstelling, eigenaar, afdeling, laatste beoordelingsdatum, reden kritiek (alleen bij een kritiek proces), gekoppelde applicaties, BIA/BIV, RTO/RPO en businesscontext.

compleet: niets ontbreekt · aandacht: 1 tot 3 ontbreken · onvolledig: 4 of meer.

Daaruit volgt de prioriteit in het dashboard, in deze volgorde van beoordelen:

critical: kritiek proces zonder BIA. Je weet niet hoe erg het is bij het proces waar het het meest toe doet.
high: hoog risico (een van B, I, V is 1 of 2) zonder RTO en RPO.
high: kritiek proces dat verder onvolledig is.
medium: vier of meer velden ontbreken.
low: een tot drie velden ontbreken.

Op tijd beoordeeld

Een datum is "op tijd" als hij niet ouder is dan een jaar. Het dashboard telt dat voor vier dingen: de procesbeoordeling, het BIA-interview, de review van de businesscontext en de review per applicatie. Een leeg datumveld telt als niet op tijd; dat is geen straf maar een vraag.

De blast radius

Importeer je CI-landschap (JSON of CSV, formaat in de verantwoording) of vul de componenten met de hand. De keten loopt van component naar applicatie naar proces, en de analyse beantwoordt drie vragen:

Wat valt er om als dit onderdeel uitvalt: alles wat er stroomafwaarts van hangt, met daarin de processen en de kritieke processen apart geteld. De ranglijst zet bovenaan wat de meeste kritieke processen raakt.
Waar zit geen redundantie: kritieke processen die op hoogstens een applicatie steunen.
Klopt het landschap: relaties naar een onbekend doel en cycli worden gemeld, niet stil genegeerd.

De tekening is dezelfde data in drie kolommen. Klik op een onderdeel om te zien wat eronder valt. Bij meer dan zestig onderdelen tekent hij alleen wat een kritiek proces draagt; de tabel blijft volledig.

Importeren voegt toe en overschrijft niets. Een proces of applicatie die de tool herkent aan de code of de naam, blijft staan zoals hij is; een tweede import van hetzelfde bestand verandert niets.

De uitdraai

Alles op een rij, in negen hoofdstukken, afdrukbaar op A4 met de knop Afdrukken of Ctrl+P. Hoofdstuk 3 is de kroonjuwelenlijst: de kritieke processen, zwaarste klasse eerst, met eigenaar en de systemen eronder. Dat is de tabel waar Risicoanalyse langs aanvalspaden in stap 1 om vraagt. Staat er meer dan tien in, kies er dan tien; de risicoanalyse werkt met een korte lijst, anders wordt het een inventarisatie in plaats van een analyse.

De AI-hulp

Een procesoverzicht van tachtig processen typ je niet over. De AI-hulp zet zo'n document, of een CMDB-export, om naar een voorstel in het datamodel van de tool: processen met naam, beschrijving, doelstelling en eigenaar; applicaties met eigenaren en soort; componenten met de relaties ertussen.

Wat hij nooit doet: scores, klassen of prioriteiten bepalen. Dat rekent de tool, uit jouw antwoorden.

Zo werkt het:

Je vult op de AI-pagina je eigen API-sleutel in. Mistral is de standaard (Europese partij, hosting in de EU); een lokale Ollama of een andere leverancier met een OpenAI-compatibele endpoint kan ook. De sleutel blijft in die tab en verdwijnt als je hem sluit.
Je kiest een opdracht en plakt tekst of kiest een bestand (txt, md, csv, xlsx). De pagina zegt wat er waarheen gaat en vraagt per sessie je toestemming. Stuur geen persoonsgegevens mee die daar niet horen; de anonimizer staat ernaast.
Het model levert per item een letterlijk citaat uit je invoer. Staat dat citaat er niet in, dan wordt het item gemarkeerd en staat het standaard op overslaan. Wat het model niet zeker wist, staat eronder.
Je slaat het voorstel op en laadt het in de tool met Voorstel laden. Per regel zie je of het nieuw is, al bestaat of botst met wat er staat, en kies je overnemen, samenvoegen (alleen lege velden vullen) of overslaan. Niets verandert voordat je op Overnemen klikt; wat je overneemt, staat in de uitdraai onder Verantwoording met leverancier, model en datum.

De tool zelf doet geen enkele netwerkaanroep, ook niet als je de AI-hulp gebruikt; alleen de AI-pagina praat naar buiten, en een test bewaakt dat.

Je dossier

Alles blijft in je browser. Dossier opslaan geeft je een JSON-bestand (procescheck-dossier-<organisatie>-<datum>.json) dat je kunt delen, archiveren en later terugzetten. Bewaar het in je eigen documentbeheer; git of een gedateerde kopie is je audit trail. Er is geen auditlog in de tool, want die had alleen zin toen meerdere mensen in dezelfde database werkten.

In het bestand staat een vingerafdruk van de bron. Laad je later een dossier terwijl de vragen inmiddels zijn gewijzigd, dan zegt de tool dat erbij en loop je de uitkomsten na.

Waar de inhoud vandaan komt

Een instrument dat een klasse aan een proces hangt, moet kunnen zeggen waar die klasse vandaan komt. Hier staat per onderdeel wat is overgenomen, wat eigen invulling is, en waar de bron zichzelf tegenspreekt.

De vragen en de antwoordklassen

De zes vragen, de vijf antwoordklassen en de omschrijving per klasse komen woordelijk uit de applicatie die procescheck tot september 2026 was. Die applicatie noemt als herkomst het sjabloon Template BIA & BIV-Classificatie.xlsx.

De bron is geen overgetypte kopie. instrument/haal_bron.py leest de code op de git-tag v0-applicatie (frontend/src/pages/Bia/BiaPage.tsx en biaShared.tsx) en schrijft daar procescheck.json uit; instrument/tests/test_bron.py legt elke vraag, elke tooltip en elk van de dertig antwoordteksten daarna weer naast diezelfde code. Wijkt er een letter af, dan valt de test om. De tag staat vast en verhuist niet.

B1 en B2 hebben dezelfde vijf antwoordteksten. Zo staat het in de bron: het sjabloon herhaalde de alinea bij de vraag over uitvalduur en die over dataverlies. Dat is geen fout van het extractiescript. De vragen zelf verschillen wel, en de parameters die eruit volgen ook (RTO tegenover RPO).

De continuiteitsparameters, en waar de bron zichzelf tegenspreekt

B1 levert de RTO, B2 de RPO, B3 de WRT en B4 de MTPD. Die koppeling staat als commentaar in de oorspronkelijke code en is hier vastgelegd. De labels per score komen uit PARAM_MAP in biaShared.tsx; voor de RTO staan dezelfde vijf teksten in backend/app/routers/export.py, en de test vergelijkt beide.

Daarnaast bestaat er een klassentabel in Docs/MTPD-RTO-WRT-RPO-classificatie.md, die je in de tool terugvindt onder De klassen naast elkaar. Voor de WRT lopen die twee tegen elkaar in:

	Catastrofaal (1)	Verwaarloosbaar (5)
Vragenlijst (`PARAM_MAP`)	Enkele uren	Meer dan een week
Klassentabel (`Docs/`)	meerdere werkdagen	minder dan 1 uur

Dat is te verklaren: de tabel leest WRT als "hoeveel tijd heb je nog om de achterstand weg te werken" (bij een catastrofaal proces heb je die tijd juist niet, dus staat er ruimte in de tabel als tegenwicht bij RTO), terwijl de vragenlijst vraagt hoeveel tijd je nodig hebt. Beide zijn overgenomen zoals ze in de bron staan; we hebben er niet stilzwijgend een van rechtgezet, want dan zou de tool iets anders zeggen dan de organisatie die ermee werkte. De vragenlijst bepaalt de score, de tabel is naslag. Een test legt dit verschil vast, zodat het een besluit blijft en geen slordigheid wordt.

De rekenregels

De aggregatie (min over de ingevulde scores), de tien volledigheidscontroles, de prioriteitsregels, de dekkingspercentages en de reviewregel van een jaar komen uit backend/app/routers/dashboard.py op dezelfde tag. instrument/reken.py is de referentie-implementatie; instrument/bron/app.js heeft dezelfde functies onder dezelfde namen, en de browsertests vergelijken wat op het scherm staat met wat de referentie uitrekent.

Twee dingen wijken bewust af van de applicatie:

Het gedachtestreepje wordt een komma. De reden die in de code als Kritisch proces, gedachtestreepje, onvolledig gedocumenteerd staat, heet hier Kritisch proces, onvolledig gedocumenteerd; de commons schrijft geen gedachtestreepjes.
De lichtste prioriteit heet low en niet medium. In de applicatie kregen "vier of meer velden ontbreken" en "een tot drie velden ontbreken" allebei het label medium, met alleen een ander redentekst. Hier heet de tweede low, zodat de prioriteit gelijkloopt met de bandbreedtes die de applicatie zelf al hanteerde voor volledigheid (0 compleet, 1 tot 3 aandacht, 4 of meer onvolledig). De redenteksten zijn wel letterlijk overgenomen, inclusief het verschil tussen "velden ontbreken" en "veld(en) ontbreken".

Afronden gebeurt half omhoog. Dat lijkt een detail en is het niet: Python rondt 12,5 af naar 12 (banker's rounding), JavaScript naar 13. Zonder een gedeelde regel zou de referentie een ander percentage tonen dan de pagina. Beide kanten gebruiken floor(x + 0.5), en een test bewaakt het.

De blast radius

De analyse komt uit blast-radius, een losse CLI die in september 2026 in procescheck is opgegaan. Reden: de vraag "wat valt er om" gaat over processen, en de data (proces, applicatie, component) stond hier al. De rekenregels zijn overgenomen uit blastradius/analysis.py: het bereik is de transitieve afsluiting over de uitgaande relaties, de dekking telt de dragende applicaties per proces, en de ranglijst sorteert op kritieke processen, dan processen, dan omvang. Een test vergelijkt de uitkomst met die van de oorspronkelijke CLI zolang die repo ernaast staat.

Het importformaat is dat van blastradius/parsers.py:

JSON: {"nodes": [{"id", "label", "type", "kritiek"}], "edges": [{"from", "to", "relatie"}]}, met type uit ci, app of proces. Een relatie loopt van drager naar gedragene (ci-db01 → app-brp → proc-paspoort).
CSV: een regel per relatie, kolommen from, from_label, from_type, from_kritiek, to, to_label, to_type, to_kritiek, relatie. Ontbreekt from_type, dan is het een ci; ontbreekt to_type, dan een proces. Kritiek is waar bij ja, true, 1 of yes.

Het voorbeeldlandschap in de tool is de testdata van blast-radius: verzonnen, maar herkenbaar gemeentelijk.

Eigen invulling bij het opgaan: de ids krijgen in de graaf een voorvoegsel (proces:, app:, ci:), zodat een proces P01 en een applicatie P01 elkaar niet overschrijven, en een relatie naar een doel dat noch applicatie noch component is, wordt als waarschuwing gemeld in plaats van stil overgeslagen.

Wat eigen invulling is

De kroonjuwelenlijst in de uitdraai: de kritieke processen, zwaarste klasse eerst, in de kolommen die stap 1 van de risicoanalyse langs aanvalspaden vraagt.
Het veld soort bij een applicatie (applicatie of object met industriële automatisering) en de optionele verwijzing naar een CSIR-dossier. Dat is de haak naar de CSIR Assessment Tool en verplicht tot niets.
Het dossierformaat (JSON met een vingerafdruk van de bron) en de uitdraai zelf.

Wat is vervallen ten opzichte van de applicatie

Inloggen met Azure AD, de auditlog, de exportserver voor xlsx, docx en pptx, de Docker-omgeving en de losse pagina Ketenarchitectuur. Dat was geen inhoud maar hosting: een database, een account en een beheerder tussen jou en een formulier met zes vragen. De auditlog bestond omdat meerdere mensen in dezelfde database werkten; een dossier op je eigen schijf heeft git of een gedateerde kopie als audit trail. De graaf uit de Ketenarchitectuur-pagina is teruggekomen als de tekening bij de blast radius.

Zestien vraagslots uit het oorspronkelijke sjabloon (b5 tot en met b8, i2 tot en met i7, v2 tot en met v7) zijn niet meegegaan: ze werden nergens gesteld. Wie ze nodig heeft, voegt ze toe aan procescheck.json; de pagina toont wat er in de bron staat.

De AI-hulp

De opdrachten (systeemprompts, JSON-schema's, toegestane invoer) staan als data in ai/opdrachten.json; de rekenregels van de tool en het dossier gaan nooit naar het model. Elke prompt eist dat het model niets verzint, lege velden leeg laat en per item een letterlijk citaat uit de invoer geeft; die citaten controleert de pagina zelf. Geen prompt vraagt om een score, klasse of prioriteit. De vorm (aparte pagina met eigen Content-Security-Policy, sleutel alleen per sessie, voorstel in plaats van schrijven) staat in het bouwplan AI-hulp van 03-09-2026 en in het redactiestatuut, B14.

Mistral is de standaardleverancier omdat het een Europese partij is met hosting in de EU; wie soevereiner wil, draait een model lokaal met Ollama. De keuze is aan de gebruiker, en de bewaartermijnen van de eigen leverancier ook. De voorbeeldantwoorden in ai/tests/fixtures/antwoorden/ zijn één keer met Mistral (mistral-medium-latest) opgenomen op verzonnen invoer en daarna vastgelegd; de tests spelen ze na en hebben geen sleutel.

Wat dit niet is

Geen technische verificatie en geen risicoanalyse. De uitkomst komt uit je eigen antwoorden. De klasse zegt hoe erg het is als het misgaat, niet hoe waarschijnlijk dat is en niet of je maatregelen deugen. Voor de vraag hoe een aanvaller bij een kroonjuweel komt, gebruik je de risicoanalyse langs aanvalspaden; voor de eisen aan een object met industriele automatisering de CSIR Assessment Tool.