Publish a policy with report contact details, response timing, and enough information for a reporter to submit a vulnerability; then monitor, triage, remediate, and retain evidence through the . ETSI EN 303 645 V3.1.3 provision 5.2 states the disclosure, timely-action, and monitoring expectations. ETSI TS 103 701 V2.1.1 assesses them through public-policy checks, information, confirmations, and verdicts. Separate laws or assessment schemes can impose additional reporting events and clocks.
1
Section 1
What EN 303 645 says about vulnerability disclosure
EN 303 645 provision 5.2-1 states that the manufacturer shall make a publicly available. At minimum, the policy shall 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 describes 90 days as a conventional time in which a software vulnerability process is completed, including patch availability and notification. It is not a universal deadline: the standard says timing is incident-specific, and hardware fixes or deployment to devices can take longer.
Provision 5.2-3 adds the operating recommendation 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 .
Publish a where researchers and others can access it without an account or gated support flow.
Include a reporting contact route, acknowledgement timeline, and status-update timeline in the public policy.
Define how reported vulnerabilities are triaged, remediated, communicated, and tracked to resolution.
Keep vulnerability monitoring active for products and related services during the .
Workflow from report intake to remediation decision
The public disclosure policy starts the workflow. A useful CVD process shows how a report reaches the responsible team, how the reporter receives an acknowledgement, how product impact is assessed, and how the organization chooses 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.
Intake: receive reports through the published contact route and record affected product, service, firmware, app, component, and reporter contact details.
Acknowledgement: respond within the policy timeline and give the reporter a status-update expectation that can be tracked.
Triage: classify whether the issue affects a single product or service, a third-party component, hardware, firmware, software, an associated service, or a potentially systemic vulnerability.
Action: assign a remediation path, owner, collaboration contacts, expected timeframe, and communication decision.
Closure: record the fix, mitigation, update, notification, or unresolved risk decision and keep the status history with the report.
How TS 103 701 turns the workflow into assessment evidence
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 information to the test laboratory. IXIT 2-UserInfo describes the publication of the , 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 EN 303 645 to define the public policy and operating expectations.
Use TS 103 701 TSO 5.2 to structure assessment evidence for publication, contents, action timeliness, implementation confirmation, and vulnerability monitoring.
Do not call a policy assessed merely because it exists internally; TS 103 701 checks public accessibility and required contents.
Do not use evidence as public marketing copy unless the claim also matches the published policy, DUT boundary, and assessment scope.
This operating table applies when turning provision 5.2 into reviewable evidence. The rows are written so each one can become a task, entry, support runbook item, or assessment request.
| Step | Owner | Evidence | Decision |
| --- | --- | --- | --- |
| 1 | Product security owner | Public 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, 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? |
Keep the table product-specific; copying another product's response timings or vendor contacts creates weak evidence.
Record third-party component and associated-service dependencies because TS 103 701 considers collaboration and clearly defined responsibilities as indicators for timely deployment.
Keep public policy evidence separate from internal vulnerability action records so public accessibility and remediation operations can be assessed independently.
Implementation checklist for EN 303 645 provision 5.2
Review 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.
Public policy: publish a on a stable external page and make sure it is reachable without a login.
Minimum contents: include reporting contact information, initial acknowledgement timing, and status-update timing until resolution.
Intake records: capture affected products, firmware, software, app, cloud or associated-service dependencies, component origin, reporter contact, dates, and current status.
Action matrix: define actions and time frames for vulnerability types, including firmware, hardware, software, associated services, open source components, and commercial third-party libraries where applicable.
Monitoring: document how the team continually monitors for, identifies, and rectifies security vulnerabilities during the .
Assessment pack: maintain the ICS claim and entries needed for TSO 5.2, with confirmations that the implementation preconditions are in place.
A generic security email address is not a complete disclosure policy. The policy also needs acknowledgement and status-update timelines, while internal records need to map vulnerability actions to the DUT, associated services, and .
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.
Do not claim provision 5.2 coverage if the disclosure policy is internal, login-gated, or missing acknowledgement and status-update timelines.
Do not mix EN 303 645 provisions with TS 103 701 verdict language; one states baseline expectations, the other structures assessment checks.
Do not assume a hardware or third-party component issue follows the same remediation timing as a server-side software fix; document the dependency and communication path.
Do not stop at intake; provision 5.2-3 also expects continuous monitoring, identification, and rectification during the .
Do not cite local evidence records or internal source records in public source entries; use stable external HTTPS URLs with the Sorena reference parameter.