Artifact GuideUKStatement Of Compliance and 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.

The guide separates binding duties from OPSS guidance, ETSI good practice, internal controls, and the limited deemed-compliance routes introduced in 2025.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
4

Structured answer sets in this page tree.

Primary sources
10

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

The statement is a short manufacturer declaration; the is the controlled record behind it. Build the pack around the exact product type, batch, release, manufacturer, UK supply route, and statement route. It should show why the product is in scope, how each applicable security requirement is met or deemed met, how the statement accompanies the product, and how importers and distributors completed their checks.

Section 1

Layer 1: scope, roles, and statement route

Open the pack with the legal decision, not test results. Identify the relevant connectable product, UK consumer facts, exceptions considered, first-supply date, and every manufacturer, importer, distributor, and authorised representative for the route.

State whether the release uses the ordinary Schedule 4 statement or Schedule 2A. For Schedule 2A, preserve the exact product-to-label match, scheme, referenced scheme version, label level where applicable, validity, expiry, and verification date. The label route addresses accompaniment; it does not erase the manufacturer's security requirements or the actor-specific checks and compliance-failure duties.

End this layer with a signed decision: route approved, route rejected, or release blocked. A blocked decision names the missing scope fact, label evidence, actor confirmation, or statement field and the person responsible for resolving it.

  • Product identity: commercial name, type, batch, hardware, software, configuration, accessories, connectivity, intended purpose, and release date.
  • Scope decision: sections 4 to 6 analysis, Schedule 3 exception check, section 54 consumer facts, sources, assumptions, owner, reviewer, and date.
  • Role map: legal entities, branding, manufacturing, import, distribution, authorised-representative agreement, and handoff contacts.
  • Route record: ordinary statement and accompaniment method, or Schedule 2A label evidence and expiry monitoring.
Section 2

Layer 2: security-requirement evidence

Create a traceability row for each Schedule 1 requirement. State the legal test, responsible owner, product-specific evidence, result, limitation, and approval. If relying on Schedule 2 deemed compliance, identify the exact condition and specified standard or current scheme evidence instead of writing a broad ETSI claim. Keep "met directly," "deemed met," "not met," "not applicable with condition," and "unresolved" as separate outcomes.

  • Passwords: all default-password paths, user-definition flow, per-product generation, prohibited derivation checks, guessability testing, test units, results, and exceptions.
  • Vulnerability reporting: public point of contact, promised acknowledgement and status-update timings, English and free access, no-prior-request check, external access test, monitoring owner, and dated capture.
  • Support period: covered models and software, minimum duration, end date, approval basis, public URL, non-technical clarity test, unrestricted access, and dated capture.
  • Release mapping: build identifier, firmware or software hash, manufacturing configuration, test environment, assessor, test date, result, retest, and evidence location.
Section 3

Layer 3: issued statement and supply-chain proof

For the ordinary route, preserve the exact signed statement, all Schedule 4 fields, signatory authority, and proof that it accompanied the product. A digital path can be possible, but test it from the supplied product to the exact statement. Record importer receipt and pre-supply verification, distributor verification, and any stock block or exception.

Manufacturer and importer retention is the longer of 10 years from statement issue or the defined support period stated in the statement. Calculate both candidate dates and retain to the later one. Keep the calculation and an ownership transfer plan; do not rely on a general document-retention policy.

  • Issued statement: version, product type and batch, entities, declarations, standard details where applicable, support period, signature, name, function, place, and date.
  • Accompaniment: packaging location, insert, QR code, URL, app path, or other method; accessibility test; product mapping; issue date; and archived capture.
  • Importer: verification record, copy received, retention owner and deadline, upstream contact, and stop-supply authority.
  • Distributor: stock-level verification, statement or label route, exception handling, and stop-supply authority.
Section 4

Layer 4: changes, failures, and regulator readiness

Set explicit reassessment triggers. A previous pack cannot support a changed product unless the change assessment shows which facts and evidence remain valid. When a suspected failure arises, preserve the awareness date, investigation, decision, actions, contacts, notifications, and remediation evidence required for the actor. A vulnerability report is an input to that assessment, not automatic proof of a PSTI compliance failure.

Keep each Chapter 2 investigation or compliance-failure record for 10 years from the day that record is made. This clock is separate from statement retention, so the pack needs a record-level creation date and destruction date rather than one product-wide retention date.

  • Trigger review after connectivity, intended purpose, branding, manufacturer, supplier, firmware, password flow, disclosure route, support period, batch, scheme label, or market-route changes.
  • Keep open assumptions visible; name the missing evidence, responsible owner, deadline, and release impact.
  • Prepare an index that can be exported without exposing secrets unnecessarily: legal decision, evidence reference, owner, date, result, limitation, and location.
  • Keep regulator-response copies separate from mutable working files and preserve the version supplied to OPSS.
Primary sources

References and citations

etsi.org
Referenced sections
  • Voluntary assessment methods and IXIT evidence fields; useful for evidence structure but not legal approval.
Related guides

Explore more topics

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 Act: vulnerability disclosure policy requirements and template
Publish a free, clear, accessible English reporting route plus expected acknowledgement and status-update times, and retain evidence that the information remained available.
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 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 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.
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 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
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 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 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 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 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 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 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.
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.