Beroepsfout ICT: voorbeelden, afbakening en wat je moet checken

Wanneer is een ICT-probleem een beroepsfout?

Een “beroepsfout” bij ICT betekent in de kern dat iemand met professionele kennis en kunde, die normaal gesproken passende zorgvuldigheid mag worden verwacht, niet (voldoende) zorgvuldig heeft gehandeld. Het gevolg is dat daardoor schade ontstaat of het risico op schade aanzienlijk toeneemt. Het woord “voorbeeld” is daarbij belangrijk: een concreet incident is niet automatisch een beroepsfout, maar het kan wel aanwijzen dat er onvoldoende professioneel is gewerkt.

Belangrijk is dus de combinatie van drie onderdelen: (1) het handelen of nalaten, (2) de professionele norm/verwachting die je redelijkerwijs mag hanteren voor dat type werk, en (3) het effect daarvan (schade of een aantoonbaar relevant risico). Zonder die samenhang blijft het vaak bij een technische storing of een mislukte implementatie, waarbij de vraag is of er echt sprake was van onzorgvuldigheid.

Concrete beroepsfout-ICT voorbeelden (geclusterd)

Onderstaande voorbeelden zijn bedoeld als herkenningskaders. Of het in een specifieke situatie een beroepsfout is, hangt altijd af van context zoals afspraken, scope, planning, beschikbare informatie en de handelswijze die je van vergelijkbare professionals mag verwachten.

1) Fouten in uitvoering en implementatie

Oplevering van functionaliteit met bekende kritieke fouten terwijl er geen redelijke, passende veiligheidsmaatregelen zijn genomen.
Aanpassingen in productie zonder deugdelijk wijzigingsbeheer of zonder adequate terugval/rollback bij een verhoogd risico.
Verkeerde koppelingen of migratiestappen waardoor gegevens verkeerd worden overgezet, terwijl een zorgvuldige testaanpak die fout had kunnen signaleren.

2) Tekortschietende test- en kwaliteitsborging

Het niet uitvoeren van relevante tests (bijvoorbeeld op betrouwbaarheid of beveiligingsaspecten) terwijl die tests redelijkerwijs nodig waren.
Testscenario’s die bewust niet aansluiten op de praktijk (bijvoorbeeld geen aandacht voor randgevallen), met als gevolg dat het probleem pas bij livegebruik zichtbaar wordt.
Het ontbreken van controle op reconciliatie/consistentie na een migratie, terwijl je daarmee doorgaans problemen vroeg kunt ontdekken.

3) Onzorgvuldig advies of ontwerpbeslissingen

Ontwerpkeuzes die evident niet passen bij de eisen (zoals beschikbaarheid, schaalbaarheid of beveiliging) zonder onderbouwde risicoafweging.
Onvolledige of onjuiste informatievoorziening aan de opdrachtgever, bijvoorbeeld waardoor men implementeert met verkeerde aannames.
Het niet (tijdig) signaleren van dat een requirement in strijd is met beveiligings- of datakwaliteitsdoelen, terwijl dat bij normale analyse had moeten blijken.

4) Communicatie- en overdrachtsfouten

Het niet documenteren van essentiële technische of functionele keuzes, waardoor overdracht naar beheer/operations onveilig of onjuist gebeurt.
Onvoldoende waarschuwing voor bekende risico’s of afhankelijkheden, terwijl die risico’s kenbaar waren.

Hoe verschilt een beroepsfout van een “gewone” storing?

Een veelvoorkomende misvatting is dat ieder incident in ICT automatisch een beroepsfout is. Dat klopt niet. Het verschil zit meestal in zorgvuldigheid en voorzienbaarheid.

Voorzienbaarheid: was het probleem redelijkerwijs te verwachten op basis van eerdere ervaringen, technische analyses of testbevindingen?
Zorgvuldigheid: is er gewerkt volgens een aanpak die past bij het type werk (bijvoorbeeld testen, reviewen, risicobeheersing, wijzigingsbeheer)?
Afspraken en scope: paste de geleverde oplossing bij wat was afgesproken en waarvoor redelijke verantwoordelijkheid was genomen?
Beperking van schade/risico: is er adequaat gehandeld zodra het risico of de fout zichtbaar werd (bijvoorbeeld tijdig herstel, containment, herstelplan)?

Als een probleem ontstaat door factoren die redelijkerwijs niet voorzienbaar waren, of als er wel zorgvuldig is gewerkt maar het toch misgaat, dan is de kwalificatie “beroepsfout” niet automatisch passend. De beoordeling draait dan om bewijs en onderbouwing.

Gevolg: welke controlepunten helpen bij beoordeling?

Zonder dat je alvast conclusies trekt, kun je bij beroepsfout-achtige situaties wel gerichte controlepunten gebruiken. Dit zijn vooral organisatorische en bewijsgerichte vragen.

Wat is precies gebeurd (feitelijk)? Beschrijf de tijdlijn: start, wijzigingen, testmomenten, meldingen, herstelacties. Zonder feitelijke helderheid blijft het een discussie op aannames.
Welke professionele aanpak was passend? Werk uit welke stappen je redelijkerwijs mag verwachten voor het soort werk: review, testen, risicobeperking, wijzigingsbeheer en documentatie.
Wat was het resultaat van testen en controles? Vraag naar testdocumentatie, bevindingen, en hoe bevindingen zijn beoordeeld. Ook “geen test uitgevoerd” is relevante informatie, maar dan moet je kunnen uitleggen waarom dat verdedigbaar was.
Welke afspraken waren leidend? Leg de scope, verantwoordelijkheden en acceptatiecriteria vast. Een incident buiten scope is vaak een ander beoordelingskader dan een incident binnen scope.
Is er schade of een relevant risico? Geef aan wat de impact is: dataverlies, onjuiste output, stilstand, veiligheidsrisico, of aantoonbare extra kosten door het incident. Ook hier geldt: zonder onderbouwing blijft “impact” te vaag.

Tot slot: bij elk voorbeeld is het nuttig om misverstanden te vermijden. Het doel is niet om snel “schuld” toe te wijzen, maar om helder te krijgen of er professionele onzorgvuldigheid aantoonbaar is en welke rol ICT-werk daarin speelde.

Als je je begrip wilt aanscherpen op begrippenniveau, kan een basisuitleg over definities helpen om “beroepsfout” en aanverwante begrippen correct te plaatsen: definities. Ook kan het nuttig zijn om te kijken hoe beroepsfouten zich vertalen naar aansprakelijkheidsvragen in bredere context, bijvoorbeeld bij voorbeelden beroepsfouten beroepsaansprakelijkheid.