Grip op general IT controls – deel II

Dit is het tweede deel van het tweeluik ‘Grip op…’. Dit tweeluik is primair bedoeld voor auditprofessionals die geen IT-achtergrond hebben. Deel I handelde over application controls. Deel II gaat over het fenomeen general IT controls.

De term general IT controls (GITC) is in de jaren tachtig van de vorige eeuw ontstaan in de accountancy. We hebben het over het tijdsgewricht dat de financiële boekhoudingen net waren geautomatiseerd. De certificerende accountant had comfort nodig omtrent betrouwbare werking van de geautomatiseerde boekhouding. De meeste certificerende accountants hadden in die tijd nog nauwelijks kennis van IT. Daarom werd een professional in het team opgenomen die zich een oordeel moest vormen over de algemene maatregelen die de betrouwbare werking van de automatisering moesten waarborgen. In die tijd is de term GITC, ook wel ITGC genoemd, ontstaan. Professionals die de accountant bij jaarrekeningcontrole als ‘onderaannemer’ gebruikt, werden in die tijd EDP-auditors genoemd. Tegenwoordig gebruiken we de term IT-auditor.

GITC’s zijn belangrijk voor elke organisatie. Het zijn fundamentele beheersingsmaatregelen die de betrouwbaarheid, veiligheid en continuïteit van IT-systemen waarborgen. Ze vormen de basis voor betrouwbare geautomatiseerde bedrijfsprocessen en (financiële) verslaglegging. Anders gezegd, GITC’s maken de werking van informatietechnologie als geheel betrouwbaar.

Definitie

Er zijn meerdere definities in omloop. Wij kiezen hier voor de definitie van de Amerikaanse beroepsorganisatie van IT-auditors ISACA: ‘Beheersingsmaatregelen die betrekking hebben op de IT-omgeving waarin applicaties worden ontwikkeld, onderhouden en gebruikt. Ze zijn van toepassing op alle systemen en processen en zijn essentieel voor het waarborgen van de betrouwbaarheid van informatieverwerking en financiële verslaglegging’ (ISACA, 2022).

General IT controls zorgen ervoor dat er zekerheid is dat de systemen, diens data en functionaliteiten niet zonder intentie wijzigen

GITC’s zijn dus een onmisbaar onderdeel van IT-governance. Het zijn applicatie- en procesoverstijgende technische of organisatorische maatregelen. Voorbeeld van een technische maatregel: het toepassen van encryptie voor het veilig delen van alle data met externe partijen. Of het gebruik van een firewall om het IT-netwerk te beveiligen. GITC’s kunnen ook fysieke of organisatorische maatregelen zijn, zoals bijvoorbeeld de toegangscontrole van een datacenter/serverruimte om deze adequaat te beveiligen.

Relevantie GITC’s

General IT controls zijn het fundament voor goed werkende systemen. Zonder beheerde IT-processen zou de werking mogelijk in het geding komen, maar misschien belangrijker nog zou er niet op gegevens of functionaliteit van systemen vertrouwd kunnen worden. General IT controls zorgen ervoor dat er zekerheid is dat de systemen, diens data en functionaliteiten niet zonder intentie wijzigen.

Veel organisaties gebruiken ITIL-processen om het dagelijkse IT-beheer vorm te geven. General IT controls sluiten hier direct op aan. Waar ITIL beschrijft hoe incidenten, wijzigingen, releases en toegang worden georganiseerd, kijkt de internal auditor via GITC’s naar de vraag of die processen ook voldoende beheersing bieden. De taal is soms anders, maar de onderliggende werkelijkheid is dezelfde.

Onderzoek

Recent onderzoek van ECIIA Risk in Focus (2025) wijst uit dat ruim 80% van onderzochte bedrijven cyber- en databeveiliging als een van de Top-5-risico’s noemt. Deze bevinding uit het onderzoek wordt haast dagelijks bevestigd door de media wanneer gemeld wordt dat weer een organisatie gehackt is. Om onder andere deze risico’s te mitigeren zijn met name GITC’s nodig. Het is dan ook niet verwonderlijk dat de recente Europese regelgeving (digital operational resilience act (DORA) en de richtlijn network and information security 2 (NIS2) op het gebied van digitale weerbaarheid, gedetailleerde eisen stelt aan onder andere de GITC’s. Ook de definitie van ISACA geeft het belang van GITC’s helder weer. Ze zijn onmisbaar voor een veilige en betrouwbare IT-huishouding

De GITC’s dragen bij aan het:

• mitigeren van cyber risk – dat wil zeggen het verkleinen van de kans op datalekken en ongeautoriseerde toegang tot het IT-netwerk en vertrouwelijke data;
• naleven van relevante wet- en regelgeving (bijvoorbeeld de AVG);
• versterken van de algehele beheersing;
• verhogen van betrouwbaarheid informatiesystemen.

Tabel 1 geeft een overzicht van de GITC’s die daarna worden toegelicht.Tabel 1. Overzicht van GITC’s – Bronnen (vrij naar): ACCA – IT General Controls; IT Governance Institute – IT Control Objectives for Sarbanes-Oxley; PCAOB – Auditing Standard 2201)

Logische toegangsbeveiliging (LTB)/IAM
Logische toegangsbeveiliging (LTB) is een GITC waar elke organisatie, ongeacht de omvang en sector, mee te maken heeft. LTB wordt ook wel identity & access management (IAM) genoemd en draait om de vraag wie in de organisatie, en in de keten van leveranciers en SaaS‑diensten, op welk moment toegang heeft tot welke informatie en functionaliteit. In een volwassen inrichting sluiten authenticatie single sign on (SSO) of multi factor authenticatie (MFA) en autorisatie door middel van role based access (RBAC) of account based access (ABAC) aan op het verloop van (externe) medewerkers. Het hr‑systeem fungeert als bron voor identiteiten; nieuwe medewerkers, functiewisselingen en uitdiensttreding leiden automatisch tot het toekennen, aanpassen of intrekken van toegangsrechten. Voor high‑privilege handelingen worden tijdelijke ‘just‑in‑verstrekt, met vastlegging van sessies en expliciete goedkeuring vooraf. Ook service‑ en technische accounts dienen een eigenaar, een doel en een beperkte geldigheidsduur te hebben.

Goede inrichting
Een goede inrichting van logische toegangsbeveiliging (LTB) laat zich vooral kenmerken door het consistent en aantoonbaar uitvoeren van beheersingsmaatregelen. MFA wordt breed afgedwongen en toegangsrechten op kritieke systemen worden periodiek en risicogebaseerd beoordeeld. Uitzonderingen dienen schaars te zijn en horen gedocumenteerd te worden.

Deze GITC is altijd van toepassing, ongeacht of een organisatie uitsluitend SaaS-oplossingen en/of maatwerksoftware gebruikt. Alleen in dat geval vinden deze processen plaats door en bij de softwareleverancier. Daarom is het belangrijk om in dergelijke gevallen de assurancerapportage (SOC1/2) kritisch te beoordelen.

Fysieke (toegang) beveiliging
Fysieke beveiliging schermt de infrastructuur af tegen ingrepen die de getroffen technische beheersingsmaatregelen kunnen omzeilen. Toegang tot datacenters en serverruimten dient beperkt te zijn tot het strikt noodzakelijke en herleidbaar tot specifieke personen. (tijdelijke) toegang dient een specifiek doel te dienen en dient gedocumenteerd te worden, zodat achteraf te reconstrueren is wie toegang tot kritieke ruimten heeft gehad. Cameratoezicht en bezoekersregistratie sluiten de cirkel.

Onder fysieke beveiliging valt ook het beheer van sleutels en pasjes, veilige opslag en vernietiging van gegevensdragers, en geborgd transport van hardware. Waar infrastructuur bij cloudleveranciers staat, wordt fysieke beveiliging door de leverancier uitgevoerd en via assurancerapportages onderbouwd. Lokale apparatuur zoals netwerkapparatuur en bijvoorbeeld laptops blijven onder de eigen fysieke controle.

 Asset‑ en configuratiebeheer
Asset‑ en configuratiebeheer maakt zichtbaar wat de IT‑omgeving precies omvat en hoe die omgeving er in de gewenste, geautoriseerde toestand uitziet. Een actuele inventaris (CMDB) en vastgelegde configuratiebaselines vormen het referentiekader voor wijzigingen, patches en monitoring. Door geautomatiseerde ontdekking te koppelen aan de CMDB, periodiek te ‘reconciliëren’ en eigenaarschap op systeem‑ en configuratieniveau te beleggen, ontstaat aantoonbare volledigheid.

Controletechnische functiescheiding is cruciaal: wie ontwikkelt of test, mag niet dezelfde zijn die de productie-uitrol doet

Wijzigingsbeheer
Dit proces wordt ook wel change management genoemd en heeft als doel ervoor te zorgen dat functionele en technische aanpassingen aan systemen beheerst, voorspelbaar en herleidbaar verlopen. Dit proces begint met een formele aanvraag om een functionele of technische wijziging, met risicoclassificatie. Dat wordt gevolgd door passende tests en een onafhankelijke beoordeling van de testresultaten. Het eindigt met een beheerste implementatie. Controletechnische functiescheiding is cruciaal: wie ontwikkelt of test, mag niet dezelfde zijn die de productie-uitrol doet. Voor noodwijzigingen moet een proces zijn ingericht om snel te kunnen handelen. In dergelijke gevallen dient altijd een achterafbeoordeling plaats te vinden; tevens dient er een volledig dossier met noodzakelijke vastleggingen aanwezig te zijn.

Ideale situatie
In een ideale situatie is er sprake van één bronregistratie (bijvoorbeeld in een applicatie als ServiceNow of Jira) waarin de hele keten zichtbaar is: van aanvraag tot inproductiename en releasetag. Elk dossier bevat testbewijs, goedkeuringen en de genomen besluiten. De risicoclassificatie bepaalt de diepgang van testen en autorisatie. Traceerbaarheid is leidend: tickets, testresultaten en goedkeuringen dienen aantoonbaar te corresponderen met de logging van wijzigingen in de productieomgeving en release-/deploymomenten. De scheiding tussen ontwikkel-, test- en productieomgevingen dient zichtbaar gehandhaafd te worden. Deze GITC is altijd van toepassing, ook in geval dat een organisatie uitsluitend SaaS-oplossingen gebruikt.

Ontwikkel- en releasebeheer
Dit proces wordt ook wel system development life cycle (SDLC) genoemd. Het betreft in feite twee opeenvolgende processen. De software wordt eerste ontwikkeld (of gewijzigd), getest en daarna naar productieomgeving gebracht (releasebeheer). Waar maatwerkontwikkeling of intensieve configuratie een rol speelt, verschuift de aandacht naar de integriteit van de softwarelevenscyclus. Ontwikkel- en releasebeheer zorgen ervoor dat code en configuratie via gecontroleerde, reproduceerbare pipelines naar productie gaan. Versiebeheer met een heldere branche-ingstrategie, geautomatiseerde quality gates (zoals geautomatiseerde tests) en gescheiden test- en productieomgevingen voorkomen dat software ongecontroleerd kan worden gewijzigd. De norm is dat software uitsluitend via de pijplijn naar productieomgeving gaat. Afwijken van de pijplijn (handmatige ingrepen) in dit proces zijn uit den boze.

Kenmerken
Een volwassen ontwikkel- en releasebeheer kenmerkt zich door onveranderbare pipelinelogs en ondertekende documentatie, zodat altijd vast te stellen is wie welke wijziging wanneer heeft doorgevoerd. De releases dienen in een herkenbare cadans gepland te worden. Om voorspelbaarheid te vergroten is het gebruikelijk om rondom drukke perioden in de business en ‘changefreeze’ te hanteren.

Deze processen en de bijbehorende controls zijn altijd van toepassing; ook in geval dat een organisatie uitsluitend SaaS-oplossingen gebruikt. Alleen vinden deze processen in dat geval plaats door en bij de softwareleverancier. Daarom is het belangrijk om in dergelijke gevallen de assurancerapportage (SOC1/2) kritisch te beoordelen.

Operationeel beheer
Operationeel beheer richt zich op de dagelijkse, betrouwbare verwerking van batchjobs en interfaces, het tijdig signaleren en afhandelen van storingen en het borgen van herstelbaarheid. Effectieve monitoring koppelt betekenisvolle drempelwaarden aan automatische alerts en kent duidelijke escalaties. Incident- en problemmanagement zorgen voor structurele verbetering, terwijl runbooks en on-callafspraken de responstijd en consistentie verhogen. Back-up en recovery gaan verder dan ‘een back-up maken’: hersteltesten tonen periodiek aan dat data volledig en integer kan worden teruggezet binnen de afgesproken return point objective (RPO) of return time objective (RTO). Dit is het maximaal geaccepteerde, dus hangt het samen met risicobereidheid, dataverlies bij een verstoring.

Verstoringen
Een goed functionerend operationeel beheer laat zien dat verstoringen niet alleen worden gemeld, maar ook worden geanalyseerd en tijdig opgevolgd. De interfaces inclusief reconciliatiecontroles, werken naar behoren. Capaciteits- en continuïteitsbeheer zorgen dat piekbelasting en het (jaarlijks) testen van de uitwijk realistisch zijn. In geval dat een organisatie uitsluitend SaaS-oplossingen gebruikt, vindt dit proces plaats bij de softwareleverancier. Daarom is het belangrijk om in dergelijke gevallen de assurancerapportage (SOC1/2) van softwareleverancier kritisch te beoordelen.

Continuïteitsbeheer
Continuïteitsbeheer richt zich op het waarborgen dat essentiële IT‑diensten na een storing snel kunnen worden hersteld. Dit omvat het maken van betrouwbare (offline) back‑ups, het testen van herstelprocedures en het plannen van servicecontinuïteit bij incidenten. Zo blijft de organisatie in staat haar meest kritieke processen te continueren.

 Kwetsbaarheden‑ en patchbeheer
Kwetsbaarhedenbeheer raakt alle in gebruik zijnde hard- en software. Het betreft technische en organisatorische maatregelen om bekende kwetsbaarheden tijdig te detecteren en te verhelpen. Baselineconfiguraties en hardening vormen de ondergrond; periodieke scanning bestrijkt servers, end-points, containers, netwerkapparatuur en cloudresources. Hardening is het doelgericht verkleinen van de aanvalskans op een IT-systeem door overbodige functionaliteit uit te schakelen en instellingen zo veilig mogelijk te configureren. Patchbeheer betreft de updates voor de infratructuur, zoals het operating system Windows. Het volgt risicogebaseerde termijnen, waarbij uitzonderingen tijdelijk en gemotiveerd zijn. Door patching te verankeren in het changeproces blijven testen, uitrol en rollback beheerst. Een volwassen aanpak werkt met trendinformatie: doorlooptijden voor critical‑ en high issues, achterstanden per platform en zicht op ‘blind spots’. Het management stuurt op reductie van exposure in plaats van alleen op aantallen tickets.

Breekt één schakel, dan verschuiven de overige schakels van zekerheid naar aannamen

Samenhang en afhankelijkheden

GITC’s vormen een samenhangend geheel en zijn sterk van elkaar afhankelijk. Wie een ‘minimale’ set aan GITC’s wil bepalen, moet daarom redeneren vanuit noodzakelijke voorwaarden: welke maatregel is onmisbaar zodat de volgende schakel in de keten betrouwbaar kan functioneren? In dit artikel hanteren we deze keten ook als minimale set GITC-domeinen waar een internal auditor in ieder geval iets van moet vinden. Hierna lichten we de belangrijkste afhankelijkheden kort toe.

Logische toegangsbeveiliging – Aan de basis van dit systeem staat logische toegangsbeveiliging (LTB), die de juistheid van toegangsrechten waarborgt. Zonder een sluitende koppeling tussen een bewezen identiteit en juist toegekende autorisaties verliest het principe van functiescheiding zijn betekenis en wordt elke actie in een applicatie in feite anoniem. LTB is daarmee een fundamentele voorwaarde voor een beheerste IT-omgeving.

Asset- en configuratiebeheer – Direct hierop volgt asset- en configuratiebeheer, dat de context en de scope definieert. Dit domein legt de geautoriseerde ‘werkelijkheid’ van het IT-landschap vast: welke systemen zijn er, waar bevinden ze zich en wat is hun normconfiguratie? Zonder dit gevalideerde referentiekader opereren andere processen in het ongewisse, wijzigingen en patches worden stuurloos en hun volledigheid is niet goed te verifiëren.

Ontwikkel- en releasebeheer – Deze vormen samen de gecontroleerde route voor aanpassingen naar de productieomgeving. Wijzigingsbeheer fungeert als inhoudelijke poortwachter die de wenselijkheid, het risico en de kwaliteit van een verandering beoordeelt. Releasebeheer borgt vervolgens de procedurele integriteit en zorgt ervoor dat exact de goedgekeurde componenten op een beheerste wijze worden geïmplementeerd.

De voorspelbaarheid die releasebeheer creëert, is een directe voorwaarde voor een stabiel operationeel beheer. Een belangrijk onderdeel hiervan is back-up en recovery, cruciaal voor elke organisatie. De aanwezigheid van een back-up alleen is onvoldoende. De echte beheersing zit in het vermogen om daadwerkelijk te kunnen herstellen. Dat betekent data zó terugzetten dat de bedrijfsprocessen weer tijdig hervat kunnen worden. Daarom zijn periodieke hersteltesten onmisbaar. Zonder test is continuïteit van de bedrijfsvoering geen zekerheid maar een aanname.

Kwetsbaarheden- en patchbeheer – Dit is de veiligheidsklep van de hele keten. Het verlaagt het aanvalsoppervlak alleen wanneer duidelijk is wat in scope is (via een actuele inventaris en baselines) en wanneer fixes via dezelfde gecontroleerde route naar productie gaan als iedere andere wijziging. Zonder aansluiting op asset- en configuratiebeheer blijft de dekking giswerk. En zonder koppeling aan wijzigings- en releasebeheer verzandt het in signaleren zonder structurele risicoreductie. Met die koppelingen wél op orde wordt detectie daadwerkelijk mitigatie.

Fysieke toegangsbeveiliging – Onder al deze processen ligt fysieke toegangsbeveiliging als basis. Fysieke beveiliging voorkomt dat iemand met fysieke toegang logische maatregelen omzeilt of bewijs manipuleert. Zonder fysieke beveiliging kan niet worden vertrouwd op de logische maatregelen en verliest de hele keten aan geloofwaardigheid.

Tot slot

Dit alles laat zien dat betrouwbaarheid geen optelsom is van losse GITC’s, maar een samenhangend ‘systeem’ met meerder onderdelen. De werking van de maatregel steunt op de werking van de vorige en voedt de volgende: identiteit geeft herleidbaarheid, inventaris geeft scope, gecontroleerde uitrol geeft voorspelbaarheid, operationeel beheer geeft aantoonbare continuïteit, kwetsbaarhedenbeheer geeft risicoreductie en fysieke beveiliging verankert het geheel. Breekt één schakel, dan verschuiven de overige schakels van zekerheid naar aannamen. Daarom werkt het alleen als de schakels elkaar consequent versterken. De in dit artikel geschetste GITC’s zijn samen te vatten als de belangrijkste beheersingsdomeinen voor overzicht en inzicht in de inrichting van IT-omgeving.