Ten minste eens per drie jaar De toezichthouder wijst aan Het attest komt van de autoriteit

Software voor het TLPT-traject onder DORA laten maken

Threat-led penetration testing is de zwaarste testvorm in DORA, Verordening (EU) 2022/2554, en het is geen algemene plicht. Uw toezichthouder bepaalt of u zulke tests moet uitvoeren. Vanaf die aanwijzing ligt een traject vast met eigen rollen, eigen termijnen en documenten die de autoriteit stuk voor stuk goedkeurt.

Wat het regime van u vraagt

Artikel 26 van DORA legt geavanceerde tests op aan financiële entiteiten die daarvoor zijn aangewezen. Zij verrichten ten minste om de drie jaar een TLPT, en de bevoegde autoriteit kan die frequentie verlagen of verhogen. Micro-ondernemingen en de entiteiten uit artikel 16, lid 1, vallen erbuiten. Wie wel wordt aangewezen, bepaalt de autoriteit zelf, op basis van effectgerelateerde factoren, het systemisch karakter en het ICT-risicoprofiel.

De uitwerking is inmiddels vastgesteld. Gedelegeerde Verordening (EU) 2025/1190 van 13 februari 2025 verscheen op 18 juni 2025 in het Publicatieblad en bevat harde criteria. Systeemrelevante kredietinstellingen vallen eronder, net als centrale effectenbewaarinstellingen en centrale tegenpartijen. Voor betaalinstellingen ligt de drempel bij 150 miljard euro aan betalingstransacties in elk van de twee voorafgaande kalenderjaren.

De test raakt meerdere of alle kritieke of belangrijke functies en loopt op systemen die in het echt draaien. U beoordeelt zelf welke functies erin gaan, maar die uitkomst wordt gevalideerd door de autoriteit en het scoping-document gaat langs uw leidinggevend orgaan. Deze pagina gaat alleen over dat testregime. Het ICT-risicokader, het incidentenregister en het register van uitbestedingen staan op onze pagina over DORA-compliance software.

Hoe wij dit bouwen

Het traject begint met een kennisgeving van de TLPT-autoriteit en eindigt met een attest. Daartussen liggen documenten die elk hun eigen goedkeuring nodig hebben.

1
De aanwijzing en de startdocumenten

Binnen drie maanden na de kennisgeving levert u een project charter, de leider van het control team en de codenaam. Het scoping-document volgt binnen zes maanden.

2
De rollen scheiden en gescheiden houden

Control team, blauw team, testers en de aanbieder van dreigingsinformatie hebben elk hun eigen positie. Toegang loopt op need-to-know, en dat hoort een systeem af te dwingen.

3
De opleverstukken als één reeks

Scoping-document, dreigingsinformatierapport, red-teamtestplan, beide testrapporten, de samenvatting en het remediëringsplan horen bij elkaar, in één dossier met versies en goedkeuringen.

4
Bevindingen tot en met de afronding

Elke bevinding krijgt een oorzaakanalyse, een maatregel met prioriteit, een eigenaar en het risico van niet uitvoeren. Dat is wat de RTS van een remediëringsplan verlangt.

Wat de software concreet doet

Het dossier draagt het geheel. Wat u daarnaast inricht, hangt af van het aantal functies in de scope en het aantal partijen dat meedoet.

Het scoping-document met onderbouwing

Welke functies erin gaan en waarom, met de onderliggende systemen, processen en technologieën erbij. De RTS vraagt die motivering ook voor wat u buiten de scope laat.

De risicobeoordeling van de test zelf

U laat aanvallen los op productiesystemen. De beoordeling gaat over verstoring, dataschade en escalatie, en loopt door zolang de test duurt.

Toegang op need-to-know

Alleen het control team, het leidinggevend orgaan, de testers, de aanbieder van dreigingsinformatie en de autoriteit. De test krijgt een codenaam, en meer staat er niet in het systeem.

Geschiktheid van aanbieders vastleggen

Curricula vitae, certificeringen, referenties en de verzekering voor beroepsaansprakelijkheid. Die documentatie moet er zijn voordat er wordt gecontracteerd.

De termijnen van de afsluitende fase

Het red-teamtestrapport binnen vier weken, het rapport van het blauwe team uiterlijk tien weken na het einde van de actieve fase.

Van bevinding naar maatregel

Elke kwetsbaarheid krijgt een oorzaak, een maatregel, een prioriteit en een eigenaar, en sluit aan op uw auditsoftware.

Voor wie wij bouwen

De aanwijzing komt bij heel verschillende instellingen terecht. Vier situaties.

Banken en systeemrelevante instellingen

Kredietinstellingen die als mondiaal of anderszins systeemrelevant zijn aangemerkt staan in de RTS. Belangrijke kredietinstellingen mogen alleen externe testers inzetten. Zie ook software voor de financiële sector.

Betalen en elektronisch geld

Boven 150 miljard euro aan betalingstransacties in elk van de twee voorafgaande kalenderjaren komt de aanwijzing in beeld, met voor elektronisch geld een drempel van 40 miljard euro uitstaand saldo.

Bewaring, clearing en handel

Centrale effectenbewaarinstellingen en centrale tegenpartijen staan zonder drempel in de tekst; handelsplatformen komen erbij op grond van marktaandeel. Hosting hoort dan bij de vraag, via een soevereine cloud.

Verzekeraars en herverzekeraars

De RTS werkt hier in twee stappen: eerst drempels voor premies, technische voorzieningen en aandeel in de totale activa, en binnen die groep nog een tweede set.

Nog niet zeker over een groot traject?

Test je idee eerst — werkend prototype in 1 dag

Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.

Bekijk OneDayBuild →

Technologie en koppelingen

De RTS schrijft voor wat er in de documenten hoort, niet hoe ze eruitzien. Sjablonen, rollen en goedkeuringen horen instelbaar te zijn, zodat een volgende test niet bij nul begint.

Webapplicatie met rollen en rechten Sjablonen voor de bijlagen uit de RTS Versiebeheer met goedkeuringsstappen Scheiding tussen control team en blauw team Markering van gevoelige informatie Codenaam in plaats van projectnaam Register van aanbieders en referenties Termijnbewaking vanaf het einde van de testfase Bevindingen met oorzaak en prioriteit Koppeling met issue- en risicoregister Export voor de toezichthouder Onwijzigbare auditlogging Bewaartermijnen per document Hosting in de EU

Waarom Appfront

Een traject met een vaste volgorde

Wij bouwen de stappen in de volgorde die de RTS aanhoudt, met goedkeuring als voorwaarde voor de volgende. Een dossier dat die volgorde negeert, laat achteraf gaten zien.

Het attest is het sluitstuk

De autoriteit bevestigt in een attest dat de test volgens de vereisten is verricht, en onderzoekt daarvoor een lijst documenten. Die lijst hoort compleet te zijn op dat moment.

Scheiding die u kunt aantonen

Wie wat wanneer heeft gezien, is hier onderdeel van het bewijs. Wij leggen toegang en inzage vast in plaats van te vertrouwen op de afspraak dat niemand meekijkt.

Wij voeren de test niet uit

Het red team huurt u apart in, met artikel 27 als maatstaf. Wij bouwen het systeem eromheen, naast bijvoorbeeld devsecops.

Security en privacy

Een TLPT-dossier bevat de zwakke plekken van uw kritieke functies, de aanvalspaden die werkten en de systemen die daarbij zijn geraakt. Dat is de informatie waarmee iemand anders u zou kunnen aanvallen. De RTS noemt dit gevoelige informatie en laat de testmanagers rapporten vragen waarin die ontbreekt. Wij bouwen die scheiding in het document zelf, zodat zo een versie geen knipwerk achteraf wordt.

Vertrouwelijkheid is hier onderdeel van de uitkomst: de RTS noemt een inbreuk op de geheimhouding van de test als reden waarom het attest kan uitblijven. Wij zetten toegang per rol, houden het blauwe team buiten het systeem tot het control team het informeert, en leggen elke inzage vast. Hoe wij zelf met beveiliging omgaan staat in ons informatiebeveiligingsbeleid; meldingen van buitenaf lopen via ons CVD-beleid.

Veelgestelde vragen over TLPT onder DORA

Nee, het is een selectie. De bevoegde autoriteiten wijzen aan wie deze verplichting krijgt, op basis van effectgerelateerde factoren, het systemisch karakter en het ICT-risicoprofiel. Micro-ondernemingen en entiteiten onder het vereenvoudigde ICT-kader zijn uitgezonderd; de RTS vult er drempels bij in.

Ten minste om de drie jaar, zegt artikel 26 van DORA. De autoriteit kan die frequentie verlagen of verhogen op grond van uw risicoprofiel. Dat staat los van artikel 24, dat vraagt om ten minste jaarlijkse tests van de ICT-systemen achter kritieke of belangrijke functies.

Ja. Gedelegeerde Verordening (EU) 2025/1190 van 13 februari 2025 is op 18 juni 2025 bekendgemaakt en trad in werking op de twintigste dag daarna. Zij regelt de identificatiecriteria, de inzet van interne testers, de fasen en de samenwerking tussen autoriteiten.

DNB ontwikkelde TIBER-NL in 2016; de ECB stelde daarna, geïnspireerd op die aanpak, TIBER-EU op. Op 11 februari 2025 is TIBER-EU geactualiseerd om aan te sluiten op de RTS. Purple teaming werd daarbij verplicht en de rol die White Team heette, heet voortaan Control Team.

Alleen onder voorwaarden. De autoriteit moet het goedkeuren en geverifieerd hebben dat u genoeg middelen inzet en belangenconflicten uitsluit; de aanbieder van dreigingsinformatie is altijd extern. Om de drie tests schakelt u externe testers in.

De autoriteit bevestigt daarin dat de test volgens de vereisten is verricht, zodat andere autoriteiten hem erkennen. Er staan onder meer de scope en de duur van de actieve red-teamfase in. Een attest is geen goedkeuring van uw vermogen om ICT-risico te beheersen; DORA zegt dat erbij.

Wij bouwen het systeem om het traject en het bewijs heen: scoping, rollen, documenten, termijnen en opvolging. Het testen laat u doen door testers die aan artikel 27 voldoen. Voor de rest van DORA is er DORA-compliance software, voor een regulier onderzoek het ICT-beveiligingsassessment en voor het moment tijdens de test de TLPT-app.

Dat hangt af van het aantal functies in de scope, of er derde aanbieders meedoen en of het om een gezamenlijke of gepoolde test gaat. Het dossier is doorgaans het eerst bruikbaar. Wij geven een onderbouwde inschatting na de verkenning.

Weten of uw dossier het attest haalt?

Pak het scoping-document erbij en kijk of bij elke functie die u buiten de scope liet, staat waarom. Die motivering is een eis uit de RTS en het eerste waar de testmanagers naar kijken. Wij bouwen dit als los systeem en binnen een breder traject software-ontwikkeling.

Edit Content