ETSI EN 303 645 CVD workflow

EN 303 645 provision 5.2-1 requires the manufacturer to make a vulnerability disclosure policy publicly available. At minimum, the policy has to give contact information for reporting issues and timelines for initial acknowledgement and status updates until resolution.

Provision 5.2-2 says disclosed vulnerabilities should be acted on in a timely manner. The standard warns that timing is incident-specific: software fixes are conventionally completed within 90 days including patches and notification, while hardware fixes or deployed-device rollouts can take longer.

Provision 5.2-3 adds the operating duty behind the policy: manufacturers should continually monitor for, identify, and rectify security vulnerabilities in products and services they sell, produce, have produced, and operate during the defined support period.

Treat the public disclosure policy as the start of the workflow, not the whole control. A useful CVD process shows how a report reaches the right team, how the reporter receives an acknowledgement, how severity and product impact are assessed, and how the organization decides between a fix, mitigation, warning, or coordinated escalation.

EN 303 645 recognizes different disclosure paths. Product-specific vulnerabilities are expected to be reported to the affected stakeholder first, such as the device manufacturer, IoT service provider, or mobile application developer. For systemic vulnerabilities, a competent industry body can coordinate a wider response.

TS 103 701 does not supersede the EN 303 645 requirement. It gives an assessment method for checking whether the DUT, associated services, and relevant processes support the claimed provision. For TSO 5.2, it separates public-policy publication checks from process and monitoring evidence.

The assessment vocabulary matters. The supplier organization provides ICS and IXIT information to the test laboratory. IXIT 2-UserInfo describes the publication of the vulnerability disclosure policy, IXIT 3-VulnTypes describes actions and time frames for vulnerability types, IXIT 4-Conf records confirmations, and IXIT 5-VulnMon documents monitoring, identifying, and rectifying procedures.

Use this operating table when turning provision 5.2 into reviewable evidence. The rows are written so each one can become a task, IXIT entry, support runbook item, or assessment request.

| Step | Owner | Evidence | Decision |

| --- | --- | --- | --- |

| 1 | Product security owner | Public vulnerability disclosure policy URL and access path | Can anybody access the policy without an account? |

| 2 | Security operations or support owner | Contact route, acknowledgement timeline, and status-update timeline | Does the policy contain the minimum EN 303 645 information? |

| 3 | Vulnerability response owner | Vulnerability-type action matrix with owners, time frames, collaboration contacts, and escalation rules | Is there no indication that described vulnerability types are handled untimely? |

| 4 | Engineering or supplier owner | Fix, mitigation, warning, rollout, or third-party coordination record | Does the response path fit firmware, hardware, software, associated-service, or component realities? |

| 5 | Compliance or assessment owner | ICS support claim, IXIT 2-UserInfo, IXIT 3-VulnTypes, IXIT 4-Conf, IXIT 5-VulnMon, and test verdicts | Does the evidence match the DUT and associated services in scope? |

Use this checklist before release, procurement review, or TS 103 701 evidence collection. It focuses on whether the CVD workflow is visible, actionable, and tied to the product boundary rather than buried in general support language.

Most weak evidence is not caused by missing terminology. It comes from treating a generic security email address as a disclosure policy, publishing a policy with no update expectations, or keeping vulnerability actions in ticket notes that cannot be mapped to the DUT, associated services, and support period.

Be careful with the 90-day statement in EN 303 645. It is described as a conventional software vulnerability process timeline, not a universal deadline for every hardware, firmware, associated-service, or third-party dependency scenario.