Wat gebeurt er als een externe onderzoeker een kwetsbaarheid in jouw systeem vindt? Zonder een gepubliceerd responsible-disclosure-beleid (ook wel coordinated vulnerability disclosure) heeft die persoon geen veilige manier om het te melden — en jij geen proces om het op te vangen. De Europese Cyber Resilience Act (CRA) en steeds meer enterprise-contracten vereisen zo’n proces, en zonder is je ISO 27001-incidentmanagement incompleet.
Waarom dit nu een eis is
Twee ontwikkelingen maken responsible disclosure van een “nice to have” een verplichting. Ten eerste de CRA, die van fabrikanten van producten met digitale elementen verlangt dat ze kwetsbaarheden gedurende de levensduur opvangen en afhandelen. Ten tweede de inkoopvoorwaarden van grote klanten, die steeds vaker een meldkanaal en een afhandelproces eisen. Ontbreekt dat, dan mis je aantoonbare due diligence — precies wat een auditor of opdrachtgever controleert.
Het minimale beleid
Je hoeft geen bug-bountyprogramma met beloningen op te tuigen. Een werkbaar beleid bevat vier dingen:
- Contact: een duidelijk kanaal, zoals een security@-adres of een speciaal meldformulier, dat vindbaar is.
- Scope en safe harbour: welke systemen vallen eronder, en de toezegging dat je onderzoekers die zich netjes gedragen niet juridisch vervolgt.
- SLA: je bevestigt ontvangst binnen bijvoorbeeld 48 uur, en je koppelt een hersteltermijn aan de ernst van de melding.
- Registratie: meldingen worden tickets, geen losse e-mails die in iemands inbox verdwijnen.
Koppel dit aan je incidentmanagementproces en je ISMS.
Publiceer het waar mensen het zoeken
Een disclosure-beleid dat niemand kan vinden, bestaat niet. Zet het op een vaste, logische plek op je website (bijvoorbeeld /responsible-disclosure of via een security.txt-bestand). Onderzoekers, maar ook auditors en klanten, zoeken hier actief naar. De aanwezigheid van een publiek beleid is op zichzelf al een positief signaal van volwassenheid.
Van melding naar herstel
Het beleid is het begin; de afhandeling is waar het om draait. Zorg dat elke melding dezelfde route volgt: bevestigen, beoordelen op ernst, koppelen aan je vulnerability- en patchproces, herstellen binnen de afgesproken termijn, en de melder informeren. Een melding die netjes is afgehandeld en gedocumenteerd, is sterk bewijs dat je proces werkt — sterker dan een mooi beleidsdocument zonder praktijk.
Oefen het proces
Net als bij incidentrespons geldt: een proces dat nooit is gebruikt, is een aanname. Stuur eens per jaar een fictieve melding via je eigen kanaal en kijk of de keten werkt — komt de mail aan, wordt er een ticket aangemaakt, wordt de SLA gehaald? Leg de uitkomst vast en neem twee kengetallen mee in je management review: het aantal meldingen en de gemiddelde hersteltijd. Zo laat je zien dat het proces leeft.
Veelgemaakte fouten
- Alleen een e-mailadres zonder proces erachter — meldingen verdwijnen dan in een inbox.
- Geen safe harbour — zonder de toezegging niet te vervolgen, melden serieuze onderzoekers liever niet.
- Beleid niet publiceren — een intern document helpt de buitenwereld niet en telt niet als kanaal.
- Nooit oefenen — je ontdekt een kapot meldkanaal het liefst met een testmelding, niet met een echte 0-day.
Aan de slag
Zet deze week een security@-adres op, schrijf een korte beleidspagina met scope, safe harbour en SLA, en publiceer die. Koppel binnenkomende meldingen aan je incidentproces. Daarmee dek je een concrete CRA- en klanteis af. Meer weten over incidentmanagement? Bekijk onze pagina over ISO 27001 of doe de gratis readiness-scan.