ISO/IEC 29147 & 30111 (Vulnerability Disclosure)

Introduction: The Twin Standards of Coordinated Vulnerability Disclosure

ISO/IEC 29147 (Information technology — Security techniques — Vulnerability disclosure) and ISO/IEC 30111 (Information technology — Security techniques — Vulnerability handling processes) are the two internationally recognised standards that together define how an organisation should receive information about potential vulnerabilities in its products and online services, and how it should investigate, remediate and publicly disclose those vulnerabilities. Where 29147 is externally facing — describing the interface between a vendor and the outside world (finders, researchers, coordinators, users) — 30111 is internally facing, describing the disciplined engineering process that runs behind that interface. Neither standard makes sense in isolation: a slick disclosure front-end with no repeatable handling process merely generates broken promises, and a rigorous handling process with no disclosure channel means the organisation never hears about the vulnerabilities it is so well-equipped to fix.

The current editions are ISO/IEC 29147:2018 and ISO/IEC 30111:2019. Both were revised from their 2013/2014 first editions to align terminology, embrace the language of Coordinated Vulnerability Disclosure (CVD), and reflect the maturity of bug-bounty programmes, third-party coordinators (such as national CERTs and CERT/CC) and the Common Vulnerabilities and Exposures (CVE) ecosystem. This guide treats the two standards as a single operating model — the vulnerability disclosure and handling lifecycle — because that is how an auditor assesses them and how a product security team must implement them. It is written for both the assessor validating conformance and the product/PSIRT team building the capability from scratch.

What is Vulnerability Disclosure (ISO/IEC 29147 & 30111)?

Vulnerability disclosure is the process by which knowledge of a security weakness in a product or service moves from the person who found it (the finder or reporter) to the party that can fix it (the vendor or service operator), and ultimately — in a controlled, coordinated fashion — to the users and the wider public who need to protect themselves. The twin standards codify this so that the process is predictable, respectful of all parties, and repeatable across an organisation's entire portfolio rather than being reinvented in a panic every time a researcher sends an email.

ISO/IEC 29147 focuses on the disclosure interface and communications. It specifies how a vendor should advertise the ability to receive reports, how it should acknowledge and respond to finders, and what information a security advisory should contain so that users can make informed remediation decisions. Its central concepts are the receipt of vulnerability reports, the ongoing communication with reporters and coordinators, and the publication of vulnerability advisories.

ISO/IEC 30111 focuses on the handling process. It describes the organisational structure and workflow needed to receive a report, verify and triage it, investigate root cause and scope, develop and test a remediation, and release that remediation in coordination with disclosure. It emphasises that vulnerability handling is a cross-functional business process — not merely a task for a security team — spanning engineering, legal, communications, support and executive management.

Together they establish Coordinated Vulnerability Disclosure (CVD): a model in which finder and vendor cooperate, a remediation is prepared before public disclosure where feasible, and the release of advisory and fix is timed to minimise the window in which users are exposed to a known-but-unpatched flaw. This contrasts with 'full disclosure' (immediate public release regardless of a fix) and 'non-disclosure' (concealment), both of which the standards implicitly discourage in favour of coordination.

Who Must Comply

Neither standard is legally mandatory in itself, but conformance to ISO/IEC 29147 and 30111 is increasingly demanded by regulators, procurement frameworks and customers. Adoption is effectively obligatory for any organisation that ships software, firmware, hardware or online services to third parties. The table below summarises who is in scope and why.

Structure of the Vulnerability Disclosure & Handling Standards

The standards are not organised as a list of numbered 'controls' in the way ISO/IEC 27001 Annex A is. Instead each standard defines a set of concepts, process phases, and requirements/recommendations. For assessment purposes it is useful to decompose them into logical domains. The table below maps the domains an auditor typically evaluates, indicating which standard each domain draws from.

Master Assessment Checklist

This is the core of the guide. Each h3 below corresponds to a domain of the twin standards. For every domain a table enumerates the specific items an assessor verifies alongside the typical evidence an implementer should produce. Nothing is skipped: intake, communication, advisory content, the full 30111 handling phases, multi-party coordination and continual improvement are all covered. Use these tables both as an audit programme and as an implementation backlog.

D1 — Vulnerability Disclosure Policy & Governance

D2 — Report Receipt & Intake Capability (29147)

D3 — Reporter (Finder) Communication (29147)

D4 — Vulnerability Advisory Publication (29147)

D5 — Handling Process Organisation (30111)

D6 — Triage & Verification (30111 Phase)

D7 — Remediation Development (30111 Phase)

D8 — Release & Disclosure Coordination (30111 + 29147)

D9 — Post-Release & Continual Improvement (30111)

D10 — Multi-Party & Coordinator Handling (29147 + 30111)

Scoping the Disclosure & Handling Programme

Scoping determines which assets, products, services and third-party relationships fall under the disclosure policy and the handling process. Under-scoping (excluding legacy or acquired products) leaves blind spots that finders will inevitably probe; over-scoping stretches the PSIRT beyond its capacity and erodes response times. A defensible scope is explicit, asset-driven and reviewed as the portfolio changes.

• Enumerate all products, product versions, firmware, APIs and online services offered to third parties, and record their support/EOL status.
• Decide which are in-scope for accepting reports and which are explicitly out of scope, and state this in the published policy.
• Map dependencies and third-party/open-source components (via SBOM) that could carry inherited vulnerabilities.
• Define the boundary with the internal incident-response process — a disclosed vulnerability may escalate into a live security incident.
• Clarify geographic and regulatory scope (e.g. CERT-In reporting duties in India, EU CRA obligations) that overlay the standards.
• Identify multi-party scenarios (shared libraries, OEM/white-label relationships) requiring coordinator involvement.
• Set out-of-scope exclusions clearly (e.g. social-engineering, physical attacks, third-party-hosted assets) to manage reporter expectations.

Implementation Approach (Phased)

Building a conformant disclosure and handling capability is best done in phases. Each phase below lists its key activities and the deliverables an auditor will later request as evidence.

Phase 1 — Foundation & Governance

• Activities: secure executive sponsorship; establish (or formalise) a PSIRT; draft the vulnerability disclosure policy; obtain legal review of safe-harbour language; define roles via a RACI.
• Deliverables: approved VDP; PSIRT charter; RACI matrix; legal safe-harbour clause; management sign-off record.

Phase 2 — Intake & Communication Interface (29147)

• Activities: stand up reporting channels (form/alias/portal); publish security.txt; provision a PGP key; integrate intake with a case-management system; define acknowledgement and status-update SLAs.
• Deliverables: live intake channel; published /.well-known/security.txt; case-management workflow; SLA definitions; reporter communication templates.

Phase 3 — Handling Process (30111)

• Activities: document the end-to-end handling workflow (triage, verification, remediation, testing, release); define severity/CVSS scoring; establish root-cause and variant-analysis practice; connect to the secure SDLC and QA gates.
• Deliverables: handling SOP; triage & scoring guide; RCA template; test/QA gate definitions; escalation procedure.

Phase 4 — Advisory & Coordination Capability

• Activities: create the advisory template; become or engage a CVE CNA; adopt machine-readable advisory formats (CSAF/VEX); establish coordinator relationships and embargo management; build downstream notification lists.
• Deliverables: advisory template; CVE/CNA process; CSAF pipeline; coordinator contact register; embargo tracker.

Phase 5 — Operate, Measure & Improve

• Activities: run the programme live; capture KPIs; conduct post-incident retrospectives; feed recurring root causes into engineering hardening; review and update policy periodically.
• Deliverables: KPI dashboard; retrospective reports; management-review minutes; policy version history; researcher feedback records.

Maturity / Capability Model

The standards themselves are not tiered, but assessors commonly grade a disclosure and handling programme against a five-level capability model. This helps organisations benchmark and plan improvement. The model below is a CyberSigma assessment construct aligned to the intent of 29147 and 30111.

Assessment & Audit Approach

A conformance assessment against ISO/IEC 29147 and 30111 follows a structured sequence, combining documentation review with process walkthroughs and live-case sampling.

1. Define the assessment scope: which products, services and organisational units are covered, and confirm the standards' editions in use.
2. Review the published disclosure policy, security.txt and intake channels for existence, discoverability and completeness.
3. Examine the documented 30111 handling process and PSIRT charter, mapping each phase to responsible roles.
4. Sample recent vulnerability cases end to end — from intake through triage, remediation, release and advisory — to test process adherence.
5. Test reporter communication: verify acknowledgements, status updates, credit handling and disclosure-timing coordination against SLAs.
6. Assess advisory quality: identifiers, affected-version accuracy, CVSS scoring, remediation guidance and coordinated timing.
7. Evaluate multi-party and coordinator handling, embargo management and downstream notification where applicable.
8. Review metrics, management reviews and continual-improvement evidence to confirm the process is measured and maturing.
9. Document findings, non-conformities and observations; rate maturity; and agree a remediation plan with owners and dates.

Evidence Request List

Assessors typically request the following categorised evidence in advance of fieldwork. Implementers should treat this as a readiness inventory.

• Governance: approved vulnerability disclosure policy; PSIRT charter; RACI; management-review minutes; policy version history.
• Intake: screenshots/links of reporting channels; published security.txt; PGP key details; case-management configuration.
• Communication: sample reporter correspondence showing acknowledgement and updates; credit/acknowledgements page; embargo notices.
• Handling process: end-to-end handling SOP; triage and CVSS scoring guides; RCA and variant-analysis templates; QA/security test gates.
• Advisories: advisory template; published advisories; CVE/CNA records; CSAF/VEX artefacts if used.
• Coordination: coordinator contact register; multi-vendor notification records; embargo tracker; downstream notification lists.
• Metrics & improvement: KPI dashboards; SLA-compliance reports; retrospective/lessons-learned reports; researcher feedback.
• Case sample: a set of closed and in-flight vulnerability cases with full audit trail for walkthrough.

Roles & Responsibilities

KPIs to Track

• Time-to-acknowledge: median and 90th-percentile time from report receipt to finder acknowledgement, against SLA.
• Time-to-triage: time from receipt to validated severity and scope decision.
• Time-to-remediate (mean time to remediate): time from validation to available fix, segmented by severity.
• Time-to-disclose: time from remediation availability to public advisory (coordinated window).
• Open vulnerability backlog and its age distribution.
• Reopen / regression rate: proportion of advisories requiring a follow-up fix (incomplete-fix indicator).
• Report validity rate: share of inbound reports that are valid, unique vulnerabilities.
• Advisory completeness: percentage of advisories with CVE ID, CVSS vector and remediation guidance.
• Coverage: percentage of in-scope products with an active, documented disclosure channel.
• Researcher satisfaction / repeat-reporter rate as a proxy for programme health.

Readiness Checklist

• A management-approved vulnerability disclosure policy is published and version-controlled.
• Reporting channels are live and discoverable via security.txt (RFC 9116).
• Secure submission (PGP/TLS) is available for sensitive reports.
• Acknowledgement and status-update SLAs are defined and being met.
• A PSIRT (or equivalent) with a documented charter and RACI is in place.
• An end-to-end 30111 handling process (triage, remediation, testing, release) is documented and followed.
• Root-cause and variant analysis are standard practice for every remediation.
• A CVSS-based severity model and consistent prioritisation are applied.
• An advisory template with CVE ID, affected versions, CVSS and remediation exists.
• CVE assignment (via CNA or a CNA-of-last-resort) is in place.
• Coordinated disclosure timing is negotiated with finders and coordinators.
• Multi-party and downstream notification procedures exist for shared components.
• KPIs are captured and reviewed by management on a defined cadence.
• Retrospectives feed lessons learned into the secure SDLC and policy updates.
• Machine-readable advisory formats (CSAF/VEX) are adopted or planned.

Common Gaps

• No published disclosure channel — finders resort to social media or full disclosure because they cannot find a way to report.
• security.txt absent or pointing to an unmonitored mailbox, so reports are silently lost.
• A disclosure front-end with no underlying 30111 handling process, producing acknowledgements but no fixes.
• Missing safe-harbour language, deterring good-faith researchers or provoking legal disputes.
• Symptom-only fixes with no root-cause or variant analysis, leading to repeated related vulnerabilities.
• Advisories lacking CVE IDs, precise affected versions or CVSS scoring, leaving users unable to prioritise.
• Uncoordinated disclosure timing that either exposes users to unpatched flaws or burns finder goodwill.
• No handling for end-of-life products or third-party/open-source components carrying inherited vulnerabilities.
• Over-reliance on a single individual, so intake and coordination stall during absence.
• No metrics or management review, so SLA breaches and backlog growth go unnoticed.
• Poor multi-party coordination on shared components, causing unfair or premature disclosure across vendors.
• No feedback loop into the secure SDLC, so the same classes of vulnerability keep recurring.

Vulnerability Disclosure Mapped to Other Frameworks

ISO/IEC 29147 and 30111 dovetail with numerous other standards and regulations. Mapping them helps organisations reuse evidence and satisfy overlapping obligations.

Frequently asked questions

Need help with Vuln Disclosure?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.