Wettelijke meldtermijnen beginnen niet bij het incident maar op het moment dat u het weet. Een organisatie die haar afhankelijkheden niet volgt, ontdekt iets weken later en is formeel op tijd terwijl er wekenlang een gat stond. Wij richten het proces in dat dat moment naar voren haalt.
Op vier plekken, en zelden bij het scannen zelf. Ten eerste bij het binnenhalen: er wordt gekeken naar de eigen systemen, maar niet naar de onderdelen waar de software op leunt. Ten tweede bij het wegen: een lijst wordt van boven naar beneden afgewerkt op een cijfer dat door iemand anders is bepaald voor een situatie die de uwe niet is. Ten derde bij het herstellen: er is geen afgesproken termijn, dus alles wat niet dringend voelt schuift op. En ten vierde bij het niet-herstellen — wat blijft staan, staat er zonder reden en zonder datum.
Er is een vijfde plek die minder zichtbaar is: het moment van constateren. Toezichthouders kijken daar inmiddels naar, en niet alleen of u tijdig meldde maar of u redelijkerwijs eerder had kunnen weten dat er iets speelde. Dat verschuift het zwaartepunt van het afhandelen naar het opmerken, en dat is precies het deel waar de meeste organisaties niets voor hebben ingericht.
Wij bouwen geen scanner — die bestaan en ze zijn goed. Wat wij doen is het proces eromheen: bronnen aansluiten op wat u werkelijk gebruikt, een weging die uw eigen situatie meeneemt, termijnen die haalbaar zijn, en een register voor wat u bewust laat staan. Dat leunt op een actueel componentoverzicht, sluit aan op controles in de pijplijn en op de meldplichten uit de Cyber Resilience Act en de Cyberbeveiligingswet.
De volgorde is bijna altijd dezelfde: eerst weten, dan wegen, dan afspreken. In het eerste gesprek bepalen we waar bij u het grootste gat zit.
Signalen binnenhalen over de onderdelen waar uw software op leunt, niet alleen over de servers waarop hij draait. Dat betekent koppelen aan uw componentoverzicht en aan de containerlaag eronder, met bronnen als de nationale kwetsbaarhedendatabank en open registers. Het doel is het moment van constateren naar voren halen, want daar begint elke wettelijke klok en daar zit de meeste onbeheerste tijd.
Een gepubliceerde ernstscore zegt iets over de kwetsbaarheid en niets over uw situatie. Een kritieke fout in een onderdeel dat u wel meelevert maar nooit aanroept, is minder dringend dan een matige fout in het hart van uw inlogproces. Wij combineren drie dingen: hoe ernstig het volgens de bron is, of het actief wordt misbruikt, en waar het bij u zit. Dat laatste kunt u alleen beantwoorden als u weet welke onderdelen u gebruikt en waarvoor.
Een hersteltermijn per ernstniveau die uw team ook echt haalt, een register voor alles wat bewust blijft staan — met de reden, de tussenmaatregel en een herbeoordelingsdatum — en de koppeling naar uw meldplichten. Wij richten het zo in dat de informatie die een melding vraagt uit hetzelfde proces komt: wat is gevonden, wanneer wisten we het, welke versies zijn geraakt, welke maatregel is genomen.
Een proces dat draait zonder dat er iemand elke ochtend een lijst hoeft door te lopen, plus de vastlegging die u bij een audit nodig heeft.
Vier situaties die wij terugzien bij organisaties die ons hiervoor benaderen. Meestal is er een aanleiding en blijkt het proces breder te ontbreken.
De Cyberbeveiligingswet of, voor wie een product op de markt brengt, de Cyber Resilience Act legt u korte termijnen op die beginnen bij constateren. Zonder een proces dat signalen vroeg binnenhaalt, is die termijn niet te halen, hoe goed uw meldprocedure ook op papier staat.
Er wordt gescand, er komt een lijst uit, en die lijst wordt elke maand langer. Het probleem is bijna nooit het aantal maar het ontbreken van twee dingen: een weging die zegt wat eerst moet, en een datum voor wat blijft staan.
Een kwetsbaarheid in een veelgebruikt onderdeel haalde het nieuws, en dat was het moment waarop bij u de vraag ontstond of u het gebruikt. Dat is te laat en het is te voorkomen.
Bij een audit is het eerste wat gevraagd wordt niet de lijst met opgeloste bevindingen maar het register van wat bewust blijft staan, met de onderbouwing. Dat is precies wat in de meeste organisaties niet bestaat.
Wat wordt er nu gescand, welke bronnen komen binnen, en hoe lang duurde het bij de laatste grote melding voordat er een onderbouwd oordeel lag. Die laatste vraag legt meer bloot dan een inventarisatie van gereedschap, en hij is het ijkpunt voor de rest van het traject.
We koppelen de signalen aan wat u werkelijk gebruikt: uw componentoverzicht, de containerlaag, uw ingekochte software en de leveranciers die zelf melden. Waar dat overzicht ontbreekt, beginnen we daar, want zonder die lijst is elke melding een zoekopdracht.
We combineren ernst, bekend misbruik en de plek in uw landschap tot een voorsortering, en toetsen die aan de bevindingen van de afgelopen periode: had deze volgorde u de goede kant op gestuurd? Dat is een kort experiment dat veel discussie voorkomt.
Hersteltermijnen per ernstniveau, afgesproken met de mensen die ze uitvoeren en niet alleen met wie erover beslist. Daarnaast het register voor wat blijft staan, met reden, tussenmaatregel en herbeoordelingsdatum. Zonder die datum groeit elke lijst.
De koppeling naar uw meldplichten, een keer oefenen met een realistisch scenario, en een overdracht aan uw team. Daarna een evaluatie waarin we de tijd tot een onderbouwd oordeel afzetten tegen de nulmeting.
Wat security-officers, IT-managers en ontwikkelteams ons vragen voordat zij hiermee beginnen.
Een kennismaking van een half uur, vrijblijvend. Vertel hoe lang het bij de laatste grote melding duurde voordat u wist of het u raakte, dan zeggen we waar wij zouden beginnen — ook als we uiteindelijk niet samenwerken.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
