Already ISO 9001 certified? The parts of the CRA you can hook onto your quality system (and the parts you can't)
29 July 2026·7 min read·Alberto Scarpa
Faced with a CRA that requires documented processes, nonconformity management, and internal audits, a certified manufacturer almost always reacts the same way: “we already have these things, we’re ISO 9001”. It’s half true. The quality management system is a concrete advantage, you already have the organisational backbone the CRA needs. But it’s also the source of the costliest illusion: thinking that “ISO 9001 compliant” means “almost CRA compliant”. It doesn’t. The difference lies in three processes the 9001 doesn’t provide, and if you don’t see them you end up exposed exactly where the CRA bites.
This is the map: what I hook onto the existing quality system, what I have to build new, and where reuse is dangerous. 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.
Operational 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.
Where reuse becomes dangerous
A warning, because it’s the mistake that recurs most often. It’s not reusing the quality system too little, it’s reusing it badly, assuming that form equals substance. A nonconformity management process that measures time in weeks does not become an incident reporting process just because you write “cybersecurity” on top of it. The 24 hours of art. 14 don’t tolerate the rhythm of traditional quality. If you hook incident reporting onto the nonconformity cycle without redesigning timescales and responsibilities, you have a process that looks compliant on paper and collapses at the first real case.
The practical rule is simple: reuse the 9001 for the structure (documents, audits, review, suppliers, competences) and build new for the three processes that live in hours and look outside the company. Whoever confuses the two levels doesn’t save work: they find out too late, at the worst possible moment.
If you’re ISO 9001, you start with an advantage. But the advantage is the backbone, not the muscle, and the CRA’s muscle has to be built on purpose.
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 operational are my interpretations, not regulatory text.