31 oktober 2026 · 12 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Een pentest voorbereiden: de checklist voor scope en gereedheid in de weken voordat het testen begint
U heeft een testbedrijf gekozen en de offerte getekend. Wat er in de volgende twee tot vier weken gebeurt, bepaalt of de testers hun dagen besteden aan het vinden van kwetsbaarheden of aan het wachten op accounts, firewall-uitzonderingen en akkoorden. Deze gids behandelt alles wat uw organisatie moet bepalen, voorbereiden en communiceren vóór dag één. Hij begint waar de leverancierskeuze eindigt; vergelijkt u nog offertes, lees dan eerst onze pentest offerte checklist.
Waarom voorbereiding de waarde van de test bepaalt
Een penetratietest koopt u in consultantdagen. Elk uur dat de tester besteedt aan het najagen van een VPN-account, aan de vraag welke IP-reeksen nu eigenlijk in scope zijn, of aan wachten tot het WAF-team een uitzondering toevoegt, is een uur dat niet wordt besteed aan de systemen waarvoor u betaalt. In meer dan tien jaar aan opdrachten hebben wij geleerd dat het grootste verschil tussen een test die het kritieke pad vindt en een test die een mager rapport oplevert, niet de vaardigheid van de tester is. Het is of de opdrachtgever scope, toegang en toestemming klaar had toen het testvenster openging.
Voorbereiding beschermt u ook. Een test zonder ondertekende toestemmingsverklaring, zonder afgebakende scope en zonder noodcontact is een test die een productiesysteem kan platleggen zonder dat iemand weet wie te bellen, of een host van een derde partij kan aftasten die u helemaal niet mocht meenemen. De checklist hieronder volgt de volgorde waarin een volwassen securityteam werkt: bepaal wat en waarom, bepaal hoe, regel toegang, regel bescherming, regel mensen, en houd dan de kickoff.
Dit artikel gaat ervan uit dat de commerciële beslissing is genomen. Het kiezen tussen bedrijven, het vergelijken van methodieken en het lezen van offertes behandelen wij in onze pentest offerte checklist en in onze gids over het kiezen van een pentestbedrijf. Hier gaat het om wat u de opdracht verschuldigd bent zodra het contract is getekend.
Stap één: doelstelling, scope en testposities bepalen
Scope is een geschreven lijst, geen gesprek. De tester moet hem kunnen lezen en voor elk adres en elke applicatie weten of die binnen of buiten de scope valt.
1. Schrijf de doelstelling op in één zin
Compliancebewijs voor ISO 27001 A.8.8 of PCI DSS Req. 11.4, zekerheid vóór een productlancering, validatie na een migratie, of een specifieke vraag zoals 'kan een aanvaller vanaf internet klantgegevens bereiken'. De doelstelling bepaalt welke testposities tellen en hoe de tester zijn tijd prioriteert. Een test zonder uitgesproken doelstelling vervalt tot breedte, en dat is zelden wat de opdrachtgever wilde.
2. Benoem de systemen expliciet
Externe IP-reeksen en hostnames, interne subnetten, webapplicaties met hun URL's per omgeving, API's met hun specificaties, mobiele builds, cloudaccounts en subscriptions met account-ID's, en de identity provider. Neem ook de zaken op waarover u twijfelt en markeer ze als vraag. De gevaarlijkste scope is de scope die 'onze webapplicatie' zegt en de tester laat raden welke van de veertien subdomeinen daarmee wordt bedoeld.
3. Benoem de uitsluitingen en de redenen
SaaS van derden die u niet bezit, systemen onder een wijzigingsstop, gedeelde hosting waar een test andere huurders raakt, legacy-apparatuur die een poortscan niet verdraagt. Uitsluitingen zijn legitiem, maar ze moeten worden opgeschreven zodat het rapport kan vermelden wat niet is getest en waarom. Auditors lezen de uitsluitingslijst even nauwkeurig als de bevindingen.
4. Bepaal de testposities
Extern zonder authenticatie (internetaanvaller), extern met authenticatie (een klant of partner), intern zonder authenticatie (een apparaat in het kantoornetwerk), intern met authenticatie (een gewone medewerker, de assumed-breach-positie) en bevoorrecht (een ontwikkelaar of beheerder, voor white-box-diepgang). Elke positie beantwoordt een andere vraag; een scope met één positie beantwoordt één vraag.
5. Leg de spelregels vast
Testuren (alleen kantooruren of 24 uur), of denial-of-service-technieken zijn uitgesloten (bijna altijd), of social engineering binnen of buiten de scope valt, of de tester van het ene in-scope-systeem naar het andere mag doorstappen, wat er gebeurt als de tester een pad vindt naar een systeem buiten de scope, en hoe ver exploitatie gaat zodra een kwetsbaarheid is bevestigd. Deze regels staan in de opdrachtomschrijving en worden bij de kickoff herhaald.
Black box, grey box of white box: wat u voor elk moet voorbereiden
Het kennisniveau dat u de tester geeft, bepaalt wat u moet aanleveren. Grey box is de standaard voor de meeste eerste en jaarlijkse tests omdat het de meeste bevindingen per dag oplevert; black box is voor een specifieke vraag over een aanvaller zonder hulp; white box is voor diepgang op een kritieke applicatie.
| Aspect | Black box | Grey box | White box |
|---|---|---|---|
| Waarmee de tester begint | Bedrijfsnaam, doelenlijst, verder niets | Doelenlijst, architectuuroverzicht, testaccounts per rol, API-documentatie | Alles uit grey box plus broncode, configuratie, infrastructure-as-code, ontwerpdocumenten |
| Wat u moet voorbereiden | Toestemmingsverklaring, scopelijst, contactpersonen | Accounts en rollen, documentatie, toegang tot de omgeving, whitelisting | Toegang tot repositories, bouwinstructies, leestoegang tot cloudconsoles, contact met een ontwikkelaar |
| Tijd besteed aan verkenning | Hoog (een tot drie dagen van een gangbare opdracht) | Laag | Minimaal |
| Meest geschikt voor | Valideren wat een buitenstaander ziet; red-team-achtige vragen | Jaarlijkse tests, compliancebewijs, de meeste web- en interne tests | Kritieke applicaties, security review vóór release, logicafouten, cryptografie |
| Typisch risico | Oppervlakkige dekking van geauthenticeerde functionaliteit | Vertraging in accountuitgifte vreet het venster op | Toegangsaanvragen via security review duren weken; begin vroeg |
Stap twee: toegang, omgeving en bescherming regelen
Deze zes punten zijn verantwoordelijk voor de meeste verloren testdagen. Elk heeft in uw organisatie een eigenaar die meestal niet degene is die de test heeft ingekocht.
Testaccounts en rollen
Twee accounts per rol, zodat de tester horizontale privilegescheiding kan controleren (gebruiker A leest gegevens van gebruiker B), plus één account per bevoegdheidsniveau (gebruiker, manager, beheerder). Accounts moeten zijn aangemaakt, als werkend zijn geverifieerd en MFA hebben ingeschreven of een afgesproken MFA-omleiding voor de testidentiteit. Vul ze met realistische maar synthetische gegevens.
Testomgeving versus productie
De discussie hierover in de sector is reëel. Testen op productie geeft het meest waarheidsgetrouwe beeld van configuratie en blootstelling; testen op acceptatie beschermt beschikbaarheid en klantgegevens. Het eerlijke antwoord is dat een acceptatieomgeving alleen een geldige vervanger is als zij een getrouwe kopie is: dezelfde codeversie, dezelfde configuratie, dezelfde koppelingen, dezelfde authenticatie. Is dat niet zo, test dan productie met afgesproken uren, snelheidslimieten en een uitsluitingslijst. Besluit, documenteer, en vertel de tester welke het is.
WAF, IDS en snelheidslimieten
Bepaal of de bronadressen van de tester door de web application firewall en intrusion prevention worden gewhitelist, of dat die maatregelen in het pad blijven. Whitelisten test de applicatie; de maatregelen laten staan test de maatregelen. De meeste programma's whitelisten voor de applicatietest en voeren een korte aparte oefening tegen de WAF uit. Informeer in beide gevallen het SOC, zodat het verkeer van de tester niet als incident wordt geëscaleerd, tenzij detectie expliciet onderdeel van de test is.
Netwerktoegang voor interne tests
Een VPN-account met dezelfde netwerkpositie als een gewone medewerker, een fysiek apparaat dat naar kantoor wordt gestuurd en op een gebruikerspoort wordt aangesloten, of een jump host in het doelsegment. Elk moet vóór dag één worden aangevraagd, goedgekeurd en getest. Bevestig welke VLAN's de testpositie ziet en of 802.1X-netwerktoegangscontrole in scope is of voor het testapparaat wordt omzeild.
Wijzigingsstop op de geteste systemen
Een deployment midden in het testvenster maakt bevindingen ongeldig, creëert valse negatieven en verspilt hertestinspanning. Spreek een stop af op de in-scope-systemen voor de duur van de test, of als dat onmogelijk is, een meldprotocol zodat de tester weet wat wanneer is veranderd. Leg de geteste versie of build-identificatie vast in het rapport.
Gegevensverwerking en vertrouwelijkheid
Bevestig dat de geheimhoudingsovereenkomst is getekend en de individuele testers van het testbedrijf dekt. Spreek af wat de tester mag doen met aangetroffen gegevens: een steekproef als bewijs vastleggen, nooit volledige records exfiltreren, nooit persoonsgegevens van de testmachine kopiëren. Spreek af hoe het rapport wordt geleverd (versleuteld, aan benoemde ontvangers) en hoe lang het bedrijf bewijs bewaart. Onder artikel 28 AVG treedt het testbedrijf op als uw verwerker, en daar hoort een verwerkersovereenkomst bij.
Stap drie: juridische toestemming, schriftelijk, voordat iemand verbinding maakt
Onbevoegd binnendringen in een computersysteem is strafbaar in elk rechtsgebied waar een penetratietester werkt. In Nederland is dat computervredebreuk, artikel 138ab Wetboek van Strafrecht; in de Verenigde Staten de Computer Fraud and Abuse Act (18 U.S.C. § 1030); in het Verenigd Koninkrijk de Computer Misuse Act 1990. Het enige dat een penetratietest van een strafbaar feit scheidt, is de toestemming van de eigenaar, en de enige vorm van toestemming die beide partijen beschermt, is een schriftelijke toestemmingsverklaring, ondertekend door iemand die bevoegd is haar te geven.
De toestemmingsverklaring (ook wel vrijwaringsverklaring of permission-to-test-brief genoemd) moet het testbedrijf en de individuele testers bij naam noemen, de exacte scope per adres en hostname opsommen, het testvenster vermelden, de ondertekenaar aan opdrachtgeverszijde en diens functie noemen, en bevestigen dat de opdrachtgever eigenaar is van elk genoemd systeem of het recht heeft om het testen ervan toe te staan. Dat laatste punt vangt een veelvoorkomend probleem af: systemen die bij een derde partij worden gehost. De klantovereenkomst van een cloudprovider staat het testen van uw eigen workloads doorgaans toe, maar het contract van een managed service provider mogelijk niet, en dat van een SaaS-leverancier bijna nooit zonder eigen toestemming. Controleer dit voordat u ze opneemt.
Houd de ondertekende verklaring gedurende de opdracht bij de tester. Voor onderdelen op locatie en fysieke onderdelen hoort zij op papier te worden meegedragen. Raakt een opdracht systemen in meerdere landen, bevestig dan dat de toestemming onder het recht van elk rechtsgebied geldig is en dat gegevens uit de test rechtmatig mogen worden verplaatst naar de plek waar de testers ze analyseren.
Stap vier: mensen, contactpersonen en communicatie
De tester heeft tijdens de opdracht meerdere keren een mens nodig. Bepaal wie, en vertel het hen, voordat het begint.
- Eén opdrachteigenaar aan uw kant die tijdens de test scopebeslissingen kan nemen en tijdens de testuren bereikbaar is
- Een technisch contactpersoon per in-scope-systeem (applicatie-eigenaar, netwerkbeheerder, cloudbeheerder) voor toegangsproblemen en voor de triage van bevindingen
- Een noodcontact met telefoonnummer, 24 uur bereikbaar als 24 uur wordt getest, die het stoppen van de test kan autoriseren en die de tester belt als een systeem instabiel wordt of een kritieke bevinding wordt bevestigd
- Het escalatiepad voor kritieke bevindingen vóór het rapport: de tester moet weten wie binnen het uur hoort van een bevestigde remote code execution, en hoe (telefoon, versleuteld bericht, ticket)
- Een briefing voor het SOC, de managed-detection-and-response-leverancier of de MSSP: data, bron-IP-adressen, testposities, en of detectie wordt beoordeeld of juist moet terugtreden
- Een melding aan de hostingprovider of cloudaccounteigenaar als hun gebruiksvoorwaarden melding van testen vereisen
- Een interne mededeling aan de teams wier systemen in scope zijn, zodat een ontwikkelaar die ongebruikelijke verzoeken in de logs ziet geen incident start, tenzij juist die reactie is wat u wilt meten
- Een beslissing of de servicedesk en HR moeten weten van de test, wat het geval is als social engineering of fysiek testen deel uitmaakt van de scope
Gereed voor dag één: wat er bij de kickoff op tafel moet liggen
De kickoff, doorgaans 45 tot 60 minuten een paar dagen vóór het testen, is waar de tester alles hierboven bevestigt. Kom binnen met deze punten afgerond en de eerste testdag is een testdag.
- Ondertekende opdrachtomschrijving, geheimhoudings- of verwerkersovereenkomst en toestemmingsverklaring, met de namen van de testers ingevuld
- Definitief scopedocument: adressen, hostnames, applicaties per omgeving, cloudaccount-identificaties, uitsluitingen met redenen
- Testaccounts aangemaakt en geverifieerd door eenmaal in te loggen vanuit een schone browser, inloggegevens geleverd via het afgesproken beveiligde kanaal
- VPN- of netwerktoegang van begin tot eind getest, of het testapparaat verzonden en ontvangst bevestigd
- Beslissingen over WAF, IDS en snelheidslimieten doorgevoerd en geverifieerd voor de bronadressen van de tester
- Architectuuroverzicht, API-specificaties (OpenAPI of vergelijkbaar) en voor white box de repository-toegang, alles vooraf gedeeld
- Testvenster, uren en wijzigingsstop bevestigd met de teams die deployments beheren
- Contactlijst met opdrachteigenaar, technische contactpersonen en noodcontact, inclusief nummers buiten kantooruren
- Afgesproken vorm en frequentie van statusupdates tijdens de test (dagelijkse samenvatting, directe melding van kritieke bevindingen) en de leverdatum van het rapport
Wat een pentest vertraagt, en hoe HackersHub dat voorkomt
De terugkerende vertragingen zijn voorspelbaar. Accounts die zijn aangemaakt maar nooit getest, zodat de eerste login strandt op een verplichte wachtwoordreset die niemand kan afronden. MFA op testaccounts met de authenticator op de telefoon van een medewerker die met verlof is. Een VPN die de tester in een gastsegment plaatst zonder route naar de doelen. Een WAF-uitzondering die is aangevraagd maar niet uitgerold. Een scope-e-mail die 'de gebruikelijke productiereeksen' noemt, van een voorganger die is vertrokken. Een deployment op dag twee die de authenticatieflow verandert. Elk hiervan kost een halve tot twee dagen van een venster dat doorgaans vijf tot tien dagen beslaat.
HackersHub pakt dit aan met een gestructureerde fase vóór de opdracht. Na ondertekening van de offerte ontvangt u een scopingvragenlijst en een gereedheidschecklist met benoemde eigenaren en data, gevolgd door een scopingsessie met de lead tester, dezelfde OSCP-gecertificeerde consultant die in het rapport bij naam wordt genoemd. Wij verifiëren accounts en netwerktoegang samen met u twee werkdagen voordat het venster opent, zodat een toegangsprobleem wordt opgelost voordat het testtijd kost, niet tijdens. De spelregels, testposities, uitsluitingen en contactlijst worden in de opdrachtomschrijving vastgelegd en bij de kickoff teruggelezen.
Tijdens de test ontvangt u aan het einde van elke testdag een korte statusnotitie en bij elke kritieke bevinding direct een telefoontje. Aan het einde legt het rapport precies vast wat is getest, vanuit welke posities, op welke versie en wat is uitgesloten, zodat uw auditor, uw klant of uw bestuur de scopeverklaring kan lezen en de bevindingen die volgen kan vertrouwen. Voorbereiding is geen administratie rondom de test; het is wat het resultaat van de test betrouwbaar maakt.
Veelgestelde vragen
Klaar om de scope van uw penetratietest te bepalen?
Onze lead tester voert de scopingsessie met u, stuurt de gereedheidschecklist met benoemde eigenaren en verifieert de toegang voordat het venster opent. Praat met een expert.