ISO/IEC 29147 and 30111: the coordinated vulnerability disclosure process explained

Coordinated vulnerability disclosure (CVD) is the umbrella term for how a reporter tells a vendor about a security flaw, how the vendor verifies and fixes it, and how the fix and advisory reach the public without giving attackers a head start. Two ISO/IEC standards split that process in half: ISO/IEC 29147, which governs the vendor-facing interface — how reports come in and how remediation information goes out — and ISO/IEC 30111, which governs what the vendor does internally between those two points: verification, triage and remediation. Together they are the international reference point that regional rules such as the EU Cyber Resilience Act's disclosure duties build on.

ISO/IEC 29147: vulnerability disclosure

According to its ISO catalogue listing, ISO/IEC 29147:2018 ("Information technology — Security techniques — Vulnerability disclosure") is the second edition, replacing the 2014 first edition. The catalogue describes its content as guidelines on:

• receiving reports about potential vulnerabilities;
• disclosing vulnerability remediation information;
• terms and definitions specific to vulnerability disclosure;
• an overview of vulnerability disclosure concepts, techniques and policy considerations, with examples.

In short, 29147 is about the interface: how a finder reaches you, what you acknowledge and when, and what a vulnerability advisory should contain once a fix exists. A published disclosure policy and a security.txt contact point, as described in our vulnerability disclosure policy template, are a practical implementation of this half of the process.

ISO/IEC 30111: vulnerability handling processes

ISO/IEC 30111:2019 ("Information technology — Security techniques — Vulnerability handling processes") is the second edition on the ISO catalogue, replacing the withdrawn 2013 first edition and applicable, per its scope note, to vendors involved in handling vulnerabilities. Where 29147 governs what a vendor says to the outside world, 30111 governs the work that happens before that: receiving the report internally, reproducing and verifying it, assessing severity and affected versions, tracking remediation to completion, and preparing the information that 29147 says should be disclosed.

How the two standards relate

	ISO/IEC 29147	ISO/IEC 30111
Focus	External interface: reporters, coordinators, users	Internal process: verification, triage, remediation
Current edition (ISO catalogue)	2018, 2nd edition (replaces 2014)	2019, 2nd edition (replaces 2013)
Typical artefact	Disclosure policy, intake contact, published advisory	Internal triage runbook, severity assessment, fix tracking
Also see	security.txt (RFC 9116), CVD policy templates	PSIRT process frameworks (e.g. FIRST)

Both standards are under active revision: the ISO catalogue lists open work items (ISO/IEC AWI 29147 and AWI 30111) that would broaden their scope from "vendors" to "anyone involved in handling vulnerabilities," so check the catalogue for the current edition before citing a specific year in a contract or policy.

Multi-party disclosure: ISO/IEC TR 5895

A single reporter and a single vendor is the simple case both 29147 and 30111 were written for. Real firmware and connected products rarely ship that cleanly: a component from one SDK vendor can affect products from dozens of brands at once, and none of them may be the one who received the report. ISO/IEC TR 5895:2022, "Cybersecurity — Multi-party coordinated vulnerability disclosure and handling," extends the model to cover multiple vendors (coordinating, mitigating and dependent), non-vendor coordinators, and shared or inherited components — the common shape of an embedded-systems supply chain.

How CISA's own process compares

CISA publishes its own Coordinated Vulnerability Disclosure (CVD) Process, describing it as facilitating "the timely and synchronized dissemination of vulnerability information" to minimise the window attackers have to exploit a flaw before a fix is public. As published on CISA's page, the process runs in seven stages:

1. Vulnerability report submission — researchers report through CISA's intake channel (VINCE-NT).
2. CVD intake and triage — CISA assesses legitimacy, actionability and scope.
3. CVD coordination — CISA identifies affected suppliers, analyses technical details and mediates between parties.
4. CVE record determination — CISA determines CVE eligibility and the responsible CVE Numbering Authority.
5. Advisory development and publication prep — stakeholders agree the final advisory text and timeline.
6. Public disclosure — CISA publishes the advisory, CVE record and machine-readable CSAF documentation.
7. KEV evaluation — ongoing assessment for inclusion in the Known Exploited Vulnerabilities catalog.

CISA's page does not cite ISO/IEC 29147 or 30111 by number, so there is no stated formal conformance claim to either standard; what can be said honestly is that the seven stages follow the same receive → verify/triage → remediate → disclose shape that the two ISO standards describe, with CVE assignment and KEV evaluation added as CISA-specific steps.

Where this shows up in regulation and industry practice

The EU's ENISA has long aligned its own guidance with ISO/IEC 29147: ENISA's 2016 Good Practice Guide on Vulnerability Disclosure recommends processes that later ENISA work describes as being in alignment with the ISO standard, and ENISA's EU Common Criteria certification scheme (EUCC) guidelines state that vulnerability handling and disclosure processes under that scheme are based on ISO/IEC 30111:2019 and ISO/IEC 29147:2018. FIRST's PSIRT Services Framework (v1.1) describes equivalent PSIRT intake, coordination and disclosure services without citing the ISO standards by number, and is a free alternative reference for teams building a process without purchasing the ISO texts. The EU Cyber Resilience Act's own vulnerability-handling duties — a published CVD policy, a security contact, and 24-hour reporting of actively exploited vulnerabilities — sit on top of the same receive/triage/disclose shape; see our guides to the CRA 24h/72h reporting duty and CRA checklist for device makers.

Building a CVD process in practice

1. Publish the external interface (29147-style). A disclosure policy, a security contact, and a security.txt file (see our template) so reports have somewhere to land.
2. Define the internal workflow (30111-style). Who verifies a report, how severity is assessed, who owns a fix, and how the fix is tracked to release.
3. Plan for multi-party cases. If your product embeds third-party SDKs or chipsets, agree in advance how you will coordinate with an upstream vendor or a non-vendor coordinator when the report is not about your own code — the ISO/IEC TR 5895 model.
4. Match your CVE and advisory output to what downstream consumers expect, including machine-readable formats such as CSAF; see our guide to CSAF/VEX for device makers.
5. Re-check the standard editions periodically. Both 29147 and 30111 have open revision work items on the ISO catalogue; a policy written against the 2018/2019 editions should be revisited if a new edition publishes.

No in-house PSIRT to run this end to end? SoftWSP can receive, triage and coordinate vulnerability reports against this process for your products: see PSIRT as a service.

This guide summarises publicly available descriptions of ISO/IEC 29147 and 30111; it does not reproduce their paywalled text and is not legal advice.