Wanneer mensen het woord "audit" horen, denken ze meestal aan accountants, spreadsheets en het belastingseizoen. In software is auditeren een totaal andere discipline. Het gaat minder om het sluiten van grootboeken en meer om het stellen van kritische vragen over je code, je data en je controles. Een systeemaudit evalueert of je informatie-activa veilig zijn, of je data accuraat blijft en of je middelen daadwerkelijk werken zoals je denkt dat ze werken.

Een functioneel systeem is niet hetzelfde als een betrouwbaar systeem. Een platform voor academische gegevens kan studenten correct inschrijven en nette cijferlijsten genereren, terwijl het stilletjes wachtwoorden in platte tekst opslaat. Een logistiek dashboard kan perfecte levertijden tonen terwijl het zijn database-inloggegevens blootstelt in publiekelijk leesbare broncode. Systeemauditing bestaat om dat gat te dichten.

Wat een systeemaudit feitelijk omvat

In de kern kijkt een systeemaudit naar drie zaken: vertrouwelijkheid, integriteit en efficiëntie. Vertrouwelijkheid betekent dat je studentendossiers, transactielogs of patiëntendossiers alleen toegankelijk zijn voor de juiste mensen. Integriteit betekent dat de data zichzelf niet stilletjes corrumpeert, de herkomst niet verliest of in de loop van de tijd afwijkt van de werkelijkheid. Efficiëntie betekent dat je servers, services en processen waarde leveren in plaats van alleen maar middelen te verbruiken terwijl niemand kijkt.

Deze drie kwaliteiten moeten verifieerbaar zijn. Vertrouwen op je database omdat deze nog niet is gecrasht, is geen verificatie. Een echte audit levert bewijs dat je kunt aanwijzen wanneer een toezichthouder, een klant of je toekomstige zelf vraagt hoe je weet dat het systeem deugt.

De belangrijkste soorten systeemaudits

Niet elke audit kijkt naar hetzelfde. Afhankelijk van de risico's waar je mee te maken krijgt, heb je mogelijk een of meer van de volgende soorten nodig:

Application Audit. Dit kijkt of de softwarelogica correct is. Zijn berekeningen nauwkeurig? Verwerken state machines edge cases correct? Wordt autorisatie afgedwongen binnen elke functie die gevoelige gegevens aanraakt? Een klassieke fout op applicatieniveau is een cijfermodule die decimalen onjuist afrondt, of een controle op beursgerechtigdheid die omzeild kan worden door een waarde in een dropdown-menu aan te passen.

Security Audit. Deze richt zich op toegangscontroles, encryptie en kwetsbaarheden. Het stelt de vraag wie welke gegevens kan lezen, of data versleuteld is tijdens transport (in transit) en in rust (at rest), en of je sessiebeheer bestand is tegen manipulatie. Het controleert ook of je dependencies bekende kwetsbaarheden bevatten die je stilletjes blootstellen aan exploitatie.

Database Audit. Hier draait alles om dataintegriteit. Worden referentiële beperkingen afgedwongen? Zijn back-ups daadwerkelijk herstelbaar, of heb je ze alleen ingepland? Voldoen bewaartermijnen aan de wettelijke vereisten? Een databaseaudit onderzoekt ook herstelplannen, want een back-up waar je nooit een oefening mee hebt gedaan, is slechts een theorie.

Network Audit. Deze inspecteert servers, firewalls, routing en beschikbaarheid. Het bevestigt dat alleen de noodzakelijke poorten openstaan, dat firewall-regels zijn gedocumenteerd en dat je infrastructuur verkeerspieken of denial-of-service-aanvallen kan opvangen. Het controleert ook of besturingssystemen zijn gepatcht, en niet alleen de applicatielaag.

Compliance Audit. Deze toetst het systeem aan externe regels. Platforms voor studenten moeten mogelijk voldoen aan FERPA. Gezondheidssystemen moeten voldoen aan HIPAA. Betalingsverwerking vereist PCI-DSS-conformiteit. Compliance gaat niet alleen over veilig zijn; het gaat erom dat je die veiligheid kunt aantonen aan een externe autoriteit.

Operational Audit. Code is slechts de helft van het verhaal. Deze audit onderzoekt onderhoudsprocessen, support-workflows, change management en de actualiteit van de documentatie. Een briljante applicatie wordt een risico wanneer de enige persoon die de deployment pipeline begrijpt, de organisatie verlaat.

Een praktijkvoorbeeld: het auditeren van EduManage v1.0

Ik heb onlangs een interne security- en applicatieaudit uitgevoerd op EduManage v1.0, een platform voor academisch beheer. Het systeem beheerde inschrijvingen, dossiers en cijfers. Voordat het echte studentgegevens aanraakte, moesten we weten of het vertrouwd kon worden. Ik volgde een eenvoudig proces van zes stappen, en ik raad dezezelfde structuur aan voor de meeste interne audits.

Bepaal de scope. Audits zonder grenzen veranderen in eindeloze slepende processen. We hebben precies gedefinieerd welke modules binnen de scope vielen: authenticatie, recordbeheer en kernworkflows voor inschrijving. Integraties van derden en fysieke infrastructuur vielen expliciet buiten de scope. We hebben twee weken toegewezen en de belangrijkste personen geïdentificeerd die vragen konden beantwoorden. Deze helderheid voorkomt scope creep en zorgt ervoor dat iedereen op één lijn blijft.

Verzamel informatie en documentatie. Ik heb architectuurdiagrammen, API-documentatie, databaseschema's en eerdere incidentrapporten verzameld. Ik heb met de lead developer gesproken over deployment-praktijken en keuzes in de tech stack. Je kunt niet testen wat je niet begrijpt, en aannames die in deze fase worden gedaan, zullen elke daaropvolgende bevinding vergiftigen.

Voer tests uit. We benaderden het systeem vanuit drie invalshoeken. Een code review zocht naar anti-patterns, injection-kwetsbaarheden en onveilige dependencies. Functionele tests verifieerden of bedrijfsregels — zoals inschrijvingslimieten en controle op vereisten — daadwerkelijk ongeldige statussen blokkeerden in plaats van ze alleen te verbergen achter frontend-code. Penetratietests simuleerden een externe aanvaller door blootgestelde endpoints te onderzoeken en verzoeken te manipuleren om te zien wat er lekte of kapotging.

Analyseer risico's en bevindingen. Rauwe kwetsbaarheden zijn niet allemaal even belangrijk. We hebben elke bevinding in kaart gebracht op basis van waarschijnlijkheid en