Glossary

Programmable Logic Controller

A PLC is an industrial digital computer used to monitor inputs and control outputs in automation and process control.

Data Integration, Security and Trust IEC 62443 Industrial Cybersecurity for Manufacturing and OT Cybersecurity and Defense Compliance

A programmable logic controller (PLC) is a ruggedized industrial digital computer designed to execute control logic for machines, processes, and production lines. It operates continuously in a cyclic manner, reading input signals, executing a user-defined control program, and updating output signals.

In the context of ISA‑95 and industrial automation, a PLC typically resides at Level 1 (basic control) of the hierarchy. It interfaces directly with field devices such as sensors, switches, and actuators, and exposes process data and status information to higher-level systems like SCADA, DCS, or MES.

Operationally, a PLC:

Receives digital or analog input signals from field devices.
Processes these inputs according to programmed logic (e.g., ladder logic, function block diagrams, structured text).
Generates corresponding digital or analog outputs to control actuators and other equipment.
Communicates with other PLCs and supervisory systems over industrial networks and protocols.

PLCs are configured and maintained using vendor-specific programming and diagnostic tools, and their control programs are typically stored in non-volatile memory for continuous operation.

ISO/IEC 27001 Annex A controls do apply to manufacturing equipment and OT, but they must be interpreted in an OT context. Many controls map to PLCs, CNCs, SCADA, DCS, historians, and networking, but practical implementation depends on vendor capabilities, legacy constraints, validation, and change control. Not all controls are technically or operationally feasible for every asset, so you often document justified exceptions, compensating controls, and long-term remediation plans instead of immediate full alignment.

How do I decide what security level a production zone needs?

Security levels for production zones should be based on structured risk assessment, not generic templates. Start from business and safety impact, map assets and data flows, and then align with a reference model (such as IEC 62443 zones and conduits). In brownfield plants, expect mixed levels and compensating controls, and document rationale, traceability, and change control.

How detailed do threat scenarios need to be for OT systems?

Threat scenarios for OT systems need enough detail to link real-world attack paths to specific assets, controls, and consequences, without pretending you can model every edge case. The right level is concrete attack narratives tied to your architecture, safeguards, and recovery plans, updated through change control and validated in a brownfield environment.

How do vendors demonstrate the security level of their components?

Vendors in industrial and regulated environments typically demonstrate security through a mix of documentation, third‑party assessments, standards alignment, technical test results, and lifecycle processes. None of these guarantee compliance or safety. You still need to verify fit, validate in your own environment, and maintain traceability and change control.

Related Glossary