Undocumented PLC Code as a Safety Risk

An undocumented PLC program is a liability. When no one understands what the code does, every maintenance intervention becomes a gamble. Wrong assumptions about timer values, safety interlocks, or sequence logic can cause machine damage, product defects, or injuries. This article explains the concrete risks and what standards like IEC 62443 and the EU Machinery Regulation expect from plant operators.

The Four Risks of Undocumented PLC Code#

1. Operational Risk: Uncontrolled Changes#

When a technician modifies a program they do not fully understand, the consequences are unpredictable. Common scenarios:

Changing a timer value without understanding the context. A timer that appears to be "just a delay" may actually be a critical safety interlock. Reducing it from 5 seconds to 1 second because "the machine runs too slow" can eliminate the time needed for a hydraulic pressure release, a safety gate to close, or a motor to reach full speed before the next operation starts.

Disabling an interlock to "get production running." When a sensor fails and the machine stops, the pressure to restart production is immense. A technician who does not understand the interlock logic may bridge the sensor input (force it TRUE) without realizing that the sensor protects against a collision, an overflow, or a pinch point.

Copy-paste errors across similar machines. When a program modification works on Machine A, it gets copied to Machine B — but Machine B has a different I/O configuration, different timer values, or different safety requirements. Without documentation, these differences are invisible.

These are not theoretical risks. They happen in industrial plants every week. The difference between "nothing happened" and a serious incident is often just luck.

2. Knowledge Risk: Single Point of Failure#

When only one person understands the PLC program, that person is a single point of failure — for the entire production system.

Retirement: The engineer who wrote the program 20 years ago retires. Their knowledge of why certain logic exists, what edge cases it handles, and what must never be changed disappears permanently.

Job change: A key technician leaves for another company. The replacement has no context for the existing code.

Illness or absence: Even a two-week vacation by the only person who understands a critical system can create unacceptable risk if a failure occurs during that time.

The cost of this knowledge loss is not immediately visible. It manifests as longer troubleshooting times, more trial-and-error during maintenance, higher scrap rates after program changes, and eventually a catastrophic failure that no one can diagnose.

3. Cybersecurity Risk: Unknown Attack Surface#

Undocumented PLC code creates cybersecurity blind spots:

No baseline for change detection. If you do not know what the program should look like, you cannot detect unauthorized changes. A malicious actor (or even a well-meaning but unauthorized modification) goes unnoticed.

Unknown network exposure. Undocumented communication blocks may connect the PLC to networks that the IT department does not know about. Legacy S5 and S7-300 systems often have MPI, PROFIBUS, or even dial-up modem connections that were configured decades ago and never documented.

No patch management possible. You cannot assess whether a firmware update is safe to apply if you do not understand what the PLC program does. Many operators choose to never update, which leaves known vulnerabilities permanently open.

The 2022 Pipedream malware toolkit, designed specifically to target PLCs and SCADA systems, demonstrated that industrial control systems are active targets. Undocumented systems are the easiest targets because their owners cannot even describe what "normal" looks like.

4. Compliance Risk: Regulatory Requirements#

Several regulatory frameworks either explicitly or implicitly require documented control systems:

IEC 62443 (Industrial Cybersecurity): IEC 62443 defines maturity levels for industrial cybersecurity. At Level 1 (Initial), processes are described as "ad hoc and often undocumented." To reach Level 2 (Managed) and above, documented processes are mandatory. An undocumented PLC program fails even the most basic IEC 62443 maturity assessment.

IEC 62443 also requires change management for IACS (Industrial Automation and Control Systems). Change management is impossible without a documented baseline.

EU Machinery Regulation (2023/1230): The new EU Machinery Regulation (replacing the Machinery Directive 2006/42/EC) requires that manufacturers provide "instructions and information for safe use." For machines with PLC-based safety functions, this includes documentation of the control logic. While this primarily applies to machine manufacturers, plant operators who modify machines must maintain equivalent documentation.

ISO 13849 / IEC 62061 (Functional Safety of Machinery): These standards require that safety-related control functions are documented, validated, and maintained. An undocumented PLC program that includes safety interlocks cannot demonstrate compliance with these standards. During an accident investigation, the absence of documentation becomes a serious liability.

Insurance and liability: Industrial insurance policies increasingly require evidence of maintenance management — including software maintenance. An undocumented control system may void or limit insurance coverage in the event of a claim.

The Minimum Acceptable Documentation#

You do not need a 200-page manual for every PLC. But you need at least:

1. A symbol table with meaningful names for every used I/O address
2. Network comments explaining the purpose of each logic section
3. A current backup of the PLC program, verified and stored in at least two locations
4. An I/O list mapping PLC addresses to physical devices (sensors, actuators)
5. A change log recording every modification with date, author, and reason

This minimum documentation can be created in 1–3 days for a typical PLC program (see our documentation guide). The cost of not having it can be measured in production days lost, safety incidents, and audit findings.

How PLCcheck Pro Helps#

PLCcheck Pro is designed specifically for undocumented PLC code:

• Upload raw AWL/STL code → get plain-language explanations of every block
• Automatic I/O identification → see every input and output used in the program
• Safety-relevant pattern recognition → identifies interlocks, emergency stop logic, safety timers
• Instant documentation → exportable reports you can hand to auditors, management, or maintenance teams

Documentation is not a project you do once. It is a habit that starts with understanding what you have. PLCcheck Pro makes that first step fast.

Upload your code now →

Frequently Asked Questions#

Is undocumented PLC code illegal?

Not directly. There is no law that says "PLC programs must be documented." However, if a safety-related function is undocumented and an accident occurs, the absence of documentation can be used as evidence of negligence. Standards like IEC 62443, ISO 13849, and the EU Machinery Regulation set clear expectations for documentation.

Who is responsible for PLC documentation?

The plant operator (asset owner) is ultimately responsible for maintaining their control systems, including documentation. Machine manufacturers are responsible for delivering initial documentation. After modifications, the responsibility shifts to whoever made the change.

Can undocumented code cause a failed audit?

Yes. IEC 62443 audits, ISO audits, insurance inspections, and customer audits increasingly include questions about control system documentation. "We do not have documentation" is a finding that can lead to corrective action requirements, higher insurance premiums, or loss of customer certification.

---

Maintained by PLCcheck.ai. Last update: March 2026. Not affiliated with Siemens AG.