What does the Cyber Resilience Act actually mean for your organisation if you're already working with NIS2 or ISO 27001? Here's how to align the three frameworks – and what to watch out for if your products need to reach the EU market.
If you've already got NIS2 or ISO 27001 under control, one question tends to follow quickly: what do we actually need to do on top of that for CRA?
It's a fair question – and an important one. The short answer is that your existing compliance work is worth more than you might think. But realising that value requires you to actively map what you already have, what can be reused, and what CRA adds as a genuinely new layer.
Raja Hamza Ali, Nordic GRC Advisor at NorthGRC, puts it this way:
"The three frameworks each have their own purpose and legal character, and it's important to understand them as separate layers. But that doesn't mean you need to reinvent the wheel three times. There are overlaps, and you can put them to good use."
If you've already invested serious effort in NIS2 or ISO 27001, you're starting from a strong position. But be careful not to assume that work on one framework automatically translates to CRA coverage. It doesn't – and that assumption is one of the most common reasons organisations discover gaps far too late.
"Working on NIS2 can give you the impression that your cybersecurity posture is solid across the board. And that work undoubtedly helps with CRA. But there are specific, unique requirements in CRA that aren't automatically addressed through NIS2," says Raja Hamza Ali.
Problems typically emerge when each framework lands in its own organisational silo. Raja Hamza Ali explains what that looks like in practice:
"When there's no coherence or transparency across departments, information falls through the cracks – and regulators will find those cracks in an audit."
Specifically, siloing CRA, NIS2, and ISO 27001 tends to produce four recurring problems:
A joined-up approach across all three frameworks helps you avoid these pitfalls – and ensures your products can actually reach EU customers.
It’s important to fully understand what each framework is designed to do before you can meaningfully align them.
ISO 27001 is a voluntary international standard. It gives your organisation a management system for approaching information security in a structured, repeatable way – the foundation for building and maturing an ISMS (Information Security Management System), including the measures, processes, policies, and procedures that underpin your security programme. Think of ISO 27001 as the governance engine.
NIS2 is an EU directive focused on organisational cyber resilience: governance, risk management, incident response, and the systems and services your organisation depends on. One of its most distinctive features is that it explicitly places accountability with senior leadership – who must be directly involved in, approve, and oversee cybersecurity measures. NIS2 moves cybersecurity from the IT department to the boardroom. Worth noting: as a directive, NIS2 is transposed into each member state's national law individually, which means requirements can vary across borders even though they share the same starting point.
CRA – the Cyber Resilience Act – is of a different kind. It's a regulation, meaning it applies directly and uniformly across all EU member states. And unlike NIS2, its focus isn't the organisation – it's the products. CRA sets requirements for the cybersecurity of digital products from the moment they're designed, across the full product lifecycle: planning, development, production, and ongoing maintenance. That applies to hardware, software, and the supporting solutions around them.
Standard browser-based SaaS and cloud services are generally outside CRA's scope – though there are exceptions.
"Put together, ISO 27001 gives you a mature risk management process. NIS2 strengthens your work on cyber risk, governance, and critical services. And CRA addresses the security of the actual products. The three frameworks genuinely complement each other," explains Raja Hamza Ali.
Read more here: Cloud and CRA – when does your cloud backend fall within scope?
Despite their different purposes, there is real common ground – which means there are genuine efficiency gains to be found by mapping what can be carried forward from NIS2 and ISO 27001 as you approach CRA.
You've built a strong organisational foundation. Your governance structure is in place, risk owners are identified, and your reporting processes work. All of that gives you a running start on CRA, because the organisational processes and policies CRA builds on are already there.
What's missing is the product-specific layer: risk assessments for individual products, vulnerability management, a clear view of component dependencies, defined support periods, and conformity documentation – the Declaration of Conformity and CE marking.
NIS2 lays the foundation. CRA builds on top.
With ISO 27001, you have a mature risk management process, functioning internal audits, continuous improvement cycles, and a documented ISMS. Much of that translates directly – but the certificate documents your organisation's management system, not your products. It doesn't automatically demonstrate that product X meets CRA's requirements.
ISO 27001 builds the engine for managing risk and vulnerabilities. CRA specifies how that engine must perform at the product level.
CRA fills precisely the space where organisational security meets product liability – historically one of the most significant blind spots in cybersecurity regulation.
The Act is built on the principle of security by design: security isn't something you layer on after the product is built. It has to be embedded from the design phase onward.
An example: As a minimum requirement, CRA requires manufacturers to maintain visibility over the top-level components in their products – effectively an ingredient list for software, known technically as an SBOM (Software Bill of Materials).
In practice, that's rarely sufficient.
Vulnerabilities typically hide in sub-components – the libraries and packages that your components themselves depend on. If a product contains 200 open source components and a critical vulnerability surfaces tomorrow deep inside one of them, you need to identify it immediately, assess whether it affects your product, and act. That requires knowing the full component tree – not just the top layer.
CRA requires that the process be documented, repeatable, and maintained throughout the product's entire support period.
Without that visibility, you're exposed to both significant fines and mandatory product withdrawal from the market.
The key shift is moving from three parallel compliance tracks to a single, coherent programme. You don't need to start from scratch – but you do need to actively connect what you already have.
In practice, this work is significantly more manageable when it's supported by a platform built to handle multiple frameworks within a single system, says Raja Hamza Ali:
"If you have a platform that consolidates processes, policies, and documentation – so everything is connected – it actively helps you build the overview you need to stay in control."
Mapping requirements and controls across three frameworks can feel overwhelming at the outset. But as the work progresses, a coherent picture emerges – and that's exactly the point. Because that clarity is the difference between months of duplicated effort and firefighting, and a clean path to compliance across all three frameworks.
A platform like NorthGRC, built to handle multiple regulatory frameworks in one place, can take much of that weight off your team. And if you're not sure where to start – how to map the overlaps, identify the gaps, and build real visibility across your compliance programme – our consultants are ready to help.
With over 20 years of experience helping organisations achieve operational control across complex regulatory landscapes, we've seen what works – and we can help you get there.