Framework

ISO/IEC 29147
vulnerability disclosure standard for PSIRT and product security teams

ISO/IEC 29147:2018 (Information technology, Security techniques, Vulnerability disclosure) is the international standard for the external-facing half of vulnerability disclosure. It describes how a vendor receives reports from finders, communicates through the case lifecycle, coordinates where relevant, and publishes the advisory. The standard pairs with ISO/IEC 30111 (Vulnerability handling processes), and is the international anchor that the EU Cyber Resilience Act, the CISA Coordinated Vulnerability Disclosure model, the FIRST PSIRT Services Framework, and the US federal disclosure mandates inherit from. This page covers the five-phase disclosure lifecycle, the policy artefact set, the failure modes the standard surfaces, the relationship with adjacent regimes, and the audit-grade evidence pack the programme produces.

Get Started Free

No credit card required. Free plan available forever.

ISO/IEC 29147 explained for product security and PSIRT teams

ISO/IEC 29147:2018 (Information technology, Security techniques, Vulnerability disclosure) is the international standard for the external-facing half of vulnerability disclosure. It describes how an organisation that produces software, hardware, or services receives vulnerability reports from external finders, communicates with those finders through the case lifecycle, coordinates with other parties where relevant, and publishes the advisory that downstream consumers act on. The standard names the policy, the intake, the acknowledgement and verification clocks, the remediation development cadence, the release timing, and the post-release loop, and it pairs explicitly with ISO/IEC 30111 (Vulnerability handling processes) which covers the internal-handling counterpart.

For PSIRT teams, product security teams at vendors, AppSec teams accountable for externally reported issues, GRC owners producing the audit pack, and CISOs at organisations that ship products read against by federal, EU, financial, or critical-infrastructure regulators, ISO/IEC 29147 is the operating reference the disclosure-side discipline reads against. The standard is the international anchor that the EU Cyber Resilience Act, the CISA Coordinated Vulnerability Disclosure model, the FIRST PSIRT Services Framework, the US federal vulnerability disclosure mandates, and the wider sector-specific disclosure regimes inherit from.

This page walks through the scope of the standard, the five phases of the disclosure lifecycle, the policy artefacts the standard expects, the failure modes the standard was published to surface, the relationship with adjacent regimes, the audit-grade evidence pack the programme produces, and where ISO/IEC 29147 sits alongside the vulnerability disclosure programme setup guide, the vulnerability disclosure programme management workflow, and the PSIRT operating workflow. Programmes that adopt ISO/IEC 29147 as the disclosure-side reference and ISO/IEC 30111 as the internal-handling counterpart produce a coherent vulnerability disclosure posture that holds up under EU CRA, CISA CVD, FIRST PSIRT, federal mandate, and audit-committee scrutiny on one record.

What ISO/IEC 29147 covers

The standard is narrower than the full vulnerability lifecycle and broader than a single policy template. It covers the externally facing half of vulnerability disclosure; ISO/IEC 30111 covers the internal-handling half. The two read together as a pair, with the same case identifier walking across both records.

External vulnerability disclosure

ISO/IEC 29147 is the external-facing half of the vulnerability disclosure pair. The standard describes how a vendor receives vulnerability reports from external finders (independent researchers, customers, partners, coordinating bodies, government CERTs) and how the vendor communicates back to those finders, downstream consumers, and the wider ecosystem.

Process discipline rather than tooling

The standard is deliberately tool-agnostic. It names what the disclosure process must produce (a published policy, an intake channel, an acknowledgement clock, a triage decision, a remediation plan, a coordinated release, a public advisory) rather than the specific software a vendor uses to operate it. Programmes that adopt the standard pair it with whichever workspace, ticketing, or document system already carries the rest of the security operating record.

Pairs with ISO/IEC 30111

ISO/IEC 29147 covers the external interface (intake, finder communications, advisory publication). ISO/IEC 30111 covers the internal handling (triage, root-cause analysis, fix development, regression, release readiness). The two standards are designed to be operated together; programmes that adopt one without the other produce either an external promise without an internal capability or an internal capability with no defensible external interface.

The five phases of the disclosure lifecycle

ISO/IEC 29147 describes the disclosure lifecycle in five phases. The phases are not separate processes; they are stages on the same case record, each with named outputs the next phase reads against. Read sequentially: receipt produces the intake record, verification produces the calibrated finding, remediation produces the fix and the affected-version matrix, release produces the advisory, and post-release produces the deployment evidence and the lessons-learned record.

  1. 1

    Phase 1: Receipt

    The vendor maintains a published vulnerability disclosure policy, a documented intake channel (security.txt, dedicated email address, web form, or an authenticated researcher portal), and a documented acknowledgement clock. Reports arrive in a structured intake record with the finder identity (or anonymised handle), the affected product and version, the reproduction steps, the supporting evidence, and the requested embargo or timeline. The intake record is the canonical artefact every later phase reads against.

  2. 2

    Phase 2: Verification

    The vendor verifies the report. Verification confirms the affected product and version, reproduces the issue in a controlled environment, captures the technical evidence, calibrates a working severity (typically with CVSS 3.1 or CVSS 4.0 environmental modifiers), and returns a verification status to the finder within the documented clock. Verification is not the fix decision; it is the gate that turns a report into a tracked finding the rest of the programme reads against.

  3. 3

    Phase 3: Remediation development

    The vendor develops the remediation. The remediation may be a code patch, a configuration change, a workaround, an ecosystem-coordinated fix, or, where the issue is not exploitable in shipped products, a documented advisory with no code change. The remediation phase carries the regression evidence, the affected-version matrix, the backport decisions, and the customer-facing impact assessment. ISO/IEC 30111 is the internal-handling counterpart that governs the technical work; ISO/IEC 29147 governs the disclosure side of the same record.

  4. 4

    Phase 4: Release

    The vendor publishes the advisory and ships the remediation. The advisory carries the affected products and versions, the severity assessment with the supporting vector, the recommended action (patch, upgrade, mitigation), the credit to the finder where they consent, the CVE identifier where one is appropriate, and the references to coordinating bodies (CERT, ISAC, sector regulator) where the vulnerability is coordinated. The release is timed against the disclosure policy, the embargo, and any coordinated multi-vendor disclosure.

  5. 5

    Phase 5: Post-release

    The vendor closes the disclosure with the finder, captures the lessons learned, updates the affected-version matrix as customers deploy the remediation, refreshes the advisory if material new information emerges (regression, exploit observation in the wild, additional affected products), and feeds the case into the post-mortem record the programme reads at quarterly and annual review. The disclosure record stays open as a queryable artefact rather than archived behind a static PDF.

The policy artefact set

The standard expects a defined artefact set rather than a single document. The pack below is the minimum durable set most programmes maintain when they adopt ISO/IEC 29147 as the operating baseline. Each artefact has a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail.

  • A public vulnerability disclosure policy that names the scope (which products, services, and platforms accept reports), the intake channel, the acknowledgement clock, the safe-harbour or authorised-research statement where applicable, the embargo and coordination expectations, and the publication commitment. The policy is version-controlled and dated.
  • A security.txt file at the well-known URL, a dedicated security@ contact, or a researcher portal that the published policy references. The intake channel is monitored on the documented cadence rather than aspirationally.
  • An intake record template that captures the finder identity (or handle), the contact preference, the affected product and version, the reproduction steps, the impact assessment, the requested embargo, the working severity, and the references to any prior reports.
  • A finder communication log that captures every outbound and inbound message on the case (acknowledgement, verification result, remediation timeline, embargo updates, advisory draft for review where appropriate, post-release follow-up), with timestamps and named owners.
  • An internal triage decision register that records the verification status, the working severity, the affected-version matrix, the remediation owner, the planned release window, and the embargo posture, with the rationale captured at the time of the decision rather than reconstructed at audit time.
  • A published advisory record per disclosed vulnerability with the affected products and versions, the severity vector, the recommended action, the credit, the CVE identifier where applicable, the coordination references, and the version history of the advisory itself when the advisory is updated post-release.
  • A coordination record for multi-vendor or supply-chain-coordinated cases that names the coordinating body (CERT, ISAC, sector regulator, lead vendor), the embargo timeline, the participating parties, and the synchronisation points before the joint release.

Failure modes the standard is designed to surface

The standard is forgiving on the choice of tooling, the wording of the policy, and the prioritisation order within the case register. It is unforgiving about a small number of patterns that turn the disclosure programme cosmetic rather than operational. The patterns below recur across vulnerability disclosure adoptions and are the ones that erode finder trust and audit defensibility most reliably.

  • Publishing a disclosure policy without monitoring the intake channel. The published policy is read as a commitment by finders and regulators; an unmonitored channel turns the commitment into a documented failure rather than a documented gap. The cheapest version of operating 29147 is the published policy plus a monitored channel with a documented acknowledgement clock that holds.
  • Treating the standard as a one-off project rather than a programme. ISO/IEC 29147 expects the disclosure process to be operating, not implemented and shelved. Programmes that file the policy and then let the intake go cold within a year read worse to a regulator than programmes that did not publish at all.
  • No verification clock. Reports that sit in intake without verification turn the disclosure relationship adversarial fast. The standard expects an explicit verification clock, captured in the policy, communicated to the finder at acknowledgement, and held against on the case record.
  • Skipping the working severity. Programmes that go straight from intake to fix without recording a working severity (typically CVSS 3.1 or 4.0 with environmental modifiers) lose the prioritisation rationale and produce advisories that downstream consumers cannot calibrate against. The severity is captured at verification and refined as the case develops.
  • Advisory without an affected-version matrix. The advisory is the artefact downstream consumers act on. Advisories that name the product without naming the affected versions, the fixed versions, the workaround posture, and the backport status produce remediation guesswork rather than remediation action.
  • Coordinated disclosure without a coordination record. Multi-vendor or supply-chain-coordinated cases without a documented coordination record (coordinating body, embargo timeline, participating parties, synchronisation points) collapse under the first off-cycle leak; the coordination record is the artefact that reconstructs the timeline if the embargo breaks.
  • No post-release loop. Programmes that close the case at advisory publication miss the deployment evidence, the regression observation, the exploit-in-the-wild observation, and the lessons-learned record. The standard expects the case to remain open as a queryable artefact, with the post-release loop carrying the operational learning the programme reads at quarterly review.

How ISO/IEC 29147 relates to adjacent regimes

ISO/IEC 29147 sits in a busy disclosure neighbourhood. The relationships below are the ones programmes encounter most often when they read 29147 against the rest of the disclosure regime. Programmes operating across regions and sectors use 29147 as the process spine and read CISA CVD, the FIRST PSIRT Services Framework, the CERT/CC CVD guide, the EU CRA, and the federal mandates as the contextual layers around it.

ISO/IEC 29147 vs ISO/IEC 30111

ISO/IEC 29147 (Vulnerability disclosure) is the external-facing standard. ISO/IEC 30111 (Vulnerability handling processes) is the internal-handling counterpart. 29147 governs the policy, the intake, the finder communications, and the advisory. 30111 governs the triage, the verification, the fix development, the regression, and the release readiness. The two are designed to be operated together; the same case ID walks across both records, with the 29147-side artefacts being the externally visible interface and the 30111-side artefacts being the internal operating record.

ISO/IEC 29147 vs CISA Coordinated Vulnerability Disclosure (CVD)

CISA CVD is the US government coordinated disclosure model that builds on the ISO/IEC 29147 baseline. CVD adds the role of the coordinator (CISA itself, CERT/CC, sector ISACs, or other coordinating bodies) and the multi-stakeholder communication discipline that goes alongside the vendor-finder pair. Programmes that adopt 29147 as the baseline read CVD as the multi-stakeholder extension when the vulnerability touches critical infrastructure, multiple vendors, or a supply chain in scope of CISA notification.

ISO/IEC 29147 vs FIRST PSIRT Services Framework

FIRST publishes the PSIRT Services Framework, which describes the services a Product Security Incident Response Team (PSIRT) is expected to deliver across vulnerability discovery, analysis, remediation, and disclosure. The PSIRT Services Framework is service-oriented; ISO/IEC 29147 is process-oriented. PSIRTs operating to FIRST guidance read 29147 as the disclosure-side process that the PSIRT services framework calls into for the externally facing parts of the lifecycle.

ISO/IEC 29147 vs CERT/CC Guide to Coordinated Vulnerability Disclosure

The CERT/CC Guide to CVD is the practical playbook for coordinated disclosure with multiple parties. It pairs naturally with ISO/IEC 29147: the standard names the vendor-side discipline; the CERT/CC guide names the coordination patterns when the disclosure crosses vendor boundaries. Programmes that maintain a public CVD policy, an intake channel, and a coordinator relationship with CERT/CC operate against both references in parallel.

ISO/IEC 29147 vs the EU Cyber Resilience Act

The EU Cyber Resilience Act obliges manufacturers placing products with digital elements on the EU market to maintain a coordinated vulnerability disclosure policy, accept reports from third parties, address vulnerabilities without undue delay, and provide security updates. ISO/IEC 29147 is the international standard the CRA expectations read against; vendors operating CRA-aware programmes use 29147 as the operating reference and the published 29147 policy as evidence the CRA disclosure obligation is being met.

ISO/IEC 29147 vs the US Federal vulnerability disclosure mandates

CISA Binding Operational Directive 20-01, OMB M-20-32, and the related federal-civilian executive expectations require federal agencies and federal-acquisition contractors to operate published vulnerability disclosure policies. The required policy elements (scope, authorised testing, communication, disclosure, safe harbour) inherit directly from ISO/IEC 29147. Federal contractors operating an ISO/IEC 29147-aligned policy produce one artefact that satisfies multiple regulatory readers.

The audit-grade evidence pack

Internal auditors, ISO/IEC 27001 certification bodies reading Annex A controls A.5.7 (threat intelligence), A.5.10 (acceptable use), A.6.7 (remote working), A.5.36 (compliance with policies, rules, and standards), federal customers under FedRAMP and NIST SP 800-171, financial regulators under DORA Article 28, EU market surveillance under CRA, and critical-infrastructure regulators under CISA CVD all read disclosure evidence in similar shapes. The minimum durable pack below is the residue of the operating work rather than a separate compilation produced at reading time.

  • The published vulnerability disclosure policy with version history, the dated review record, and the named accountable owner. The policy is the load-bearing artefact every other piece of evidence reads against.
  • The intake channel record (security.txt deployment, dedicated security email account, researcher portal access controls) with the monitoring cadence and the on-call rotation that proves the channel is operating rather than aspirational.
  • The case register with one record per disclosure, walking from intake through verification, triage, remediation, release, and post-release. Each record carries the timestamps that prove the policy clocks (acknowledgement, verification, remediation target, release window) were held against.
  • The finder communication log per case, with the inbound and outbound messages, the acknowledgement of receipt, the verification result, the remediation timeline updates, the embargo confirmations, and the post-release follow-up. The log is the auditable interface to the finder.
  • The advisory archive with one record per published advisory. Each advisory carries the affected and fixed-version matrix, the severity assessment with the vector, the recommended action, the finder credit where given, the CVE identifier where issued, the coordination references, and the version history when the advisory has been updated post-release.
  • The coordination record for multi-vendor or supply-chain cases, with the coordinating body, the embargo timeline, the participating parties, and the synchronisation points. The coordination record is the artefact that reconstructs the cross-vendor timeline if the embargo breaks or a regulator queries the disclosure path.
  • The post-release loop record per case, with the deployment evidence, the regression observation, the exploit-in-the-wild observation where applicable, the advisory updates, and the lessons-learned summary. The loop is the artefact the programme reads at quarterly and annual review.
  • The metric pack the programme reports against the policy clocks: time-to-acknowledgement, time-to-verification, time-to-remediation, time-to-publication, advisory-update rate, coordinated-case rate, and finder-relationship continuity. The metric pack is the operating dashboard the executive layer reads against the standard.

Where SecPortal fits in an ISO/IEC 29147 programme

SecPortal is the operating layer for the disclosure case lifecycle, not a replacement for the policy hierarchy, the legal counsel relationship, or the coordinator engagement that the standard expects. The platform handles the case-side workstreams (intake, verification, triage, remediation, release coordination, post-release loop, advisory archive) so the artefacts the policy commits to are produced as structured records rather than reconstructed across email threads, ticketing systems, and document drives at audit time. The same workspace that hosts the disclosure case hosts the SAST, dependency analysis, authenticated DAST, external scanning, and continuous monitoring evidence the verification and remediation phases depend on.

  • Engagement management dedicated to the disclosure programme, with one engagement record per disclosure case so the intake, the verification, the remediation, the release, and the post-release loop sit on one record rather than being stitched together at audit time across email threads, ticketing systems, and document drives.
  • Findings management with CVSS 3.1 scoring, CWE tagging, and 300+ structured finding templates so the working severity, the affected-component reference, and the recommended remediation are captured against the case record rather than recomputed when the advisory is drafted.
  • Document management for the published vulnerability disclosure policy, the security.txt deployment evidence, the advisory archive, the coordination records, and the post-mortem write-ups, with version history per artefact so the policy refresh and the advisory updates produce a defensible audit trail.
  • AI report generation that turns the case record into the advisory draft, the post-release summary, and the quarterly programme review without recomputing the underlying record. The AI works against the structured finding, not against unstructured email content.
  • Activity log with CSV export that captures every state change on a disclosure case (intake, verification, owner reassignment, severity adjustment, embargo update, advisory publication, post-release update), so an internal auditor or external auditor can reconstruct the disclosure timeline without a multi-team excavation.
  • Team management with role-based access (owner, admin, member, viewer, billing) that keeps the PSIRT, AppSec, product engineering, customer support, and legal teams on the same workspace with appropriate scoping per role, plus MFA enforcement for accounts that touch the disclosure record.
  • Notifications and alerts that fire on disclosure-case state changes (new report received, verification status updated, embargo expiring, advisory published) so the programme operates against the policy clocks rather than relying on inbox vigilance.
  • Compliance tracking that reads the same evidence pack across ISO/IEC 29147, ISO/IEC 30111, the FIRST PSIRT Services Framework, the CISA CVD model, and the EU CRA disclosure obligations, so the cross-regime read is reconcilable rather than reconciled per audit.
  • Code scanning with Semgrep-based SAST and dependency analysis that surfaces internal-discovery findings into the same workspace the externally reported cases live in, so internal and external discovery feed one disclosure pipeline rather than two.
  • Client portal with branded delivery on a tenant subdomain that hosts the published advisory archive, the coordinated-disclosure pages, and the customer-facing remediation guidance behind a managed access surface where appropriate.

The case-side evidence (intake, verification, remediation, release, post-release) reads against operational workflows that already exist as named use cases. The PSIRT operating workflow carries the case-management discipline the disclosure record reads against. The vulnerability disclosure programme management workflow carries the published policy, the intake channel, and the finder-relationship operating trail. The zero-day and emergency vulnerability response workflow carries the accelerated-disclosure path for cases where a coordinated release window cannot be held and an emergency advisory is required. The security advisory request workflow covers the customer-driven advisory enquiry that arrives outside the finder-driven case load and feeds into the same advisory archive.

For internal security teams operating ISO/IEC 29147 as part of the wider product security baseline, the product security teams workspace bundles the platform with the engagement structure the disclosure cadence reads against. For GRC and compliance teams reading the disclosure evidence against ISO/IEC 27001, SOC 2, EU CRA, and the federal mandates, the GRC and compliance teams workspace covers the policy hierarchy, the evidence pack, and the audit cadence the standard expects. For CISOs and security leaders carrying the programme-level reporting on the disclosure posture, the CISOs and security leaders workspace covers the executive-layer reporting model that sits on top of the disclosure operating record.

For deeper reading on the disciplines this standard reads against, the vulnerability disclosure programme setup guide covers the practical setup walkthrough for the published policy, the intake channel, the coordination posture, and the safe-harbour language the standard expects. The CVE Numbering Authority guide covers the CVE issuance discipline that pairs with the advisory phase. The VEX guide covers the exploitability-statement artefact paired with SBOM that downstream consumers read alongside the advisory. The EU Cyber Resilience Act vulnerability handling guide covers the regulation that operationalises the ISO/IEC 29147 expectations for manufacturers placing products with digital elements on the EU market. The EU CRA framework page covers the regulatory scope and the parallel evidence package. The ISO 27001 framework page covers the wider ISMS context the disclosure programme sits inside. The ISO/IEC 27035 framework page covers the international incident management standard that pairs with 29147 and 30111 to form the ISO incident-and-disclosure trio for organisations that both operate an ISMS and ship products with disclosure obligations.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Phase 1: Receipt and intake

The vendor publishes a vulnerability disclosure policy, maintains a documented intake channel (security.txt, dedicated email, web form, or researcher portal), and operates a documented acknowledgement clock. Reports arrive in a structured intake record that captures the finder identity, the affected product and version, the reproduction steps, the supporting evidence, and any requested embargo or timeline.

Phase 2: Verification

The vendor verifies the report. Verification confirms the affected product and version, reproduces the issue in a controlled environment, captures the technical evidence, calibrates a working severity (typically CVSS 3.1 or CVSS 4.0 with environmental modifiers), and returns a verification status to the finder within the documented clock. Verification is the gate that turns a report into a tracked finding.

Phase 3: Remediation development

The vendor develops the remediation. The remediation may be a code patch, a configuration change, a workaround, an ecosystem-coordinated fix, or a documented advisory with no code change where the issue is not exploitable in shipped products. The phase carries the regression evidence, the affected-version matrix, the backport decisions, and the customer-facing impact assessment.

Phase 4: Release and advisory

The vendor publishes the advisory and ships the remediation. The advisory carries the affected and fixed versions, the severity assessment with the supporting vector, the recommended action, the finder credit where consented, the CVE identifier where appropriate, and the references to coordinating bodies. The release is timed against the disclosure policy, the embargo, and any coordinated multi-vendor disclosure.

Phase 5: Post-release loop

The vendor closes the disclosure with the finder, captures the lessons learned, updates the affected-version matrix as customers deploy the remediation, refreshes the advisory if material new information emerges, and feeds the case into the post-mortem record. The disclosure record stays open as a queryable artefact rather than archived behind a static PDF.

Pairing with ISO/IEC 30111

ISO/IEC 29147 covers the external interface (intake, finder communications, advisory publication). ISO/IEC 30111 covers the internal handling (triage, root-cause analysis, fix development, regression, release readiness). The two standards are designed to be operated together; the same case identifier walks across both records, with 29147-side artefacts as the externally visible interface and 30111-side artefacts as the internal operating record.

Coordination with external bodies

The standard addresses coordinated disclosure where the vulnerability touches multiple vendors, a supply chain, or critical infrastructure. Coordination involves a coordinating body (CISA, CERT/CC, sector ISACs, or other coordinators), an embargo timeline, the participating parties, and synchronisation points before a joint release. The coordination record is the artefact that reconstructs the cross-vendor timeline if the embargo breaks.

Audit evidence the programme produces

The minimum durable pack is the published policy with version history, the intake channel record, the case register with one record per disclosure, the finder communication log, the advisory archive with version history, the coordination records for multi-vendor cases, the post-release loop record, and the metric pack reporting against the policy clocks. The pack is the residue of the operating work rather than a separate compilation produced at audit time.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

AI-powered reports in seconds, not days

Every action recorded across the workspace

Collaborate across your entire team

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

Run an ISO/IEC 29147-aligned disclosure programme on one record

Hold the published policy, the intake record, the verification trail, the advisory archive, and the post-release loop on one workspace, then read the same record across ISO/IEC 29147, ISO/IEC 30111, EU CRA, CISA CVD, and the FIRST PSIRT Services Framework. Start free.

Get Started Free

No credit card required. Free plan available forever.