Completing Compliance with Evidence : A Bottom-Up Approach to NIS2, DORA, and the Cyber Resilience Act

A Paradigm Shift for Cybersecurity

The approach proposed here does not seek to replace the documentary approach, but to complement it with another source of evidence. The idea is to occasionally reverse the direction of reading: rather than starting from the legal article, start from a verifiable technical question: Can an attacker gain access to the information system? Can they exfiltrate sensitive data ? Do we detect it ? Can we recover from it and in how much time? and then connect the answer obtained to the requirements it documents. Compliance then also rests on elements that are measured, not only declared.

The regulatory context makes this shift no longer merely desirable but inevitable: the three structuring texts of the moment now explicitly require demonstrated resilience.

Target Regulatory Requirements

1. NIS2 (Directive EU 2022/2555). Mandates risk-management measures (Article 21), incident notification under time constraints, and  a point often underestimated  personal liability of management bodies. A "documented" but ineffective measure is no longer covered, it is legal exposure for the executive who signed off on it.
2. DORA (Regulation EU 2022/2554). This is the text that most explicitly opens the door to technical evidence. Beyond ICT risk management, it provides for an operational resilience testing program, including  for significant entities  Threat-Led Penetration Testing (TLPT) inspired by the TIBER-EU framework. Offensive testing thus finds a direct regulatory footing here, making it a natural entry point for an evidence-based approach.
3. Cyber Resilience Act (Regulation EU 2024/2847). Shifts the burden toward manufacturers of products with digital elements: security by design, documented vulnerability management across the entire lifecycle, SBOM (Software Bill of Materials), and CE marking conditioned on these obligations. Here too, a self-declaration will not be enough to bear product liability: a technical chain of evidence is needed (secure build, composition analysis, CVE handling, configuration audit, code audit, and architecture audit).

These three regulatory regimes share the same fundamental requirement: resilience must be attested by verifiable elements, and not merely declared.

The Audits That Can Objectivize Maturity

Meeting these new requirements means going beyond documentation. Here is a panel of technical assessments, classified by demonstrated defensive capability. Each produces dated, reproducible, and usable evidence.

The distinguishing criterion against classic GRC: none of these forms of evidence is declarative. Each answers a testable assertion with a measured, timestamped, and replayable result.

Synacktiv's Expertise in the Service of Compliance

At Synacktiv, we help organizations translate the requirements of NIS2, DORA, and the Cyber Resilience Act into technical assessments tailored to their challenges. Our teams work in particular to:

1. Assess the robustness of information systems through penetration testing and Red Team exercises;
2. Support financial institutions in their operational resilience efforts and advanced security exercises;
3. Audit the security of digital products through code analysis, reverse engineering, and vulnerability research;
4. Deliver technical results that can be used by security teams, management, and supervisory authorities alike.
5. Conduct a thorough analysis of the compromised systems to understand the attack vector, determine the scope of the attack, and assess the impact of the attack.

The goal is simple: to provide an objective view of the real level of security and to enable organizations to demonstrate their compliance in a tangible way.

How to Try the Methodology

The approach can unfold in five steps. The aim: that a single piece of technical evidence can, as far as possible, document several requirements at once, test once and map to several frameworks.

1. Translate requirements into testable assertions. Rather than rephrasing the legal article into a policy, you can break it down into a verifiable question: "DORA calls for resilience testing" becomes "did our last exercise allow us to detect an exfiltration on the critical perimeter?".
2. Anchor these assertions to a technical framework. MITRE ATT&CK for offense and detection, CIS benchmarks for configuration, CRA lifecycle requirements for the product. This provides a common language between the technical team and the auditor.
3. Execute and produce the evidence. Each test generates a usable artifact: TLPT report, ATT&CK coverage matrix, timestamped restoration log, SBOM, CI scan result.
4. Map up to an evidence matrix. Each artifact can be mapped to controls (ISO 27002:2022) and then to the corresponding NIS2/DORA/CRA articles. The result is a matrix where, alongside the usual documentary evidence, you also find elements drawn from real tests.
5. Embed the approach over time. BAS and CI/CD integration make it possible to move, gradually, from a one-off check to more regular validation. Compliance then rests on a snapshot that is refreshed more often than just at audit cadence.

On audit day, the organization can thus present, in addition to its documentary corpus, a set of measured elements, each of which points to a test that can, if needed, be replayed.

Compliance Grounded in Technical Evidence

Why is this approach worth considering?

Without claiming it to be the one "right" method, several factors argue for exploring this approach as a complement to classic GRC.

1. It aligns with the direction of the regulations. DORA gives offensive testing (TLPT) a regulatory footing; the CRA emphasizes the SBOM and vulnerability tracking. Holding technical evidence seems consistent with this evolution.
2. It may reduce certain exposures. Under NIS2, showing that a measure actually works offers more tangible support than a mere declaration; under the CRA, a technical chain of evidence tends to better underpin product liability.
3. It can be more efficient. A well-mapped piece of technical evidence is meant to serve several frameworks (ISO/IEC, NIS2, DORA, CRA) at once, which can limit redundancy and bring security and compliance teams together around a single artifact.

As a complement to the classic approach, a risk-analysis-based method makes it possible to identify critical perimeters upstream, thereby giving the bottom-up approach its full relevance. This articulation creates a virtuous cycle: GRC draws on technical reality to gain precision, while the technical side finds in GRC a framework that gives it coherence and effectiveness, thereby optimizing evidence collection and resource allocation.