We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideUKVulnerability Disclosure Policy

UK PSTI Product Security Vulnerability Disclosure Policy

Publish a free, clear, accessible English reporting route plus expected acknowledgement and status-update times, and retain evidence that the information remained available.

State a working reporting route and realistic acknowledgment and status-update timings, then connect each report to triage, investigation, updates, remediation, and any statutory action.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
4 sections7 primary sources
Overview

A can satisfy the public-facing part of Schedule 1 when it gives reporters a usable route for security issues and states when they can expect acknowledgment and status updates until resolution. Manufacturers of in-scope UK consumer connectable products have had to publish that information since 29 April 2024. It must be available without prior request, without asking for personal information, in English, free of charge, and in a clear, accessible, transparent form. PSTI does not prescribe one email address, acknowledgment deadline, disclosure embargo, or remediation deadline for every manufacturer.

Section 1

What must the public reporting policy say?

A tells researchers, customers, and other reporters where and how to submit a suspected security issue. For PSTI, first confirm that the business is a manufacturer of a relevant connectable product intended, or known or reasonably expected, to be a UK consumer connectable product. The requirement has applied since 29 April 2024.

The visible policy must identify a usable reporting route and the timescales within which the reporter can expect acknowledgment of receipt and status updates until the reported issue is resolved. Set times that the security team can meet, and distinguish acknowledgment, triage, status updates, remediation, and public disclosure.

Optional policy wording to complete before publication: "Report security issues affecting [covered product models and software] through [working contact route]. We acknowledge receipt within [chosen period] and provide status updates every [chosen interval] until resolution." Replace every bracketed field and test the route. These timings are manufacturer choices, not government-set deadlines. Make the policy itself readable without an account, payment, prior request or provision of personal information.

  • Publish a monitored reporting channel, the information a reporter should provide, and a safe alternative if the primary channel fails.
  • State expected acknowledgment timing and how often or within what timescale status updates can be expected until resolution.
  • Explain which products and security issues the channel covers, without using scope language that blocks good-faith reports about a potentially in-scope product.
  • Keep vulnerability-handling instructions, legal terms, and any coordinated-disclosure request separate from the mandatory reporting route and timescales.
Section 2

Who owns intake and which records should be kept?

Product security should own the intake and case process. Engineering owns technical investigation and fixes; customer support needs a route for forwarding reports; legal or compliance reviews scope, communications, and any notification duties created by an actual .

Evidence should prove that the published route worked and remained available. Keep the approved policy, publication URL, dated captures, monitoring records, test submissions, case timestamps, acknowledgment and update messages, resolution decisions, and links to affected product versions.

  • Assign a named operational owner and backup for each reporting channel, with alerts for delivery or certificate failures.
  • Test the public route without logging in or paying, and confirm that a non-technical visitor can find and understand it.
  • Measure actual acknowledgment and status-update performance against the published timescales; investigate missed commitments.
  • Retain the manufacturer's investigation or compliance-failure record for 10 years from the day the record is made when the report enters sections 10 to 12.
Section 3

Check rebranding, outsourced channels, and older products

The reporting requirement belongs to the manufacturer. Importers, distributors, authorised representatives, support vendors, and parent companies can operate the channel, but the published route must get reports to the responsible manufacturer and must not obscure which products it covers.

A report can trigger duties beyond the public policy. Manufacturers must take all reasonable steps to investigate a reported possible and, if a failure exists, may need to prevent further supply, remedy it, notify OPSS and supply-chain actors, and maintain records. The policy itself does not replace those statutory steps.

  • Do not require a non-disclosure agreement, account, purchase proof, or payment before allowing a person to report a security issue.
  • Do not promise that every report will be fixed or publicly disclosed by a fixed date. Publish realistic acknowledgment and status-update times, then communicate case-specific remediation decisions.
  • Make the route usable for reports covering unsupported or older products; the support-period decision and the duty to receive security reports answer different questions.
  • Check rebranded products and multiple manufacturers carefully so reports reach every responsible manufacturer and the visible policy matches the product name consumers see.
Section 4

Run the response from receipt to closure

Use one case workflow from receipt through closure. Log the report, protect sensitive details, acknowledge it within the published timescale, assess whether it concerns a covered product, investigate, give status updates, decide remediation and disclosure, and record the resolution.

When the facts indicate a possible PSTI , open the statutory investigation record and assess stop-supply, remediation, and notification duties separately. A general security weakness is not automatically a failure of a relevant security requirement, so document the rule and facts rather than assuming the legal result.

  • Receipt: create a case ID, preserve the original report, confirm safe contact details, and acknowledge receipt within the published timescale.
  • Triage: identify product, version, reproducibility, impact, reporter expectations, and whether immediate containment or supply-chain contact is needed.
  • Investigation and updates: assign technical ownership, record findings and decisions, and send status updates at the published cadence until resolution.
  • Closure: tell the reporter the case status to the extent appropriate, record remediation and disclosure decisions, verify the public channel still works, and preserve any records required by the Act.
Recommended next step

Publish and test the reporting policy

Assign the reporting channel, acknowledgement and update timings, monitoring backup, case records, and compliance-failure escalation.

Assessment workflow
Open Assessment Autopilot for UK PSTI Product Security

Build the intake, monitoring, communication, and investigation checks behind the public policy.

Explore next step
Research workflow
Review UK PSTI Product Security source evidence

Use Research Copilot to answer follow-up questions with cited source material.

Explore next step
Talk to Sorena
Talk through implementation

Review scope, evidence, owners, and the next compliance actions with Sorena.

Explore next step
Primary sources

References and citations

Related guides

UK PSTI Act statement of compliance: what must the SoC contain?

Understand when a UK PSTI statement is required, the Schedule 4 fields, supply-chain checks, retention, digital accompaniment, and the December 2025 label route.

UK PSTI applicability test: product, market, and actor scope

Apply the UK PSTI tests in order: connectivity, current exceptions, UK consumer availability, supply facts, and the manufacturer, importer, or distributor trigger.

UK PSTI compliance checklist for product release

Use a release checklist with scope, role, security-control, statement, records, and compliance-failure evidence for UK consumer connectable products.

UK PSTI compliance: duties, evidence, and response

Build a UK PSTI compliance process covering product scope, supply-chain roles, the three security requirements, statements, records, and post-market failures.

UK PSTI default password requirements

Apply the UK PSTI password rule to each relevant password, test unique-per-product generation, and keep reset and release evidence for the shipped model.

UK PSTI Manufacturer, Importer and Distributor Roles

Distinguish manufacturer, importer, distributor, and authorised-representative duties per product and supply route, including rebranding, imports, statement checks, stop-supply decisions, and compliance failures.

Show all related guides (39)

UK PSTI password and security update policy requirements

Implement the UK PSTI password rule and publish a defined security support period with the required end date, access conditions, and change controls.

UK PSTI Product Security Deadlines and Compliance Calendar Guide

Track the UK PSTI regime's commencement and amendment dates, product-specific support periods, record retention, and OPSS response and appeal windows.

UK PSTI Product Security FAQ

Get direct, sourced answers on product scope, exceptions, roles, passwords, vulnerability reporting, update-period information, statements, records, and OPSS enforcement.

UK PSTI Product Security Importer and Distributor Duties Guide

Identify the pre-supply checks, statement or deemed-compliance evidence, stop-supply decisions, notification and remediation duties required of UK importers and distributors, plus importer-specific investigation and record duties.

UK PSTI Product Security Minimum Support Period and Update Transparency Guide

Publish the minimum security-update period and end date in English, free of charge, without prior request, and in clear language, without implying that PSTI sets one duration for every product.

UK PSTI Product Security OPSS Enforcement and Penalties Guide

Understand OPSS investigations, compliance, stop and recall notices, monetary penalties, forfeiture, court orders, representations, appeals, and evidence needed to respond.

UK PSTI Product Security OPSS Notices Guide

Prepare for compliance, stop, and recall notices by understanding their effects, representation and appeal routes, product records, and corrective-action evidence.

UK PSTI Product Security Penalties and Fines Guide

Understand the maximum fixed and daily PSTI penalties, how OPSS sets an amount, representation and appeal rights, and separate court-ordered sanctions.

UK PSTI product security requirements

Read the three Schedule 1 security requirements and the surrounding manufacturer, importer, distributor, statement, record, and failure-response duties.

UK PSTI relevant connectable product scope test

Decide whether one product meets the UK PSTI connectivity definition, falls within a current exception, and reaches the separate UK-consumer duty tests.

UK PSTI relevant connectable products: categories and exceptions

Understand which connected product categories can enter UK PSTI scope, how the statutory tests work, and why examples never replace the current exception schedule.

UK PSTI Scope Classifier Workflow

Decide whether a product falls within the UK PSTI product-security regime by checking connectivity, consumer supply, exceptions, actor roles, and product-specific evidence.

UK PSTI security requirements in practice

Implement the three UK PSTI security requirements through product specifications, release tests, public information, approvals, and post-release evidence.

UK PSTI Statement of Compliance Evidence Pack

Join the prescribed statement fields to product identifiers, control evidence, publication records, supply-chain checks, accompaniment evidence, retention, and change management.

UK PSTI Statement of Compliance Template

Build a statement record with the prescribed Schedule 4 information and evidence that it accompanied the product, while checking whether a current Schedule 2A deemed-compliance route applies.

UK PSTI Statement of Compliance Workflow

Prepare, approve, provide, verify, retain, and update statement evidence before a relevant connectable product is made available in the UK.

UK PSTI Support Period Evidence Workflow

Set, publish, approve, and preserve the product-specific minimum security-update period and end date, then control changes and customer information against the shipped product.

UK PSTI to ETSI Evidence Mapping

Map ETSI EN 303 645 and TS 103 701 evidence to the three UK legal requirements without treating the wider voluntary ETSI baseline as if every provision were mandatory under PSTI.

UK PSTI vs Australia Smart Device Rules

Compare UK PSTI with Australia's Cyber Security Act smart-device rules by scope, duties, statements, security controls, retention, dates, and enforcement.

UK PSTI vs ETSI EN 303 645

See how binding UK PSTI duties relate to ETSI EN 303 645, which edition the UK Regulations name, what the standard adds, and what evidence to retain.

UK PSTI vs EU Cyber Resilience Act

Decide whether UK PSTI, the EU Cyber Resilience Act, or both apply, then compare actors, exclusions, security work, documents, reporting, and dates.

UK PSTI vs EU Cyber Resilience Act (CRA)

Compare UK PSTI and the EU Cyber Resilience Act by scope, security duties, support periods, conformity assessment, reporting, evidence, and application dates.

UK PSTI Vulnerability Disclosure Workflow

Operate intake, acknowledgement, status updates, investigation, remediation, disclosure, and evidence while keeping the legal publication duty distinct from broader good-practice response targets.

UK PSTI Default Password Rules

PSTI requires each covered password to be user-defined or unique per product. Unique credentials must not use prohibited predictable generation methods.

UK PSTI ETSI Evidence and Deemed Compliance

ETSI EN 303 645 and TS 103 701 can structure technical evidence, but the standards-based PSTI route depends on the exact mapped provisions and additional Schedule 2 conditions.

UK PSTI Excepted Products and Boundaries

An internet- or network-connectable product is outside the relevant-product definition only when a current Schedule 3 exception applies; record the exact category and facts rather than relying on a broad sector label.

UK PSTI Importer and Distributor Duties

Importers and distributors have their own statement, stop-supply, remediation, and notification duties; importers also have statutory investigation and 10-year investigation-record duties.

UK PSTI OPSS Notices: Compliance, Stop, Recall, and Penalties

OPSS can use compliance, stop, and recall notices alongside monetary and other measures; notice recipients should preserve the notice, product scope, supply records, corrective actions, representations, and appeal dates.

UK PSTI Relevant Connectable Product Scope

A product is relevant when it is internet-connectable or network-connectable and not excepted, then the UK consumer-use and supply facts determine whether the Part 1 duties engage.

UK PSTI Security Update Support Periods

PSTI does not prescribe a universal minimum number of support years. The manufacturer sets and publishes a product-specific minimum period and end date; preserve the published commitment and assess any later change against the current Regulations.

UK PSTI Security Update Transparency

Publish the minimum security-update period and end date in English, free of charge, without prior request, and in language understandable without technical knowledge.

UK PSTI Statement of Compliance: Contents, Delivery, and Records

A statement must contain the prescribed information and accompany the product unless a current deemed-compliance route applies; a digital method is possible, but each business must ensure that it meets the Act.

UK PSTI Vulnerability Disclosure Requirements

Publish a clear reporting route plus expected acknowledgement and status-update times. PSTI requires the information and timescales to be available; it does not prescribe one universal response deadline for every report.