Skip to main content

    2 november 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)

    Pentest door een externe partij: waarom onafhankelijkheid telt voor uw eigen systemen, en hoe u de leveranciers test waarvan u afhankelijk bent

    Een pentest door een externe partij wordt voor twee verschillende dingen gebruikt. Het eerste is een onafhankelijke pentest van uw eigen systemen door een extern bureau, wat auditors, toezichthouders en zakelijke klanten bedoelen als zij vragen of uw test door een onafhankelijke partij is uitgevoerd. Het tweede is het testen van, of testbewijs verkrijgen over, de leveranciers en dienstverleners waarvan uw organisatie afhankelijk is. Deze gids behandelt beide: welke kaders onafhankelijkheid eisen en in welke bewoordingen, hoe intern, extern en crowdsourced testen zich verhouden, wat u bij een leverancier wel en niet mag testen, wat een pentestverklaring moet bevatten, en hoe u het samenvattende rapport van een leverancier leest.

    Plan een onafhankelijke pentest

    Wat een pentest door een externe partij betekent

    In de eerste en meest gebruikelijke betekenis is een pentest door een externe partij een penetratietest van uw eigen systemen, uitgevoerd door een gekwalificeerd bureau dat organisatorisch onafhankelijk is van de mensen die die systemen bouwen en beheren. Het punt is niet dat buitenstaanders slimmer zijn. Het punt is dat de partij die de beveiliging van een systeem beoordeelt niet mag rapporteren aan de partij die ervoor verantwoordelijk is, de maatregelen niet zelf mag hebben ontworpen, en geen belang mag hebben bij onderrapportage. Dat beginsel staat in PCI DSS, FedRAMP, NYDFS Part 500 en in de auditpraktijk rond SOC 2 en ISO 27001, en het is wat de securityvragenlijst van een klant toetst als die naar uw meest recente onafhankelijke pentest vraagt.

    In de tweede betekenis is de externe partij de leverancier. Elke organisatie draait inmiddels op software die zij niet heeft geschreven en infrastructuur die zij niet beheert: SaaS-platformen, betaalverwerkers, managed service providers, cloudhosting, identiteitsaanbieders, uitbestede ontwikkeling. Een zwakheid bij een van hen is een zwakheid in uw omgeving, en de ketenaanvallen van de afgelopen jaren op managed-file-transfer-software, SaaS-koppelingen en dienstverleners hebben toezichthouders en besturen leveranciersbeveiliging als een primair risico laten behandelen. Een pentest door een externe partij betekent in deze zin dat u vaststelt, via eigen tests waar dat is toegestaan en via bewijs waar dat niet kan, dat de leveranciers achter uw kritieke processen worden getest op een niveau dat u voor uzelf zou accepteren.

    De twee betekenissen komen in het midden samen. De pentestverklaring die uw leverancier u stuurt, is de uitkomst van zijn onafhankelijke test in de eerste betekenis. De verklaring die u aan uw klanten stuurt, is hetzelfde document van de andere kant bekeken. Organisaties die beide kanten begrijpen, kopen betere tests, schrijven betere contracten en beantwoorden due-diligencevragen sneller.

    Betekenis één: waarom auditors en klanten een onafhankelijke tester eisen

    Weinig kaders gebruiken het woord extern. De meeste spreken van onafhankelijkheid, een gekwalificeerde externe partij of een geaccrediteerde beoordelaar. Hier zit de eis werkelijk.

    PCI DSS v4.0.1, Requirement 11.4

    Interne en externe penetratietesten minimaal elke 12 maanden en na significante wijzigingen (11.4.2 en 11.4.3), uitgevoerd door een gekwalificeerde interne medewerker of een gekwalificeerde externe partij, met expliciet vereiste organisatorische onafhankelijkheid van de tester. De tester hoeft geen QSA of ASV te zijn. 11.4.1 vereist een gedocumenteerde methodiek; 11.4.4 vereist herstel en hertest.

    AICPA Trust Services Criteria (serviceorganisatierapporten)

    SOC 2 verplicht geen pentest, maar CC4.1 (doorlopende en afzonderlijke evaluaties) en CC7.1 (detectie van kwetsbaarheden) worden vrijwel altijd met een pentest onderbouwd, en de auditor beoordeelt of de evaluatie objectief was. Een onafhankelijke test met een benoemd bureau, scope en data is het bewijs dat zonder discussie wordt geaccepteerd; een zelftest door het ontwikkelteam vraagt om uitzonderingen.

    ISO/IEC 27001:2022

    Annex A-maatregel 8.8 (beheer van technische kwetsbaarheden) verwacht testbewijs; maatregel 5.35 vereist een onafhankelijke beoordeling van de informatiebeveiliging; de maatregelen 5.19 tot en met 5.22 regelen leveranciersrelaties, leveranciersovereenkomsten, de ICT-toeleveringsketen en het monitoren van leveranciersdiensten. Certificerende auditors verwachten dat de tester onafhankelijk is van de eigenaar van het ISMS.

    HIPAA Security Rule

    45 CFR 164.308(a)(8) vereist periodieke technische en niet-technische evaluatie; 164.308(b) en 164.314(a) vereisen business associate agreements die leveranciers aan dezelfde waarborgen binden. De in januari 2025 voorgestelde herziening van de Security Rule zou een jaarlijkse pentest door een gekwalificeerde persoon expliciet maken; tot die definitief is, behandelen de richtlijnen en handhaving van OCR onafhankelijk testen al als de verwachte evaluatiemethode.

    FedRAMP en CMMC 2.0

    FedRAMP vereist penetratietesten door een geaccrediteerde Third Party Assessment Organization (3PAO) onder maatregel CA-8 en de FedRAMP Penetration Test Guidance, bij autorisatie en jaarlijks. CMMC 2.0 Level 2 vereist voor de meeste defensieleveranciers een beoordeling door een gecertificeerde C3PAO. In beide programma's is onafhankelijkheid geen voorkeur; het is de structuur van het programma.

    NYDFS 23 NYCRR 500.5 en de GLBA Safeguards Rule

    NYDFS 500.5(a)(1) vereist jaarlijkse penetratietesten van informatiesystemen door een gekwalificeerde interne of externe partij; 500.11 vereist een beleid voor externe dienstverleners. De FTC Safeguards Rule, 16 CFR 314.4(d)(2), vereist jaarlijkse penetratietesten en halfjaarlijkse kwetsbaarheidsbeoordelingen, en 314.4(f) vereist toezicht op dienstverleners.

    DORA en NIS2 (EU)

    DORA artikel 24 vereist dat tests worden uitgevoerd door onafhankelijke interne of externe testers; bij threat-led penetration testing (artikel 26 en 27) moet de threat-intelligence-aanbieder altijd extern zijn. Artikel 28 tot en met 30 regelen het ICT-risico van derden, inclusief contractuele rechten op toegang, inspectie en audit bij aanbieders. NIS2 artikel 21(2)(d) maakt beveiliging van de toeleveringsketen een verplichte maatregel en 21(2)(f) vereist het testen en auditen van de maatregelen.

    Intern team versus extern bureau versus crowdsourced testen

    Elk model heeft zijn plaats. Slechts één ervan voldoet op zichzelf aan een onafhankelijkheidseis.

    AspectIntern securityteamExtern pentestbureauCrowdsourced / bug bounty
    OnafhankelijkheidLaag: rapporteert binnen dezelfde organisatie; heeft mogelijk de maatregelen gebouwdHoog: organisatorisch gescheiden, contractueel gebonden, testers bij naamGemiddeld: onderzoekers zijn extern, maar dekking en methode zijn niet gestuurd
    Geaccepteerd als bewijs doorInterne audit; zelden op zichzelf door PCI, FedRAMP, NYDFS of zakelijke klantenPCI DSS, SOC 2, ISO 27001, HIPAA, NYDFS, GLBA, DORA, klantonderzoekNuttige aanvulling; in geen enkel kader een vervanging van een gescopete test
    DekkingDiepe systeemkennis, doorlopend; blinde vlekken waar het team het systeem ontwierpGescopet en volledig tegen een benoemde methodiek; frisse blikOnvoorspelbaar; concentreert zich op wat loont, slaat geauthenticeerde en interne scope over
    VertrouwelijkheidHoogstContractueel: NDA, omgang met data, personen bij naamLaagst: veel onbekende deelnemers
    OpleveringTickets en interne rapportenRapport met scope, methodiek, bewijs, herstel, hertest en pentestverklaringLosse meldingen per bevinding; geen scopeverklaring
    KostenlogicaVaste bezetting; per test het laagst zodra bemand, duur om op te bouwenPer opdracht geoffreerd op scope en diepteBetaling per geldige bevinding plus platformkosten; onbegrensd
    Het beste voorDoorlopend testen tussen externe opdrachten, regressie van herstelde bevindingenJaarlijks en wijzigingsgedreven testen, compliancebewijs, verklaringen voor klantenPublieke applicaties nadat een onafhankelijke test de basis heeft afgedekt

    Betekenis twee: het testen van de partijen waarvan u afhankelijk bent

    Een leveranciersrisicoprogramma sorteert leveranciers op de data die zij bewaren en de processen die zij ondersteunen, en bepaalt vervolgens welk bewijs elke laag u verschuldigd is. Voor kritieke leveranciers hoort daar penetratietesten bij: uw eigen test van de onderdelen die u mag testen, of hun onafhankelijke testrapport en pentestverklaring, of beide. Vragenlijsten alleen tonen niet aan dat een maatregel werkt; een test wel. De praktische volgorde is: classificeer de leverancier, lees de scope van zijn SOC 2- of ISO 27001-rapport om te zien wat de auditor werkelijk heeft gedekt, vraag de pentestverklaring en het samenvattende rapport op voor de dienst die u afneemt, en test daarna zelf uw kant van de koppeling.

    Wat u mag testen wordt bepaald door de voorwaarden van de leverancier en door het model van gedeelde verantwoordelijkheid. Op een multi-tenant SaaS-platform mag u het platform zelf doorgaans niet testen: de gebruiksvoorwaarden verbieden het, en een ongeautoriseerde test tegen gedeelde infrastructuur is ongeautoriseerde toegang tot de data van andere klanten. U mag wel uw tenantconfiguratie testen, uw single sign-on en identiteitskoppeling, de API's en webhooks die u op het platform heeft gebouwd, eigen code die u erin heeft uitgerold, en de datastromen tussen de leverancier en uw eigen systemen. Managed service providers, uitbestede ontwikkelaars en hostingpartners die een toegewijde omgeving voor u beheren, kunnen meestal worden getest onder een schriftelijke machtiging die hen als partij benoemt.

    Cloudhosting is het bijzondere geval, en de term pentest door een externe partij wordt er soms voor gebruikt. De meeste grote cloudaanbieders publiceren een beleid voor pentesten door klanten dat het testen van uw eigen gehoste middelen zonder voorafgaande melding toestaat voor gangbare diensten, terwijl tests tegen de gedeelde infrastructuur van de aanbieder en elke vorm van denial-of-service verboden blijven. De aanbieder beveiligt het onderliggende platform; u blijft verantwoordelijk voor identiteit, configuratie, netwerkblootstelling en workloads, en dat is de scope van een cloud-penetratietest (link hieronder).

    Waar u niet mag testen, moet het contract het werk doen. Een auditrechtclausule hoort te benoemen wat u mag auditen (maatregelen, bewijs, testrapporten), hoe vaak, op wiens kosten, en wat er gebeurt als een kritieke bevinding openstaat. Zij hoort onderscheid te maken tussen een audit en een test, het recht te geven op het samenvattende pentestrapport en de verklaring van de leverancier, minimaal jaarlijks en na grote wijzigingen, hersteltermijnen te stellen voor bevindingen die uw dienst raken, en u toe te staan met aankondiging een test van toegewijde componenten te laten uitvoeren. DORA artikel 30 maakt verschillende van deze bepalingen verplicht voor kritieke ICT-aanbieders van financiële entiteiten; voor alle anderen zijn zij onderhandelbaar, en vóór ondertekening eenvoudiger te bedingen dan na een incident.

    Wat een pentestverklaring moet bevatten

    Een pentestverklaring is het document van een of twee pagina's dat een leverancier deelt in plaats van het volledige rapport. Of u er een schrijft of leest, deze punten horen erin.

    • Identiteit van het testbureau, de lead tester bij naam met certificeringen, en een verklaring over de onafhankelijkheid van het bureau ten opzichte van de geteste organisatie
    • Testdata en de datum van de verklaring, met de geldigheidsperiode waar het bureau voor instaat
    • Scope in concrete termen: de geteste applicaties, URL's, IP-reeksen, omgevingen (productie of staging) en versies, en wat uitdrukkelijk is uitgesloten
    • Testtype en diepte: extern, intern, webapplicatie, API, cloudconfiguratie; black, grey of white box; geteste geauthenticeerde rollen
    • Methodiek bij naam (PTES, OWASP WSTG of MASTG, NIST SP 800-115) met bevestiging dat handmatig is getest
    • Bevindingen samengevat per ernst, volgens een benoemd ernstmodel zoals CVSS, zonder technische details die de leverancier zouden blootstellen
    • Herstelstatus op het moment van de verklaring en de datum en uitkomst van de hertest
    • Beperkingen: testvensters, limieten, componenten buiten scope, alles wat de dekking heeft verkleind
    • Een contactpersoon bij het testbureau die de echtheid van de verklaring op verzoek bevestigt

    Hoe u het samenvattende pentestrapport van een leverancier leest

    De meeste samenvattingen van leveranciers zijn geschreven om gerust te stellen. Lees ze op wat zij bewijzen over de dienst die u werkelijk afneemt.

    1. Komt de scope overeen met de dienst die u afneemt?

    Een test van de marketingwebsite of van één productlijn zegt niets over de API die uw koppeling gebruikt. Leg de scopeverklaring naast uw architectuurschema en vraag om de test die uw componenten dekt als die ontbreekt.

    2. Hoe recent, en hoe vaak?

    Een test ouder dan twaalf maanden, of een test van vóór een grote release, is geschiedenis in plaats van bewijs. Vraag naar de testfrequentie en naar wijzigingsgedreven tests, en controleer die tegen de release notes.

    3. Wie heeft getest, en was die onafhankelijk?

    Zoek naar een benoemd extern bureau, testers bij naam met certificeringen en een onafhankelijkheidsverklaring. Een naamloos team of een geautomatiseerde scandienst die als pentest wordt gepresenteerd, is de meest voorkomende zwakte in leveranciersbewijs.

    4. Wat was de verdeling naar ernst en wat staat nog open?

    Nul bevindingen in een volwassen product is een scope- of diepteprobleem, geen beveiligingsprestatie. Vraag naar de aantallen per ernst, de hersteldata en de hertestuitkomst, en naar hoe lang kritieke bevindingen open hebben gestaan.

    5. Welke omgeving, en op welke diepte?

    Een black-box-test van een stagingomgeving is geen bewijs over autorisatiemaatregelen in productie. Grey-box-testen met geauthenticeerde rollen op productie of een productie-identieke omgeving is de norm die een kritieke leverancier moet halen.

    6. Hoe sluit het aan op zijn auditrapport?

    Lees de systeembeschrijving in het SOC 2-rapport, de uitgesloten subdienstverleners en de aanvullende maatregelen die van u als gebruiker worden verwacht. De pentest hoort het systeem te dekken dat het SOC 2-rapport beschrijft, en een bridge letter hoort de periode sinds het einde van de rapportageperiode te overbruggen.

    Hoe HackersHub aan beide kanten past

    Voor organisaties die een onafhankelijke test van hun eigen systemen nodig hebben, is HackersHub de externe partij: een offensief securitybureau uit Amsterdam met 10+ jaar ervaring, testers die alle minimaal OSCP hebben met OSWE- en CREST-gecertificeerde testers in het team, een gedocumenteerde methodiek die aansluit op PTES, OWASP WSTG en MASTG en NIST SP 800-115, en rapporten gebouwd voor de mensen die ze lezen: een managementsamenvatting, CVSS-gescoorde bevindingen met bewijs, een aanvalsverhaal en geprioriteerd herstel. Een verificatiehertest van bevindingen vanaf medium binnen 90 dagen is inbegrepen, en wij geven een pentestverklaring af die u aan auditors en klanten kunt overhandigen. Levering gebeurt op afstand vanuit Amsterdam, Nederland, met werk op locatie waar een opdracht dat vraagt.

    Voor organisaties die zekerheid over hun leveranciers nodig hebben, testen wij de componenten die u mag laten testen (tenantconfiguratie, identiteitskoppeling, API's, toegewijde omgevingen die voor u worden beheerd), beoordelen wij het pentestbewijs dat uw kritieke leveranciers aanleveren en vertellen wij u wat het wel en niet bewijst, en helpen wij de test- en auditrechtbepalingen in contracten te schrijven voordat die worden ondertekend. Het kiezen van het bureau voor beide kanten is een aparte vraag, behandeld in onze gids over het kiezen van een pentestbedrijf, die u naast deze gids zou moeten lezen.

    Veelgestelde vragen

    Verder lezen

    Een onafhankelijke test nodig, of zekerheid over een leverancier?

    Wij testen uw systemen als de onafhankelijke partij die uw auditors en klanten verwachten, testen de leverancierscomponenten die u mag laten testen, en vertellen u wat het bewijs van een leverancier werkelijk aantoont. Praat met een expert.

    Plan een onafhankelijke pentestPraat met een expert