GLOBAL-CAPABILITY-04 · SCADA & OT
Restore operator trust before remote control.
For overseas owners, OEMs, integrators and cybersecurity teams coordinating work in Korea, a responsive HMI is not proof of safe recovery. Integration evidence must connect asset identity, point meaning, data quality and time, command authority, physical feedback, failure behavior, rollback and accountable handover.
SYSTEM BOUNDARY
Six workstreams that must remain traceable end to end
Assets and operating authority
Site, process, controller, HMI, SCADA, historian, gateway, versions, drawings, owners, local/remote modes and final control authority.
Point and event meaning
Source tag, engineering unit, scale, state, quality, source timestamp, alarm priority, event sequence, historian rule and consumer.
Command-to-field chain
User and role, command origin, permissive, inhibit, arbitration, output, device readback, physical process response and failed-command behavior.
Network and trust boundary
Zones, conduits, interfaces, protocols, ports, certificates, accounts, remote access, jump path, logging, exposure and external dependencies.
Backup and recovery
Projects, configurations, licenses, certificates, historian data, time source, redundancy, safe state, restore order, validation and rollback.
Tested as-left operation
FAT and SAT evidence, failure scenarios, limitations, disabled functions, open items, training, source files, signatures and follow-up ownership.
EVIDENCE GATES
A green screen is observation—not operational release.
| Gate | Question to close | Minimum evidence | Named output |
|---|---|---|---|
| 0 · Safe operating boundary | What process, energy, personnel and local-control state permits this integration test? | Work boundary, affected assets, permits, safe state, local fallback, stop authority and named operating owner | Approved work and control boundary |
| 1 · Architecture baseline | What exact assets, versions, paths, zones and trust relationships are being accepted? | Asset list, drawings, data flows, interfaces, protocol and port list, accounts, certificates, backups and responsibility matrix | Approved architecture and discrepancy register |
| 2 · Trusted observation | Does each displayed value preserve source identity, meaning, quality, time and event behavior? | Point map, unit and scale, source and server timestamps, quality states, alarms, SOE, historian gaps and read-only tests | Observed-data verification record |
| 3 · Controlled command | Can one authorized command prove its entire path and physical result under bounded conditions? | Role and mode, select/operate or equivalent, command and readback, permissive and inhibit, field feedback, timeout and failed-command test | End-to-end function proof |
| 4 · Failure and recovery | What proves safe degradation, restoration, rollback and accepted as-left operation? | Loss-of-link and service tests, redundancy, safe state, restore sequence, backups, audit evidence, residual limits and acceptance signatures | Accepted recovery and as-left package |
STOP CONDITIONS
Hold remote control when the evidence is not trustworthy.
Local/remote, manual/auto, active owner, fallback operator or stop authority cannot be confirmed.
Source tag, unit, scale, normal state, alarm meaning or consumer mapping does not match.
Source time, server time, quality state, stale-data behavior or historian gap cannot be distinguished.
Unknown account, exposed service, shared credential, unapproved remote path or invalid certificate remains.
A command appears successful without independent device and process feedback or failed-command behavior.
Original backup, safe state, restore order, rollback, open-item owner or final acceptance authority is missing.
PREPARE THE BOUNDARY
Start with a five-part integration and recovery brief
- 01Identify the process and assets.
System boundary, critical functions, controllers, servers, gateways, clients, versions, drawings and dependencies.
- 02Name the authorities.
Owner, operations, control engineer, OEM, integrator, cybersecurity, safety and final release roles.
- 03Define modes and failure states.
Local, remote, manual, auto, degraded, isolated, link loss, server loss, stale data, recovery and rollback.
- 04Define evidence and acceptance.
Original logs, point map, test records, timestamps, expected response, stop condition, limitation and reviewer.
- 05Name the final package.
As-left files, backups, accounts and certificates, diagrams, test results, disabled features, open items and ownership.
Confirm the country, AHJ, site policy, permits, safety functions, cybersecurity program, qualified personnel, OEM instructions and responsible owner before scanning, changing, connecting, commanding, restoring or releasing an OT system.
OFFICIAL PRIMARY SOURCES
Use each source within its published scope and site context.
- NIST SP 800-82 Rev. 3 — OT security with performance, reliability and safety considerations
- IEC 62443-3-2:2020 — IACS security risk assessment for system design
- ISA/IEC 62443 series — lifecycle roles, processes and requirements for secure IACS
- OPC UA Part 1 — security model, sessions and audit-trail context
- CISA ICS Recommended Practices — incident response, remote access, defense in depth and recovery planning resources
NIST and CISA are United States government guidance; IEC and ISA/IEC provide international IACS frameworks; OPC Foundation specifies protocol capabilities but not site risk choices. None creates a universal topology, port list, alarm priority, recovery time, security level or acceptance value. Use the current purchased standards and the site's risk assessment, architecture, OEM limits and responsible authorities.
RELATED FIELD RESOURCES