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 ICS entries, IXIT information, and reviewable assessment evidence.

This serves as implementation and assessment planning guidance. It is not a certification claim, operational guidance, or a substitute for the ETSI standards.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

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

Use this template after freezing the 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 the route identity stable: one row per EN 303 645 provision or provision group, not one row per internal control.
  • 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.
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.

  • No mandatory provision claimed as No in a final assessment set unless the team is deliberately recording a failing or non-conforming result.
  • 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 to remove from public-facing content

Public guidance should not blur the standards. EN 303 645 gives the baseline consumer IoT provisions and pro forma context; TS 103 701 gives the assessment methodology and pro forma context. Mixing them makes the page less useful to implementers and easier to challenge in procurement or assessment review.

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.

  • Do not cite private reference labels, unpublished working notes, or private source locations.
  • 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

Related guides

Explore more topics

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 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 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 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 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.
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 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 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 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 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 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.
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.
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.