---
title: "ETSI TS 103 701 Test Evidence Workflow for EN 303 645"
canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow"
source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow"
author: "Sorena AI"
description: "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."
published_at: "2026-05-09"
updated_at: "2026-05-27"
keywords:
  - "ETSI TS 103 701 test evidence"
  - "ETSI EN 303 645 assessment workflow"
  - "ICS IXIT"
  - "consumer IoT conformance assessment"
  - "external evidence"
  - "ETSI TS 103 701"
  - "ETSI EN 303 645"
  - "test evidence"
  - "ICS and IXIT"
  - "consumer IoT security"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

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

*Assessment Workflow* *GLOBAL* *ETSI EN 303 645*

## ETSI TS 103 701 test evidence workflow

A source-linked workflow for moving from EN 303 645 provision claims to TS 103 701 DUT identification, ICS, IXIT, test planning, verdicts, and external evidence review.

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

Use this page when a consumer IoT team needs to prepare evidence for an ETSI TS 103 701 assessment against ETSI EN 303 645 provisions. EN 303 645 supplies the baseline consumer IoT provisions and the ICS pro forma context; TS 103 701 supplies the assessment methodology, including the Device Under Test, Supplier Organization, Test Laboratory, ICS, IXIT, test-plan, verdict, and external-evidence concepts.

## Start with the DUT, not a generic control list

ETSI TS 103 701 defines the Device Under Test as the specific consumer IoT device that is assessed against ETSI EN 303 645 provisions. The evidence workflow should therefore begin with a precise DUT record before anyone collects policies, test reports, screenshots, or external certificates.

The DUT record should identify the product boundary, software version, offered interfaces, relevant user documentation, and the associated-service relationships that matter to the assessed functionality. TS 103 701 assumes the DUT is in live operation for assessment purposes and that the test laboratory is not in control of the associated services belonging to the DUT, so evidence should explain how those dependencies are observed or documented.

- Create one DUT identification record for the exact model, release, firmware or software version, and assessed configuration.
- List device interfaces, user-facing setup paths, companion application dependencies, update paths, and associated services that affect EN 303 645 provision claims.
- Name the Supplier Organization contact and evidence owners because TS 103 701 expects the SO to provide the ICS, IXIT, and information needed by the Test Laboratory.
- Do not reuse evidence from a different product, software release, service environment, or assessment boundary unless the scope match is explicit.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for DUT, SO, TL, live-operation assumptions, and the role of associated services in assessment.
- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Source for the consumer IoT scope, including devices connected to network infrastructure and interactions with associated services.

## Convert EN 303 645 provisions into ICS support claims

The ICS is where the Supplier Organization states which EN 303 645 provisions are claimed for the DUT. Keep this separate from internal control language: the support decision should be tied to the EN 303 645 provision, while the detail field explains the implemented measure, non-support reason, or not-applicable rationale.

EN 303 645 Annex B provides the pro forma context for support values and detail. TS 103 701 then requires the SO to complete the ICS correctly and requires the Test Laboratory to validate the ICS, including checking mandatory provisions, conditional provisions, feature-dependent provisions, and N/A claims against the available information.

- Use ICS rows for support status: Yes for provisions claimed as supported, N for applicable provisions not fulfilled, and N/A only where the conditional or feature logic permits it.
- Require a detail entry for every supported, unsupported, or not-applicable decision so the reason is reviewable outside the drafting team.
- Check that no mandatory provision is claimed as N in a final passing assessment set.
- Check that every N/A aligns with the condition or feature status and is not contradicted by the DUT, user documentation, or IXIT.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1 Annex B ICS pro forma](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Source for support statuses, detail expectations, mandatory and recommended notation, and N/A rationale in the implementation conformance statement pro forma.
- [ETSI TS 103 701 V2.1.1 assessment procedure](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for completing and verifying the ICS during the assessment procedure.

## Build IXIT only for the claimed assessment scope

The IXIT is not a new EN 303 645 obligation. Under TS 103 701, it is the extra implementation and assessment-environment information that enables the Test Laboratory to perform appropriate test activities. It is the basis for grey-box testing and provides design details for the TL.

Complete IXIT entries for provisions claimed as Yes in the ICS. TS 103 701 says the SO is not required to complete all IXIT entries, but the entries that are necessary for claimed provisions need to be exhaustive and correct. If the information is incomplete or insufficient for proper test execution, an inconclusive verdict may result.

- Map each Yes claim to the IXIT entries needed by the related test group, rather than collecting broad evidence folders with no provision link.
- Use distinct identifiers inside IXIT tables so test results, indications, documents, and exceptions can reference the exact mechanism or process.
- If the IXIT references existing product documentation, provide that documentation to the assessment owner or TL instead of relying on a bare citation.
- Review IXIT completeness before testing begins; missing IXIT detail is a test-execution risk, not a formatting issue.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 IXIT methodology](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for IXIT purpose, grey-box testing, completion expectations, references to existing documentation, and inconclusive verdict risk.

## Plan conceptual and functional evidence separately

TS 103 701 test cases typically distinguish conceptual and functional aspects. Conceptual assessment checks conformity of the IXIT against the requirements of the provision, while functional assessment checks DUT functionality, associated-service relations, or development and management processes against the provision requirements.

A useful evidence workflow therefore has two lanes. The conceptual lane holds design explanations, process descriptions, public user information, IXIT entries, and documented rationale. The functional lane holds observations from the DUT, interface behavior, test outputs, update behavior, publication checks, or process evidence that demonstrates the implementation behaves as claimed.

- For each test group, identify whether the evidence needed is conceptual, functional, or both.
- Tie conceptual evidence to the IXIT entry and EN 303 645 provision it is intended to support.
- Tie functional evidence to the exact DUT configuration, test conditions, tools, and observable result.
- Document the indications used for verdict assignment so another reviewer can reproduce the reasoning.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 test scenarios and test cases](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for conceptual and functional test distinctions, test plans, test units, and documented indications for verdicts.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize ETSI EN 303 645 assessment evidence

Use this workflow to connect DUT scope, EN 303 645 ICS claims, TS 103 701 IXIT detail, test plans, verdict records, and external evidence checks.

- [Open Assessment Autopilot for ETSI EN 303 645](/solutions/assessment.md): Convert DUT scope, ICS rows, IXIT dependencies, evidence gaps, and verdict readiness into accountable assessment tasks.
- [Research ETSI EN 303 645 source questions](/solutions/research-copilot.md): Resolve applicability, ICS, IXIT, external-evidence, and verdict questions before implementation or assessor handoff.
- [Talk through ETSI EN 303 645 assessment evidence](/contact.md): Review DUT scope, provision claims, evidence owners, and TS 103 701 workflow gaps with Sorena.

## Use verdict rules as evidence gates

TS 103 701 defines overall verdicts, test group verdicts, and test case verdicts. For workflow purposes, this means an evidence pack should not stop at gathered documents; it should show whether each claimed provision has enough material for the corresponding test group and whether the result is pass, fail, inconclusive, or still open.

The overall verdict depends on a valid ICS and the verdicts for provisions claimed as Yes. A PASS requires the ICS to be valid and every provision claimed as Yes in the ICS to have a PASS test group verdict. A FAIL can result from an invalid ICS or from at least one claimed provision receiving a FAIL test group verdict. An INCONCLUSIVE result covers situations where no fail criterion is met but at least one claimed provision has an inconclusive test group verdict.

- Add a verdict-readiness field to each provision row: ready for test, missing IXIT, missing DUT access, external evidence under review, pass, fail, or inconclusive.
- Do not describe a provision as passed until the corresponding test group verdict basis is recorded.
- Treat missing test elements, missing tools, or insufficient IXIT as potential inconclusive blockers.
- Keep recommended-provision failures visible; TS 103 701 explains how assessment results may be reused with a revised ICS and justification, but the original gap should not be hidden.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 verdict assignment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for overall, test group, and test case verdict rules, including PASS, FAIL, and INCONCLUSIVE handling.

## Control external evidence before relying on it

TS 103 701 allows existing security certifications or third-party evaluations of parts of the DUT to be used partially as evidence to reduce assessment effort. That is not the same as a blanket EN 303 645 conformance claim. The SO has to announce the evidence in the addressed ICS detail field and provide the certification, certification details, test reports, or other information needed for verification.

The Test Laboratory still examines whether the external evidence is adequate for the corresponding test group. TS 103 701 requires review of scope against the test group objective, whether the test activities meet each test purpose in the group, and whether the test depth or evaluation assurance level is appropriate to the level addressed by the test group.

- Record the evidence scope, issuing body or evaluator, date or version, assessed component or process, and the EN 303 645 provision or TS 103 701 test group it supports.
- Reject external evidence that covers a different device, software version, service boundary, cryptographic configuration, or process than the assessed DUT.
- Store the underlying report or certificate detail, not only a marketing label or high-level statement.
- Keep accepted external evidence as a test group input, not as a claim that the whole product is certified unless a separate scheme supports that wording.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 external evidences](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for when existing certifications or third-party evaluations may be used and what the TL examines before accepting them for a test group.

## Workflow table for assessment preparation

Use this as the operating sequence for an assessment-preparation tracker: Step | Owner | Evidence object | Decision gate.

1 | Supplier Organization | DUT identification record | Is the assessed product boundary specific enough for the TL to plan tests?

2 | Provision owner | EN 303 645 ICS row | Is the support decision Yes, N, or N/A with the required detail or rationale?

3 | Evidence owner | IXIT entry or referenced document | Is the information exhaustive and correct for each provision claimed as Yes?

4 | Test owner or TL | Conceptual and functional test plan | Are methods, tools, conditions, and instructions adequate for the DUT and IXIT?

5 | Assessment owner | Test case, test group, and overall verdict record | Is the result pass, fail, inconclusive, or blocked by missing evidence?

6 | External evidence owner | Certificate, third-party report, or evaluation record | Does the evidence satisfy the TS 103 701 scope, test-purpose, and depth checks?

- Keep the EN 303 645 provision claim, TS 103 701 assessment input, and actual evidence artifact in separate fields.
- Require a named owner and review status for every missing ICS detail, IXIT entry, public document, test result, or external evidence item.
- Update the evidence pack after material product, software, interface, associated-service, user-documentation, or process changes.
- Avoid public claims that imply certification, legal compliance, or complete product security unless a separate assessment scheme, certificate, or legal review supports them.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 assessment procedure](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Source for the assessment phases: DUT identification, ICS, IXIT, ICS verification, performing assessment, and overall verdict.
- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Source for EN 303 645 as the consumer IoT baseline provisions being claimed through the ICS.

## Primary sources

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, scope, applicability, and Annex B implementation conformance statement pro forma.
  - Quote: "Baseline Requirements"
- [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT identification, SO and TL roles, ICS, IXIT, conceptual and functional tests, verdicts, and external evidence handling.
  - Quote: "The TL uses these documents to derive a test plan."

## Related Topic Guides

- [ETSI EN 303 645 Applicability and Scope](/artifacts/global/etsi-en-303-645/applicability-and-scope.md): 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](/artifacts/global/etsi-en-303-645/compliance.md): Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and source-linked controls.
- [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md): ETSI EN 303 645 FAQ on consumer IoT product scope: devices, associated services, constrained devices, out-of-scope industrial uses, ICS, IXIT, and TS 103 701 evidence.
- [ETSI EN 303 645 Current Version Tracker](/artifacts/global/etsi-en-303-645/current-version-tracker.md): 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](/artifacts/global/etsi-en-303-645/vulnerability-disclosure-cvd-workflow.md): Source-linked 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](/artifacts/global/etsi-en-303-645/data-protection-provisions.md): source-linked guide to ETSI EN 303 645 data protection provisions for consumer IoT: personal data security, telemetry transparency, consent, and deletion evidence.
- [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md): 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](/artifacts/global/etsi-en-303-645/faq.md): source-linked answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, default passwords, updates, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence.
- [ETSI EN 303 645 ICS and IXIT Evidence Template](/artifacts/global/etsi-en-303-645/ics-and-ixit-evidence-template.md): Build a source-linked ICS and IXIT evidence template for ETSI EN 303 645 consumer IoT assessments, with clear separation between EN provisions and TS 103 701 test information.
- [ETSI EN 303 645 implementation checklist](/artifacts/global/etsi-en-303-645/implementation-checklist.md): Use this ETSI EN 303 645 implementation checklist to 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](/artifacts/global/etsi-en-303-645/implementation-evidence.md): 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](/artifacts/global/etsi-en-303-645/iot-applicability-workflow.md): 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](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md): 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](/artifacts/global/etsi-en-303-645/requirements.md): 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](/artifacts/global/etsi-en-303-645/secure-update-evidence-workflow.md): 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](/artifacts/global/etsi-en-303-645/secure-update-workflow.md): 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](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): source-linked guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and TS 103 701 evidence.
- [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md): ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, constrained-device replacement support, model designation, and TS 103 701 evidence.
- [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md): 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?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md): 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](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-eu-cra.md): Use ETSI EN 303 645 and ETSI TS 103 701 evidence when preparing consumer IoT cybersecurity work that may also need a separate EU CRA legal mapping.
- [ETSI EN 303 645 vs RED Cybersecurity Delegated Act](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-red-cybersecurity-delegated-act.md): Compare ETSI EN 303 645 consumer IoT security evidence with RED cybersecurity planning without treating the ETSI baseline as a substitute for RED legal scope.
- [ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Compare ETSI EN 303 645 evidence with UK PSTI review needs without assuming the same scope, legal trigger, or assurance route.
- [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md): 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?](/artifacts/global/etsi-en-303-645/faq/constrained-devices.md): ETSI EN 303 645 constrained-device guidance: what counts as constrained, when non-applicability can be justified, and what evidence should support update and authentication decisions.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow
