Industrial & OT Systems CVD Policy Template

[COMPANY NAME] designs and manufactures [DESCRIPTION OF PRODUCTS, e.g. programmable logic controllers, SCADA software, industrial HMIs, building automation controllers, distributed control systems]. Our products are deployed in industrial, critical infrastructure, and operational technology (OT) environments where availability, integrity, and safety are paramount.

This Coordinated Vulnerability Disclosure (CVD) Policy governs how [COMPANY NAME] receives, assesses, and responds to reports of security vulnerabilities in our products.

This policy is published in compliance with Article 13 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847). [COMPANY NAME]'s products include products classified as [Important / Critical] under CRA Annex III, for which third-party conformity assessment [is / will be] required.

We recognise that OT vulnerability management presents challenges distinct from IT software: systems may operate continuously for years without downtime, patches must be verified against certified configurations, air-gapped deployments limit update delivery, and exploitation of vulnerabilities can have physical safety consequences. This policy reflects those realities.

This policy covers the following [COMPANY NAME] products and associated software:

| Product Line | Models | CRA Classification | Annex III | Active Versions | |-------------|--------|--------------------|-----------|------------------| | [PRODUCT LINE 1] | [MODEL A, B] | [Important] | [Class II] | [Firmware X.x] | | [PRODUCT LINE 2] | [MODEL C, D] | [Important] | [Class I] | [Firmware Y.x] | | [PRODUCT LINE 3] | [MODEL E] | [Default] | [N/A] | [Version Z.x] | | [SCADA SOFTWARE] | — | [Important] | [Class I] | [Version 2.x, 3.x] | | [ENGINEERING WORKSTATION SOFTWARE] | — | [Default] | [N/A] | [All supported] |

Associated systems in scope:

• Remote access and management software: [PRODUCT NAME, VERSION]
• Historian and data collection software: [PRODUCT NAME, VERSION]
• OPC-UA and communication protocol stacks: [COMPONENT, VERSION]

Not covered by this policy:

• Products at end-of-life (see [SUPPORT PAGE URL])
• Third-party components integrated by end customers without [COMPANY NAME] involvement
• Vulnerabilities requiring sustained physical access to site infrastructure
• Safety instrumented systems (SIS) that are [independently certified / not under [COMPANY NAME] software control]

To report a security vulnerability in any [COMPANY NAME] product, please use:

Preferred: Submit via our vulnerability disclosure portal: [PORTAL URL]

Email: [[email protected]] PGP encryption: Key fingerprint [FINGERPRINT] | Available at [KEY URL]

security.txt: https://[YOUR-DOMAIN]/.well-known/security.txt

For URGENT reports (active exploitation suspected or confirmed, or safety-critical impact): contact [PSIRT EMERGENCY CONTACT] by telephone as well as submitting a written report.

Please include in your report:

• Affected product name, model, firmware/software version
• Whether the vulnerability is exploitable remotely (e.g. over OT network) or requires local/physical access
• Whether the vulnerability involves OPC-UA, Modbus, PROFINET, or other industrial protocol components
• Whether you believe safety systems could be affected
• Steps to reproduce in a test or lab environment if available
• Whether you are aware of any exploitation in operational environments

Reports involving active exploitation in industrial or critical infrastructure environments will be treated with the highest urgency and routed to our safety and critical infrastructure response team.

[COMPANY NAME] applies CVSS 4.0 severity scoring to all vulnerability reports. For OT and industrial products, we additionally assess the following factors:

Safety Impact Assessment

Vulnerabilities with potential physical safety consequences — including those that could affect safety instrumented systems, emergency shutdown systems, or process control integrity — are treated as Critical regardless of CVSS base score.

Safety impact indicators:

• Ability to modify or corrupt control system setpoints or logic
• Ability to interfere with or disable safety functions
• Ability to cause unexpected actuator, motor, or process state changes
• Vulnerability in a component interfacing with physical plant equipment

Availability Criticality

OT systems often have 99.999% availability requirements. Vulnerabilities enabling denial-of-service in production environments are elevated by one severity band compared to IT context.

IEC 62443 Security Level Assessment

Where applicable, we assess the vulnerability against the IEC 62443-3-3 security level requirements applicable to the affected product and deployment context.

Exploitation in Air-Gapped Environments

Many [COMPANY NAME] customers operate air-gapped OT networks. We assess:

• Can this vulnerability be exploited without internet connectivity?
• Does exploitation require access to the OT network (Level 0-2 in the Purdue model)?
• Could exploitation occur via a compromised IT/OT boundary device or removable media?

Priority Matrix:

| Severity | Safety Impact | Priority | |----------|--------------|----------| | Any | Confirmed | Critical | | Critical (CVSS 9+) | Possible | Critical | | High (CVSS 7+) | None | High | | Medium (CVSS 4-6.9) | None | Medium | | Low (CVSS <4) | None | Low |

[COMPANY NAME] acknowledges that OT patch deployment is fundamentally different from IT patch deployment. Operational environments often cannot be taken offline on short notice, and firmware updates to industrial controllers require certified test procedures before deployment in production.

Our patch delivery process:

1. Development and internal testing: Security fix developed and unit tested in our lab environment
2. Regression and integration testing: Fix tested against full product test suite, including hardware-in-the-loop testing where applicable
3. Certification verification: For products subject to functional safety certification (e.g. SIL-rated components), assessment of whether the change requires recertification
4. Staged release: Patch released initially to a subset of customers for validation before general availability
5. Customer notification: Customers notified via [NOTIFICATION CHANNEL] with patch notes and installation guidance

Workarounds and mitigations:

For vulnerabilities where a patch requires a planned maintenance window, [COMPANY NAME] will publish documented interim mitigations including:

• Network segmentation and firewall rule recommendations
• Access control hardening measures
• Monitoring signatures for detection of exploitation attempts
• Configuration changes that reduce attack surface

Targeted remediation timelines (OT-adjusted):

| Severity | Target Patch Time | Interim Mitigation | |----------|-------------------|--------------------| | Critical | [30] calendar days (patch), [72 hours] (mitigation published) | Required | | High | [60] calendar days | Required if >30 days | | Medium | [90] calendar days | Recommended | | Low | [180] calendar days | Optional |

Where a vulnerability cannot be remediated within these timelines due to certification or operational constraints, we will document the reason, provide the best available mitigations, and agree an extension timeline with the reporting researcher.

[COMPANY NAME] products are deployed in environments that may fall within the scope of critical infrastructure protection frameworks, including the EU NIS2 Directive (Directive (EU) 2022/2555).

Pre-notification for Critical vulnerabilities:

For Critical and High severity vulnerabilities, [COMPANY NAME] will provide pre-notification to affected critical infrastructure operators at least [10] business days before public advisory release, under embargo, to allow them to:

• Assess the impact on their specific deployments
• Prepare and schedule a maintenance window for patch deployment
• Implement interim mitigations pending the patch window
• Notify their own competent authorities if required under NIS2

Sector coordination:

[COMPANY NAME] participates in or coordinates with the following sector information sharing organisations where relevant to our products:

• [ICS-CERT / CISA ICS-CERT (for US-deployed products)]
• [ENISA ICS/SCADA working groups]
• [Sector-specific ISAC, e.g. E-ISAC for energy, WaterISAC]

Dedicated critical infrastructure contact:

Operators of critical infrastructure who need to report a vulnerability or discuss a security concern outside the standard disclosure process should contact: [DEDICATED CI SECURITY CONTACT EMAIL / PHONE]

NIS2 Interaction:

Operators of essential services using [COMPANY NAME] products who are themselves subject to NIS2 incident reporting obligations should note that a vulnerability in [COMPANY NAME] products does not automatically constitute a NIS2 reportable incident — the NIS2 reporting obligation depends on whether the incident has a significant impact on the continuity of the essential service.

Where a reported vulnerability affecting [COMPANY NAME] products meets the Article 14 CRA threshold — actively exploited or constituting a severe security incident — [COMPANY NAME] will:

1. Submit an early warning to ENISA within 24 hours of becoming aware
2. Submit a full notification to ENISA within 72 hours
3. Submit a final report within 14 days

For OT/ICS products, Article 14 triggers are particularly relevant where:

• A vulnerability is actively exploited in an industrial or critical infrastructure environment
• A vulnerability enables disruption of industrial process control or safety functions
• A vulnerability is being exploited in a campaign targeting OT environments (e.g. confirmed threat actor activity)
• A severe security incident has caused or risks causing physical consequences

NIS2 co-notification:

Article 14 CRA notifications are made to ENISA in [COMPANY NAME]'s capacity as a manufacturer. [COMPANY NAME]'s obligations under Article 14 are distinct from the reporting obligations of critical infrastructure operators under NIS2.

However, where [COMPANY NAME] becomes aware that a vulnerability in our products is being actively exploited against NIS2-essential service operators, we will additionally notify the relevant national CSIRT(s) to enable sector-level coordination.

Notifications are submitted via the ENISA Single Reporting Platform (SRP).

[COMPANY NAME] authorises good-faith security research on [COMPANY NAME] products conducted in accordance with this policy.

We will not take legal action against researchers who:

• Follow this policy
• Conduct research using test equipment or lab environments, not production OT systems
• Limit testing to what is strictly necessary to confirm the vulnerability exists
• Report to us before any public or third-party disclosure

Critical OT safety restriction: Security research on [COMPANY NAME] products must NOT be conducted on equipment connected to live production, operational, or safety-critical systems. Testing on live industrial control systems can cause unexpected process states, equipment damage, or physical harm.

[COMPANY NAME] can provide access to a dedicated test environment for researchers requiring realistic hardware or software configurations for OT research. Contact [[email protected]] with a description of your research to request access.

Responsible disclosure for OT vulnerabilities: We ask researchers to exercise particular care in timing public disclosure of vulnerabilities affecting OT systems, given the longer patch deployment windows in operational environments. We will always honour our 90-day coordinated disclosure timeline, but we may request an extension of up to [30] days for vulnerabilities requiring certified configuration testing before patch deployment. We will not request unlimited extensions.