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.

Evidence TemplateGLOBALETSI EN 303 645

ETSI EN 303 645 ICS and IXIT evidence template

A practical structure for turning EN 303 645 provision claims into entries, information, and reviewable assessment evidence.

Use this structure to prepare implementation and assessment records alongside the official ETSI standards. A completed template does not establish certification or conformance.

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

Use this template after freezing the (DUT) identity. The records the Supplier Organization's support decision for every EN 303 645 provision in the assessment set. The records the additional product and assessment-environment information needed by the Test Laboratory. Evidence references point to the actual documents, configurations, observations, and test outputs; the template itself proves nothing.

Section 1

What should the template separate?

Start by separating three layers: the ETSI EN 303 645 provision, the support decision for that provision, and the TS 103 701 information that explains the implemented mechanism or process. Do not turn IXIT fields into new EN 303 645 obligations; TS 103 701 uses IXIT information to support assessment against the EN provisions.

ETSI EN 303 645 V3.1.3 Annex B provides an implementation conformance statement pro forma. It records whether a provision is supported, not supported, or not applicable and provides a detail field for the implemented measure, non-support reason, or N/A rationale. TS 103 701 V2.1.1 identifies V3.1.3 as its normative EN reference and explains how the Supplier Organization provides and to the Test Laboratory for test-plan derivation.

  • Keep provision references stable: use one row per EN 303 645 provision or provision group, then link any internal controls to those references.
  • Use the EN Annex B notation in fields: Y for supported, N for not supported, or N/A when a condition is not satisfied or an F-marked feature, capability, or mechanism does not exist. Add the detail needed to understand the decision. TS 103 701 refers to assessed provisions as claimed "Yes"; do not let the wording difference change the support decision.
  • Use fields for assessment inputs: mechanism descriptions, interfaces, update paths, user documentation, security guarantees, cryptographic details, process confirmations, and references to provided documents.
  • Use evidence fields for the actual artifacts: product documentation, design records, configuration exports, test outputs, vulnerability disclosure pages, update records, or references.
Recommended next step

Assign provision claims and assessment evidence

This template structure helps connect EN 303 645 provision decisions with TS 103 701 IXIT information, owners, evidence artifacts, and assessment review status.

Assessment workflow
Open Assessment Autopilot for ETSI EN 303 645

Convert provision claims, IXIT dependencies, and evidence gaps into accountable assessment tasks.

Explore next step
Research workflow
Research ETSI EN 303 645 source questions

Resolve scope, applicability, and source interpretation questions before evidence collection.

Explore next step
Talk to Sorena
Talk through ETSI EN 303 645 implementation

Review consumer IoT scope, evidence owners, and the next assessment actions with Sorena.

Explore next step
Section 2

Minimum row design for an ICS and IXIT evidence register

An evidence template should let a reviewer move from a public provision claim to the information the assessor will need. A compact register can do this without copying the standards into a spreadsheet.

Use the first columns to identify the provision and support decision, the middle columns to identify dependencies, and the final columns to record evidence, owner, version, and assessment result. This keeps public EN 303 645 claims separate from the TS 103 701 assessment mechanics that test laboratories use.

  • Provision reference: for example, EN 303 645 provision 5.1-1, 5.2-1, 5.3-13, 5.8-3, 5.10-1, 5.11-1, or 6-5.
  • support status: Y for claimed support, N for an applicable provision not fulfilled, or N/A only where the standard's conditional or feature logic allows it.
  • detail: implemented measure, non-support reason, or not-applicable rationale written so a supply-chain reviewer can understand the decision without private context.
  • dependency: the relevant IXIT table or list, such as authentication mechanisms, user information, vulnerability types, confirmations, software components, update mechanisms, security parameters, personal data, telemetry data, deletion functions, user decisions, user interfaces, logical interfaces, or input validation.
  • Evidence reference: stable document ID, public URL, test report, certificate, configuration export, log extract, product manual section, or process record supplied to the assessment owner.
  • Evidence owner and state: named person or team, source location, product and document version, collection date, reviewer, expiry or refresh trigger, access classification, and open gap.
  • Review result: use open question, ready for assessment, or not yet assessed for internal preparation. Reserve PASS, FAIL, and INCONCLUSIVE for verdicts assigned through the TS 103 701 test-case, test-group, and overall-verdict rules, and record the responsible reviewer and date.
Section 3

How to handle EN 303 645 provision claims

Treat ETSI EN 303 645 as the source for the consumer IoT security and data protection provisions. V3.1.3 is outcome-focused and covers devices connected to network infrastructure and their interactions with associated services. TS 103 701 assesses the DUT's relation to associated services and relevant processes.

The template should make applicability visible before it asks for evidence. EN 303 645 recognizes that provision applicability depends on the device, and Provision 5.0-1 requires a justification for each recommendation considered not applicable or not fulfilled by the consumer IoT device.

  • Record product scope in consumer IoT terms: device, firmware, user interfaces, companion application, associated-service interaction, support process, and public user information.
  • Mark mandatory, recommended, conditional, and feature-dependent provisions according to the pro forma rather than internal priority labels.
  • For recommendations not fulfilled or not applicable, require a clear justification before the row can be closed.
  • Avoid broad phrases such as compliant with ETSI EN 303 645 unless the template also states the version, DUT boundary, support set, assessment approach, and evidence basis.
Section 4

How to handle TS 103 701 assessment evidence

Use ETSI TS 103 701 for the assessment side of the template. It defines the , Supplier Organization, Test Laboratory, assessment phases, conceptual and functional test concepts, pro forma, verdict handling, and external-evidence handling.

The template needs enough detail for grey-box testing. TS 103 701 says the IXIT provides design details to the Test Laboratory and is the basis for that methodology. Incomplete or insufficient IXIT information can produce an INCONCLUSIVE verdict when it prevents proper test execution.

  • Identify the DUT precisely, including model, software version, interfaces, update state, and the associated services that matter to the assessed functionality.
  • Capture supplier organization contacts and evidence owners because the SO is expected to provide and and support the TL with necessary information.
  • Distinguish conceptual evidence from functional evidence: conceptual checks assess the against provision requirements, while functional checks assess DUT functionality, associated-service relations, or development and management processes.
  • For , require scope, certification or test-report details, the relevant test activities, test depth or assurance level, and the provision or test group it supports.
  • When an row references an existing document, supply that document to the Test Laboratory and use stable IXIT identifiers so the test plan and findings can point to the exact entry.
Section 5

Template checks before using the evidence pack

Before using the template in a release review, procurement response, self-assessment, or test-lab handoff, run a consistency check across the and rows. Most evidence problems appear when the support claim says one thing and the IXIT, user documentation, or functional behavior says another.

This review is also where teams should remove overclaims. TS 103 701 is explicit that defining a certification or conformance declaration scheme is out of scope, and that assessment schemes typically define additional requirements such as tester expertise, cryptographic requirements, and accepted third-party evidence.

  • Record N whenever an applicable provision is not fulfilled and explain the gap. A mandatory N makes the invalid and prevents an overall PASS; it requires implementation work rather than an unsupported Y or N/A entry.
  • Every N/A has a condition or feature rationale and is checked against the and user documentation.
  • Every Yes claim has the entries needed for the relevant test groups and enough evidence for conceptual or functional review.
  • Every item is scoped to the DUT, provision, and test purpose it is supposed to support.
  • Every public claim avoids implying certification, legal compliance, or complete product security unless a separate scheme, certificate, or legal assessment actually supports that claim.
  • Reopen affected rows after a firmware, hardware, app, associated-service, interface, support-period, process, documentation, ETSI-edition, or assessment-scheme change.
Section 6

Common mistakes in the evidence register

Keep EN 303 645 provision claims separate from TS 103 701 assessment information. EN 303 645 supplies the baseline provisions and pro forma; TS 103 701 supplies the assessment methodology and pro forma. Record which source supports each register field.

Remove claims that the template itself proves conformance. A template can organize evidence and make assessment preparation more consistent, but the assessment result depends on the completed , sufficient information, applied test groups, verdict rules, and any assessment-scheme requirements.

  • Give assessors access to every referenced evidence item; a private filename or working-note label alone does not identify a reviewable record.
  • Do not use stale or generic source links when a specific ETSI deliverable URL supports the claim.
  • Do not describe the as an EN 303 645 requirement; describe it as TS 103 701 assessment information.
  • Do not copy sample implementation values into a real product row unless they are true for that DUT.
  • Do not hide unresolved applicability decisions inside narrative text; keep them as open rows with owners and evidence gaps.
Primary sources

References and citations

ETSI TS 103 701 V2.1.1 cybersecurity assessment for consumer IoT
etsi.org6 citations
Referenced sections
  • Assessment source for DUT, supplier organization, test laboratory, ICS, IXIT, conceptual tests, functional tests, verdicts, and external evidence handling.
  • Source for DUT, SO, TL, ICS, IXIT, assessment phases, verdicts, and external evidence concepts.
  • Clause 4.5 and Annex A describe IXIT information and pro forma entries used for assessment planning.
Show 3 more
  • Source for assessment roles, phases, conceptual and functional tests, IXIT expectations, verdicts, and external evidence criteria.
  • Source for ICS verification, IXIT sufficiency, overall verdicts, and the limits of the assessment methodology.
  • Source for TS 103 701 assessment methodology and IXIT pro forma context.
"The TL uses these documents to derive a test plan."
More quoted passages
"additional necessary information to perform the assessment"
"basis for grey-box testing methodology"
"Defining a certification or conformance declaration scheme is out of scope"
"Only entries necessary for the provisions claimed as "Yes""
ETSI EN 303 645 V3.1.3 consumer IoT baseline requirements
etsi.org5 citations
Referenced sections
  • Primary ETSI source for consumer IoT baseline provisions, reporting implementation, and Annex B implementation conformance statement pro forma.
  • Source for consumer IoT baseline provisions and Annex B implementation conformance statement pro forma.
  • Annex B defines the support and detail columns for implementation reporting.
Show 2 more
  • Source for scope, applicability, reporting implementation, and Annex B support-detail conventions.
  • Source for EN 303 645 provisions and ICS pro forma context.
"Implementation conformance statement pro forma"
More quoted passages
"If a provision is supported by the implementation"
"A justification shall be recorded"
"provisions applicable to all consumer IoT devices"

Related guides

ETSI EN 303 645 Applicability and Scope

Decide whether a connected product is in scope of ETSI EN 303 645, define the consumer IoT evidence boundary, and document N/A justifications for assessment.

ETSI EN 303 645 compliance: ICS, IXIT, evidence

Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and cited controls.

ETSI EN 303 645 Current Version Tracker

Track ETSI EN 303 645 version evidence, ETSI deliverable status checks, TS 103 701 assessment alignment, and change triggers for consumer IoT security work.

ETSI EN 303 645 CVD Workflow for IoT Vulnerability Reports

Cited workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence.

ETSI EN 303 645 Data Protection Provisions

Guide to ETSI EN 303 645 data protection provisions for consumer IoT, including security, consent, telemetry, deletion, minimization, aggregation, and anonymization.

ETSI EN 303 645 FAQ: Consumer IoT Security Questions

Practical answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, passwords, updates, vulnerability disclosure, telemetry, deletion, and assessment evidence.

Show all related guides (25)

ETSI EN 303 645 implementation checklist

This ETSI EN 303 645 implementation checklist helps scope a consumer IoT product, record Annex B support statuses, map IXIT evidence, and avoid weak conformance claims.

ETSI EN 303 645 Implementation Evidence Guide

Build ETSI EN 303 645 implementation evidence from Annex B support/detail records, TS 103 701 ICS and IXIT inputs, test verdicts, and scoped external evidence.

ETSI EN 303 645 IoT Applicability Workflow

Decide whether ETSI EN 303 645 applies to a consumer IoT product, what associated services belong in scope, and how to record justified non-applicability.

ETSI EN 303 645 requirements: consumer IoT provision map

Map ETSI EN 303 645 consumer IoT requirements to product scope, Annex B ICS entries, TS 103 701 evidence, and implementation owners.

ETSI EN 303 645 Secure Update Evidence Workflow

Build secure-update evidence for ETSI EN 303 645 using provision 5.3, Annex B support/detail records, and TS 103 701 ICS, IXIT, and test-plan inputs.

ETSI EN 303 645 Secure Update Workflow

Map ETSI EN 303 645 secure-update provisions into a practical workflow for consumer IoT update mechanisms, support-period disclosures, and TS 103 701 evidence.

ETSI EN 303 645 Secure Updates and Vulnerability Disclosure

Source-backed guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and assessment evidence.

ETSI EN 303 645 vs EU CRA for Consumer IoT

Compare ETSI EN 303 645 consumer IoT evidence with the EU Cyber Resilience Act's scope, manufacturer duties, application dates, and conformity requirements.

ETSI EN 303 645 vs RED Cybersecurity Delegated Act

Compare ETSI EN 303 645 consumer IoT evidence with the RED cybersecurity requirements, EN 18031 standards, application date, and conformity routes.

ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk

Compare ETSI EN 303 645 evidence with UK PSTI scope, three mandatory security requirements, statements of compliance, duties, and enforcement.

ETSI TS 103 701 Test Evidence Workflow for EN 303 645

Build an ETSI TS 103 701 test evidence workflow for EN 303 645 consumer IoT assessments: DUT identification, ICS, IXIT, test plans, verdicts, and external evidence.

ETSI EN 303 645 consumer IoT products: what is in scope?

Decide whether a device and its associated services are in scope of ETSI EN 303 645 V3.1.3 and document the DUT, ICS, IXIT, and assessment boundary.

ETSI EN 303 645 default passwords: what must consumer IoT teams do?

ETSI EN 303 645 default password guidance for consumer IoT: unique or user-defined passwords, pre-installed password generation, change mechanisms, brute-force controls, and TS 103 701 evidence.

ETSI EN 303 645 personal data deletion FAQ for consumer IoT

What ETSI EN 303 645 says about deleting user data and personal data from consumer IoT devices, associated services, apps, and evidence records.

ETSI EN 303 645 support period: what must consumer IoT teams publish?

ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, non-updateable-device replacement support, model designation, and TS 103 701 evidence.

ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?

ETSI EN 303 645 telemetry guidance for consumer IoT teams: security anomaly examination, IXIT 24-TelData evidence, personal-data minimization, and consumer telemetry disclosures.

ETSI EN 303 645 test evidence: what should consumer IoT teams keep?

ETSI EN 303 645 test evidence guidance for consumer IoT teams: ICS support claims, IXIT detail, TS 103 701 test plans, verdicts, and external evidence checks.

ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT

What ETSI EN 303 645 requires for consumer IoT vulnerability disclosure policies, report handling, status updates, timely action, and TS 103 701 evidence.

How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?

How ETSI EN 303 645 V3.1.3 treats use-case resource constraints, non-updateable devices, N/A claims, authentication controls, and assessment evidence.