Walk into most water plants, substations, or production lines and you will find people who know their systems cold. Ask the same team for a current asset inventory, a network diagram that matches what is actually on the wire, or a written process for vendor remote access, and the answer is often a long pause.
That is the OT documentation gap. It is rarely a knowledge problem. It is a writing-it-down problem, and it creates real risk for the organizations that run critical infrastructure.
Why OT documentation falls behind
- Systems outlive the people who built them. Controllers and HMIs stay in service for decades. Integrators come and go, and the drawings stay in a binder from the original install.
- IT policies do not fit. Many OT teams inherit a policy set written for the office: regular patching, agents on every endpoint, reboots whenever needed. Operators cannot follow it, so it gets ignored, and the real practices never get written down.
- Changes happen in the field. A switch added for a project, a laptop left for a vendor, a firewall rule opened during troubleshooting. Each one makes sense in the moment. Few make it back into the documentation.
- Nobody owns it. Engineering owns the process, IT owns the network, and security owns compliance. Documentation for the OT environment falls in the gap between them.
Where the gap shows up
Audits and assessments. The frameworks built for OT expect evidence. NERC CIP asks registered entities to show configuration baselines, change control, and access records. ISA/IEC 62443 starts with defining zones and conduits, which you cannot do without an accurate picture of assets and connections. CISA's Cybersecurity Performance Goals list an asset inventory and a documented network topology among the basics. Without the documentation, an assessment stalls at step one.
Incidents. When something goes wrong at 2 a.m., responders need to know what is connected to what, who has remote access, and how to bring a system back to a known good state. Without that, response is slower and recovery is riskier.
Turnover. When a senior operator or controls engineer retires, undocumented knowledge walks out the door with them.
Scrutiny from outside. Regulators, insurers, and customers increasingly ask for evidence, not assurances. "We have it handled" is not an answer they can accept.
What good looks like
Good OT documentation is not a thousand-page binder. It is a small set of living documents that match reality:
- An asset inventory covering controllers, HMIs, engineering workstations, and network gear, with firmware versions and owners
- Network architecture diagrams that show zones, conduits, and every path in from outside, including remote access
- OT-specific policies and procedures that operators can actually follow
- Configuration baselines and a change management process that keeps them current
- An incident response and recovery plan written for the plant, not the office
- A record of who has access, and why
The bottom line
Documentation is not paperwork for its own sake. It is how you prove your systems are secure, how you recover when they are not, and how you keep hard-won knowledge in the building.
In our next post, we walk through how to build OT documentation without taking the plant offline.
Questions about OT documentation or GRC? Reach out to Kelli Tarala, our Director of GRC, through our contact form.