CRA and ISO 9001: what to hook onto the quality system and what to build
Updated 12 August 2026·6 min read·Alberto Scarpa
Most industrial manufacturers already have an ISO 9001 certified quality management system. It’s a real advantage on the CRA, you already have the organisational backbone the regulation presupposes, but only if you know which mechanisms you can reuse and which you have to build from scratch.
This is the map: what I hook onto the existing quality system, what I have to build new, and where the 9001 helps more than it seems. In brackets the references: articles and annexes of Regulation (EU) 2024/2847 (CRA) for the obligations, clauses of ISO 9001:2015 for the quality system. Where I interpret or advise, I flag it. I assume the general picture of the CRA is known; if you need it, the starting point is The CRA in one hour.
What really hooks on
The CRA doesn’t ask you to reinvent the way you govern the company. It asks you to apply it to product security. If you have a mature quality system, several of its mechanisms extend to the CRA almost frictionlessly.
Control of documented information (ISO 9001, clause 7.5) is the most direct case. The 9001 already requires you to manage versions, approvals, and controlled archiving. The technical documentation the CRA requires (art. 31 and Annex VII), including the cybersecurity risk assessment, lives on the same structure. You don’t need a second system: you need to extend it to the new content.
Nonconformity and corrective action management (ISO 9001, clause 10.2) is the right mental structure for handling a vulnerability. I detect a problem, I assess its impact, I decide on an action, I verify it worked, I keep a record. The cycle is the same the CRA requires to address and remediate vulnerabilities (Annex I, part II, points 2 and 8). The object changes, a security flaw instead of a production defect, and the timescales change, but the organisational mechanism already exists.
Internal audits (ISO 9001, clause 9.2) and management review (clause 9.3) become the places where product security enters corporate governance, instead of remaining a technical topic confined to R&D. If management already reviews quality every quarter, adding the state of CRA compliance to that table costs little and is worth a lot.
Supplier management (ISO 9001, clause 8.4) is the hook for the most neglected part of the CRA: third-party components. The CRA requires due diligence on integrated components, including open source ones, so they don’t compromise the product’s security (art. 13, para. 5). The 9001 already has you qualify and monitor suppliers; the CRA adds a new question, how is this software component managed from a security standpoint, but the contractual relationship and the qualification process to hang it on are already there.
Competence management (ISO 9001, clause 7.2), finally, gives you the register where you note that someone, in the company, has the training to do threat modelling or to handle a notification. The CRA presupposes competences the 9001 doesn’t name, but the place to track them exists.
What you have to build from scratch
Here reuse ends and the new work begins. There are three processes, and it’s no coincidence they are the same three obligations that no generalist management standard provides.
Vulnerability handling has no equivalent in the 9001. The CRA imposes it as a vulnerability handling requirement (Annex I, part II) for the entire support period (art. 13, para. 8). It’s not the management of a product nonconformity: it’s a process that actively monitors the vulnerabilities of integrated components, including those discovered years after the sale. The 9001 reacts to what you detect; vulnerability handling forces you to look outward, continuously.
Incident reporting to ENISA is even further from the quality world. An actively exploited vulnerability must be notified within 24 hours of discovery, with a full notification within 72 (art. 14, para. 2), through the single reporting platform (art. 16). No ISO 9001 process works on these timescales, and none provides for a mandatory notification to an external authority through a defined channel. It has to be built: who is authorised to notify, with which account, with which internal procedure, and where the evidence of what you notified and when is kept, because it’s the first thing an audit will look for. That deadline, 11 September 2026, and the other two are laid out in The CRA deadlines.
The software bill of materials (SBOM) is the inventory of the product’s software components, required by the CRA with at least the top-level dependencies (Annex I, part II, point 1; definition in art. 3, point 39). The 9001 knows the mechanical bill of materials; it doesn’t know the software one. Generating it and keeping it up to date is a new technical process, one that touches the development toolchain, not the quality office.
To these three is added the secure development process in the strict sense: security by design and the product’s cybersecurity risk assessment (art. 13, para. 2 and 3; Annex I, part I). The 9001 governs how you develop (clause 8.3), it doesn’t tell you how to make it secure. It’s the level where IEC 62443-4-1, if you choose to adopt it, hooks on, covering the CRA requirement and giving you a certification you can spend.
Where the 9001 helps more than it seems
A point that goes little noticed, and that plays in your favour. Among the conformity assessment procedures, the CRA provides a module based on full quality assurance (module H, Annex VIII, part IV), which rests on a quality system approved for design, development, testing, and vulnerability handling. Whoever already has a mature quality system starts with an advantage precisely on the conformity path for important products, not only on the internal organisation.
Author’s note (my reading, not the text of the law). Module H doesn’t hand you compliance: it asks you to extend the quality system to security and vulnerability handling, under the surveillance of a notified body. But if you actually live the 9001, and don’t treat it as a binder for the audit, this is the road where your prior investment pays off most.
One warning closes the loop: hooking the 9001 onto the CRA for its structure is right, but reusing it badly — assuming that form equals substance — is the mistake that recurs most often. The point, and why the 24 hours of art. 14 don’t tolerate the rhythm of traditional quality, I’ve singled out in “We’re already ISO 9001”: why it isn’t enough for the CRA.
References: Regulation (EU) 2024/2847 (CRA), articles 3, 13, 14, 16, 31, 32 and Annexes I, VII, VIII; ISO 9001:2015, clauses 7.2, 7.5, 8.3, 8.4, 9.2, 9.3, 10.2; IEC 62443-4-1. The notes flagged as the author’s are my interpretations, not regulatory text.