ISO/IEC 29147: ISO/IEC 29147 – Tutorial (about 60 minutes)

ISO/IEC 29147 is the international guidance on vulnerability disclosure: how a company that makes products or runs online services should receive reports of security weaknesses from outsiders, keep the people involved informed, and tell its users what to do once a fix or workaround exists. Product security teams, PSIRTs, cloud operators, open-source maintainers, security researchers, coordinators and buyers who write security clauses into contracts all use it. After this tutorial you will be able to explain the roles and steps of coordinated disclosure, write a sound vulnerability disclosure policy, plan how reports are taken in and answered, and decide what a good security advisory must contain.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC 29147:2018, "Information technology – Security techniques – Vulnerability disclosure", the second edition, published in October 2018 by ISO and IEC through joint subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). It replaced the first edition, ISO/IEC 29147:2014, which is withdrawn. ISO reviewed the 2018 edition and confirmed it in 2024. Europe adopted the 2018 text unchanged as EN ISO/IEC 29147:2020. A third edition is in preparation: ISO lists an approved work item (stage 20.00, registered 8 October 2025) with the proposed new title "Cybersecurity – Vulnerability disclosure processes", which will replace the 2018 edition when it is published. Until then the 2018 edition is the one in force, and this course teaches it. Verified 2026-10-29 from the ISO committee catalogue pages for the 2018 edition (listed as published, 32 pages) and for the edition 3 work item. Check the ISO catalogue for later progress before you cite an edition in a contract or policy.

Who this is for: engineers and product managers who have just been asked to "set up a security reporting process", members of a new product security incident response team (PSIRT), security operations staff at companies that run cloud or web services, open-source maintainers, compliance and procurement people who see "ISO/IEC 29147" in customer questionnaires or regulations, and security researchers who want to understand what a well-run vendor is trying to do with their report.

Prerequisites: none. A rough idea of what a software vulnerability is will help, but every term is explained when it first appears. This tutorial paraphrases the standard and does not reproduce its text; if you implement it formally, buy the official document from ISO, IEC or your national standards body.

By the end of this tutorial:

You will be able to explain why vendors need a planned way to receive and publish vulnerability information, and what ISO/IEC 29147 covers and deliberately leaves to ISO/IEC 30111.
You will be able to use the core vocabulary correctly, including finder, vendor, coordinator, vulnerability, remediation, mitigation, advisory and coordinated disclosure.
You will be able to describe the main parts of the standard: concepts, receiving reports, publishing advisories, coordination and the disclosure policy.
You will be able to design a report intake process with acknowledgement, initial assessment, tracking and secure, ongoing communication.
You will be able to list the information a useful advisory carries and explain when and how it should be released.
You will be able to explain how conformity with the guidance is judged, and why there is no ISO/IEC 29147 certificate for an organisation.
You will be able to place the standard next to ISO/IEC 30111, ISO/IEC 27002, NIST SP 800-216, RFC 9116, CVE and the EU Cyber Resilience Act.

Lesson 1 – Origins, purpose and scope

The problem the standard solves

Every product that contains software will, sooner or later, turn out to contain a security weakness that its makers did not know about. Very often the first person to notice is not an employee. It may be a customer's security team running a penetration test, a university researcher, a hobbyist taking a router apart, a bug bounty hunter, another vendor that uses the same library, or a national cybersecurity agency that saw the weakness being abused in an attack. That person now holds information that is valuable and dangerous at the same time. Used well, it lets the vendor fix the flaw before criminals find it. Handled badly, it can leak, be ignored, or be published before any fix exists, leaving every user exposed.

Before vendors had published processes, the experience of reporting a vulnerability was often miserable. A researcher would email a general support address and get a reply about resetting a password. Or the report would sit unread for months. Some researchers were threatened with legal action for simply telling a company about a problem. Frustrated, some went straight to the press or posted full details online, a practice called full disclosure, so that the vendor would be forced to act. Users, meanwhile, often learned about serious flaws from news articles rather than from the vendor, with no clear guidance on what to do.

The security community gradually converged on a middle path called coordinated vulnerability disclosure: the finder tells the vendor privately, the vendor investigates and prepares a fix, and the details are made public in a planned way once users can protect themselves. ISO/IEC 29147 turns this practice into international guidance for the vendor side. It tells a vendor how to make itself easy to reach, how to treat the person reporting, how to work with other parties, and how to communicate the outcome to the people who use its products and services.

Scope in one paragraph

The standard is written for vendors: any organisation that develops, supplies or operates products and online services and chooses to practise vulnerability disclosure. It gives requirements and recommendations for two activities that face the outside world: receiving reports about potential vulnerabilities, and disclosing information about how to fix or work around them. It also defines the terms used, explains the concepts and roles, gives advice on policy and on coordination when several vendors are involved, and contains informative annexes with example policies, techniques and communications. Its aim is to reduce the risk that a vulnerability is exploited, and so to support users in managing technical vulnerabilities in the systems they run.

What it leaves to its companion

Between "we received a report" and "we published an advisory" lies a lot of internal work: reproducing the problem, judging its severity, finding the root cause, building and testing a fix, and deciding how to ship it. ISO/IEC 29147 does not cover that internal work. Its companion standard, ISO/IEC 30111 (Vulnerability handling processes), does. The two are designed as a pair: ISO's own summary of ISO/IEC 29147 points to ISO/IEC 30111 for everything that happens between receiving a report and disclosing remediation information, so you are expected to use them together. A useful way to remember the split: 29147 is about the conversation with the outside world, 30111 is about the work inside the building.

From 2014 to 2018 and beyond

The first edition appeared in 2014. The 2018 edition is a revision of it, and ISO/IEC 30111 was revised in turn in 2019. Like the first edition, it covers online services (software a vendor runs for customers, such as a cloud application) as well as products that customers install themselves. Since then the subject has moved from good practice to legal expectation in several places. The United States federal government requires its agencies to publish disclosure policies, and the EU Cyber Resilience Act expects manufacturers of products with digital elements to have a coordinated vulnerability disclosure policy and a reporting contact. Some of these documents point to the ISO/IEC pair directly: the US IoT Cybersecurity Improvement Act of 2020 asked for federal disclosure guidelines aligned with ISO/IEC 29147 and ISO/IEC 30111, and NIST SP 800-216 is written to be used together with both. That is one reason the standard now appears so often in procurement questionnaires. The planned third edition is expected to update the guidance to this new environment.

Lesson 2 – Key concepts and vocabulary

Disclosure conversations go wrong quickly when the parties use words differently. The definitions below are explained in plain language; the standard's own definitions are worded differently and are worth reading in the official text.

Vulnerability – a weakness in a product or online service that someone could use to break its security, for example to read data they should not see, run their own code, or stop the service working.
Potential vulnerability – a reported problem that has not yet been confirmed. Many reports turn out to be duplicates, configuration issues or not security problems at all, so the vendor treats a report as potential until it has verified it.
Vendor – the organisation responsible for a product or service and for fixing it. A vendor can be a company, an open-source project, or a government body that builds its own systems.
Finder – the person or organisation that discovers a potential vulnerability. Finders include independent researchers, customers, academics, other vendors and automated scanning services.
Reporter – whoever tells the vendor about the potential vulnerability. Usually the finder, but sometimes a coordinator or another party passes the report on.
Coordinator – a trusted third party that helps finders and vendors communicate, especially when several vendors are affected or when one side cannot reach or trust the other. National CSIRTs, CERT/CC and some industry bodies act as coordinators.
User – anyone who uses or operates the affected product or service and needs to act on the vendor's information: home users, enterprise IT teams, integrators and other vendors who embed the component.
Remediation – a change that removes the vulnerability, such as a software update, a patched release or a fix deployed by the vendor to its online service.
Mitigation – an action that reduces the risk without removing the root cause, for example a configuration change, disabling a feature or blocking a network port, typically used until a remediation is available.
Vulnerability advisory – the vendor's published notice that tells users about a vulnerability, which products or services are affected, how serious it is and what to do. Also called a security advisory or security bulletin.
Vulnerability disclosure – the overall process through which vendors and finders share vulnerability information so that risk to users can be reduced. In this standard it covers receiving reports and publishing remediation information.
Coordinated vulnerability disclosure (CVD) – disclosure in which the parties agree to share details privately first and publish when users can act, rather than publishing before the vendor has had a chance to respond.
Vulnerability disclosure policy – the public statement in which a vendor explains how to report vulnerabilities to it, what reporters can expect, and how the vendor publishes information.
Vulnerability handling process – the vendor's internal process of investigating, triaging and remediating a reported vulnerability, described by ISO/IEC 30111.
Exploit – code or a technique that uses a vulnerability. A flaw that is being actively exploited is far more urgent than one that is only theoretical.
PSIRT – a product security incident response team: the function inside a vendor that runs disclosure and handling. Small vendors may not have a dedicated team, but someone still has to own the role.

Roles are hats, not job titles

One of the most useful ideas in the standard is that one organisation can play several roles at once. A large software company is a vendor of its own products, a user of thousands of third-party components, and often a finder when its engineers discover flaws in someone else's code. A cloud provider is a vendor of its service and a user of the open-source software inside it. When your own team finds a bug in a library you depend on, you are the finder and the library's maintainers are the vendor, and you should behave the way you would want a finder to behave towards you.

Figure 1 – The stakeholder roles in coordinated disclosure and how vulnerability information flows between them.

Why private first, public later

The heart of coordinated disclosure is a trade-off about timing. If details are published before a fix exists, attackers get a head start and defenders have nothing to apply. If details are never published, users cannot judge their risk, cannot tell whether they are protected, and vendors face no pressure to fix anything. Coordinated disclosure balances these by keeping details confidential for a limited time while the vendor works, then publishing enough for users to act. The standard is written from that viewpoint: the goal of every step is to reduce harm to users, not to protect the vendor's reputation or the finder's credit, although both deserve respect.

Products and online services behave differently

For a product that customers install, such as firmware in a camera or a desktop application, fixing the vendor's code is only half the job: every customer must install the update, and some never will. An advisory is essential because users must take action. For an online service the vendor runs, the vendor can often deploy the fix itself, and users may have nothing to do. That changes what needs to be published and when. The standard recognises both cases and asks vendors to think about what their users actually need to know, which for online services may be a short notice, a statement in a transparency report, or a notice to customers whose data might have been exposed.

Lesson 3 – Structure of the standard

ISO/IEC 29147:2018 is a short document (32 pages in ISO's catalogue). After the usual opening clauses (scope, normative references, terms and definitions, and abbreviated terms) it has five main technical clauses, followed by informative annexes. The clause numbers below follow the 2018 edition; the titles are given in paraphrase.

Clause 5 – Concepts

This clause sets the scene. It explains vulnerabilities in products and in online services, the roles of users, vendors, finders and coordinators, and how the disclosure process meets the vulnerability handling process of ISO/IEC 30111. It also covers the relationship to other standards (for example the vulnerability management guidance in ISO/IEC 27002), the exchange of information during disclosure, the need to keep that information confidential, what advisories are for, and how exploitation and risk affect decisions. If you read only one clause to understand the mindset of the standard, read this one.

Clause 6 – Receiving vulnerability reports

This clause describes the vendor's front door. A vendor should be able to receive reports, monitor the channels it publishes, track every report, acknowledge receipt, make an initial assessment, carry out further investigation, and keep communicating with the reporter throughout. It also covers when to involve a coordinator and the operational security needed to protect sensitive report data. Lesson 4 turns this into a working process.

Clause 7 – Publishing vulnerability advisories

This clause covers the vendor's announcement. It discusses when to publish, what an advisory should contain, how to communicate it, which formats to use (including machine-readable ones), and how users can be sure that both the advisory and the fix really came from the vendor. Lesson 4 lists the typical contents.

Clause 8 – Coordination

This clause deals with situations that involve more than one vendor, which are now the norm because almost all products are built from shared components. It covers vendors that play several roles at once, how vendors report vulnerabilities to each other, and how information should be passed to other affected vendors in a way that keeps it confidential and leads to a joint, well-timed release.

Clause 9 – Vulnerability disclosure policy

This clause explains what a vendor's public policy should say. The standard sorts the possible contents into tiers. At minimum, the policy has to tell people how to contact the vendor. Beyond that it recommends further elements, such as what information to include in a report, how to communicate securely, what response the reporter can expect, which products and services are in scope, how the vendor publishes advisories, and how it recognises finders. Other elements, such as legal statements and disclosure timelines, are treated as optional choices that each vendor makes for itself.

The annexes

The informative annexes give examples: sample disclosure policies and techniques, and sample communications such as advisories. They are helpful starting points, but they are illustrations, not templates you must copy word for word. The standard also uses the usual ISO verbal forms: "shall" marks a requirement, "should" a recommendation, and "may" a permission. Because vendors adopt the guidance voluntarily, the requirements bind only those who claim to follow it.

Figure 2 – The main parts of ISO/IEC 29147:2018 and where ISO/IEC 30111 fits between receiving a report and publishing an advisory.

How the clauses connect

Read the clauses as one journey. The policy (clause 9) invites reports. Receiving (clause 6) gets them safely through the door and keeps the reporter informed. The internal handling defined in ISO/IEC 30111 verifies the problem and produces a remediation. Publishing (clause 7) tells users what to do. Coordination (clause 8) runs alongside whenever another vendor's product, or a shared component, is involved. The concepts (clause 5) explain why each step exists. Keeping this picture in mind stops a common mistake: treating the disclosure policy page as the whole job, when it is only the invitation.

Lesson 4 – How it works in practice

This lesson turns the structure into the day-to-day work of a vendor. It follows a single report from the moment it arrives to the moment the vendor's advisory is out and the reporter has been thanked.

Preparation: before the first report arrives

ISO/IEC 30111 starts with preparation, and disclosure depends on it. Before inviting reports, a vendor needs an owner for the process, a place to track reports, an agreed way to rate severity, people in engineering who will respond when asked, and a way to publish advisories. It also needs to know what it sells and what is inside: an up-to-date inventory of products, versions and third-party components (often kept as a software bill of materials, or SBOM) makes it possible to answer "are we affected?" in hours rather than weeks. Finally, it needs management support, because fixing a vulnerability sometimes means delaying a feature release.

Step 1 – Be easy to find

Finders will not search for long. A good vendor publishes a clear security contact on its website, typically a dedicated security page and an email address or web form that goes directly to the people who handle reports. Many vendors also publish a security.txt file at /.well-known/security.txt on their web domains, a simple text format defined in RFC 9116 that tells researchers where to report and where the policy is. The channel must be monitored, including during holidays, and it should support confidential communication, for example by offering an encryption key or an authenticated upload portal.

Step 2 – Acknowledge quickly

The standard expects the vendor to confirm receipt of a report within a reasonable time and to tell the reporter what to expect next. A prompt human acknowledgement does more to prevent premature public disclosure than any legal statement, because the most common reason finders go public is silence. The acknowledgement should give a tracking reference, name a contact or team, and say roughly when the reporter will hear more. An automatic reply is a start, but a person should follow up.

Step 3 – Initial assessment

Next the vendor decides what it has received. Is it a security issue at all? Is it in scope, meaning a product or service the vendor is responsible for? Is it a duplicate of something already known? Does it describe a problem in someone else's component, in which case the vendor may need to tell that other vendor or a coordinator? Is there evidence that it is already public or being exploited? This first look determines priority. A report of active exploitation of a remote code execution flaw in an internet-facing product goes straight to the top of the queue.

Step 4 – Investigation and handling (the 30111 part)

If the report looks valid, it passes into the internal vulnerability handling process. Engineers try to reproduce it, identify the root cause, find all affected versions and products (including other products that share the same code), judge severity, and develop and test a remediation or at least a mitigation. Severity is often expressed using the Common Vulnerability Scoring System (CVSS), published by FIRST, although the standard does not require any particular scoring system. Throughout this work, information about the vulnerability is kept on a need-to-know basis.

Step 5 – Keep talking to the reporter

Ongoing communication is not a courtesy; it is part of the process. The vendor should update the reporter when the report is confirmed or rejected, when a fix is planned, if the plan slips, and before publication. If the vendor disagrees with the reporter about severity or about whether something is a vulnerability at all, it should explain why. If the conversation breaks down, involving a coordinator is often the best way to rebuild trust. Reporters, for their part, are asked by most policies to give the vendor reasonable time, avoid harming users or data, and share details only privately until the agreed date.

Figure 3 – The life of a single vulnerability report at a vendor, including the exits for reports that are rejected or belong to someone else.

Step 6 – Publish the advisory

An advisory is how the vendor reaches users who never saw the original report. The standard lists the kinds of information a good advisory contains. In summary, an advisory usually includes:

a unique identifier from the vendor and, where one is assigned, a Common Vulnerabilities and Exposures (CVE) identifier, so that users and tools can match it across sources;
a title, a date of first publication and a revision history so readers know whether they are looking at the latest version;
a short overview that tells a busy reader whether they should care;
the affected products, versions and services, and, just as usefully, the unaffected ones;
a description of the vulnerability and its impact, in enough detail to judge risk but not so much that it becomes an attack recipe;
a severity rating, and the scoring method used;
remediation and mitigation instructions, including where to get the update and how to verify it;
credit to the finder, if they want it, and references to related information;
contact details and any terms of use.

Advisories should be easy to find (a stable security advisories page is the usual home), available in the languages the vendor's users need, and published in human-readable form. More and more vendors also publish machine-readable versions, for example in the OASIS Common Security Advisory Framework (CSAF) format, so that customers can process advisories automatically. The standard also stresses authenticity: users must be able to trust that an advisory and a downloaded fix really come from the vendor, for example through HTTPS publication and digital signatures, because attackers sometimes imitate vendors to spread malware disguised as patches.

Timing of publication

Normally the vendor publishes the advisory when a remediation is available, so that users can act at once. The standard recognises that waiting is not always right. If the vulnerability is already public or being actively exploited, users may need an advisory with mitigations straight away, even before a full fix exists. When several vendors are involved, publication is ideally synchronised so that no one's users are left exposed by another vendor's early announcement. ISO/IEC 29147 deliberately does not set a fixed deadline such as 90 days; each vendor decides whether to state a target timeline in its policy.

Step 7 – After release

Work does not stop when the advisory is published. Users ask questions, someone reports that the fix is incomplete, or a variant of the same flaw turns up. Advisories are updated, with the revision history showing what changed. The vendor also looks back at the case: how long each stage took, whether the reporter was kept informed, and whether the root cause points to a weakness in its development process that should be fixed so that similar flaws do not recur. That feedback loop connects disclosure to secure development practice.

Writing the vulnerability disclosure policy

The disclosure policy is the public face of all of this. A clear policy usually covers:

how to report, through which channels, and how to communicate securely;
what to include in a report: the product and version, a description of the issue, steps to reproduce, and the reporter's contact details;
what the reporter can expect: acknowledgement, updates and a rough idea of response times;
which products, services and types of issue are in scope, and which are not;
how and where the vendor publishes advisories, and whether it requests CVE identifiers;
how the vendor credits finders, and whether it offers any reward;
optionally, legal assurances (for example, that the vendor will not pursue good-faith research that follows the policy) and any disclosure timeline the vendor commits to.

Good policies are short, written in plain language and kept up to date. A policy that promises a reply in two days and then takes two months does more harm than one that promises ten days and keeps its word.

Operational security

Vulnerability reports are some of the most sensitive data a vendor holds: a list of unfixed ways to attack its customers. The standard therefore expects vendors to protect them. Access to the tracking system should be restricted, reports should not be pasted into public bug trackers or broad chat channels, encryption should be used when sending details to partners, and staff should know not to discuss unpublished vulnerabilities outside the need-to-know group. A leaked report can turn a private problem into a public emergency.

Lesson 5 – Assessment, certification and compliance

There is no ISO/IEC 29147 certificate for organisations

ISO/IEC 29147 is not a management system standard like ISO/IEC 27001, and no accredited certification scheme exists for it. You cannot be "ISO/IEC 29147 certified" in the way a company can be certified to ISO 9001 or ISO/IEC 27001. Be wary of any marketing that claims otherwise. What organisations can do is state that their disclosure practice follows or is aligned with ISO/IEC 29147, and let customers, auditors or regulators check that statement.

How alignment is judged in practice

Because the document contains a small number of requirements and many recommendations, assessment is usually a structured review rather than a pass or fail audit. Common forms are:

Self-assessment – the vendor compares its policy, intake process and advisories against each clause, records gaps and fixes them. This is the most common and most useful form.
Customer or second-party assessment – buyers ask for evidence in security questionnaires or contract reviews: a link to the disclosure policy, a security contact, sample advisories, average response times, and a description of the handling process.
Third-party review – consultants, internal audit or the auditor of a wider scheme examine disclosure as part of something larger, such as an ISO/IEC 27001 audit of technical vulnerability management, a secure development assessment, an IEC 62443 product security assessment for industrial products, or a regulator's review.

What evidence an assessor looks for

Whoever does the checking, the evidence tends to be the same: a published, current policy and contact; records showing reports are tracked, acknowledged and followed up; examples of advisories with the expected contents; signs that reports are protected; a defined link to the internal handling process; and data on timing, such as time to acknowledge and time to remediate. An assessor will usually sample a few real cases from intake to advisory rather than reading only the policy. A beautifully written policy with an unmonitored mailbox behind it fails the most important test.

Where it becomes mandatory

The standard itself is voluntary, but its ideas are increasingly required by law, regulation or contract. In the United States, CISA Binding Operational Directive 20-01 (2020) requires federal civilian agencies to publish vulnerability disclosure policies, and NIST SP 800-216 (2023) recommends federal disclosure guidelines that draw on the same practices. In the European Union, the Cyber Resilience Act requires manufacturers of products with digital elements to handle vulnerabilities throughout the support period, including having a coordinated vulnerability disclosure policy, a contact address for reports and a practice of publishing information about fixed vulnerabilities, and it adds duties to report actively exploited vulnerabilities to the authorities. The NIS2 Directive gives national CSIRTs a coordinator role. Sector regulators, such as those for medical devices, also expect manufacturers to accept and act on vulnerability reports. In each case the regulation sets the obligation and ISO/IEC 29147 is a well-known way to meet it, but you should read the specific legal text for exact duties and deadlines, which the standard does not define.

Measuring your own process

Useful internal measures include the time from receipt to acknowledgement, the time to initial assessment, the share of reports that receive a status update at agreed intervals, the time from confirmation to a published remediation by severity, the number of advisories that later had to be corrected, and reporter satisfaction. Track them over time and use them in management reviews; the point is improvement, not a single score.

Lesson 6 – Worked example

This example follows a fictional mid-sized company, Brightline Meters, through building a disclosure capability and handling its first difficult case. It is invented for teaching, but every step is typical.

The starting point

Brightline makes smart electricity meters for utilities, with firmware in each device, a mobile app for installers and a cloud dashboard that utilities use to read meters. It has about 400 staff. Until now, security issues have arrived randomly: a utility customer emailed an account manager, a researcher posted a message on social media tagging the company, and a support ticket mentioned "a hacker" without details. A large utility tender now asks whether Brightline follows ISO/IEC 29147 and ISO/IEC 30111, and the EU market rules for connected products are approaching. The head of engineering is asked to fix this within three months.

Month 1 – Preparation

The head of engineering appoints a product security lead and forms a small virtual PSIRT: the security lead, one senior engineer from each of firmware, mobile and cloud, a support manager, a communications manager and a lawyer on call. They buy the two standards and read clause 5 of ISO/IEC 29147 together to agree on vocabulary. They then build the foundations:

a private tracker project for vulnerability reports, with access limited to the PSIRT;
a component inventory for each firmware and app release, generated as an SBOM in the build pipeline;
a severity method based on CVSS, with Brightline's own notes on what "critical" means for meters that control power supply;
an internal handling procedure following ISO/IEC 30111, with target times for each severity level;
an advisory template covering the elements listed in Lesson 4, and a plan to publish CSAF files later.

Month 2 – Opening the front door

Brightline publishes a security page with its vulnerability disclosure policy. The policy names a dedicated email address and a web form, offers an encryption key, explains what to include in a report, promises an acknowledgement within three working days and status updates at least every two weeks, and lists the products and services in scope (meter firmware, the installer app, the dashboard) and what is out of scope (customer-owned networks, physical attacks requiring removal of the utility seal). It states that Brightline will not take legal action against good-faith research that follows the policy, explains that advisories will be published on a stable advisories page, and says finders will be credited if they wish. A security.txt file points to the contact and policy. Support and account managers are trained to forward anything that sounds like a security report to the PSIRT the same day.

Month 3 – The first serious report

A university researcher reports, through the web form, that meters accept firmware updates over the local optical port without checking a signature properly, so someone with physical access to the meter's front panel could install modified firmware. The PSIRT acknowledges within one day, gives a tracking number and names the security lead as contact. The initial assessment finds the report plausible, in scope and not public. The firmware engineer reproduces the problem in two days and finds the root cause: a verification step that can be bypassed with a malformed update header.

While investigating, the engineer notices that the vulnerable update-handling code comes from a bootloader library supplied by a chip vendor and used by at least two other meter manufacturers. Brightline is now a vendor of its own product and a finder for the chip vendor. Following clause 8, it reports the library flaw privately to the chip vendor and asks the national CSIRT to act as coordinator, because the other affected manufacturers are competitors Brightline has no confidential channel with.

Figure 4 – The multi-party coordination in the worked example, from the private report to a synchronised publication.

Remediation and timing

The chip vendor delivers a corrected library in five weeks. Brightline builds new firmware, tests it with two pilot utilities, and plans a staged update through the utilities' head-end systems. Because the attack needs physical access and the meters sit behind sealed covers, the PSIRT rates the issue as high rather than critical, and agrees with the researcher and the coordinator on a joint publication date eleven weeks after the original report. The researcher had hoped to present the work at a conference earlier; the security lead explains the update schedule, and the researcher agrees to wait, because they have been kept informed at every step and the reason for the delay is clear.

In week eight a utility security team reports suspicious tampering with meters in one region. The PSIRT treats this as possible exploitation, tells the coordinator, and Brightline sends a private notice with mitigations (increased seal inspections and alerting on unexpected firmware versions) to all utility customers, without public details. No exploitation is confirmed, and the joint date holds.

The advisory

On the agreed day Brightline, the chip vendor and the other manufacturers publish their advisories within the same hour. Brightline's advisory carries its own identifier and the CVE identifier the coordinator arranged, lists the affected meter models and firmware versions and the fixed version, describes the issue at a level that lets utilities assess risk without explaining exactly how to build malicious firmware, gives a CVSS score with the vector, explains the update procedure and the interim mitigations, credits the researcher by name, and links to the chip vendor's advisory. It is published on the HTTPS advisories page with a signed CSAF file, and the firmware image is signed so utilities can verify it.

After release

Two weeks later a utility asks whether a meter model not listed is affected. The PSIRT checks the SBOM, confirms it uses a different bootloader, and updates the advisory with an "unaffected products" line and a revision note. At the case review the team finds that acknowledgement and coordination went well, but that it took four days to work out which firmware versions shipped the library. They automate that lookup and add signature-bypass testing to the firmware test suite. When the next utility tender arrives, Brightline can answer the ISO/IEC 29147 question with evidence: the policy, the tracking records, the advisory and the timeline.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 29147 sits in a family of documents about vulnerabilities. Knowing the neighbours helps you use each for its proper job and avoid duplicate work.

Standard or framework	Owner	Main focus	How it relates to ISO/IEC 29147
ISO/IEC 30111	ISO/IEC JTC 1/SC 27	The vendor's internal vulnerability handling: preparation, verification, remediation, release and follow-up	Companion standard designed to be used with 29147; covers the internal work between receiving a report and publishing an advisory
ISO/IEC 27002 and ISO/IEC 27001	ISO/IEC JTC 1/SC 27	Security controls and the ISMS, including management of technical vulnerabilities (control 8.8 in the 2022 editions)	Covers the user side, applying vendor fixes inside an organisation; 29147 covers the vendor side that produces the information users act on
ISO/IEC 27035 series	ISO/IEC JTC 1/SC 27	Information security incident management	Exploitation of a vulnerability can become an incident; disclosure and incident teams need agreed hand-offs
NIST SP 800-216	NIST (USA)	Recommended vulnerability disclosure framework for US federal agencies	Applies the same ideas to government systems and adds federal coordination roles
CERT Guide to Coordinated Vulnerability Disclosure	CERT/CC, Carnegie Mellon SEI	Practical, free guidance on CVD from the viewpoint of finders, vendors and coordinators	A readable companion that explains the practice in depth; not a standard
RFC 9116 (security.txt)	IETF	A simple file that tells researchers how to contact a domain's security team	A practical way to publish the contact point the policy promises
CVE, CVSS and CSAF	CVE Program (MITRE/CISA), FIRST, OASIS	Identifiers, severity scoring and machine-readable advisories	Common building blocks for the advisory contents 29147 describes
FIRST PSIRT Services Framework	FIRST	The services a product security team provides and how to organise them	Helps a vendor organise the team that operates 29147 and 30111
EU Cyber Resilience Act	European Union	Legal security requirements for products with digital elements, including vulnerability handling and reporting	Creates legal duties that a 29147-aligned process helps meet; the law, not the standard, sets deadlines

Disclosure and handling as one capability

In practice no vendor runs "a 29147 process" and "a 30111 process" separately. They run one vulnerability management capability whose outside edges follow ISO/IEC 29147 and whose inside follows ISO/IEC 30111. Write one procedure, assign one owner and keep one tracking record per case, and refer to both standards when describing it.

Figure 5 – One end-to-end vulnerability capability, showing which standard guides each stage from the vendor's preparation to the user applying the fix.

Common pitfalls and best practices

Pitfalls

A contact that leads nowhere. Publishing a security address that nobody monitors, or a form that drops attachments, is worse than having none, because it creates expectations and then silence.
Treating reporters as attackers. Threatening legal action against good-faith researchers discourages future reports and often leads to public disclosure without the vendor's input.
Silence during the fix. Going quiet for weeks while engineers work leaves the reporter guessing. Most premature disclosures follow a breakdown in communication, not bad intent.
Ignoring shared components. Fixing your own copy of a vulnerable library and staying quiet leaves other vendors' users exposed and may later expose your fix as a pointer to the unfixed products.
Vague or missing advisories. Shipping a "stability improvement" update that silently fixes a serious vulnerability leaves users unable to judge urgency, so many will not update.
Leaking unpublished details. Copying reports into public issue trackers, broad chat channels or unencrypted email to partners can hand attackers a ready-made target.
Policy without process. Writing an impressive policy page but no internal handling procedure means reports arrive with no one to fix them.

Best practices

Make reporting effortless. One clear security page, a monitored address or form, an encryption option and a security.txt file on each domain.
Acknowledge fast and update on a rhythm. Commit to realistic times in the policy and track them; a short, honest update beats a polished one that comes late.
Know what is inside your products. Maintain SBOMs and a product and version inventory so that you can tell quickly who is affected.
Use a coordinator when you need one. Bring in a national CSIRT or similar body for multi-vendor cases, unresponsive vendors or a breakdown in trust.
Write advisories for the reader. Lead with what is affected and what to do, use CVE identifiers, publish in a stable place, and add machine-readable CSAF where your customers can use it.
Protect authenticity. Publish over HTTPS, sign advisories and updates, and tell users how to verify them.
Close the loop. Review each case, measure timings and feed root causes back into secure development so the same class of flaw becomes rarer.
Credit finders. Public thanks, if the finder wants it, builds the relationships that bring you the next report first.

Summary and key takeaways

ISO/IEC 29147:2018 is the current edition of the international guidance for vendors on receiving vulnerability reports and publishing remediation information; a third edition is under development.
It covers the outward-facing parts of vulnerability management; the internal investigation and fixing work is described by its companion, ISO/IEC 30111, and the two are meant to be used together.
The main roles are finder, vendor, coordinator and user, and one organisation can hold several of them at once.
Coordinated disclosure keeps details private while the vendor works and publishes when users can act, with earlier publication of mitigations if a flaw is already public or exploited.
A good intake process is easy to find, acknowledges quickly, assesses and tracks every report, protects the data and keeps the reporter informed.
A good advisory identifies the issue, the affected and fixed versions, severity, remediation and mitigation, credit and revision history, and can be trusted as authentic.
There is no organisational certification to ISO/IEC 29147; alignment is shown with evidence and is increasingly expected by regulations such as the EU Cyber Resilience Act.

Reflection questions

If a security researcher wanted to report a flaw in your organisation's main product today, how would they find out where to send it, and who would read it within the next week?
Which components in your products come from other vendors or open-source projects, and how would you notify those parties if your team found a flaw in one of them?
Draft the "what to expect" section of a disclosure policy for your organisation. Which response times could you honestly promise, and what would you need to change to promise better ones?
Think of a vulnerability in an online service you run that you could fix without any customer action. What, if anything, would you publish about it, and why?
Your organisation receives a report and a deadline from a finder that is shorter than your release cycle allows. How would you handle the conversation, and at what point would you involve a coordinator?