How should safety-related control systems be covered?
Annex III section 1.2.1 requires control systems to be designed and constructed so hazardous situations do not arise. For cybersecurity, the key evidence is not a generic penetration-test label; it is the link between foreseeable interference and the safety function that could fail.
The record should cover hardware faults, logic errors, human error, external influences, and reasonably foreseeable malicious attempts from third parties where those attempts could lead to a hazardous situation. For uploaded safety software, the Regulation also calls for a tracing log of intervention data and safety-software versions after placing on the market or putting into service.
- Map each safety function to the sensors, logic, actuators, safety components, software versions, and data inputs it depends on.
- Record the limits of the safety function set by the manufacturer's risk assessment and show that later settings or learned rules cannot be changed in a way that creates a hazardous situation.
- Keep validation evidence for failures in hardware, logic, communications, configuration, and software updates that could affect the safety function.
- Enable traceability for intervention data and uploaded safety-software versions for the Regulation's five-year period where Annex III section 1.2.1(f) applies.
- For software-based safety systems with fully or partially self-evolving behaviour or logic, keep the safety-related decision-making data required by Annex III section 1.2.1 for the Regulation's one-year period where that requirement applies.
Supports the control-system requirements in Annex III section 1.2.1, including faults, logic errors, external influences, malicious attempts, safety-software trace logs, and retained decision-making data for certain software-based safety systems.
Provides machinery-manufacturer guidance on cybersecurity aspects related to ISO 12100 when IT-security threats can influence machinery safety.