In the CTO's vulnerability process, which part does 29147 cover and which does 30111 cover?
| Standard | What it covers | Typical outputs |
|---|---|---|
| ISO/IEC 29147 (vulnerability disclosure) | External: receiving reports, communicating with reporters, publishing advisories | Reporting contact and security.txt, coordinated disclosure policy, advisory templates |
| ISO/IEC 30111 (vulnerability handling) | Internal: verification, rating, root cause analysis, remediation and release | Handling process, rating criteria, handling records and time limits |
The two standards reference each other and their processes interlock; implementing them separately leaves an audit gap at the hand-off, so build them as a pair. The versions currently in force are ISO/IEC 29147:2018 and ISO/IEC 30111:2019; revisions have been registered in ISO/IEC JTC 1/SC 27, and the new editions have not yet been published.
What hard requirements and time limits does the EU CRA set for R&D's vulnerability handling?
Annex I Part II of the CRA requires manufacturers to:
- draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies (point (1));
- address and remediate vulnerabilities "without delay", providing security updates separately from functionality updates where technically feasible (point (2));
- put in place and enforce a coordinated vulnerability disclosure (CVD) policy (point (5)) and provide a contact address for reporting vulnerabilities (point (6));
- distribute security updates "without delay" once available, free of charge unless otherwise agreed for tailor-made products (point (8)).
Article 14 reporting: on becoming aware of an actively exploited vulnerability, the manufacturer notifies the CSIRT designated as coordinator and ENISA simultaneously via ENISA's single reporting platform: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. This has applied since 11 September 2026 and also covers products placed on the market before 11 December 2027.
After a vulnerability report arrives, how should R&D's internal handling gates be designed?
The core is to write "who takes the report, who verifies, who rates, who fixes, who releases, and how fast" into an auditable process with time limits:
| Gate | What it decides | Common gap |
|---|---|---|
| Intake and verification | Whether the report is valid, reproducible, and which products and versions it affects | No product and component inventory, so scope cannot be judged |
| Rating | Which criteria set severity and handling time limits | Rating criteria exist only in individual experience |
| Remediation | Who owns the fix, workarounds and testing | Nobody owns old versions and discontinued models |
| Release | How security updates reach users, and when the advisory is published | Security updates bundled with feature updates |
| Review | Root cause analysis and process improvement | Similar vulnerabilities keep recurring |
Rating criteria can be localised to the product context (for example localised CVSS criteria); vendors with multiple product lines also need a cross-cutting mechanism for assessing vulnerability impact.
SBOM, regular testing and secure update distribution: what if 29147 and 30111 do not cover them?
According to the 2024 mapping analysis by the EU Joint Research Centre (JRC) and ENISA:
- 30111 maps to points 2, 4, 5, 6 and 8 of Annex I Part II;
- 29147 maps to points 2, 4, 5 and 6;
- the SBOM (point 1), regular testing and review (point 3) and secure distribution of updates (point 7) are not mapped to either standard and must be covered by other standards or procedures.
The report is an analysis, not a harmonised standard, and gives no presumption of conformity; it also notes that no single standard covers every aspect. The CTO needs to add three things to the toolchain and release process: an SBOM tied to each product version, regular security testing, and a mechanism for distributing security updates. The 30111 remediation process must connect to the SBOM (you only know which component vulnerability concerns you if you know what is in the product) and to security update delivery (a fix must reach users).
Do old versions, discontinued models and products already on the market need vulnerability handling during the support period?
Yes. The CRA requires manufacturers to handle vulnerabilities effectively in line with Annex I Part II from placing on the market and throughout the support period (Article 13(8)):
- Support period: at least 5 years (or the expected use time if shorter), with the end date (at least month and year) clearly stated at the time of purchase (Article 13(19)).
- Keeping security updates available: each security update issued during the support period stays available for at least 10 years or until the end of the support period, whichever is longer (Article 13(9)).
- Products already on the market: the Article 14 reporting obligations also cover products placed on the market before 11 December 2027 (Article 69(3)).
For the CTO, this means fixes and testing for old versions need a clear owner, and version branches and build environments must remain reproducible throughout the support period.
Engineering staffing: does a small company need a PSIRT, and is an existing incident response procedure enough?
You do not need a large team, but you need a clear intake channel, an owner and a response process; the minimum requirements of 29147 already allow for scale, so the system can be lean but cannot be absent.
An existing security incident procedure is a good foundation but is not vulnerability handling: incident handling (ISO/IEC 27035) deals with attacks that have happened, while vulnerability handling (30111) deals with reported weaknesses; their triggers, time limits and outputs differ, and CRA audits look at the vulnerability-specific process and evidence. The 30111 process should connect to existing incident response (27035) and supplier management (27036). Organisations with ISO 27001 can attach the CVD process to their existing ISMS and share documents and audit mechanisms.
How does Winners Consulting help a CTO with ISO/IEC 29147 and 30111?
Vice-president and director-level consultants personally lead the work end to end, never outsourced, and 29147 and 30111 are implemented as a pair. Deliverables listed on the service pages:
- 29147, disclosure side: security.txt and a reporting mailbox or form, time limits for acknowledging and responding to reports, a coordinated vulnerability disclosure policy with a safe harbour statement, advisory templates and a publishing process, and a CVE ID request procedure where needed.
- 30111, handling side: vulnerability handling policy and process documents, rating criteria, handling records and time-limit reporting, an SBOM linkage procedure, and interface documents with the 29147 disclosure side, all built to be auditable by notified bodies and customers.
- Hands-on experience: Winners Consulting's own delivery pipeline generates, signs and monitors SBOMs daily, and that mechanism is live teaching material for the engagement.
The service pages list no number of months.
Go deeper: ISO/IEC 29147 vulnerability disclosure, ISO/IEC 30111 vulnerability handling, Choosing a 29147 consultant, What a CTO builds into the R&D process. Request a free mechanism diagnosis
How other roles see this service
Other services for this role
- EU CRA for CTOs: what changes in development, SBOM and launch timing?
- IEC 62443-4-1 for CTOs: what changes in secure development and how long?
- ISO/SAE 21434 for CTOs: how does TARA fit the existing development process?
- ISO 42001 and the EU AI Act for CTOs: what does AI product development need?
- ISO 27701 and GDPR for CTOs: how to design privacy into products and systems?
- Trade secret protection for CTOs: how to classify R&D data and what records to keep
- ISO 56001 for CTOs: piloting innovation projects and the ESG extra point
- TISAX prototype protection for CTOs: what ISA2027 changes and what to prepare
- Digital transformation for CTOs: keeping security in step with ERP, MES and IoT
- AI transformation for CTOs: choosing the first use case and governance to build first