Penetration-testing evidence for NIS2, DORA and ISO 27001 — without data leaving the EU.

NIS2 Article 21 and the Dutch Cyberbeveiligingswet

NIS2 Article 21(2)(f) requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures.” That is a test-and-prove obligation, not a paperwork one: an annual snapshot rarely evidences that controls still work after months of change. R0 runs continuously on hardware you own and produces standing, dated, CVSS-scored evidence that controls were actually exercised and exactly how far an attacker could get — the kind of proof that answers an assessor rather than a self-declaration. In the Netherlands, NIS2 is implemented through the Cyberbeveiligingswet (Cbw), which places the burden of demonstrating effectiveness on the entity; continuous testing between formal audits keeps that evidence current instead of a year stale.

DORA, TLPT and TIBER-NL

For financial entities, DORA Articles 24–26 mandate a digital operational resilience testing programme, with threat-led penetration testing (TLPT) for significant entities on roughly a three-year cycle, carried out under the TIBER-EU framework and, in the Netherlands, TIBER-NL as overseen by De Nederlandsche Bank (DNB). A TLPT is deep but infrequent. R0 is what runs between those cycles: it re-tests the same estate continuously, keeps an append-only ledger of every action on hardware inside your own perimeter, and surfaces regressions long before the next scenario-led engagement — so the three-year cadence is a floor, not your only signal.

ISO 27001:2022 — A.8.8 and A.8.29

ISO/IEC 27001:2022 Annex A control A.8.8 covers the management of technical vulnerabilities, and A.8.29 covers security testing in development and acceptance. R0's output attaches directly to an ISMS: demonstrated attack chains rather than scanner lists, a CVSS 3.1 vector computed the same way every time, and a reproducible, replayable record an auditor can re-run. That turns “we have a vulnerability-management process” into dated evidence that the process finds and proves real, exploitable issues.

Built in the EU, for EU data residency

R0 is made and operated by ReactiveZero, a Dutch company (KVK 97512249) in Rotterdam, and it runs on hardware in your own jurisdiction. Because the model, the tooling and the evidence never leave the appliance, there is no third-country transfer to assess and no external processor holding your attack-surface data — GDPR data residency is satisfied by construction, not by a data-processing agreement. For sovereign, regulated and defence-adjacent estates, the self-hosted, air-gap-capable deployment model is the point: your data stays in the EU because it stays on your box.

Data residency, by construction

R0 is an on-prem appliance. The model, the tooling and the evidence all live on hardware you own; findings and model inference never reach a vendor cloud. For a regulated or sovereign environment that removes the hardest question — “where does our attack-surface data go?” — because the answer is “nowhere.” R0 is also air-gap capable for internal-only engagements.

What the evidence looks like

• A demonstrated attack chain per finding — not a scanner list — with the exact steps that reproduced it.
• A CVSS 3.1 vector and score computed the same way every time.
• An append-only, replayable ledger: any step can be re-run deterministically for an auditor or a retest.
• A blue-team detection checkpoint for each step, so the report improves your monitoring, not just your risk register.

R0 supports your compliance evidence; it is not a certification and does not replace a formal audit or an accredited assessor.