1 november 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Security audit vs pentest: twee verschillende vragen, twee soorten bewijs, en hoe zij samen in één jaarcyclus passen
Een audit vraagt of uw maatregelen bestaan en werken zoals ontworpen. Een penetratietest vraagt of een aanvaller er toch doorheen komt. Organisaties die de twee verwarren, eindigen met een certificaat en een datalek, of met een stapel bevindingen en geen manier om een toezichthouder te laten zien wat zij ermee hebben gedaan.
Het korte antwoord
Een security audit (beveiligingsaudit) is een formeel, criteriumgericht onderzoek naar de vraag of de beveiligingsmaatregelen van een organisatie bestaan, goed zijn ontworpen en doeltreffend werken, gemeten langs een norm zoals ISO/IEC 27001, de Trust Services Criteria van de AICPA achter SOC 2, PCI DSS, of een wettelijk regime zoals NIS2 of DORA. Zij wordt uitgevoerd door een auditor, werkt grotendeels op basis van documentatie, interviews, steekproeven van configuraties en bewijs van werking, en levert een oordeel, een certificaat of een lijst afwijkingen op. Een penetratietest is een in tijd begrensde, geautoriseerde aanval op een afgebakende scope door gekwalificeerde testers, die kwetsbaarheden proberen te vinden en te misbruiken zoals een echte aanvaller dat zou doen. Zij levert een rapport op van wat is gevonden, hoe het is misbruikt, hoe ernstig het in uw context is en hoe u het verhelpt.
De twee overlappen op precies één plek: de audit vraagt om bewijs dat technische kwetsbaarheden worden geïdentificeerd en beheerst, en het pentestrapport is het sterkste bewijs dat u kunt overleggen. Op alle andere punten verschillen zij in vraag, methode, uitvoerder, resultaat en ritme. Deze gids zet beide uiteen, laat zien waar elk kader testbewijs verwacht en geeft een gecombineerde jaarcyclus die auditors tevreden stelt zonder van testen papierwerk te maken.
Wat een security audit is: de vier vormen die u tegenkomt
Het woord 'audit' dekt verschillende exercities. Welke uw gesprekspartner bedoelt, bepaalt wie haar uitvoert en wat zij oplevert.
ISO/IEC 27001-audit
Twee soorten: de interne audit die hoofdstuk 9.2 vereist, uitgevoerd door of voor de organisatie langs het eigen ISMS, en de certificeringsaudit door een geaccrediteerde certificatie-instelling (fase 1-documentatiebeoordeling, fase 2-implementatieaudit, jaarlijkse controle-audits, hercertificering in jaar drie). Het resultaat is een certificaat met scopeverklaring plus afwijkingen en observaties. De maatregelen 8.8 en 8.29 uit bijlage A zijn de plek waar testbewijs wordt beoordeeld.
SOC 2-examination
Een assurance-opdracht door een erkend Amerikaans accountantskantoor (CPA firm) onder de attestatiestandaarden van de AICPA, langs de Trust Services Criteria (Security, plus optioneel Availability, Processing Integrity, Confidentiality en Privacy). Type I beoordeelt het ontwerp op één moment; Type II beoordeelt de werking over een periode, doorgaans zes tot twaalf maanden. Het resultaat is het oordeel van de auditor plus een systeembeschrijving. Pentestbewijs ondersteunt de criteria CC4.1 en CC7.1.
NIS2-toezichtsaudit
Onder NIS2 (Richtlijn (EU) 2022/2555) mogen bevoegde autoriteiten essentiële entiteiten onderwerpen aan regelmatige en gerichte beveiligingsaudits, inspecties ter plaatse en beveiligingsscans (artikel 32), en belangrijke entiteiten aan toezicht achteraf (artikel 33). In Nederland loopt dit via de Cyberbeveiligingswet met sectorale toezichthouders zoals de Rijksinspectie Digitale Infrastructuur. De entiteit moet onder artikel 21(2)(f) beleid en procedures tonen om de doeltreffendheid van haar risicobeheersmaatregelen te beoordelen; regelmatig testen is de manier waarop dat wordt aangetoond.
IT-audit door een Register EDP-auditor of CISA
Een bredere assurance-opdracht op de IT general controls door een gecertificeerde IT-auditor (een RE ingeschreven bij NOREA, of een CISA onder ISACA), vaak als onderdeel van de jaarrekeningcontrole of als ISAE 3402- of 3000-rapport voor serviceorganisaties. Zij dekt toegang, wijzigingen, operations en continuïteit. Het beheer van technische kwetsbaarheden is één van de beheersgebieden, en een actueel pentestrapport is daarvoor het gangbare bewijs.
Wat een penetratietest is
Een penetratietest is een geautoriseerde, afgebakende simulatie van een aanval, uitgevoerd door gekwalificeerde testers op systemen, applicaties, netwerken of mensen, binnen een afgesproken tijdvenster en spelregels. De methode volgt erkende standaarden (PTES, OWASP WSTG en MASTG, NIST SP 800-115): verkenning, kwetsbaarheidsanalyse, exploitatie, post-exploitatie en rapportage. Anders dan een kwetsbaarheidsscan is zij handmatig en vijandig. Testers koppelen zwakheden aan elkaar, misbruiken bedrijfslogica en bewegen lateraal door de omgeving, en daar zitten doorgaans de bevindingen die voor een directie tellen.
Het resultaat is een rapport: een managementsamenvatting, een scope- en methodiekverklaring, bevindingen met ernstscore (CVSS, bijgesteld naar uw context) en reproduceerbaar bewijs, een aanvalsverhaal dat laat zien hoe bevindingen samenkomen, en geprioriteerde herstelmaatregelen. Een hertest bevestigt de oplossingen. De test vertelt u wat een aanvaller vandaag kan. Zij vertelt u niet of uw beleid bestaat, of uw toegangsreviews elk kwartaal draaien of of uw leverancierscontracten de juiste bepalingen bevatten. Dat is het terrein van de auditor.
Security audit vs pentest, naast elkaar
Zeven dimensies waarop de twee instrumenten verschillen. De enige plek waar zij elkaar raken, is de rij bewijs.
| Dimensie | Security audit | Penetratietest |
|---|---|---|
| Beantwoorde vraag | Bestaan de vereiste maatregelen, zijn zij goed ontworpen en hebben zij over de periode gewerkt zoals bedoeld? | Kan een aanvaller binnen deze scope en tijd deze systemen compromitteren, en wat zou de impact zijn? |
| Methode | Documentbeoordeling, interviews, walkthroughs, steekproeven van bewijs, configuratiebeoordeling langs criteria | Handmatig vijandig testen: verkenning, exploitatie, privilege-escalatie, laterale beweging |
| Geproduceerd bewijs | Auditspoor van steekproeven, interviewnotities, resultaten van controletoetsen, bevestigingen van het management | Reproduceerbaar exploitatiebewijs: schermafbeeldingen, request- en responseparen, proof of concept, verkregen toegang |
| Wie voert uit | Interne auditor, geaccrediteerde certificatie-instelling, accountantskantoor, RE of CISA, of de toezichthouder | Gecertificeerde pentesters (OSCP, OSWE, CREST), onafhankelijk van de systeemeigenaren |
| Resultaat | Oordeel, certificaat of assurancerapport; afwijkingen, bevindingen, aanbevelingen | Bevindingenrapport met ernst, aanvalsverhaal en herstelplan; hertestbevestiging |
| Frequentie | Jaarlijkse controle-audit of examinationperiode; interne audit volgens het auditplan; toezichtsaudits volgens planning of ad hoc | Minimaal jaarlijks en na ingrijpende wijzigingen (PCI DSS, DORA, de meeste auditors); per release voor kritieke applicaties |
| Kostenbepalend | Omvang van het ISMS of de systeemgrens, aantal maatregelen en locaties, lengte van de periode, senioriteit van de auditor | Breedte en diepte van de scope (hosts, applicaties, rollen), testtype, senioriteit van de tester, rapportage en hertest |
Hoe pentestbewijs de audit voedt
Auditors voeren geen penetratietesten uit. Zij vragen om bewijs dat u dat doet, en dat u met de resultaten aan de slag gaat. Dit zijn de bepalingen waar het rapport wordt beoordeeld.
ISO/IEC 27001:2022, bijlage A 8.8 en 8.29
Maatregel 8.8 vereist dat informatie over technische kwetsbaarheden wordt verkregen, de blootstelling wordt beoordeeld en passende maatregelen worden genomen; maatregel 8.29 vereist beveiligingstesten in ontwikkeling en acceptatie. Auditors verwachten een actueel pentestrapport voor systemen binnen scope, een vastgelegde risicobeoordeling per bevinding, herstelregistraties en hertestbewijs. De interne audit van hoofdstuk 9.2 hoort dezelfde keten als eerste te toetsen.
SOC 2 Trust Services Criteria CC4.1 en CC7.1
CC4.1 vereist doorlopende en afzonderlijke evaluaties van de vraag of beheersmaatregelen aanwezig zijn en functioneren; CC7.1 vereist procedures om nieuwe kwetsbaarheden te identificeren. De points of focus noemen penetratietesten en kwetsbaarheidsscans expliciet. Voor een Type II-rapport neemt de auditor steekproeven uit de examinationperiode, dus test en herstel moeten binnen dat venster vallen.
PCI DSS v4.0.1 requirement 11.4
De meest voorschrijvende van de vier: interne en externe penetratietesten minimaal elke 12 maanden en na ingrijpende wijzigingen, door een gekwalificeerde interne medewerker of gekwalificeerde externe partij met organisatorische onafhankelijkheid, volgens een in de sector geaccepteerde methodiek, met dekking van de kaarthouderomgeving en de segmentatiemaatregelen (11.4.5), en met correctie en hertest van misbruikbare kwetsbaarheden (11.4.4). De Qualified Security Assessor toetst het rapport per subvereiste voor het Report on Compliance.
DORA artikel 24 tot 27 en artikel 6(6)
Artikel 25 noemt penetratietesten als een van de tests die het weerbaarheidstestprogramma moet omvatten; artikel 24 vereist jaarlijks testen van ICT-systemen achter kritieke of belangrijke functies; artikel 26 en 27 voegen threat-led penetration testing toe voor aangewezen entiteiten. Artikel 6(6) vereist regelmatige interne audit van het ICT-risicobeheerkader. De testrapporten zijn waar interne audit en de toezichthouder (DNB of AFM) om zullen vragen.
AVG artikel 32(1)(d) en NIS2 artikel 21(2)(f)
Beide vereisen een procedure om de doeltreffendheid van beveiligingsmaatregelen regelmatig te testen, te beoordelen en te evalueren, zonder een methode te noemen. Toezichthouders en de Autoriteit Persoonsgegevens aanvaarden penetratietesten als de gangbare manier om dit voor technische maatregelen aan te tonen. De audit toetst of de procedure bestaat, volgens planning draait en opvolging oplevert.
Wanneer u welke nodig heeft
Kies het instrument aan de hand van de vraag die u beantwoord wilt hebben.
- Een klant, toezichthouder of directie vraagt om bewijs dat uw beveiligingsprogramma wordt bestuurd: u heeft een audit nodig (ISO 27001-certificering, een SOC 2-rapport of een ISAE-assurancerapport).
- U wilt weten of een specifieke applicatie, een netwerk of een cloudomgeving vandaag te compromitteren is: u heeft een penetratietest nodig.
- U bereidt zich voor op certificering of een SOC 2-examination: test eerst, zodat het rapport en het herstelbewijs bestaan wanneer de auditor steekproeven uit de periode neemt.
- U lanceert of wijzigt een systeem ingrijpend: een penetratietest vóór livegang. De audit pikt het bij de volgende cyclus op.
- Een toezichthouder kondigt een NIS2- of DORA-inspectie aan: beide. Controleer of uw testbewijs actueel is, en bereid dan de governancedocumentatie voor die de inspecteur als eerste leest.
- U heeft een auditcertificaat en heeft nooit getest: het certificaat bewijst dat het proces bestaat. De test vertelt u of het proces heeft gewerkt.
- U test elk jaar en bent nooit geauditeerd: u kent uw kwetsbaarheden, maar kunt governance niet aan een klant bewijzen. Een ISO 27001- of SOC 2-programma maakt van het testen bewijs.
Een gecombineerde jaarcyclus die beide bedient
De volgorde telt. Test voordat de audit steekproeven uit de periode neemt, herstel voordat de auditor ernaar vraagt en houd de twee kalenders op één pagina.
Kwartaal 1: scope en planning
Stem de ISMS- of systeemgrens af met de auditeigenaar, koppel elk systeem binnen scope aan een testtype en frequentie (de verwachting achter DORA artikel 24 en ISO 27001-maatregel 8.8) en plan de tests zo dat de rapporten minimaal acht weken vóór het auditveldwerk binnen zijn.
Kwartaal 2: penetratietesten
Externe en interne infrastructuurtests, applicatietests voor systemen binnen de auditgrens, cloudconfiguratiereview waar relevant. Bevindingen gaan het risicoregister in met eigenaren en deadlines, het document waar de auditor vanuit terugredeneert.
Kwartaal 3: herstel en hertest
Verhelpen, daarna bevindingen vanaf ernst medium hertesten. De hertestbrief is wat PCI DSS 11.4.4 afsluit en wat ISO 27001- en SOC 2-auditors als steekproef nemen als bewijs dat de maatregel werkt, en niet alleen bestaat.
Kwartaal 4: interne audit, daarna externe audit of examination
Voer de interne audit van hoofdstuk 9.2 uit op de keten van test naar herstel naar hertest, corrigeer procesgaten en leg daarna de volledige keten voor aan de certificatie-instelling, het accountantskantoor of de toezichthouder.
Doorlopend: wijzigingsgedreven testen en scannen
Maandelijkse of continue kwetsbaarheidsscans en penetratietesten gekoppeld aan ingrijpende wijzigingen houden het bewijs ononderbroken tussen de cycli. Leg vast wat als ingrijpend geldt; de auditor zal ernaar vragen.
Veelvoorkomende misverstanden
'Wij zijn ISO 27001-gecertificeerd, dus wij zijn veilig.' Het certificaat bewijst dat een managementsysteem bestaat en op steekproefbasis is geauditeerd. Certificatie-instellingen exploiteren uw systemen niet. Organisaties met een geldig certificaat worden geregeld gehackt via kwetsbaarheden die een middag testen aan het licht had gebracht. 'Wij hebben een pentest gehad, dus wij komen door de audit.' Een testrapport dekt één scope op één moment; de auditor heeft ook het beleid, de risicobeoordeling, de herstelregistraties en de hertest nodig. 'Een kwetsbaarheidsscan is een pentest.' Dat is hij niet, en PCI DSS v4.0.1 scheidt de twee om die reden in requirement 11.3 en 11.4.
'De auditor doet de pentest wel.' Auditors bewaken hun onafhankelijkheid zorgvuldig. De instelling die u certificeert, hoort niet ook de partij te zijn wier testresultaten zij certificeert, en onder de onafhankelijkheidsregels van de AICPA mag een accountantskantoor geen assurance geven over eigen werk. 'Eén keer per jaar is genoeg.' Eén keer per jaar is de ondergrens die de kaders stellen. Systemen die wekelijks veranderen, vragen om testen gekoppeld aan releases, en de audit zal vragen hoe u tot de conclusie kwam dat jaarlijks volstond.
Waar HackersHub past
HackersHub voert de pentestkant uit en schrijft het rapport zo dat het in de audit past: een scope- en methodiekverklaring, bevindingen gekoppeld aan de maatregel die zij aantonen (ISO 27001 A.8.8, SOC 2 CC7.1, PCI DSS 11.4, DORA artikel 25), reproduceerbaar bewijs, en een verificatiehertest van bevindingen vanaf ernst medium binnen 90 dagen, zodat de herstelketen compleet is wanneer de auditor er een steekproef uit neemt. Onze security-consultingpraktijk stemt de testkalender af op uw certificerings- of examinationcyclus en bereidt het governancebewijs voor dat een auditor of toezichthouder als eerste leest.
Wij geven geen ISO 27001-certificaten of SOC 2-oordelen af. Die horen bij een geaccrediteerde certificatie-instelling of een accountantskantoor, en juist het gescheiden houden van die rollen maakt het bewijs geloofwaardig. Elke pentester van HackersHub heeft minimaal de OSCP, met OSWE- en CREST-gecertificeerde testers in het team, en Michael van Mameren, Lead Penetration Tester (OSCP), tekent elk rapport af.
Veelgestelde vragen
Gerelateerde gidsen
- Security consulting en compliance-advies
- Penetratietest laten uitvoeren door HackersHub
- Wat is een penetratietest? Definitie, fasen en werkwijze
- ISO 27001 pentest: wat de auditor verwacht
- SOC 2 pentest: bewijs voor CC4.1 en CC7.1
- PCI DSS pentest: requirement 11.4 uitgelegd
- Is een pentest verplicht?
- Pentest keurmerk en certificeringen
Uw testkalender afstemmen op uw audit?
Wij testen naar de maatregel, rapporteren naar de verwachtingen van de auditor en hertesten binnen 90 dagen, zodat de bewijsketen compleet is wanneer er een steekproef uit wordt genomen. Praat met een expert.