Zo bouwt u een programma voor penetration testing remediation van 90 dagen met bewijs

Penetratietesten (pentesten) simuleert een cyberaanval om kwetsbaarheden in systemen op te sporen en legt mogelijke aanvalsvectoren bloot voordat er daadwerkelijk incidenten plaatsvinden. Maar kwetsbaarheden vinden is tegenwoordig niet moeilijk. Lastiger is het om het tempo bij te houden waarmee aanvallers misbruik maken van alles wat ze vinden.

Recent onderzoek in de sector laat zien dat het merendeel van de nieuw ontdekte kwetsbaarheden binnen mediaan 48 uur wordt gewapend. Erger nog: steeds meer aanvallers zetten AI in om verkenning en exploit chaining op machinesnelheid te automatiseren.

Een remediatieworkflow die draait om één momentopname in een rapport volstaat dus niet meer. Securityteams hebben een workflow nodig die blootstellingen continu scant en beheert.

Het goede nieuws is dat Gartner een nieuw securitykader heeft ontwikkeld dat reactief scannen op kwetsbaarheden omzet in een proactieve, risicogedreven strategie: Continuous Threat Exposure Management (CTEM).

In deze gids leest u wat CTEM is, hoe het werkt en hoe u een remediatiestrategie van 90 dagen inbouwt in de mobilisatiefase.

Wat is Continuous Threat Exposure Management (CTEM)? Een kort overzicht

Gartner definieert Continuous Threat Exposure Management (CTEM) als een “programmatische discipline om de blootstelling van een organisatie aan cyberdreigingen continu te beoordelen en zo geprioriteerde, gevalideerde en op de business afgestemde remediatie en risicoreductie aan te sturen.”

Eenvoudig gezegd is het een kader om dreigingsblootstelling proactief te beheren en te beperken. In plaats van elk kwartaal op kwetsbaarheden te controleren en te testen, behandelt CTEM blootstelling als een bewegend doel dat continu moet worden gevolgd, geprioriteerd en beperkt. Het combineert vulnerability management, attack surface management en postuurvalidatie in één operationeel model.

De CTEM-cyclus bestaat uit vijf fasen:

1. Scoping: bepaalt welke systemen, omgevingen en processen de grootste operationele impact hebben als ze worden gecompromitteerd.
2. Discovery: identificeert continu assets en mogelijke blootstellingen in alle relevante omgevingen. Denk daarbij aan cloud, on-premises infrastructuur, SaaS-platformen, identiteits- en toegangssystemen, endpoints en applicaties.
3. Prioritering: rangschikt risico’s op basis van misbruikbaarheid, bedrijfsimpact en de waarschijnlijkheid van een aanvalspad. Hier komen signalen uit vulnerability management binnen, zoals CVSS, EPSS en de KEV-status.
4. Validatie: simuleert echte aanvalspaden om vast te stellen of de bestaande maatregelen een aanvaller daadwerkelijk kunnen stoppen. Penetratietesten is een belangrijke validatieactiviteit in een CTEM-cyclus: securityteams bevestigen zo welke blootstellingen echt misbruikbaar zijn, brengen aanvalspaden naar kritieke assets in kaart en controleren of de verdedigingsmaatregelen werken zoals bedoeld.
5. Mobilisatie: remediatie-inspanningen worden gecoördineerd, gevolgd en tot afsluiting gebracht binnen security- en IT-teams.

Een van de grootste beperkingen van traditioneel pentesten is dat het slechts een momentopname is. Het is nuttig om misbruikbare kwetsbaarheden op te sporen, maar als de omgeving na de beoordeling blijft veranderen (en dat gebeurt doorgaans) mist u nieuwe blootstellingen.

CTEM lost dit probleem op door pentests te behandelen als continue validatie in plaats van als een losstaande beveiligingsoefening. Zo blijven de bevindingen uit pentests verbonden met de rest van de cyclus.

Het remediatieprogramma van 90 dagen dat hierna volgt kan bijvoorbeeld in de mobilisatiefase worden opgenomen. In plaats van alleen een rapport over te dragen en remediatietickets te volgen gebruikt u de gevalideerde bevindingen om het risico in de hele organisatie merkbaar te verlagen.

Het doel is niet alleen de bevindingen uit de laatste pentest af te sluiten, maar de blootstellingen te verkleinen die het grootste risico voor de business vormen. Naarmate het remediatieprogramma vordert, kunnen security- en IT-teams terugkeren naar de fasen Discovery, Prioritering en Validatie om nieuwe risico’s op te sporen en de CTEM-cyclus voort te zetten.

Zo brengt u CTEM-conforme penetration testing remediation in 90 dagen in de praktijk

In een CTEM-programma worden blootstellingen geprioriteerd op basis van hun misbruikbaarheid, bedrijfsimpact en hun rol in mogelijke aanvalspaden. Blootstellingen met een hoog risico krijgen onmiddellijk aandacht, terwijl kwesties met een gemiddeld tot laag risico worden doorgeschoven naar een gestructureerd remediatieplan van 90 dagen.

De termijn van 90 dagen voorkomt dat bevindingen met een lagere prioriteit uitgroeien tot een achterstand, doordat de hele remediatie-inspanning urgentie krijgt. Teams krijgen zo een praktische deadline om kleinere bevindingen te beoordelen, te verhelpen en te beperken terwijl de CTEM-cyclus doorloopt. Daarmee wordt elke bevinding uit een pentest ook echt opgelost in plaats van op de lange baan geschoven.

📌Voorwaarden:

• Definitief pentestrapport met ernstbeoordelingen (idealiter CVSS v4.0-vectoren en niet slechts één score) en bewijs
• Exploitcontext per bevinding: de status in de CISA Known Exploited Vulnerabilities (KEV) en indien mogelijk de waarschijnlijkheid volgens het Exploit Prediction Scoring System (EPSS)
• Classificatie van assets en gegevens om technisch risico te vertalen naar bedrijfsimpact
• Aangewezen eigenaren voor remediatie, validatie en goedkeuring van wijzigingen
• Een werkruimte in het ticketsysteem en een gedeelde bewijsmap voor de resultaten

Stap 1: standaardiseer pentestrapporten en wijs eigenaarschap toe

Pentestresultaten komen vaak binnen in meerdere formaten, met uiteenlopende ernstbeoordelingen, inconsistente naamgeving en soms overlappende bevindingen. Door uw bevindingen te standaardiseren met ID’s, ze aan assets te koppelen en ze in te delen op CWE of risico, ontstaat schone documentatie waarop u toekomstig remediatiewerk kunt baseren.

Aanbevolen actieplan:

1. Importeer alle bevindingen: gebruik ITSM-software om pentestresultaten en blootstellingen die tussen de tests via continue discovery en scanning naar boven komen centraal op te slaan en te volgen.
2. Wijs een uniek ID toe: door elke gevonden kwetsbaarheid een unieke identificatie te geven verloopt het volgen van detectie tot validatie soepeler.
3. Label items met gelaagde risicocontext, niet alleen met ernst: noteer de CVSS v4.0-vector, de EPSS-waarschijnlijkheid en de CISA KEV-status van de getroffen assets. Een kwestie met CVSS 9.8 zonder bewijs van misbruik in de praktijk en zonder blootstelling aan internet is iets heel anders dan een kwestie met CVSS 7.5 die actief wordt misbruikt op een systeem dat aan het internet hangt.
4. Wijs twee rollen toe per bevinding: een eigenaar die de oplossing doorvoert en coördineert en een verificateur die de resolutieworkflow bevestigt en vastlegt.
5. Leg wijzigingsvensters en afhankelijkheden vast: dat beperkt conflicten rond uitvaltijd en zorgt dat oplossingen aansluiten op onderhoudsschema’s.

Door uw bevindingen te standaardiseren met ID’s, ze aan assets te koppelen en ze in te delen op CWE of risico, ontstaat schone documentatie waarop u toekomstig remediatiewerk kunt baseren.

Stap 2: bouw een driedelige remediatieworkflow van 90 dagen

Pentests kunnen urgente kwetsbaarheden combineren met kwesties met een laag risico, waardoor remediatieworkflows overbelast raken en deadlines of werk blijven liggen. Een aanpak in golven van 90 dagen helpt de bevindingen te ordenen, maar de volgorde moet worden bepaald door misbruikbaarheid in de praktijk en niet alleen door technische complexiteit.

Aanbevolen actieplan:

1. Dag 0 tot 7: behandel alles wat op de KEV-lijst staat of actief wordt misbruikt direct in plaats van te wachten op golf één. Staat een bevinding in de KEV-catalogus van CISA of heeft die een hoge EPSS-score, dan moet u die als noodwijziging behandelen, ongeacht in welke categorie die anders zou vallen.
2. Dag 1 tot 30: pak eenvoudig misbruikbare kwetsbaarheden aan die snel te verhelpen zijn, zoals ontbrekende patches, verkeerd geconfigureerd beleid, zwakke referenties of blootgestelde beheerportalen.
3. Dag 31 tot 60: verhelp kwetsbaarheden die complexe aanpassingen op codeniveau en afstemming tussen ontwikkelaars, netwerkengineers en testers vergen. Voer de tests uit tijdens onderhoudsvensters om de impact te beheersen.
4. Dag 61 tot 90: sluit items met een laag risico af, voer configuratieverharding door, roteer referenties en rond uw documentatie af.
5. Zet het plan vast in de agenda van uw team: leg start- en einddatums vast per golf en stem die af op de release- en wijzigingscycli van uw organisatie. Behandel deze datums als afspraken tussen teams en zorg dat ze zichtbaar zijn voor alle belanghebbenden.

Stap 3: maak een wijzigingschecklist per pentestbevinding

Gestandaardiseerde checklists sturen uw strategie voor remediatie van kwetsbaarheden en de wijzigingen die u doorvoert in live klantomgevingen. Enkele stappen om te overwegen:

1. Bepaal de voorgestelde wijziging van de maatregel. Beschrijf welke wijzigingen nodig zijn om de gevonden kwetsbaarheden aan te pakken, zoals patches, configuratie-updates, codecorrecties of beleidsaanpassingen. Noteer welke diensten, gebruikers of systemen worden geraakt.
2. Stel een testplan op. Reproduceer de kwesties zoals ze in de pentests zijn aangetroffen en definieer vervolgens de succescriteria nadat een oplossing is doorgevoerd.
3. Bereid een rollbackchecklist voor. Leg vast welke stappen technici moeten zetten wanneer een oplossing onbedoeld een systeem onderuithaalt of de prestaties van een endpoint verslechtert.
4. Voeg bewijs toe. Koppel documentatie van vóór en na de oplossing uit de pentestresultaten rechtstreeks aan het unieke ID om latere validatiestappen te ondersteunen. Leg vast wie de taakeigenaar is, wat de datum is en welke testomgeving is gebruikt, zodat de verificatie consistent blijft.

Deze stappen verkleinen de kans op gedeeltelijke oplossingen, gemiste afhankelijkheden en het risico dat u nieuwe kwetsbaarheden in klantomgevingen introduceert.

Stap 4: geef voorrang aan duidelijke risico’s uit de pentestfasen

Met een goede prioritering van kwetsbaarheden richt u zich op kwetsbaarheden met een hoog risico en sluit u kritieke aanvalsvectoren direct af. Neem bijvoorbeeld deze stappen:

Aanbevolen actieplan:

1. Definieer items met een “duidelijk risico”: spoor kwetsbaarheden op met publieke exploits, vermelding in de KEV-catalogus, hoge EPSS-scores of eenvoudige aanvalsmethoden en geef die voorrang, zoals:
   • Zwakke of ontbrekende authenticatiemaatregelen
   • Insecure direct object references (IDOR’s)
   • Injectiefouten (bijvoorbeeld SQL, command of LDAP)
   • Blootgestelde beheerinterfaces
   • Zwakke toegangscontrole
   • Prompt injection en andere AI/LLM-specifieke fouten
2. Pas een minimaal werkbare oplossing toe: gebruik minimale, gerichte oplossingen die kwetsbaarheden dichten zonder grote impact of wijzigingen in het systeem. Vermijd grootschalige herontwerpen; het doel is dreigingen snel indammen, niet stacks vervangen.
3. Documenteer en plan vervolgacties: bepaal na het dichten van de gaten welke verbeteringen of herontwerpen nodig zijn voor weerbaarheid op lange termijn. Plan die als vaste taken in latere remediatiegolven.

Deze aanpak verkort de blootstellingstijd van uw klant, verkleint de kans op compromittering en laat zien dat u daadkrachtig optreedt zodra dreigingen opduiken.

Stap 5: valideer elke doorgevoerde oplossing en leg bewijs vast

Door elke oplossing opnieuw te testen met dezelfde methode als tijdens de pentest, weet u zeker dat kwetsbaarheden gedicht zijn en niet terugkeren. Hieronder staat een validatieworkflow waarop u kunt voortbouwen:

1. Reconstrueer de pentestomstandigheden (bijvoorbeeld tools, payloads of requests).
2. Voer dezelfde aanvalssimulatie of exploit uit om te controleren of uw oplossing werkt. Let op het gedrag van het systeem om te bepalen of er nog indicators of compromise of kwetsbaarheden zijn; ontbreken die, dan is de kwetsbaarheid gedicht.
3. Bewaar testbewijs van vóór en na, zoals portaaluitvoer, schermafbeeldingen of netwerktraces, waaruit blijkt dat de kwetsbaarheid is verholpen. Label deze artefacten en koppel ze aan het unieke ID van de bevinding in uw tracker of bewijsrepository.
4. Leg vast wie de oplossing heeft geverifieerd, wat de validatiedatum is en welke tools zijn gebruikt. Noteer testnotities of observaties die de oplossing in detail kunnen toelichten.

Bovendien wordt bewijs uw verdedigbare vastlegging dat risico’s echt zijn gesloten en niet elders in het systeem zijn beland.

Stap 6: leg uitzonderingen vast in uw remediatieworkflows

Sommige kwetsbaarheden zijn niet binnen 90 dagen te dichten. Door die tekortkomingen als uitzondering vast te leggen, blijven uitgestelde items in beeld. De onderstaande stappen voor uitzonderingsbeheer geven inzicht in deze workflow:

1. Wijs een eigenaar aan en leg de reden voor de uitzondering, de tijdelijke oplossing en de vervaldatum vast.
2. Houd een korte evaluatiebijeenkomst of loop een checklist door, bij voorkeur wekelijks, om het volgende te bevestigen:

• • Controleer of tijdelijke oplossingen nog effectief zijn.
  • De omstandigheden zijn niet zodanig veranderd dat remediatie alsnog mogelijk is.
  • Vervaldatums zijn bijgewerkt of op de juiste manier afgesloten.

3. Kan een kwetsbaarheid niet permanent worden verholpen, escaleer die dan voor een ontwerpreview om de systeemarchitectuur te plannen of wijzigingen in de bedrijfsacceptatie van het risico te behandelen.

Door niet-verholpen kwetsbaarheden te volgen, van een eigenaar te voorzien en te blijven beoordelen tot er een permanente oplossing is, beperkt u blinde vlekken in klantomgevingen.

Stap 7: pak kwetsbaarheden in webapplicaties systematisch aan

Kwetsbaarheden in webapplicaties volgen meestal herhaalbare patronen: zodra u een kwestie hebt gezien, vindt u die waarschijnlijk op meerdere routes, in meerdere modules of applicaties terug. Door dit soort kwetsbaarheden systematisch aan te pakken met goed doordachte wijzigingen, verhelpt u verwante kwesties in één keer.

Aanbevolen actieplan:

1. Groepeer vergelijkbare bevindingen: deel webgerelateerde bevindingen in op type en bepaal waar ze steeds terugkeren, bijvoorbeeld via gedeelde API’s, templates of middleware. Neem ook endpoints met AI/LLM-integratie mee in die groepering, aangezien die steeds vaker een gedeelde component vormen in meerdere applicaties.
2. Benoem het gemeenschappelijke patroon: begrijp het waarom achter de gevonden kwetsbaarheid. Zijn bijvoorbeeld meerdere endpoints kwetsbaar voor SQL-injectie, dan ligt het echte probleem mogelijk bij niet-gevalideerde query-invoer of bij ontbrekende sanitatie in de datalaag.
3. Centraliseer de distributie van oplossingen: pas maatregelen toe in gedeelde codepaden of via centrale componenten, zodat de oplossing automatisch in de hele omgeving wordt uitgerold.
4. Controleer de effectiviteit en leg oplossingen vast: documenteer en hertest oplossingen op alle betrokken endpoints of applicaties om te bevestigen dat de hele klasse kwetsbaarheden is afgedekt.

Stap 8: versterk uw pentest-roadmap door gaten te dichten

Naast externe exploits kunnen aanvallers uw verdediging omzeilen via interne dreigingen, zoals accounts met te veel rechten, blootgestelde referenties of zwakke configuraties. Bekijk het onderstaande actieplan voor het inzetten van toegangscontroles:

1. Dwing toegang volgens het minste voorrecht af. Beoordeel bijvoorbeeld de rechten van alle betrokken gebruikers, serviceaccounts en systemen uit de pentest. Controleer of alle accounts en API’s uitsluitend de rechten hebben die voor hun functie nodig zijn.
2. Roteer en bescherm referenties. Roteer direct alle mogelijk blootgestelde wachtwoorden, API-sleutels, SSH-sleutels of tokens. Breng gevoelige referenties onder in een beveiligde kluis en dwing sterke authenticatie af in systemen, zoals MFA voor accounts met verhoogde rechten.
3. Verhard uw baselines. Toets systeem- en applicatieconfiguraties aan beveiligingsbaselines en pas consistente verhardingstemplates toe op vergelijkbare endpoints om configuratiedrift te voorkomen.
4. Schakel logging en monitoring in. Zet logging aan voor identiteitsacties, commando’s met verhoogde rechten en authenticatiepogingen en koppel deze logs om afwijkingen te detecteren.

Zodra een aanvaller toegang heeft, kunnen bepaalde typen kwetsbaarheden hem in staat stellen tot laterale beweging en tot het verkrijgen van rechten om uw verdediging uit te schakelen.

Stap 9: breid de reikwijdte van remediatie uit naar AI- en LLM-systemen

Nu de AI Act van de EU op 2 augustus 2026 van kracht wordt, moeten applicaties of agents met AI-integratie een eigen regel krijgen in het remediatieprogramma. Deze bevindingen mogen nooit samen met uw algemene achterstand aan webapplicaties worden behandeld. Prompt injection, onveilige rechten voor tools en modelmanipulatie zijn afzonderlijke aanvalsklassen die standaard pentesten vaak mist, tenzij ze expliciet worden benoemd.

Aanbevolen actieplan:

1. Neem AI-systemen expliciet op in de testscope: ga er niet van uit dat een algemene pentest van een webapplicatie prompt injection, onveilige toolrechten voor agents of modelmanipulatie afdekt. Daarvoor zijn aparte testcases nodig
2. Volg AI-bevindingen net als elke andere bevinding: wijs een uniek ID, een eigenaar, een verificateur, bewijs en een hertest toe.
3. Let eerst op de basis van toegangscontrole: het merendeel van de AI-gerelateerde beveiligingsincidenten is terug te voeren op gewone fouten in toegangscontrole.
4. Koppel bevindingen aan de AI Act (of andere toepasselijke regelgeving) naast uw overige compliance-koppelingen.

Stap 10: voer verificatierondes uit voordat u de pentestremediatie afsluit

Na verloop van tijd kunnen oplossingen verwateren, kunnen updates kwetsbaarheden opnieuw introduceren of kunnen afhankelijkheden ongemerkt verschuiven. Met deze workflow voorkomt u die scheefgroei:

1. Herhaal de oorspronkelijke teststappen, zoals beschreven in stap 5, om te bevestigen dat elke kwetsbaarheid verholpen blijft en de resultaten overeenkomen met eerder bewijs.
2. Test verwante systemen of maatregelen waarop het remediatiewerk invloed kan hebben gehad.
3. Registreer slaag- en faalpercentages, heropende bevindingen en leg nieuwe afwijkingen vast die naar boven komen.
4. Heropen of escaleer waar nodig. Leg bijvoorbeeld alle kwesties die tijdens de ronde worden gevonden direct vast voor opvolging. Gebruik de nieuwe inzichten om uw verhardingsstrategie voor de volgende cyclus aan te scherpen.

Een laatste verificatieronde voordat uw strategie van 90 dagen afloopt bevestigt dat elke afgesloten bevinding verholpen blijft.

Stap 11: publiceer bewijspakketten ter ondersteuning van uw remediatiestrategie

Een maandelijks bewijspakket van één pagina dient als bewijs richting de klant van uw workflows voor penetration testing remediation. Nu NIS2 en DORA allebei actief worden gehandhaafd, mogen deze pakketten niet alleen samenvatten; ze moeten rechtstreeks verwijzen naar de kaders waaraan auditors of toezichthouders toetsen.

Aanbevolen actieplan:

1. Vat de belangrijkste cijfers samen: vermeld het aantal open en gesloten bevindingen, trends in risicoafbouw en eventuele uitzonderingen en heropende kwetsbaarheden.
2. Koppel bewijs aan bevindingen: verwijs naar de validatieartefacten die tijdens de remediatie zijn verzameld en zorg dat elk gegeven herleidbaar is tot het unieke ID, zodat alles auditeerbaar blijft.
3. Koppel bewijs aan het toepasselijke kader: voor NIS2 betekent dit meestal dat u gestructureerd testen en remediëren aantoont onder artikel 21. Maak bij DORA onderscheid tussen bewijs van reguliere remediatie en Threat-Led Penetration Testing onder TIBER-EU. Verwijs bij PCI DSS 4.0 of ISO 27001 naar de specifieke maatregel waaraan elk bewijsstuk voldoet.
4. Neem de strategie voor de volgende maand op: schets wat er in de volgende remediatiegolf komt, zoals verificaties, ontwerpreviews of verhardingsstrategieën.
5. Houd een consistente opmaak aan: houd de pakketten goed leesbaar door steeds dezelfde opmaak te gebruiken. Zo wordt uw rapportage herhaalbaar en kunt u die eenvoudig opstellen en per kwartaal vergelijken.

Voorbeeld van een automatiseringsmoment in penetration testing remediation

Automatisering ondersteunt de stappen in pentestremediatie door workflows te versnellen en tegelijk consistentie, verantwoording en bewijs in uw cyclus van 90 dagen te behouden.

• Plan nachtelijke taken om bevindingen te synchroniseren, inclusief KEV- en EPSS-updates uit trackers, om burn-downgrafieken bij te werken en vervaldatums van uitzonderingen te controleren.
• Markeer automatisch ontbrekende validatieartefacten of uitzonderingen die hun vervaldatum naderen.
• Stel wekelijkse scripts in om klassen met een hoog risico te onderzoeken en te bevestigen dat de oplossingen nog standhouden.
• Stuur nieuwe testresultaten en logs naar centrale bewijsrepository’s.

Automatiseer uw pentest-roadmap met NinjaOne

NinjaOne stroomlijnt workflows voor penetration testing remediation door het verzamelen van bewijs, het volgen van voortgang en de rapportage in uw strategie van 90 dagen te automatiseren. De tools automatiseren validatie, documentatie en vulnerability management, waardoor technici minder handwerk hebben zonder dat het beveiligingsbeleid van uw klant eronder lijdt.

• Discovery: gebruik taken die via beleid worden ingepland om het verzamelen van bewijs te automatiseren, assets te labelen met het bevindings-ID en maandelijkse bewijspakketten aan de documentatie te koppelen. De functie Geplande rapporten van NinjaOne verzamelt en verspreidt bewijs automatisch over tenants, terwijl labeling van IT-activa endpoints in klantomgevingen volgt en ordent.
• Prioritering: de dienst vulnerability management van NinjaOne brengt kwetsbaarheden in beeld met hun CVE- en CVSS-scores en voegt daar KEV-status en exploitcontext aan toe, zodat technici kunnen prioriteren wat echt directe aandacht nodig heeft in plaats van een kale lijst op ernst af te werken.
• Mobilisatie: patchautomatisering kan zo worden ingericht dat stabiele patches worden uitgerold of dat urgente patches worden gemarkeerd die onmiddellijk aandacht vragen, waardoor pentestbevindingen rechtstreeks aan remediatie worden gekoppeld.
• Documentatietool: met NinjaOne Documentation stelt u eigen remediatie-Runbooks samen en bewaart u bewijs per tenant in een centrale Knowledge base. Dat zorgt voor consistente workflows en maakt kennisoverdracht tussen technici eenvoudiger.

Bouw een pentest-roadmap van 90 dagen om risico’s te verhelpen

Haal het maximale uit pentests door bevindingen gestructureerd op te volgen en wijzigingen met bewijs vast te leggen. Door uw bevindingen te standaardiseren, in golven te plannen, oplossingen consequent te valideren, uitzonderingen te documenteren en transparant te rapporteren, verkleint u binnen 90 dagen het werkelijke risico terwijl u het vertrouwen van belanghebbenden behoudt.

Verwante onderwerpen:

• Penetratietesten versus kwetsbaarheidsscans
• Wat is remediatie van kwetsbaarheden? Uitgelegd met voorbeelden
• Tijdlijnen voor remediatie van kwetsbaarheden: 7 beste praktijken
• Wat is een kwetsbaarheidsbeoordeling en waarom is die belangrijk?