IT general controls (ITGC): wat ze zijn en waarom auditors erop sturen

IT general controls, kortweg ITGC, zijn de overkoepelende beheersmaatregelen rond de IT-omgeving die ervoor zorgen dat applicaties en gegevens betrouwbaar blijven functioneren. Ze vormen het fundament waarop auditors leunen bij vrijwel elke assurance-opdracht, van SOC 2 tot ISAE 3402. Toch worden ze in organisaties vaak onderschat, juist omdat ze niet over een specifiek bedrijfsproces gaan, maar over de IT eronder. In dit artikel leggen we uit wat ITGC zijn, welke domeinen ze beslaan, hoe ze zich verhouden tot application controls, en waarom hun kwaliteit bepaalt of een auditor op je geautomatiseerde controls kan steunen.

Wat zijn IT general controls?

ITGC zijn de beheersmaatregelen die de integriteit van programma's en gegevens binnen een IT-omgeving waarborgen. Ze werken niet op het niveau van een enkele transactie, maar op het niveau van de infrastructuur, de systemen en de processen die alle applicaties dragen. Denk aan de manier waarop toegang wordt verleend en ingetrokken, hoe wijzigingen aan systemen worden getest en goedgekeurd, en hoe back-ups en verstoringen worden beheerd. Als deze maatregelen op orde zijn, mag je erop vertrouwen dat de systemen doen wat ze horen te doen en dat de gegevens erin betrouwbaar zijn.

Het verschil met application controls

Het onderscheid tussen ITGC en application controls is essentieel om de rol van ITGC te begrijpen. Application controls zitten in een specifieke applicatie en borgen de juistheid, volledigheid en autorisatie van individuele transacties. Een invoercontrole die voorkomt dat je een negatief bedrag boekt, een automatische goedkeuringslimiet, of een drieweg-match tussen bestelling, ontvangst en factuur zijn application controls.

IT general controls werken een laag dieper. Ze bepalen of je überhaupt mag vertrouwen op die application controls. Stel dat een applicatie een goedkeuringslimiet van tienduizend euro hanteert. Die controle is alleen betrouwbaar als niemand de configuratie ongemerkt kan aanpassen en als wijzigingen aan de applicatie netjes worden getest en goedgekeurd. Dat laatste is ITGC. Met andere woorden: de application control is zo sterk als de general controls eronder.

De vier domeinen van ITGC

In de auditpraktijk worden ITGC doorgaans in vier domeinen ingedeeld. Het eerste is toegang tot programma's en data, oftewel logische toegangsbeveiliging. Hieronder valt het beheer van gebruikersaccounts, het toekennen van rechten op basis van functie, het tijdig intrekken van toegang bij uitdiensttreding, het beheer van beheerdersaccounts en periodieke toegangsbeoordelingen. Dit is in de praktijk het domein waar auditors de meeste bevindingen noteren.

Het tweede domein is wijzigingsbeheer van programma's. Het gaat erom dat wijzigingen aan systemen worden aangevraagd, getest, goedgekeurd en gecontroleerd in productie gebracht, met een functiescheiding tussen wie ontwikkelt en wie naar productie deployt. Het derde domein is systeemontwikkeling: het gestructureerd ontwikkelen en implementeren van nieuwe systemen, inclusief acceptatietesten en datamigratie. Het vierde domein is computeroperations, dat back-up en herstel, batch- en jobverwerking, monitoring en incidentafhandeling omvat. Samen dekken deze vier domeinen de levenscyclus van systemen en de dagelijkse beheersing ervan.

Waarom ITGC de basis vormen voor application controls

De kern van waarom auditors zo op ITGC sturen, zit in een afhankelijkheid. Een auditor wil zo veel mogelijk steunen op geautomatiseerde controls, omdat die consistent werken en efficiënt te toetsen zijn. Maar die steun is alleen verantwoord als de onderliggende IT-omgeving betrouwbaar is. Als de ITGC falen, bijvoorbeeld omdat ontwikkelaars ongecontroleerd wijzigingen in productie kunnen zetten of omdat iedereen beheerdersrechten heeft, dan kan de auditor niet meer aannemen dat een geautomatiseerde control het hele jaar correct heeft gewerkt.

Het gevolg is concreet en kostbaar. Zijn de ITGC niet effectief, dan kan de auditor niet op de application controls steunen en moet hij terugvallen op substantieve toetsing: handmatig grote aantallen transacties nalopen. Dat is duurder, trager en ingrijpender voor de organisatie. Zwakke ITGC ondermijnen daarmee de hele keten van assurance, en dat is precies de reden dat dit fundament zo veel aandacht krijgt.

ITGC in SOC 2 en ISAE 3402

In assurance-rapporten als SOC 2 en ISAE 3402 vormen ITGC een vast en zwaarwegend onderdeel. Beide rapporten doen een uitspraak over de opzet en, bij een type 2-rapport, de werking van controls over een periode. Een groot deel van die controls is van het type general control: toegangsbeheer, wijzigingsbeheer en operations. Een gebruikersorganisatie die op zo'n rapport leunt, leunt in de praktijk vooral op de kwaliteit van de ITGC bij haar leverancier. Vandaar dat een auditor de general controls grondig toetst voordat hij conclusies trekt over de specifiekere procescontroles.

Veelgemaakte fouten

De meest voorkomende fout is dat controles wel bestaan in de praktijk, maar niet aantoonbaar zijn. Een wijzigingsproces dat netjes wordt gevolgd maar niet wordt vastgelegd, is voor een auditor niet te toetsen. Zonder bewijs van uitvoering telt een controle niet mee. Een tweede klassieker is achterstallige toegangsintrekking: medewerkers die uit dienst zijn maar nog actieve accounts hebben, of rechten die meegroeien met elke functiewissel zonder ooit te worden opgeschoond. Een derde fout is ontbrekende functiescheiding, waarbij dezelfde persoon een wijziging ontwikkelt, goedkeurt en naar productie brengt. En tot slot zien we vaak dat beheerdersaccounts en serviceaccounts buiten het reguliere toegangsbeheer vallen, terwijl daar juist de grootste risico's zitten.

Hoe je ITGC aantoonbaar maakt

Een effectieve controle die je niet kunt aantonen, is voor een audit waardeloos. Aantoonbaarheid begint bij het systematisch vastleggen van uitvoering: tickets van wijzigingen met de bijbehorende goedkeuringen en testresultaten, logs van toegekende en ingetrokken rechten, en de uitkomsten van periodieke toegangsbeoordelingen. Wij adviseren organisaties om de bewijslast onderdeel te maken van het proces zelf, in plaats van die achteraf bij elkaar te zoeken vlak voor de audit. Een wijziging die niet door het proces is gegaan, hoort niet in productie te staan, en een proces dat consequent wordt gevolgd, levert vanzelf het bewijs op dat een auditor nodig heeft.

Hoe Secure Audit helpt

Secure Audit beoordeelt en versterkt IT general controls als onderdeel van interne IT-audits en in de voorbereiding op SOC 2- en ISAE 3402-trajecten. Wij brengen in kaart waar de ITGC effectief zijn en waar de aantoonbaarheid tekortschiet, en helpen de bewijslast structureel in de processen te verankeren. Neem contact op voor een kennismaking.