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

ISO/IEC 30111 is the international standard on vulnerability handling: what a supplier of a product or online service does internally, from the moment someone reports a possible security weakness until a fix is in customers' hands and the lessons have been learned. It is used by product security teams, software and hardware vendors, cloud service providers, open-source projects and anyone whose customers depend on them to fix security flaws. After this tutorial you will be able to explain the phases of the vulnerability handling process, set up the policy and organisation behind it, handle a report from intake to post-release review, and see how the standard fits with ISO/IEC 29147 and current regulation.

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 30111:2019, the second edition, titled "Information technology — Security techniques — Vulnerability handling processes". It was published on 1 October 2019 by ISO and IEC through their joint committee ISO/IEC JTC 1/SC 27 and replaced the first edition of 2013. After its systematic review the committee decided to revise it (ISO stage 90.92, "to be revised"). A third edition is being drafted as ISO/IEC WD 30111.2 with the provisional title "Cybersecurity — Vulnerability handling and disclosure processes"; it is at working-draft stage, is not published, and its content may still change. The companion standard ISO/IEC 29147:2018 is also being revised. This tutorial teaches the 2019 edition. Verified 2026-10-29 against ISO's public catalogue data.

Who this is for: engineers and engineering managers who build products or services, members of a product security incident response team (PSIRT), security and quality managers, support and communications staff who talk to customers during security events, and compliance professionals preparing for supplier audits or new product-security laws. You do not need to be a security researcher; the standard is mainly about organisation and process, not exploit techniques.

Prerequisites: none. A general idea of how software is released and supported helps. Every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why vulnerability handling needs a defined process and what ISO/IEC 30111 covers that ISO/IEC 29147 does not.
You will be able to use the core vocabulary correctly: vulnerability, finder, vendor, coordinator, PSIRT, remediation, mitigation, advisory and supply chain roles.
You will be able to describe the structure of the standard: the policy and organisational framework, the six handling phases, process monitoring, confidentiality and supply chain handling.
You will be able to walk a report through preparation, receipt, verification, remediation development, release and post-release, including the legitimate reasons for closing a case early.
You will be able to explain how conformance is checked in practice and why there is no certificate issued against ISO/IEC 30111 itself.
You will be able to apply the process to a realistic multi-party case involving a third-party component.
You will be able to compare ISO/IEC 30111 with ISO/IEC 29147, IEC 62443-4-1, the FIRST PSIRT Services Framework and NIST SP 800-216.

Lesson 1 – Origins, purpose and scope

The problem the standard solves

Every product that contains software has security weaknesses that nobody has found yet. Sooner or later someone finds one: an external researcher, a customer, a penetration tester hired by a customer, a university team, an automated scanner, or an engineer inside the company. What happens next decides whether users are protected or harmed. If the report disappears into a general support inbox, if engineers argue for weeks about whether it is "really" a problem, or if a fix is shipped silently without telling anyone, users stay exposed and the person who reported it may lose patience and publish the details. Attackers read those publications too.

Organisations that handled reports well in the early 2000s, such as large operating-system and network-equipment vendors, built dedicated teams and repeatable procedures. Organisations that handled them badly often learned through public embarrassment. ISO/IEC 30111 captures the good practice so that any supplier, large or small, can build a process that works the first time rather than after an incident.

Two companion standards

The work around a reported vulnerability has an external face and an internal engine. The external face is how a supplier receives reports from the outside world and later tells users about fixes; that is covered by ISO/IEC 29147, "Vulnerability disclosure". The internal engine is how the supplier investigates, prioritises, fixes and releases; that is ISO/IEC 30111. The two were written to be used together, and they share vocabulary and the same overall picture of the process. NIST, in its federal vulnerability disclosure guidance, describes 29147 as covering reporting and advisories and 30111 as covering the handling of a reported vulnerability, and refers to both as a pair.

Figure 1 – How the work divides between ISO/IEC 29147 (the external interface) and ISO/IEC 30111 (the internal handling engine).

Scope in plain words

The 2019 edition gives requirements and recommendations for processing and remediating potential vulnerabilities that have been reported in a product or a service. It applies to vendors, a word the standard uses broadly: any organisation or individual that develops, provides or maintains a product or service and is responsible for fixing it. That includes commercial software companies, device makers, cloud and SaaS providers, system integrators who ship combined solutions, and open-source maintainers.

Three points about the scope matter for beginners. First, the standard is about vulnerabilities in what you supply, not about patching the systems you run for yourself. Managing vulnerabilities in your own IT estate is called technical vulnerability management and is addressed by ISO/IEC 27002 and ISO/IEC 27001 Annex A. Second, "reported" includes reports from inside the organisation as well as from outside: a flaw found by your own fuzzing team still needs to be handled, fixed and usually disclosed. Third, the standard describes processes and organisation, not technical methods for finding or exploiting bugs.

From 2013 to 2019 and beyond

The first edition of 2013 was a short set of guidelines on how a vendor should process and resolve potential vulnerability information in a product or online service. The 2019 edition, of similar length, rephrased its scope as requirements and recommendations and was revised to work alongside the 2018 edition of ISO/IEC 29147. In broad terms it gives more weight to what must be in place beforehand (a preparation phase and a policy and organisational framework), speaks of "remediation" for the work of producing a fix or other protective measure, and addresses vulnerabilities that cross organisational boundaries in the supply chain. If you work from the 2013 text, check the current edition rather than assuming the two match clause by clause. The revision now in progress has a provisional title that mentions both handling and disclosure, which suggests closer integration with 29147, but until a draft reaches enquiry stage it is wise not to plan around details.

Lesson 2 – Key concepts and vocabulary

The terms below are explained in our own words. They are consistent with how ISO/IEC 30111 and ISO/IEC 29147 use them, but they are not the official definitions; buy the standard for those.

Vulnerability – a weakness in a product or service that can be exploited to harm confidentiality, integrity or availability. A software bug becomes a vulnerability when it has security consequences.
Potential vulnerability – a reported issue that has not yet been confirmed. Every report starts as a potential vulnerability until verification shows otherwise.
Vendor – the person or organisation responsible for a product or service and for fixing it, whether it sells it, gives it away or runs it as a service.
Finder – whoever discovers a potential vulnerability. A reporter is whoever tells the vendor; often the same person, sometimes a third party passing on someone else's finding.
Coordinator – an optional trusted intermediary, such as a national CSIRT or the CERT Coordination Center, that helps when several vendors are affected, when a vendor cannot be reached, or when parties disagree.
PSIRT – product security incident response team: the vendor function that owns vulnerability handling for products, as opposed to a corporate CSIRT that protects the company's own IT. In a small company the PSIRT may be two people with other jobs.
Vulnerability handling – the vendor's internal work of investigating, remediating and releasing fixes for reported vulnerabilities; the subject of ISO/IEC 30111.
Vulnerability disclosure – the exchange of information about vulnerabilities between finders, vendors, coordinators and users, including the published advisory; the subject of ISO/IEC 29147.
Coordinated vulnerability disclosure (CVD) – the practice of keeping vulnerability details limited to the people who need them until a remediation is available, then publishing them in an agreed, timed way.
Remediation – a change that removes the vulnerability or reduces its risk, such as a patch, a new version or a configuration change applied by the vendor.
Mitigation (or workaround) – an action that lowers the risk without fixing the root cause, for example disabling a feature or blocking a network port. Useful when a full fix will take time.
Advisory – the vendor's published notice describing an issue, the affected versions, its severity and what users should do. Machine-readable formats such as OASIS CSAF are increasingly used.
Root cause analysis – working out why the flaw exists (for example, missing input validation in a shared parser) so that the fix is complete and similar flaws are found.
Upstream and downstream – in the supply chain, upstream vendors supply components (libraries, chips, operating systems) and downstream vendors build them into their own products. A flaw upstream usually affects many downstream products.
Embargo – an agreed period during which vulnerability details stay confidential among the parties working on a fix.
Severity – an assessment of how serious a vulnerability is, often expressed with FIRST's Common Vulnerability Scoring System (CVSS). Severity drives priority but is not the only factor.

Two further identifiers appear constantly in practice. A CVE ID is a unique reference number for a publicly disclosed vulnerability, assigned through the CVE Program by a CVE Numbering Authority (CNA); many vendors become CNAs themselves. A VEX statement (Vulnerability Exploitability eXchange) tells customers whether a product is actually affected by a known vulnerability in one of its components. Neither is required by the 2019 edition, but both are now common tools for carrying out what it asks.

Lesson 3 – Structure of the standard

ISO/IEC 30111:2019 is a short document of about a dozen pages. After the usual opening clauses (scope, normative references, terms and abbreviations) it builds up in four layers. The description below is a paraphrase of the structure; the wording and the full list of requirements are in the standard itself.

Concepts and relationships

An opening concepts section explains the purpose of vulnerability handling and how it relates to neighbouring work: above all the disclosure process in ISO/IEC 29147, and more broadly secure development, supplier relationships and product security evaluation (areas covered by documents such as ISO/IEC 27034, ISO/IEC 27036 and the Common Criteria standard ISO/IEC 15408). The key idea is that handling sits between secure development (which tries to prevent vulnerabilities) and disclosure (which communicates about them).

Policy and organisational framework

The second layer is about what must exist before the first report arrives. Leadership commits to vulnerability handling and approves a policy. The policy says, at least internally, what the vendor will do with reports, which products and versions are covered, and how confidentiality is protected. An organisational framework assigns the work: a PSIRT or equivalent function coordinates, product engineering teams analyse and fix, customer support and public relations handle communication with users and the media, and legal advisers are consulted on contracts, export rules, liability and dealings with finders. The standard expects these responsibilities to be clear, not improvised during an incident.

Figure 2 – The organisational framework: leadership sets policy, the PSIRT coordinates, and each business function owns its part of the response.

The vulnerability handling process

The third layer, the core of the document, is the handling process itself, described as six phases: preparation, receipt, verification, remediation development, release and post-release. Lesson 4 walks through each one. Alongside the phases, the standard asks the vendor to monitor the process (tracking cases, timelines and outcomes so that the process can be managed and improved) and to protect the confidentiality of vulnerability information throughout, because details of an unfixed flaw are valuable to attackers.

Figure 3 – The six phases of vulnerability handling, with the early exit from verification and the improvement loop back to preparation.

Supply chain vulnerability handling

The fourth layer recognises that modern products are assembled from components made by others. A vulnerability can sit in your code, in an upstream component you use, or in a downstream product built on yours. The standard therefore addresses handling across vendors: identifying which parties are involved, sharing information securely, agreeing who leads, aligning release timing so that one vendor's advisory does not expose another's customers, and involving a coordinator when needed. This is where ISO/IEC 30111 and the multi-vendor coordination guidance in ISO/IEC 29147 overlap most.

"Requirements and recommendations"

The 2019 scope speaks of requirements and recommendations, so the document contains some "shall" statements as well as advice. It is not, however, a management system standard with an audit-ready requirements clause set like ISO/IEC 27001. In practice most organisations treat it as a reference model for designing their process and as a benchmark that customers, regulators and other standards point to.

Lesson 4 – How it works in practice

Phase 1: Preparation

Preparation is everything that makes the other phases work. Typical outputs are a written vulnerability handling policy approved by management; a named PSIRT lead and deputies; a contact point for reports (often a security web page, a security@ mailbox and a security.txt file, which are disclosure topics shared with 29147); a tracking system with restricted access; an inventory of products, versions and their support status; a software bill of materials (SBOM) or other component list so that you can tell which products contain a given library; agreed severity criteria; and templates for acknowledgements and advisories. Preparation also covers relationships: knowing how to reach the security teams of your key upstream suppliers and which national CSIRT or coordinator you would involve.

Product support status matters more than people expect. If the policy does not say which versions receive security fixes, every case turns into an argument. A clear lifecycle policy (for example, the current and previous major release receive fixes for a stated period) lets the team decide quickly and lets customers plan.

Phase 2: Receipt

In the receipt phase the vendor takes in a report, records it and responds. Reports arrive through the published channel, but also through sales staff, support tickets, social media, bug bounty platforms, coordinators, upstream suppliers and internal testing. A good process routes all of them to the PSIRT, gives each case a unique tracking identifier, stores the details securely, and acknowledges the reporter promptly, telling them what to expect next. The acknowledgement is not a promise that the issue is real; it shows the report has been received and is being looked at.

Receipt also includes an initial triage: is the report about one of our products or services, is it a security issue rather than a functional bug, and does it contain enough information to start? If the product belongs to someone else, the right action is to point the reporter to that vendor or to a coordinator rather than to ignore it.

Phase 3: Verification

Verification turns a potential vulnerability into a confirmed one, or closes it. The team tries to reproduce the issue in a test environment, confirms which products and versions are affected, and assesses its severity and the risk to users. ISO/IEC 30111 asks vendors to consider the configuration that users most commonly run, because a flaw that only appears with an unusual setting may be less urgent than one in the default installation; NIST notes this in its federal guidance as a point where government system owners take a different view, since they assess their own deployed configuration.

Verification is also where root cause analysis happens. If a buffer overflow is in a parser shared by four products, fixing only the product named in the report leaves three others exposed. The team looks for variants of the same mistake in related code and for other products that reuse the affected component.

Figure 4 – Verification as a sequence of decisions: confirm the issue, avoid duplicate work, assess it, then look for the full extent of the problem before planning the fix.

Not every case should continue to remediation. The standard recognises legitimate reasons to exit the process at this point, for example: the issue cannot be reproduced and the reporter cannot supply more detail; it is a duplicate of a case already being handled; it is not a security vulnerability; it affects only versions that are out of support; or it lies in another vendor's product. The important practice is to record the reason, tell the reporter, and, where the issue is real but out of scope, consider whether users still need a warning. An out-of-support product that many customers still run may deserve at least a mitigation notice.

Phase 4: Remediation development

Once the vulnerability is confirmed, the vendor decides how to protect users and builds that protection. Options include a code fix in a new release or patch, a configuration change in a hosted service, and interim mitigations that customers can apply until the fix is ready. Priority is set by severity and risk, but practical factors also matter: whether the issue is already public or being exploited, how many customers are affected, release schedules, regulatory deadlines and dependencies on upstream suppliers.

The fix must be tested, both to confirm that it closes the vulnerability (including the variants found during root cause analysis) and to check that it does not break the product. Rushed fixes that fail or cause outages damage trust and sometimes create new vulnerabilities. For online services the vendor can often deploy the fix centrally; for installed products and devices it must package the fix so customers can deploy it.

Phase 5: Release

Release is when the remediation is made available and users are told about it. The advisory and its content are disclosure topics described in detail in ISO/IEC 29147, but handling and disclosure meet here: the release date has to be coordinated with the reporter, any coordinator, and other affected vendors; the advisory needs accurate lists of affected and fixed versions; and support teams must be briefed before customers start calling. For a hosted service where the provider fixes the problem itself and users have nothing to do, the vendor still decides, based on its policy, whether and how to tell customers.

If the vulnerability becomes public or is exploited before the fix is ready, the timeline changes. The process should already say who can decide to publish an early advisory with mitigations, so that the team does not lose a day finding an executive.

Phase 6: Post-release

After release the case is not simply closed. The vendor watches for problems with the fix, questions from customers, reports that the fix is incomplete and signs of exploitation, and updates the advisory when new information appears. It also learns: why did this flaw get into the product, which development practice would have caught it, and what slowed the handling? Feeding these lessons into the secure development lifecycle and into the handling process itself is what turns a reactive team into one that prevents the next flaw.

Process monitoring and confidentiality

Across all phases the vendor tracks each case and the process as a whole. Useful measures include time to acknowledge, time to verify, time to release by severity, the number of cases reopened because a fix was incomplete, and the share of vulnerabilities found internally versus externally. Confidentiality runs alongside: access to unfixed vulnerability details is limited to people who need them, information is shared with partners over protected channels, and staff understand that discussing an embargoed issue on public forums or in public issue trackers is a serious breach.

Lesson 5 – Assessment, certification and compliance

No certificate against ISO/IEC 30111 itself

There is no accredited certification scheme that issues an "ISO/IEC 30111 certificate" to an organisation, and the standard is not written as a certifiable management system. Be wary of any claim of being "30111 certified". What exists is conformance: an organisation can state that its process follows ISO/IEC 30111, and others can check that claim. Several routes put real scrutiny on vulnerability handling.

Routes through which handling is assessed

Product security certifications. IEC 62443-4-1 defines secure development lifecycle requirements for industrial automation suppliers, including practices for managing security-related issues and security updates. Certification schemes based on it (for example ISASecure and IECEE schemes) audit the supplier's issue handling with evidence from real cases.
Common Criteria evaluations. Product evaluations under ISO/IEC 15408 can include flaw remediation assurance requirements, which examine how the developer tracks and corrects reported flaws.
Regulation. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, sets vulnerability handling requirements for manufacturers of products with digital elements, including identifying components, addressing vulnerabilities without delay, coordinated disclosure, and reporting actively exploited vulnerabilities to authorities; its reporting obligations apply from 11 September 2026 and most other obligations from 11 December 2027. In the United States, the IoT Cybersecurity Improvement Act of 2020 directed NIST to produce federal disclosure guidelines aligned with ISO/IEC 29147 and 30111, which became NIST SP 800-216.
Customer and supplier audits. Large customers often ask suppliers to describe their PSIRT, policy, timelines and evidence of past handling, and may cite 30111 in contracts.
Self-assessment and maturity models. Organisations compare themselves against 30111 and the FIRST PSIRT Services Framework, which breaks product security response into service areas and services and is useful for gap analysis.

What good evidence looks like

Whoever does the assessing, the same evidence convinces: an approved policy and lifecycle statement; a published contact method; defined roles with named people and deputies; a tracking system with restricted access; case records showing timestamps for each phase; severity criteria and examples of how they were applied; advisories with accurate version information; records of coordination with finders and suppliers; metrics reviewed by management; and post-release reviews that led to actual changes. A strong signal is consistency: the cases in the tracker follow the process described in the policy. A weak signal is a polished policy with no case history, or case records that stop at "fixed" with no release or review.

Running an internal review

A practical self-assessment takes a sample of recent cases, including at least one external report, one internal finding and one involving a third-party component, and traces each through the six phases. For each phase ask: was the step done, by whom, how long did it take, and where is the evidence? Gaps typically appear at the edges: reports that arrived through sales staff and were logged late, closures without a recorded reason, missing variant analysis, and no post-release review.

Lesson 6 – Worked example

The organisation

Northfield Devices is a fictional mid-sized company that makes network video recorders for shops and offices. Each recorder runs Northfield's firmware, which includes an open-source embedded web server; customers manage recorders through a local web interface, a mobile app and a cloud portal that Northfield hosts. Around 200,000 recorders are deployed worldwide. Northfield sells into the EU, so the Cyber Resilience Act applies to its new products.

Preparation (before anything happens)

A year earlier the head of engineering created a two-person PSIRT, wrote a vulnerability handling policy that the chief executive approved, and published a security page with a contact address, a PGP key and a security.txt file. The policy states that the two most recent firmware lines receive security updates for five years after release. The team set up a restricted project in the issue tracker, defined severity levels based on CVSS plus exposure (internet-facing or not), generated SBOMs for each firmware build, and listed security contacts for their main component suppliers. They also agreed with legal and communications who can approve an emergency advisory.

Receipt

On a Monday a researcher emails the security address: a crafted request to the recorder's web interface bypasses login and gives access to live camera streams. The PSIRT logs case NF-2026-014, acknowledges the email the same day, thanks the researcher, explains the next steps and asks them to keep the details private while Northfield investigates. The researcher replies that they plan to present the finding at a conference in 90 days.

Verification

An engineer reproduces the bypass on the current firmware in the lab within two days. Using the SBOM, the team finds that the request handling flaw is not in Northfield's code but in the embedded web server component, in a routine that parses authentication headers. Every firmware line from the last four years uses the component, and two other Northfield products, a door-access controller and an older recorder model, use it too. The older model is out of support, but 15,000 units are still connected.

Severity is critical: the default configuration exposes the web interface on the local network, and many customers forward it to the internet. Root cause analysis shows that Northfield's own code trusted the component's authentication result without a second check, so there is also a design lesson for Northfield.

Supply chain coordination

Because the flaw is upstream, the PSIRT contacts the web server project's security team privately, shares the reproduction details under an agreed embargo, and asks whether they already know of the issue. They do not. The upstream maintainers develop a patch in three weeks and ask Northfield to keep the details confidential until their release. Because other device makers use the same component, the maintainers involve a national CSIRT as coordinator to notify them and align a common publication date.

Figure 5 – Supply chain handling in the worked example: the vendor shares details upstream, a coordinator reaches other affected vendors, and everyone works towards one agreed release date.

Remediation development

While waiting for the upstream patch, Northfield prepares a mitigation: customers are advised to stop forwarding the web interface to the internet and to use the cloud portal, which is not affected. For the hosted portal the team adds a check that blocks the malicious request pattern from reaching recorders that connect through it. When the upstream patch arrives, engineers integrate it into both supported firmware lines and the door controller, and add Northfield's own second authentication check as a defence in depth. Testing covers the original exploit, the variants found in analysis, and normal operation on every hardware revision. For the out-of-support model, management decides to issue a one-time update because of the severity and the number of devices still in use, and records the decision as an exception.

Release

On the coordinated date, the upstream project publishes its fix, and Northfield publishes an advisory listing affected models and firmware versions, fixed versions, the CVE ID assigned by the coordinator acting as CNA, the severity score, the mitigation for customers who cannot update immediately, and credit to the researcher as they requested. A machine-readable CSAF version of the advisory goes to large customers and distributors. Support staff receive a briefing pack the day before. Because Northfield has no evidence of exploitation, no early regulatory report is required, but the PSIRT checks the CRA reporting rules as part of its release checklist.

Post-release

Over the next month the team tracks update uptake through the cloud portal, answers customer questions and watches for exploitation reports. Two weeks after release, a customer reports that the update fails on one rare hardware revision; the team issues a revised build and updates the advisory. The post-release review produces three changes: an architecture rule that security decisions must not rely on a single component's result, faster SBOM search tooling, and a clause in supplier contracts requiring security contacts and response commitments. The case is closed with a record of times for each phase: acknowledgement same day, verification in two days, fix released in 41 days, within the researcher's 90-day plan.

What the example shows

Every phase depended on preparation: the published contact, the SBOM, the lifecycle policy and the supplier contacts each saved days. The case also shows that handling is a business process, not only an engineering one, with decisions about out-of-support products, customer communication and regulation made by the right people at the right time.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 30111 is one piece of a larger product security picture. The table compares it with the documents you are most likely to meet alongside it.

Document	Owner	Main focus	Relationship to ISO/IEC 30111
ISO/IEC 29147:2018 Vulnerability disclosure	ISO/IEC JTC 1/SC 27	Receiving reports, communicating with finders, publishing advisories, multi-vendor coordination	Companion standard; covers the external interface while 30111 covers internal handling. Usually adopted together.
IEC 62443-4-1 Secure product development lifecycle	IEC (with ISA)	Secure development practices for industrial automation and control products	Includes practices for handling security issues and updates; certification schemes against it audit the same activities 30111 describes.
ISO/IEC 27002 / ISO/IEC 27001 Annex A	ISO/IEC JTC 1/SC 27	Information security controls, including technical vulnerability management in an organisation's own systems	The user side: customers rely on vendors' advisories and fixes to manage their own vulnerabilities.
FIRST PSIRT Services Framework	FIRST	Service areas and services a product security response team can offer	Practical breakdown of the PSIRT role; useful for building and maturing the organisation 30111 asks for.
NIST SP 800-216	NIST	Federal vulnerability disclosure guidelines for US government systems	Built on 29147 and 30111 and points to them; adapts handling to deployed government systems.
EU Cyber Resilience Act	European Union	Legal cybersecurity requirements for products with digital elements	Law, not a standard; its vulnerability handling obligations closely match the activities in 30111 and 29147.

Handling versus incident response and vulnerability management

Three ideas are often confused. Incident response (for example ISO/IEC 27035) deals with security events affecting an organisation's own operations. Technical vulnerability management deals with finding and patching weaknesses in systems an organisation runs. Vulnerability handling, the subject of 30111, deals with flaws in products and services an organisation supplies to others. One event can touch all three: if a vendor's hosted service is breached through a flaw in its own product, the corporate CSIRT handles the incident, IT operations patch internal systems, and the PSIRT handles the product vulnerability for all customers.

Secure development

Secure development frameworks such as the NIST Secure Software Development Framework (SP 800-218) and IEC 62443-4-1 aim to prevent vulnerabilities and include responding to them as one of their practice groups. ISO/IEC 30111 gives that response practice its detail. The post-release phase closes the loop by sending lessons back into development.

Common pitfalls and best practices

Pitfalls

No front door. Without a published, monitored contact point, reports reach random employees or are published without warning. Researchers who cannot find a contact often go public.
Treating reports as support tickets. Routing security reports into the general queue exposes details to many people and loses them among routine requests.
Fixing only what was reported. Skipping root cause and variant analysis leaves the same flaw in other products or code paths, followed by a second advisory weeks later.
Silent fixes. Shipping a patch without telling users denies them the information to prioritise updating, and attackers can compare versions to find the flaw anyway.
Closing without a record. Rejecting reports as "not a bug" without a documented reason or a reply to the reporter destroys trust and leaves no audit trail.
Ignoring the supply chain. Not knowing which products contain a vulnerable component turns every upstream advisory into a days-long investigation.
Policy on paper only. An approved policy with no named owners, no tracker and no metrics will not survive the first critical case.

Best practices

Prepare before the first report. Approve the policy, name the team and deputies, set up restricted tracking, and agree who can authorise an emergency advisory.
Know what you ship. Keep product inventories, support lifecycles and SBOMs current so that affected products can be identified within hours.
Communicate early and often with finders. Acknowledge promptly, give realistic timelines, share progress and credit them if they wish.
Prioritise by risk, not by who complains loudest. Use consistent severity criteria that consider typical configurations, exposure and exploitation.
Coordinate releases across vendors. Agree a single publication date with upstream and downstream parties and use a coordinator when many vendors are affected.
Measure and improve. Track times for each phase and reopened cases, review them with management, and feed lessons into secure development.
Use machine-readable outputs. CVE IDs, CSAF advisories and VEX statements help customers automate their response.

Summary and key takeaways

ISO/IEC 30111 describes how a vendor internally handles reported vulnerabilities in its products and services; ISO/IEC 29147 covers receiving reports and disclosing remediation information. Use them together.
The current edition is ISO/IEC 30111:2019; a third edition that brings handling and disclosure closer together is in early drafting and not yet published.
The process has six phases: preparation, receipt, verification, remediation development, release and post-release, supported by process monitoring and confidentiality controls.
A policy and organisational framework approved by leadership, with a PSIRT coordinating engineering, support, communications and legal, must exist before the first report.
Verification confirms and assesses a report, looks for the root cause and variants, and may legitimately end a case early, but always with a recorded reason and a reply.
Supply chain vulnerabilities need confidential sharing, agreed leadership and one coordinated release date across vendors.
There is no certificate for ISO/IEC 30111 itself; handling is assessed through product security certifications such as IEC 62443-4-1, Common Criteria flaw remediation, regulation like the EU Cyber Resilience Act, and customer audits.
Evidence of real cases flowing through the process, with metrics and post-release learning, is what demonstrates a working vulnerability handling capability.

Reflection questions

Where would a security report about one of your organisation's products land today, and how long would it take to reach someone able to act on it?
Which products and versions does your organisation currently support with security fixes, and is that written down somewhere customers can see?
Think of a component your products rely on heavily. How quickly could you list every product and version that contains it if a critical flaw were announced tomorrow?
Under what circumstances would you release an advisory with only a mitigation before a full fix is ready, and who in your organisation should make that call?
Which three measures would you report to management to show whether your vulnerability handling is improving, and why those three?