Pentest uitvoeren of laten uitvoeren: de zeven stappen van een penetratietest
Een pentest uitvoeren betekent in de praktijk: een gecertificeerde tester valt uw webapplicatie, API, netwerk of mobiele app gecontroleerd aan, met uw toestemming, en legt vast wat een echte aanvaller zou bereiken. Lees eerst wat een penetratietest precies is als het begrip nieuw voor u is. Deze gids gaat over het proces: wat er gebeurt tussen het eerste gesprek over de scope en het rapport dat u aan uw auditor of klant overlegt.
De vraag 'pentest uitvoeren' heeft twee lezingen. De ene is: kan ons eigen team een pentest uitvoeren? De andere is: hoe laat ik een pentest uitvoeren en wat moet ik daarvoor regelen? Beide beantwoorden we. Het korte antwoord: uw team kan veel voorbereiden en zelf scannen, maar voor bewijs richting een auditor of klant moet de tester onafhankelijk zijn.
Hieronder leest u de zeven stappen van een penetratietest, hoe lang elke fase duurt, wat u vooraf klaar moet hebben en hoe u een test bij Budget Security laat uitvoeren zonder salesgesprek.
Zelf een pentest uitvoeren of laten uitvoeren?
Wat uw eigen team wel kan. Een kwetsbaarheidsscanner draaien, patches doorvoeren, configuraties hardenen, testaccounts aanmaken en de scope beschrijven. Dat haalt de bekende, automatisch vindbare problemen weg, zodat de externe tester de testdagen besteedt aan wat een scanner niet ziet.
Waarom laten uitvoeren meestal de norm is. Drie redenen. Onafhankelijkheid: wie het systeem bouwt of beheert, kent de aannames erachter en test daar onbewust omheen. Vaardigheid: een pentest is handwerk, waarbij de tester losse kwetsbaarheden aan elkaar knoopt tot een aanvalspad. Bewijskracht: een rapport van een externe, gecertificeerde tester wordt door auditors en klanten geaccepteerd, een interne memo zelden.
Wat kaders en auditors verwachten. De grote normen schrijven zelden letterlijk 'pentest' voor, maar verwachten wel bewijs dat niet door de bouwers zelf is geproduceerd. ISO 27001 vraagt in Annex A om technisch kwetsbaarheidsbeheer en beveiligingstests; een onafhankelijk testrapport is het bewijs dat certificerende instellingen daarbij willen zien, zie ISO 27001 pentest. NIS2 verlangt in artikel 21 beleid en procedures om de effectiviteit van uw beveiligingsmaatregelen te beoordelen; een pentest is daarvoor de gangbare invulling, zie NIS2 pentest. DORA stelt eisen aan de kwalificaties en onafhankelijkheid van wie financiële instellingen test, zie DORA pentest. SOC 2-auditors nemen een pentestrapport als bewijs bij de criteria voor monitoring en kwetsbaarheidsbeheer. PCI DSS vraagt in eis 11.4 uitdrukkelijk om organisatorische onafhankelijkheid van de tester.
Wanneer intern wel volstaat. Als u alleen voor uzelf wilt weten hoe uw systemen ervoor staan, zonder auditor of klant die om bewijs vraagt. Als het om een interne tool gaat zonder klantdata. Of als u een externe test voorbereidt en eerst de bekende zaken wilt opruimen. In alle andere gevallen laat u de pentest uitvoeren en gebruikt u het interne werk als voorbereiding.
Stap 1: scope en doel bepalen
Elke pentest begint met twee vragen: wat testen we, en waarom? Het antwoord op de tweede vraag bepaalt het antwoord op de eerste.
Welke assets. Een webapplicatie met klantportaal, de API erachter, de buitenkant van uw netwerk, het interne netwerk, een mobiele app, een cloudomgeving. Kies wat de aanleiding raakt. Voor een klantvraag over uw SaaS-product is dat de webapplicatie en de API. Voor een ISO 27001-audit komt daar vaak het externe netwerk bij. Heeft u een app in de stores, dan hoort de mobiele app erbij.
Welk doel. Een audit (ISO 27001, SOC 2, NIS2, DORA, PCI DSS), een klant die om een recent rapport vraagt, een release die live gaat, of een overname waarbij de koper zekerheid wil. Het doel bepaalt de diepgang en wat het rapport moet aantonen.
Welke methode. Bij een black box-test krijgt de tester niets, bij white box alles, inclusief broncode. Wij adviseren grey box: de tester krijgt testaccounts en documentatie, zodat de testdagen naar het echte werk gaan in plaats van naar het raden van inlogpagina's. Het is ook precies wat een aanvaller met een gestolen account kan.
Hoeveel testdagen. Een test duurt 1 tot 30 testdagen, in stappen van een halve dag. Op het platform bepaalt de scopingengine dat aantal op basis van de assets die u toevoegt; voor complexe omgevingen doet de accountmanager het. Wat een pentest kost ziet u vooraf in de calculator.
Stap 2: toestemming en spelregels
Zonder toestemming is een pentest computervredebreuk, met toestemming een dienst. Deze stap is daarom niet administratief, maar de basis van alles wat volgt. Leg het volgende vast voordat de tester begint:
- Schriftelijke toestemming van de eigenaar. Alleen wie eigenaar is van het systeem kan toestemming geven. Test u een applicatie die een leverancier voor u host, dan moet die leverancier akkoord zijn.
- Hosting- en SaaS-voorwaarden. Cloudproviders staan pentests op uw eigen omgeving doorgaans toe, maar sommige diensten vragen een melding vooraf of sluiten bepaalde testvormen uit. Controleer de voorwaarden van elke partij in de scope.
- Testaccounts per rol. Voor een grey box-test maakt u minimaal twee accounts per gebruikersrol aan: beheerder, gewone gebruiker, en waar van toepassing een tweede organisatie of tenant. Daarmee kan de tester controleren of gebruiker A de gegevens van gebruiker B kan zien.
- Testvenster. Binnen welke uren mag er getest worden? Kantooruren hebben als voordeel dat uw team bereikbaar is.
- Contactpersonen. Een technisch contact voor vragen en een escalatiecontact voor kritieke bevindingen, met telefoonnummers.
- Wat buiten scope valt. Systemen van derden, denial-of-service, social engineering tenzij afgesproken, en productiedata die niet aangepast mag worden.
- Productie of staging. Een test op productie geeft het eerlijkste beeld. Staging is veiliger, mits identiek aan productie. Veel klanten kiezen productie met een afgesproken venster en aparte testaccounts.
Op het platform legt u deze afspraken vast bij het toevoegen van een asset. De tester ziet ze voordat de test begint; inloggegevens worden versleuteld opgeslagen.
Stap 3: informatie verzamelen en in kaart brengen
De eerste testdag begint zoals een echte aanval begint: met kijken. De tester brengt het aanvalsoppervlak in kaart voordat er iets wordt geprobeerd.
Reconnaissance. Welke domeinen, subdomeinen en IP-adressen horen bij de scope? Welke technologie draait er: framework, webserver, cloudprovider, authenticatiedienst? Welke versies zijn zichtbaar? Welke informatie staat publiek in documentatie, code-repositories of certificaten?
Discovery met tooling. Hier zet de tester automatisering in: poortscans, directory-enumeratie, het crawlen van de applicatie, het inladen van uw OpenAPI-specificatie. Dit is de enige fase waarin tooling het voortouw heeft. Het doel is volledigheid: elke pagina, elk endpoint, elke parameter die input accepteert.
Het aanvalsoppervlak. Het resultaat is een kaart: welke ingangen zijn er, welke rollen bestaan, waar wordt data verwerkt, waar lopen koppelingen naar andere systemen. Die kaart bepaalt waar de handmatige testdagen naartoe gaan: een inlogpagina, een bestandsupload of een betaalkoppeling krijgt meer aandacht dan een statische contactpagina.
Stap 4: kwetsbaarheden vinden en handmatig verifiëren
Nu begint het eigenlijke werk. De tester loopt de kaart af en probeert per ingang wat er misgaat. Scannerresultaten zijn hierbij een startpunt, geen uitkomst.
Geen false positives in het rapport. Elke bevinding in ons rapport is handmatig geverifieerd. Een scanner die een 'mogelijke SQL-injectie' meldt, levert pas een bevinding op als de tester heeft aangetoond dat de injectie werkt. Dat scheelt uw developers dagen aan onderzoek naar meldingen die niets blijken te zijn.
OWASP Top 10 als kapstok. De OWASP Top 10 ordent de meest voorkomende risico's in webapplicaties: gebroken toegangscontrole, cryptografische fouten, injectie, onveilig ontwerp, verkeerde configuratie, kwetsbare componenten, fouten in authenticatie en meer. Wij gebruiken die lijst als controlemiddel om niets over te slaan, niet als grens. Voor API's geldt de aparte OWASP API Security Top 10, voor mobiele apps de OWASP Mobile Top 10.
Autorisatie. Hier komen de meeste ernstige bevindingen vandaan, en hier zijn scanners vrijwel blind. Kan een gewone gebruiker een beheerdersfunctie aanroepen door een URL aan te passen? Kan klant A via de API de factuur van klant B opvragen door een ID te veranderen? Hiervoor zijn de testaccounts per rol uit stap 2 onmisbaar.
Businesslogica. Kan een korting twee keer worden toegepast? Kan een bestelling worden afgerond zonder betaling? Kan een stap in een goedkeuringsproces worden overgeslagen? Deze fouten staan in geen enkele scanner, omdat ze alleen bestaan in de context van uw applicatie.
Stap 5: exploitatie en aanvalsketens
Een kwetsbaarheid vinden is één ding. Laten zien wat een aanvaller ermee bereikt, geeft het rapport waarde voor de mensen die beslissen over budget en prioriteit.
Aanvalsketens. Losse bevindingen met een lage ernst worden samen een hoog risico. Een informatielek dat gebruikersnamen blootlegt, plus een inlogpagina zonder rate limiting, plus een wachtwoordreset die te voorspellen is: afzonderlijk drie kleine punten, samen een overname van accounts. De tester knoopt deze ketens aan elkaar en beschrijft het hele pad, van eerste ingang tot eindresultaat.
Veilig, zonder schade. Exploitatie gebeurt gecontroleerd. De tester bewijst toegang met een onschuldige actie, zoals het uitlezen van een testrecord, en gaat niet verder dan nodig is voor het bewijs. Productiedata wordt niet gewijzigd, systemen worden niet platgelegd. Wat in stap 2 buiten scope is gezet, blijft buiten scope.
Afstemming bij kritieke bevindingen. Vindt de tester iets kritiek, bijvoorbeeld een manier om zonder inloggen bij klantdata te komen, dan wacht dat niet op het rapport. De tester meldt het direct aan uw escalatiecontact, zodat u kunt kiezen: direct herstellen, of eerst de test afmaken. De overige bevindingen leest u na afloop in het portaal en in het rapport.
Stap 6: rapportage
Binnen 48 uur na afloop van de test staat het rapport in uw portaal. Het is een PDF per getest asset, met uw logo erop, geschreven voor drie lezers: de developer die herstelt, de manager die beslist en de auditor of klant die controleert. Wat erin staat:
- Een managementsamenvatting: scope, data, methode, het totaalbeeld en de belangrijkste bevindingen in gewone taal.
- De scope en methodiek: welke assets zijn getest, met welke methode (black, grey of white box), en wat is uitgesloten.
- Per bevinding: ernst, CVSS-score met uitleg in gewone taal, beschrijving, impact, herstelaanbeveling, stappen om het te reproduceren, getroffen onderdelen, referenties en bewijs.
Het portaal doet meer dan de PDF. Elke bevinding heeft een status (open, in behandeling, opgelost, gemitigeerd, risico geaccepteerd), notities en een volledige historie. U nodigt developers uit met een account dat alleen bevindingen toont, geen orders of facturen. Per bevinding maakt u met één klik een Jira Cloud-issue aan. En elke bevinding heeft een kant-en-klare prompt voor uw AI-codeertool, geschreven door het testteam, zonder payload of buitgemaakte inloggegevens.
Stap 7: herstellen en hertesten
Het rapport is het begin van het herstel, niet het einde van het project.
Prioriteren op ernst. Begin bij kritiek en hoog. Dat zijn meestal weinig bevindingen met grote impact: autorisatiefouten, injecties, authenticatieproblemen. Medium volgt in de volgende sprint. Laag en informatief plant u in bij regulier onderhoud, of u accepteert ze gemotiveerd als risico, met de status in het portaal als vastlegging.
Hertest. Een auditor of klant wil niet alleen weten wat er is gevonden, maar ook dat het is opgelost. Een hertest is een betaalde optie van 1 testdag: de tester controleert elke herstelde bevinding opnieuw en zet de status in het portaal op opgelost. Boekt u de hertest samen met de test, dan plant u die later met één klik in, op het moment dat het herstel klaar is.
Bewijs voor auditor of klant. Het rapport, de statushistorie in het portaal en het hertestresultaat vormen samen het dossier dat u overlegt. Daarmee toont u niet alleen aan dat u heeft getest, maar ook dat u heeft opgevolgd.
Hoe lang duurt het van boeking tot rapport?
De doorlooptijd van een pentest hangt af van drie dingen: hoe snel u de voorbereiding rond heeft, hoeveel testdagen de scope vraagt, en hoe snel uw team herstelt. De fasen die wij uitvoeren, hebben vaste termijnen.
| Fase | Wie | Doorlooptijd |
|---|---|---|
| Registratie en goedkeuring van uw account | U, daarna de accountmanager | Goedkeuring doorgaans binnen 24 uur op werkdagen |
| Scope en testdagen bepalen | Scopingengine of accountmanager | Direct bij een standaard asset; doorgaans binnen 24 uur bij maatwerk |
| Voorbereiding: toestemming, testaccounts, spelregels | U | Een halve dag tot enkele dagen, afhankelijk van uw organisatie |
| Start van de test | Tester | Binnen 7 dagen na boeking; sneller alleen op beschikbaarheid en met spoedtoeslag |
| Testen | Tester | Het aantal testdagen uit de scope, 1 tot 30 |
| Rapport | Tester | Binnen 48 uur na afloop van de test |
| Herstel | Uw team | Afhankelijk van de bevindingen en uw sprintplanning |
| Hertest (optioneel) | Tester | 1 testdag, in te plannen zodra het herstel klaar is |
Een rekenvoorbeeld: een test van 4 testdagen, geboekt op maandag, start uiterlijk de maandag erop, is donderdag afgerond en het rapport staat binnen twee dagen daarna in uw portaal. Een bevestigde startdatum kunt u verplaatsen, maar niet gratis, omdat de testdagen voor u gereserveerd zijn.
Voorbereidingschecklist
Loop deze lijst door voordat u de startdatum vastlegt. Elk punt dat op de eerste testdag nog openstaat, slokt testuren op die anders naar het testen zelf gaan.
- Lijst van assets in scope: URL's, IP-adressen, app-storelinks, API-specificatie.
- Het doel van de test en de norm of klant waarvoor het rapport bedoeld is.
- Schriftelijke toestemming van de systeemeigenaar en akkoord van hostingpartijen waar nodig.
- Testaccounts per rol, minimaal twee per rol, met werkende inloggegevens en eventueel een tweede tenant.
- Keuze voor productie of staging, en bij staging de bevestiging dat die gelijk is aan productie.
- Testvenster en tijdzone.
- Technisch contact en escalatiecontact, met telefoonnummer.
- Uitsluitingen: systemen van derden, functies die niet aangeraakt mogen worden, data die niet gewijzigd mag worden.
- Whitelisting van de IP-adressen van de tester in uw WAF, zodat de test het systeem test en niet de firewall.
- Een melding aan uw eigen team of SOC, zodat niemand de test als incident behandelt.
Zo laat u een pentest uitvoeren bij Budget Security
Het hele proces hierboven loopt bij ons via het platform, zonder salesgesprek. Zo gaat het:
- Registreren. Maak een account aan op app.budgetsecurity.com met uw zakelijke e-mailadres. De accountmanager keurt nieuwe accounts goed, doorgaans binnen 24 uur op werkdagen.
- Asset toevoegen. Voer uw webapplicatie, API, netwerk of mobiele app in, met de afspraken uit stap 2.
- Scopingengine. Het platform vertaalt uw asset naar een aantal testdagen en toont wat dat omvat. Past u het aantal dagen aan, dan ziet u wat dat verandert.
- Datum kiezen. Kies een startdatum binnen 7 dagen na boeking. Eerder kan alleen als er een tester beschikbaar is, met spoedtoeslag.
- Boeken. De boeking maakt een offerte aan, geen betaling. U betaalt pas nadat het rapport is opgeleverd.
- Testen en rapport. Een OSCP-gecertificeerde tester voert de test handmatig uit. Binnen 48 uur na afloop staat het rapport in uw portaal.
- Hertest. Boek de hertest bij de test of later, en sluit de bevindingen af met bewijs voor uw auditor of klant.
Nieuwe klanten vinden in het portaal een demoproject met voorbeeldbevindingen en een volledig voorbeeldrapport, zodat u vooraf ziet wat u krijgt.
FAQ
Veelgestelde vragen over het uitvoeren van een pentest
Kan ik zelf een pentest uitvoeren?
Hoe lang duurt een pentest?
Mag een pentest op productie worden uitgevoerd?
Wat heb ik nodig om te starten?
Wie mag een pentest uitvoeren voor ISO 27001 of NIS2?
Wat gebeurt er als de tester iets kritiek vindt tijdens de test?
Laat uw pentest uitvoeren door OSCP-testers
Scope zelf, kies een startdatum binnen 7 dagen en ontvang het rapport binnen 48 uur na afloop van de test. Betaling na oplevering.