Pentest Checklist: wat moet je opnemen in een Pentest opdracht?

Een pentest laten uitvoeren lijkt eenvoudig. Je kiest een leverancier, tekent een offerte en ontvangt een rapport. In de praktijk loopt het vaak mis omdat de pentest opdracht te vaag is. Het gevolg: oppervlakkige resultaten, gemiste risico’s en frustratie bij IT en management.

Deze checklist helpt bedrijven om vooraf de juiste keuzes te maken. Niet om “iets te testen”, maar om te testen wat er écht toe doet.

Waarom een goede pentest opdracht cruciaal is

Een pentest is geen standaardproduct. De kwaliteit van de test wordt grotendeels bepaald door:

• wat je laat testen,
• hoe diep er getest mag worden,
• en wat je verwacht als resultaat.

Een onduidelijke opdracht leidt vaak tot:

• tests die blijven steken op automatische scans,
• geen aandacht voor business logic of aanvalsketens,
• rapporten die technisch correct zijn, maar weinig beslissingen ondersteunen.

Met deze checklist voorkom je dat.

De complete pentest checklist

1. Doel van de pentest

Begin niet met systemen, maar met het waarom.

Stel jezelf expliciet deze vragen:

• Wat willen we leren uit deze pentest?
• Gaat het om externe blootstelling, interne risico’s of beide?
• Willen we kwetsbaarheden vinden of aantonen wat écht misbruikt kan worden?

Zonder duidelijk doel test je veel, maar leer je weinig.

2. Scope: wat zit erin en wat niet

Een van de meest gemaakte fouten is een te brede of te vage scope.

Leg vast:

• Domeinen, subdomeinen en IP-ranges
• Applicaties, API’s, cloudomgevingen
• Productie, test en acceptatie omgevingen
• Wat expliciet buiten scope valt

Een scherp afgebakende scope zorgt voor focus en diepgang.

3. Type pentest

Kies bewust het testtype, niet “wat standaard is”.

• Black box: geen voorkennis, extern perspectief
• Grey box: beperkte info of testaccounts
• White box: volledige documentatie en inzicht

Voor moderne applicaties en cloudomgevingen leveren grey box en white box tests meestal meer waarde dan pure black box tests.

4. Toegang en testaccounts

Zonder realistische toegang test je niet realistisch.

Denk aan:

• Gebruikersaccounts (klant, medewerker, admin waar relevant)
• API-keys of tokens
• Testdata met realistische rechten

Veel kritische issues zitten pas na authenticatie.

5. Diepgang: wat mag de tester doen?

Leg vast hoe ver een ethical hacker mag gaan.

Voorbeelden:

• Is privilege escalation toegestaan?
• Mag data worden ingezien of alleen aangetoond?
• Mag er lateraal bewogen worden binnen het netwerk?
• Zijn brute-force of phishing-simulaties toegestaan?

Zonder deze afspraken blijven testers vaak onnodig voorzichtig.

6. Aanvalsscenario’s en business context

Hier maken bedrijven het verschil tussen een scan en een volwaardige pentest.

Geef context:

• Kritieke processen (betalingen, orders, klantdata)
• Integraties met derde partijen
• Bekende zorgen of eerdere incidenten

Ethical hackers kunnen alleen business logic testen als ze de business begrijpen.

7. Veiligheid en continuïteit

Een pentest mag geen productie-incident worden.

Leg vast:

• Tijdvensters
• Impactlimieten
• Contactpersonen bij incidenten
• Stopcriteria

Dit geeft vertrouwen aan IT en operations.

8. Rapportagevereisten

Rapportage is vaak het grootste pijnpunt.

Vraag expliciet om:

• Executive summary in begrijpelijke taal
• Duidelijke impact per bevinding
• Reproduceerbare stappen
• Concrete en prioriteerbare remediatie
• Scheiding tussen “theoretisch” en “bewezen misbruik”

Een goed rapport ondersteunt beslissingen, geen discussie.

9. Retest en opvolging

Een pentest zonder opvolging is half werk.

Bepaal vooraf:

• Of fixes worden hertest
• Binnen welke termijn
• Hoe succes wordt vastgesteld

Zo vermijd je dat risico’s alleen “op papier” verdwijnen.

10. Verwachtingen over tooling en aanpak

Maak expliciet onderscheid tussen:

• automatische scans,
• en manuele testing door ethical hackers.

Automatisatie heeft waarde, maar echte risico’s zitten vaak in context, chaining en menselijk denkwerk. Zet dit ook zo in de opdracht.

Veelgemaakte fouten bij pentest opdrachten

• “Test alles” zonder prioriteiten
• Geen testaccounts voorzien
• Rapportage niet gespecificeerd
• Verwachten dat tools hetzelfde doen als ethical hackers
• Geen business context meegeven

Elke fout hierboven verlaagt de opbrengst van je pentest.

Conclusie

Een goede pentest begint niet bij de tester, maar bij de opdracht. Bedrijven die vooraf helder vastleggen wat, waarom en hoe ze willen testen, krijgen diepere inzichten, relevantere resultaten en bruikbare rapportage.

Of kort samengevat: een sterke pentest checklist voorkomt blinde vlekken voordat aanvallers ze vinden.