ISO/IEC 29147:2018

Guidelines for vendors on receiving and disseminating vulnerability information

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Vulnerability disclosure terminology including vulnerability, reporter, vendor, and coordinator

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Abbreviations used in the vulnerability disclosure standard

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Requirements and recommendations for vendors on how to process and remediate reported potential vulnerabilities

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Terminology for vulnerability handling including vulnerability, vendor, CSIRT/PSIRT, and remediation

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Abbreviations used throughout the vulnerability handling processes standard

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

The vendor maintains comprehensive records of received reports, handling decisions, and published advisories for an appropriate retention period.

• Vulnerability case management system with full case history
• Retention schedule aligned to legal and regulatory requirements
• Backup and recovery for the vulnerability database
• Auditor access procedure
• Annual disclosure metrics report

• Records held in disparate spreadsheets and email
• No retention schedule, records purged inconsistently
• Loss of historical advisories during website migration
• Metrics not aggregated for management review

The vendor commits in policy not to pursue legal action against finders who follow the published disclosure rules in good faith.

• Safe harbour clause referencing applicable jurisdictions
• Legal review record of the VDP
• Internal escalation path before any legal action
• Training for legal counsel on coordinated disclosure norms
• Public statements reaffirming researcher protection

• Standard cease-and-desist sent before triage assessment
• Safe harbour silent on third-party platforms
• No legal sign-off on the VDP
• Conflicting terms in product EULA reserving litigation rights

The vendor maintains structured, timely communication with the finder across the lifecycle of the report including status updates, clarifications, and credit decisions.

• Status update cadence policy (for example every 14 days)
• Finder communication log per case
• Credit and recognition policy
• Hall of fame or acknowledgement page
• Escalation contact for unresolved disputes

• Communication drops once internal remediation begins
• No process to credit researchers who request recognition
• Public statements made before finder agreement
• Conflicting messages from PR and security teams

The vendor establishes a coordinated disclosure timeline balancing remediation readiness with finder and user expectations.

• Default disclosure window (commonly 90 days) documented in policy
• Per-case disclosure plan with target dates
• Extension request and approval records
• Coordination minutes with finder agreeing to timeline
• Sign-off from product, legal, and communications

• Open-ended disclosure with no committed date
• Extensions granted without finder consent
• No internal owner accountable for the timeline
• Disclosure rushed before fix availability

Published advisories contain sufficient information for users to assess risk, identify affected versions, and apply mitigations or fixes.

• Advisory template covering affected products, CVE, CVSS, summary, mitigation, and fix
• Sample published advisories from prior 12 months
• Editorial review checklist signed before publication
• Translation or localisation records where required
• CVE assignment via CNA or coordinator

• Advisories omit affected version ranges
• Mitigation steps absent for users who cannot patch immediately
• No CVE assigned for material vulnerabilities
• Inconsistent advisory format across product lines

The vendor coordinates disclosure with upstream suppliers, downstream integrators, and coordinators when a vulnerability spans multiple parties.

• Coordinator engagement records (for example CERT/CC, JPCERT/CC)
• Upstream and downstream notification list per case
• NDA or confidentiality agreements with coordinating parties
• Joint advisory drafts with version control
• Embargo and lift schedule

• No identification of downstream OEMs reusing the affected component
• Embargoes broken by one party before agreed lift
• Coordinator brought in late after public disclosure
• No process for cross-vendor issues in shared libraries

The vendor protects the confidentiality of vulnerability information until coordinated disclosure to prevent exploitation in the wild.

• Access list to vulnerability tracking system limited to need-to-know
• Classification scheme for vulnerability records
• Encrypted storage and transmission controls
• Audit log of who viewed and modified each case
• Leak response procedure

• Broad engineering access to all open vulnerabilities
• Discussions in unencrypted chat channels
• No audit trail in tracking system
• Customer support staff inadvertently exposed to confidential reports

After public disclosure the vendor monitors exploitation activity, user adoption of fixes, and feedback to inform future improvements.

• Threat intelligence subscription covering exploitation reports
• Patch adoption telemetry where supported
• Customer feedback channel for advisory clarity
• Post-disclosure retrospective for high-severity cases
• CISA KEV catalogue cross-check

• No tracking of whether issued patch is adopted
• Exploitation in the wild reported by third parties before vendor awareness
• Retrospectives only for incidents not vulnerabilities
• No metric on time from disclosure to patch availability

General guidelines for vendors to set up processes to receive vulnerability reports

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Expected contents and format of vulnerability reports including technical details

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Guidelines for initial assessment and triage of received vulnerability reports

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Guidelines for investigating and verifying reported vulnerabilities

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Maintaining communication with reporters throughout the handling process

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

When and how to involve a coordinator in the vulnerability disclosure process

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Maintaining operational security when handling vulnerability information

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Guidelines for publishing vulnerability advisories to affected parties and the public

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Required and recommended elements in published vulnerability advisories

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Channels and methods for communicating vulnerability advisory information

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Format standards and machine-readable formats for vulnerability advisories

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Ensuring authenticity and integrity of published vulnerability advisories

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Including remediation guidance including patches, workarounds, and mitigation steps

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

General guidelines for coordinating vulnerability disclosure among multiple parties

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Handling situations where vendors serve as both vendor and coordinator

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Developing a vulnerability disclosure policy including required and recommended elements

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Establishing contact mechanisms, secure communication options, and defining disclosure scope

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

Setting communication expectations and timelines in the disclosure policy

• Vulnerability disclosure policy
• Coordinated disclosure tracker and case files
• Advisory templates and published advisories
• Vulnerability handling SOP and team roster
• Post-release lessons-learned records

• No published vulnerability reporting channel
• Coordination handoffs to upstream vendors are ad hoc
• Advisories lack remediation detail and authenticity proof
• Post-release lessons learned not fed back to SDLC

The vendor notifies regulators, large customers, and partners under contractual or regulatory obligations before or at public disclosure.

• Stakeholder notification matrix by jurisdiction and customer tier
• Pre-disclosure briefing template
• Regulatory filing evidence where required
• Customer NDA register for advance notice
• Distribution list maintained current

• Notification list outdated, key customers missed
• Regulatory disclosure deadlines missed
• Inconsistent advance notice creating perceptions of favouritism
• No record of which stakeholders received advance copy

Embargoes on vulnerability information are time-limited, documented, and managed to balance protection of users and timely disclosure.

• Embargo agreement template
• Embargo register with start, end, and parties
• Procedure for handling embargo breaches
• Lift coordination playbook
• Internal review for embargoes longer than 90 days

• No embargo agreements in writing
• Indefinite embargoes left in place
• No defined breach response
• Embargo lift uncoordinated across time zones

The vendor assigns accountability for the vulnerability disclosure programme and reviews its effectiveness at management level.

• PSIRT charter and reporting line
• Defined roles for intake, triage, remediation lead, and communications
• Quarterly programme review minutes
• KPI dashboard (time to acknowledge, fix, publish)
• Annual management review report

• PSIRT reports into engineering without independent voice
• No KPIs measured, only anecdotal performance
• Programme not reviewed by senior management
• Roles unfilled during staff transitions

The vendor provides a reliable, documented channel for external finders to submit vulnerability reports and acknowledges receipt within a defined timeframe.

• Dedicated email alias (security@) or web form for vulnerability reports
• PGP key or equivalent for encrypted submissions
• Acknowledgement template with target response time (typically 1 to 3 business days)
• Intake ticket log with received timestamp
• Reporter contact register

• Reports routed to general support and lost in queue
• No encrypted submission option
• Acknowledgements exceed published SLA
• No unique identifier assigned at intake

Personnel involved in vulnerability handling and external communications receive role-specific training on the disclosure process and confidentiality requirements.

• Role-based training curriculum for PSIRT, engineering, legal, and PR
• Annual training completion records
• Tabletop exercise reports
• Onboarding checklist for new joiners
• Refresher training schedule

• Training only on day one, no refresh
• PR and legal staff not included in training
• No tabletop exercises run in prior year
• Records not retained for audit

The vendor establishes and publishes a vulnerability disclosure policy that defines scope, points of contact, expectations, and protections for external reporters.

• Published vulnerability disclosure policy (VDP) on vendor website
• Scope statement covering in-scope products, services, and versions
• Safe harbour and legal protection language for good-faith researchers
• Policy approval record signed by accountable executive
• Annual policy review evidence

• Policy buried in legal pages without discoverability via /.well-known/security.txt
• No safe harbour clause, deterring researchers
• Scope ambiguity covering only some product lines
• Stale policy with no review cadence

Where the vendor operates a bug bounty programme it is integrated with the coordinated disclosure process and shares intake, triage, and remediation paths.

• Bounty platform configuration (for example HackerOne, Bugcrowd, Intigriti)
• Reward schedule by severity
• Integration ticket flow into internal vulnerability tracker
• Annual programme performance report
• Reconciliation between bounty payouts and finance

• Bounty platform operating in parallel without ticket sync
• Reward decisions inconsistent with documented schedule
• No taxation or contractor compliance for payouts
• Scope mismatch between VDP and bounty programme

The vendor verifies reported vulnerabilities, assesses validity and severity, and communicates triage outcomes to the finder.

• Triage procedure with validity, severity, and exploitability checks
• CVSS v3.1 or v4.0 scoring records per report
• Reproduction evidence in triage ticket
• Finder notification of triage outcome
• Decision log for duplicate, out-of-scope, or invalid reports

• No documented triage criteria leading to inconsistent decisions
• Severity scored by single reviewer without peer check
• Finder left without status for weeks during triage
• Duplicates not linked to master case