ISO/IEC 30111:2019

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

Establishing an internal vulnerability handling policy defining responsibilities at each stage of the 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

Establishing a point of contact such as a CSIRT or PSIRT for receiving and handling 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

Defining roles and responsibilities for personnel involved in vulnerability handling

• 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

Integration with ISO/IEC 29147 at report reception and remediation information distribution points

• 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 organisation establishes an internal policy defining how vulnerabilities reported from any source are received, investigated, resolved, and tracked through closure.

• Internal vulnerability handling policy approved by senior management
• Scope statement covering products, services, and shared components
• Cross-reference to ISO/IEC 29147 disclosure policy
• Annual review record
• Distribution evidence to all relevant staff

• Policy focuses on external disclosure but not internal handling
• No clear linkage between PSIRT and engineering teams
• Scope excludes legacy products still under support
• Policy not communicated beyond security team

Vulnerabilities from all sources including external finders, internal testing, suppliers, and threat intelligence are captured in a single tracking system with consistent metadata.

• Central vulnerability tracking system with all sources feeding it
• Standard metadata schema (source, asset, severity, CVE if assigned)
• Intake SLA per source type
• Daily intake queue review evidence
• Mapping of sources to internal owners

• Internal pen-test findings tracked separately from external reports
• Supplier-reported vulnerabilities lost in email
• Inconsistent metadata blocks reporting
• No deduplication across sources

Reported vulnerabilities are verified through reproduction or technical analysis to confirm validity before remediation effort is committed.

• Reproduction environments for each supported product line
• Reproduction steps and outcomes recorded in case ticket
• Evidence preservation for invalid reports in case re-opened
• Peer review of verification conclusion
• Tooling configuration documented

• Reproduction attempts not recorded, leading to inconsistent retesting
• No environment for older versions still under support
• Single-engineer verification without peer review
• Invalid reports closed without evidence

Each verified vulnerability is assessed for severity, exploitability, affected user base, and business impact to inform prioritisation.

• CVSS v3.1 or v4.0 scoring with full vector recorded
• Exploitability assessment (proof of concept, in the wild)
• Affected user count or deployment estimate
• Business impact categorisation (data loss, availability, integrity)
• Prioritisation matrix linking severity to SLA

• CVSS vector not recorded, only the base score
• No exploitability assessment, all treated equally
• Business impact missing for products serving regulated customers
• Severity assigned by reporter not validated internally

The organisation selects a remediation strategy from full fix, configuration mitigation, workaround, or deprecation based on severity, complexity, and customer needs.

• Documented remediation options analysis
• Decision authority matrix
• Customer impact assessment for mitigation versus full fix
• Architecture review for invasive fixes
• Approval signature for chosen strategy

• Always defaults to code fix even when mitigation suffices
• No documented decision record
• Customer impact not considered when choosing aggressive remediation
• Deprecation chosen without customer migration plan

Tracking reported vulnerabilities and prioritizing remediation based on severity and impact

• 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

Managing communication with reporters, coordinators, and affected parties throughout the 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

Ensuring quality and completeness of vulnerability remediations before release

• 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

Documenting vulnerability handling activities and continually improving the 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

Monitoring the effectiveness of released remediations and identifying any follow-up issues

• 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

Conducting post-mortem analysis and documenting lessons learned from vulnerability handling

• 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

Performing root cause analysis to prevent similar vulnerabilities in future products

• 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

For significant vulnerabilities the organisation performs root cause analysis to identify systemic weaknesses and prevent recurrence.

• Root cause analysis template
• Completed RCA documents for high and critical vulnerabilities
• Action plan linking RCA to engineering improvements
• Trend analysis of recurring root causes
• Sharing of lessons across product teams

• RCA limited to incidents, not vulnerabilities
• Actions captured but not tracked to closure
• No trend analysis across multiple vulnerabilities
• Lessons confined to one team

The internal vulnerability handling process feeds the external coordinated disclosure process with timely, accurate information.

• Documented hand-off between handling and disclosure functions
• Joint case view in tracking system
• Communication checkpoints aligned to fix availability
• Draft advisory reviewed by handling team
• Post-disclosure feedback loop into handling

• Handling and disclosure run on separate tools without sync
• Advisory published before fix is available for download
• No feedback to engineering on advisory accuracy
• Customer-facing materials inconsistent with internal facts

Customers receive timely notifications of vulnerabilities affecting their deployments along with mitigation guidance and support during remediation.

• Customer notification list segmented by product version
• Notification template covering risk, mitigation, fix, and timeline
• Support team briefing materials
• FAQ updated for the advisory
• Customer acknowledgement tracking

• Notifications sent to outdated contact lists
• Support staff unaware of advisory when customers call
• FAQ not updated, customers self-serve incorrectly
• No tracking of who has received and read the notice

Roles for vulnerability handling are defined, accountable individuals are named, and the programme is resourced to meet its SLAs.

• RACI for vulnerability handling activities
• Named PSIRT lead and deputies
• Headcount plan justified by case volume
• On-call rota for severe vulnerabilities
• Cross-functional steering committee

• Single point of failure with one person owning the function
• No on-call coverage outside business hours
• Headcount not scaled with product growth
• Steering committee meets irregularly

The vulnerability handling programme is measured against defined KPIs and continuously improved based on the metrics.

• Defined KPIs (mean time to triage, fix, publish)
• Dashboard refreshed monthly
• Target versus actual performance review
• Improvement actions linked to specific metrics
• Benchmarking against industry data where available

• Metrics collected but not reviewed
• No targets set
• Improvement actions disconnected from data
• Metrics gameable (closing tickets without fixing)

All vulnerability cases are tracked to closure with status visibility, ageing reports, and escalation when SLA breaches are approaching.

• Status dashboard with open, in-progress, and closed counts
• Ageing report by severity
• SLA breach escalation procedure
• Weekly stand-up minutes including vulnerability backlog
• Monthly report to management

• Backlog grows with no visibility above team level
• Ageing not measured, oldest issues forgotten
• Escalation absent, breaches normalised
• No definition of when a case is closed

Staff involved in vulnerability handling receive role-specific training on procedures, tools, and emerging threat techniques.

• Training curriculum for triage, remediation, and communication roles
• Annual training completion records
• Skills matrix per individual
• Conference and external training budget records
• Knowledge base of internal triage guides

• Training catalogue exists but completion not tracked
• No refresh training as threat landscape evolves
• Knowledge base outdated
• New hires shadow without structured onboarding

Vulnerability handling records are retained for an appropriate period to support audit, regulatory compliance, and historical analysis.

• Retention schedule for vulnerability records
• Access controls and audit logs on the tracking system
• Backup and recovery procedures
• Auditor sample access workflow
• Legal hold procedure for active litigation

• Records purged on system migration
• No legal hold capability
• Audit logs disabled to save storage
• Backups untested

Fixes are released through standard product release channels with version control, integrity protection, and clear release notes for users.

• Release notes referencing the advisory and CVE
• Signed binaries or container images
• Distribution channel logs (download CDN, repository)
• Backport plan for supported earlier versions
• Customer download portal access controls

• Fix only released in latest version, leaving supported earlier branches exposed
• No code signing on patches
• Release notes vague about security content
• Distribution channel lacks integrity verification

Code changes addressing vulnerabilities are developed following secure development practices, peer review, and quality gates equivalent to standard releases.

• Source code repository commit history for the fix
• Mandatory peer review approval (two reviewers for security fixes)
• Static analysis run on the fix branch
• Unit and regression test coverage for the fix
• Security-focused test cases added

• Single approver on security fix code reviews
• Static analysis skipped to meet deadlines
• No regression tests added to prevent recurrence
• Fix branches lacking the same gates as main

Where vulnerabilities exist in third-party components the organisation coordinates with suppliers, applies workarounds while waiting for upstream fixes, and tracks upstream status.

• Software bill of materials (SBOM) per product (SPDX or CycloneDX)
• Supplier vulnerability contact register
• Upstream issue tracker links in internal tickets
• Workaround plan when upstream fix unavailable
• Component vulnerability monitoring (for example OSV, NVD feeds)

• No SBOM, components identified only when CVE matches obvious library
• No documented escalation path to upstream maintainers
• Open source components abandoned without exit plan
• Internal product released before upstream fix verified

Developed fixes are tested to confirm they eliminate the vulnerability without introducing regressions or new vulnerabilities.

• Test plan covering the original attack vector and variants
• Regression test execution results
• Independent security testing or pen-test sign-off
• Performance impact assessment
• Sign-off by quality and security functions

• Fix tested only against original PoC, not variants
• No regression suite run before release
• Security testing performed by the developer who wrote the fix
• No performance regression check