TL;DR: De scope van een penetratietest bepaalt welke systemen, netwerken en applicaties getest worden en welke niet. Een te brede scope drijft de kosten op zonder meerwaarde. Een te smalle scope geeft valse geruststelling. De drie belangrijkste beslissingen: welke systemen zijn bedrijfskritisch, welke compliance-eisen gelden er, en wat past binnen uw budget? Dit artikel helpt u die afweging gestructureerd te maken.
Waarom de scope uw pentest maakt of breekt
De scope is het fundament van elke penetratietest. Het is de contractuele en technische grens waarbinnen een ethische hacker uw systemen mag aanvallen, en het bepaalt in grote mate hoeveel waarde u uit die test haalt.
Een te brede scope is een veelgemaakte fout. Stel: u laat uw volledige interne netwerk testen, inclusief printers, vergaderzaalsystemen en randapparatuur. Het resultaat? Weken doorlooptijd, een hoge factuur en een rapport vol bevindingen die weinig zeggen over uw werkelijke risico’s. De pentester besteedt tijd aan systemen die niet bedrijfskritisch zijn, terwijl de écht kwetsbare applicaties te weinig aandacht krijgen.
Het tegenovergestelde is minstens zo problematisch. Een scope die zich beperkt tot uw publieke website terwijl de werkelijke risico’s in uw Active Directory of onbeveiligde API-koppelingen zitten, levert een rapport op dat er geruststellend uitziet maar niets zegt over de aanvalsvectoren die een echte aanvaller zou gebruiken.
Volgens de Penetration Testing Execution Standard (PTES) is de scopingfase de fundamentele pre-engagementfase waarin operationele grenzen, testdoelen en de risicotolerantie van de organisatie expliciet worden vastgelegd. Die definitie is niet toevallig zo formeel: een goed gedefinieerde scope is het verschil tussen een investering en een kostenpost.
Wat valt er onder de scope van een penetratietest?
De scope van een pentest kan meerdere categorieën activa omvatten. Denk aan servers en werkstations, interne en externe netwerken, webapplicaties en API’s, cloudomgevingen, fysieke locaties en zelfs medewerkers (bij social engineering). In de praktijk maakt het scope-document een strikte tweedeling.
Aan de ene kant staan de in-scope activa: alle systemen, IP-adressen en applicaties die de pentester actief mag onderzoeken, scannen en exploiteren. Aan de andere kant staan de out-of-scope activa: systemen en netwerksegmenten die onder geen beding benaderd mogen worden.
Typische exclusies hebben altijd een goede reden. Productiesystemen worden vaak uitgesloten vanwege het risico op downtime en datacorruptie. In dat geval test de pentester op een staging-omgeving die functioneel identiek is aan productie. SaaS-applicaties en externe betalingsgateways vallen buiten de scope omdat u juridisch geen toestemming kunt geven voor tests op infrastructuur die niet van u is. Wat u wel kunt laten testen zijn uw eigen API-integratielagen en data-expositiepunten. En fysieke locaties zoals operationele controlekamers worden doorgaans passief geaudit, buiten de actieve operationele uren.
Het is belangrijk om te begrijpen dat deze exclusies geen zwaktes in de test zijn. Ze zijn bewuste keuzes om de test uitvoerbaar, juridisch houdbaar en operationeel veilig te houden.
Scope per type pentest
Niet elke pentest test dezelfde dingen. Het type test bepaalt welke technische parameters in de scope thuishoren.
Infrastructure pentest
Bij een infrastructuurtest wordt de scope gedefinieerd op basis van specifieke IP-ranges, subnetten en VLAN’s. Het cruciale onderscheid is dat tussen de externe perimeter (firewalls, VPN-gateways en publiek blootgestelde diensten) en het interne netwerk (Active Directory, interne routers en netwerksegmentatie). Een scope die alleen het externe deel omvat, mist de laterale bewegingsmogelijkheden die aanvallers binnen het netwerk hebben.
Webapplicatie pentest
Hier richt de scope zich op specifieke domeinen, unieke webpagina’s en API-endpoints. Een punt dat vaak onderschat wordt: de scope moet expliciet bepalen hoeveel verschillende gebruikersrollen getest worden. Een applicatie met een beheerdersrol, een standaardgebruiker en een anonieme bezoeker vraagt per rol een aparte testronde om privilege-escalatie en autorisatiefouten effectief te onderzoeken. Meer rollen betekent meer testdagen.
Cloud pentest
De testomvang specificeert exact welke cloud-accounts, tenants en regio’s getest worden. Bij een Microsoft 365 of Azure-omgeving ligt de focus op misconfiguraties en overmatig permissieve rechtenstructuren, zoals te breed ingestelde IAM-beleidsregels of publiek toegankelijke opslagcontainers. Belangrijk: de meeste cloudproviders vereisen dat u hen vooraf notificeert over geplande pentests. Voor AWS bijvoorbeeld moet u een Penetration Testing Request indienen.
OT/ICS pentest
Binnen operationele technologie is de scope conservatiever dan bij IT-systemen. Actieve netwerkscanners worden vaak expliciet uitgesloten vanwege het risico op PLC-crashes. De scope beperkt zich meestal tot passieve netwerkmonitoring, offline configuratiereviews van engineering workstations en evaluatie van fysieke toegangscontroles. Meer over de specifieke aanpak bij OT-pentests leest u in ons aparte artikel.
Hoe bepaalt u welke systemen in scope horen?
Bij een beperkt budget kunt u niet alles laten testen. De vraag is dan: welke systemen verdienen prioriteit? Een systematische classificatie helpt u die keuze te maken.
Begin met dataclassificatie. Welke systemen verwerken persoonsgegevens onder de GDPR of bedrijfskritisch intellectueel eigendom? Die systemen horen sowieso in scope. Voer vervolgens een eenvoudige Business Impact Analysis uit. Stel uzelf de vraag: wat kost het als dit systeem 24 uur onbereikbaar is? Systemen waarbij het antwoord “tienduizenden euro’s omzetverlies” luidt, verdienen een plek in de scope.
Ten slotte speelt compliance een belangrijke rol als scope-driver. Onder NIS2 moet u de effectiviteit van uw cybersecuritymaatregelen regelmatig verifiëren. In de praktijk betekent dit dat alle systemen die de levering van uw essentiële of belangrijke dienst ondersteunen, getest moeten worden. ISO 27001 vereist via Control A.8.8 dat u technische kwetsbaarheden systematisch identificeert en evalueert, en de auditor verwacht dat de pentestscope naadloos aansluit op uw risicobeoordeling.
Het CyberFundamentals (CyFun) framework van het CCB vertaalt deze eisen naar concrete, auditeerbare niveaus. Op Basic-niveau zijn actieve pentests optioneel en volstaan kwetsbaarhedenscans op internetgerichte systemen. Op Important-niveau worden periodieke pentests van bedrijfskritische systemen verwacht. Op Essential-niveau zijn diepgaande, onafhankelijke penetratietests van alle systemen die essentiële diensten ondersteunen verplicht.
Budget is altijd een begrenzende factor, en dat is niet erg. Het eerlijke antwoord is dat de scope in een directe, lineaire verhouding staat tot het benodigde budget: elke extra applicatie, IP-range of gebruikersrol vereist extra mandagen. Een realistische scope die past bij uw budget levert meer waarde op dan een ambitieuze scope die halfbakken uitgevoerd wordt.
De pentest scope voor een eerste test bij een Vlaamse KMO
Als u voor het eerst een pentest laat uitvoeren, is het verleidelijk om álles te willen testen. Dat is begrijpelijk maar zelden verstandig. Een pragmatische scope voor een eerste engagement bij een Vlaamse KMO met 50 tot 150 medewerkers ziet er typisch zo uit.
De externe perimeter omvat maximaal vijf publieke IP-adressen, inclusief uw internetgerichte firewall en actieve VPN-gateway. Eén primaire webapplicatie of klantenportal komt erbij, inclusief het testen van de onderliggende API-endpoints en twee verschillende gebruikersrollen. Op het interne netwerk doet de pentester een gerichte test op de Active Directory-omgeving vanaf één gecompromitteerd eindpunt, om te valideren of laterale beweging of privilege-escalatie mogelijk is. En een configuratiereview van uw Microsoft 365-tenant rondt het geheel af, met focus op MFA-bypass en data-expositie.
Voor een productiebedrijf met 80 medewerkers dat zijn M365-omgeving, VPN en publieke website wil laten testen, is dit een realistisch startpakket dat in drie tot vijf werkdagen uitgevoerd kan worden. De pentest kosten voor een dergelijk engagement liggen voor Belgische KMO’s doorgaans tussen €5.000 en €15.000, afhankelijk van de complexiteit.
Sinds 1 februari 2026 is de VLAIO KMO-portefeuille exclusief voorbehouden voor cybersecurityadvies. Zowel het voorbereidende scoping-advies als de pentest zelf zijn subsidiabel. Kleine ondernemingen ontvangen 45% subsidie, middelgrote ondernemingen 35%, met een jaarlijks maximum van €7.500. Dat maakt de drempel voor een eerste pentest aanzienlijk lager.
Rules of Engagement: de juridische kant van scope
De scope bepaalt wat getest wordt. De Rules of Engagement (RoE) bepalen hóé dat gebeurt. Dit document regelt de testperiode, whitelisting van IP-adressen van de testers, escalatiepaden bij kritieke incidenten en de toegestane testmethodieken.
Voordat een pentest mag starten, moeten drie juridische documenten getekend zijn. De formele autorisatie is een schriftelijke verklaring waarin u als opdrachtgever expliciet toestemming verleent om uw systemen aan te vallen. De aansprakelijkheidsbeperking vrijwaart de pentesters van onbedoelde schade, mits zij zich aan de RoE houden. En de NDA beschermt de gevoelige kwetsbaarheden en bedrijfsgegevens die tijdens de test blootgelegd worden.
In België is dit niet optioneel. Artikel 550bis van het Belgische Strafwetboek stelt hacking streng strafbaar. Zonder een voorafgaande, expliciete en ondertekende schriftelijke overeenkomst worden de acties van een pentester strafrechtelijk gekwalificeerd als een misdrijf. Het Centrum voor Cybersecurity België (CCB) biedt weliswaar een kader voor Coordinated Vulnerability Disclosure, maar dat beschermt uitsluitend ethische hackers die ongevraagd en onder strikte voorwaarden kwetsbaarheden melden. Voor commerciële, in opdracht uitgevoerde penetratietests is een sluitend contract de enige geldige rechtsgrond.
De keuze voor black box, grey box of white box testing beïnvloedt de RoE eveneens. Bij een black box test ontvangt de pentester geen voorinformatie, waardoor de scope strikt is afgebakend tot wat extern ontdekt kan worden. Bij een grey box of white box test worden credentials en architectuurdocumentatie verstrekt, wat de scope technisch verruimt.
Scope creep voorkomen
Scope creep is het ongecontroleerd uitdijen van testactiviteiten nadat de scoping-fase is afgerond. Het treedt typisch op in twee scenario’s: de IT-manager vraagt halverwege de test om extra subdomeinen te testen, of de pentester ontdekt een gekoppeld systeem dat niet in de oorspronkelijke scope stond maar duidelijk kwetsbaar is.
Beide situaties leiden tot budgetoverschrijdingen en vertragingen als ze niet goed gemanaged worden. De oplossing is een formele change-control clausule in het contract. Elke toevoeging aan de scope wordt schriftelijk ingediend, beoordeeld op budgettaire en planningstechnische consequenties, en pas na een getekende change order in behandeling genomen.
Wat als de pentester tijdens het onderzoek stuit op een kritieke kwetsbaarheid in een systeem dat buiten de scope valt? Het antwoord is helder: niet exploiteren, wel melden. De pentester meldt de bevinding via het afgesproken escalatiepad aan de IT-manager. Die beslist vervolgens of de scope via een change order wordt uitgebreid of dat het probleem intern wordt opgepakt.
Bij Cyberplan beginnen we elk pentest-traject met een scope-gesprek van een uur, kosteloos en vrijblijvend. Tijdens dat gesprek brengen we samen in kaart welke systemen bedrijfskritisch zijn, welke compliance-eisen gelden en wat realistisch is binnen uw budget. Dat voorkomt verrassingen tijdens de uitvoering en zorgt dat de resultaten bruikbaar zijn als input voor uw beveiligingsstrategie en, indien nodig, als bewijsstuk voor een pentest bedrijf kiezen of conformiteitsbeoordeling.
Veelgestelde vragen over pentest scope
Hoeveel IP-adressen horen in scope voor een eerste pentest?
Voor een Vlaamse KMO die een eerste pentest laat uitvoeren, is een scope van maximaal vijf publieke IP-adressen een realistisch vertrekpunt. Dit omvat doorgaans uw firewall, VPN-gateway en publiek toegankelijke servers. Intern komt daar een gerichte Active Directory-test bij.
Moet ik productiesystemen laten testen?
Productiesystemen worden bij voorkeur niet direct getest vanwege het risico op downtime. De best practice is om te testen op een staging-omgeving die functioneel en infrastructureel identiek is aan productie. Zo krijgt u betrouwbare resultaten zonder operationeel risico.
Wat als mijn scope niet aansluit bij de NIS2-vereisten?
NIS2 schrijft geen exact aantal IP-adressen voor, maar verwacht dat u de effectiviteit van uw beveiligingsmaatregelen regelmatig verifieert op alle systemen die uw essentiële dienst ondersteunen. Het CyFun-framework van het CCB helpt u vertalen welk testniveau bij uw organisatie past.
Kan ik SaaS-applicaties van derden laten pentesten?
Niet zonder toestemming van de eigenaar van die infrastructuur. Wat u wel kunt testen zijn uw eigen integraties, API-koppelingen en data-expositiepunten richting die SaaS-omgeving. De scope beperkt zich tot wat juridisch van u is.
Hoe voorkom ik dat de pentest duurder wordt dan begroot?
Een duidelijk scope-document met een formele change-control clausule is de beste bescherming. Elke wijziging wordt schriftelijk vastgelegd en pas na akkoord op kosten en planning uitgevoerd. Een scope-gesprek vooraf helpt om realistische verwachtingen te stellen.
Hoe verhoudt de scope zich tot een vulnerability assessment?
Een vulnerability assessment scant breed op bekende kwetsbaarheden, zonder ze actief te exploiteren. Een pentest heeft een strakkere scope maar gaat dieper: de tester probeert de gevonden kwetsbaarheden daadwerkelijk te misbruiken. De scope van een pentest is daardoor gerichter maar intensiever per geteste component.
Van scope naar offerte
De scope van uw pentest is geen technisch detail dat u aan de dienstverlener overlaat. Het is een strategische beslissing die bepaalt hoeveel waarde u uit de test haalt, hoeveel die kost, en of het resultaat bruikbaar is voor compliance en verzekeringsaanvragen.
De drie vragen die u beantwoord moet hebben voordat u een offerte aanvraagt: welke systemen zijn bedrijfskritisch en verdienen prioriteit? Welke regelgeving stelt eisen aan de minimale testomvang? En wat is realistisch uitvoerbaar binnen uw budget?
Als u gekozen hebt voor een pentest in plaats van een red teaming-aanpak, is de scope-bepaling uw volgende concrete stap. En als uw scope mede cloudomgevingen omvat, biedt ons artikel over cloud pentesting aanvullende context over de specifieke afbakening van cloudtests.
Wilt u uw scope helder krijgen? Plan een vrijblijvend scope-gesprek met een van onze pentesters. In een uur brengen we samen in kaart wat voor uw organisatie de slimste aanpak is, zodat u gericht kunt vergelijken en beslissen.
