The European Union's NIS2 Directive and Cyber Resilience Act represent the most significant expansion of cybersecurity regulatory requirements in the past decade. NIS2 broadens the scope of obligated entities to include nearly all medium and large organisations across 18 critical sectors, while the CRA introduces mandatory cybersecurity requirements for products with digital elements throughout their entire lifecycle. Together, these instruments fundamentally alter the compliance landscape for any organisation operating within or selling into the EU market. The penalties for non-compliance are substantial: up to €10 million or 2% of global annual turnover under NIS2, and market withdrawal provisions under the CRA.
Regulatory Intent vs. Technical Reality
The regulatory text of both instruments is intentionally high-level, prescribing outcomes rather than specifying technical implementations. NIS2 requires "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risk, while the CRA mandates that products be "delivered without known exploitable vulnerabilities" and "secure by default." The gap between this regulatory intent and actual technical implementation is where most organisations will struggle. Transposition into national law introduces further variability, as each member state interprets the directive's requirements through the lens of its existing regulatory infrastructure. Without a structured mapping exercise, organisations risk investing heavily in controls that satisfy the letter of the regulation while leaving substantive exposure paths unaddressed.
Mapping Requirements to Controls
Effective compliance requires a systematic translation of regulatory requirements into technical control specifications. This mapping must account for the organisation's specific risk profile, sector-specific guidance, and the maturity level of existing security infrastructure. For NIS2, Article 21 requirements must be decomposed into implementable controls across risk management, incident handling, business continuity, supply chain security, and cryptography. For the CRA, Annex I requirements must be mapped to the product development lifecycle, covering threat modelling, vulnerability handling, secure defaults, and post-market monitoring. A self-assessment framework that maintains bidirectional traceability between regulatory articles and technical controls provides the auditability that both regulators and internal governance functions require.
Consequences and Preparedness
The enforcement timeline is not distant. NIS2 transposition deadlines have passed in most member states, and supervisory authorities are actively developing audit and enforcement methodologies. The CRA enters its phased application starting in 2027, with product categories being brought into scope progressively. Organisations that treat these requirements as a paperwork exercise will find themselves exposed both to regulatory sanction and to the underlying security risks that the regulations are designed to mitigate. The most pragmatic approach is to use the regulatory driver as an opportunity to conduct a genuine security improvement programme, ensuring that compliance outputs are a natural consequence of meaningful risk reduction rather than a substitute for it.
Kryvasis has developed a regulatory-to-technical mapping methodology that provides organisations with a clear, auditable path from NIS2 and CRA requirements to implementable controls, measurable outcomes, and continuous compliance monitoring.