Content on cybersecurity for industrial systems, OT, SCADA, PLC, DCS, critical infrastructure, manufacturing, energy, water utilities, transport and healthcare. We explain OT risk assessment, IEC 62443, segmentation, secure remote access, monitoring, incident readiness and the difference between IT and OT security priorities.
OT Security in 2026: Risk Assessment for PLC, DCS and SCADA
OT security protects not only systems but also the physical processes they operate. This guide explains PLC, DCS and SCADA roles and shows how to assess risk using IEC 62443 zones and conduits. It covers maintenance access, malware protection, recovery and evidence that safeguards work. It distinguishes NIS2 and Poland’s KSC obligations from DORA’s scope, and the potential of AI and digital twins from promises of automatic protection. An illustrative scenario connects a threat with a requirement and a safe verification method.
Prepared by: CCyber Editorial Team
OT security matters because compromise of an industrial system can affect a physical process: water pumping, production, temperature, pressure or service availability. Protection needs to address devices, software, communication and how they are operated.
A sound risk assessment starts with the process and potential consequences, not a tool purchase. Identify assets and connections, establish security zones, select safeguards and verify them without endangering production. The outcome should be an action plan with owners and evidence of completion.
20 September 2026
This article develops the supplied notes on OT security, risk assessment, evidence and PLC, DCS and SCADA systems. Definitions and requirements were checked against NIST, IEC, cybersecurity authority guidance and legislation. The scenario, acceptance criteria and proposed working method are CCyber recommendations.
Technologies mentioned in the notes, including AI, digital twins and automated simulations, are treated as possible supporting capabilities. We do not assume they are universally deployed or mandatory in every OT environment.
Industrial company boards, plant managers, control engineers, maintenance teams, IT and security teams, and integrators. It also supports infrastructure service operators preparing a risk assessment, modernization project or compliance review.
Connecting plants with analytics services, cloud platforms and remote maintenance creates additional dependencies. This does not automatically make an architecture insecure, but requires decisions about which data and commands can cross between environments. This approach is developed in the international secure OT connectivity principles published in January 2026.
The risk is not merely a forecast. In an announcement dated 30 July 2026, the FBI and EPA described attacks on internet-facing PLCs in the US water and wastewater sector. Configuration changes caused loss of visibility or control functions. This is a documented US example, not a measure of incident frequency in Poland.
Missing risk documentation does not itself cause a breach. However, an inadequate assessment can leave an access path, excessive permissions or recovery gap unidentified. The assessment should therefore lead to technical and operational decisions.
Security concerns protection against compromise and unauthorized activity. Safety concerns protecting people, the environment and equipment from hazardous process consequences. The disciplines need to work together, but are not interchangeable.
The international OT cybersecurity principles put safety first. NIST also emphasizes distinct safety, reliability and performance requirements in its OT Security guide.
Do not adopt a fixed rule that IT cares about confidentiality while OT cares only about availability. A running system reporting incorrect measurements can be dangerous. Engineering information also requires confidentiality.
Our proposed assessment asks: when may operation continue, when is a contingency mode needed and who authorizes a controlled shutdown? Answers must come from people who understand the process and its protections.
A Programmable Logic Controller, or PLC, performs programmed control functions using inputs and defined logic. It can support a machine, part of an installation or a more complex process. It is not limited to basic on/off operations. Functions are described by NIST.
Security question: who can change the program, configuration and controller behaviour, and how would an unauthorized change be detected?
A Distributed Control System, or DCS, distributes control functions across components associated with the process rather than placing all control in one central unit. See the NIST definition.
A DCS can integrate control, visualization and engineering tools. Its name alone does not guarantee redundancy or the absence of single points of failure. Those are properties of the actual implementation.
Security question: could compromise of a shared engineering workstation or management service affect several parts of the process?
Supervisory Control and Data Acquisition, or SCADA, collects and processes information while enabling supervision and higher-level control. It is also used for geographically distributed assets. It need not be one central application and is not limited to business reporting. See the NIST definition.
Security question: does the operator see a trustworthy process state, and can only authorized people issue commands?
A PLC is a control device, while DCS and SCADA describe broader systems. They can work together. Include operator interfaces, or HMIs, engineering workstations, historians and communication equipment in the assessment.
The following method is a CCyber recommendation. It connects the physical process with architecture, risk and safeguard verification.
Start with a service or process, such as water treatment or a selected production line. Identify assessment boundaries, the owner, dependencies and acceptable operating conditions.
Consider consequences for people, the environment, product quality and continuity of supply separately. Do not reduce every consequence to an hourly downtime cost. Record the effects that cannot yet be assessed.
Combine engineering documentation, configurations and operator knowledge with traffic observation. Include service modems, integrator devices, removable media and external service connections.
The guidance on maintaining an accurate OT architecture view recommends multiple information sources. It also warns that active scanning can overwhelm older devices. Select and validate the method before using it.
Output: a verified asset and dependency map with unknown areas identified. An absence of traffic during a short observation should not be the sole reason for removing a connection.
A zone groups assets with common security requirements. A conduit groups communications between zones for which shared security requirements are defined.
IEC 62443-3-2 covers defining the system under consideration, partitioning it into zones and conduits, assessing risk and establishing target security levels, or SL-T. Selecting a target does not demonstrate that it has been achieved.
In our proposed model: separate office systems, maintenance access and control areas according to process requirements. Record the purpose, direction, ownership and permitted communication for each connection. A diagram or VLAN name alone does not demonstrate effective separation.
Consider scenarios such as a compromised supplier account, an unauthorized configuration change, loss of trustworthy measurements and ransomware affecting a workstation needed to operate the process.
For each scenario, identify required access, weaknesses, existing safeguards and consequences. Do not assume that shutting down a plant requires encrypting the PLC itself. A scenario may involve unavailable supervisory systems or business dependencies instead.
Output: a reasoned priority rather than only a scanner score. Mark missing information as uncertainty, not low risk.
Choose actions that address the scenario: access restriction, segmentation, configuration protection, better monitoring or improved recovery. Assign an owner, deadline and verification method.
Where an update requires a maintenance window, include compatibility testing and rollback arrangements. If remediation cannot occur immediately, define interim protection and a reassessment date. “It cannot be patched” should not end the assessment.
Check that the safeguard operates and has not impaired process conditions. The risk owner should understand remaining limitations.
Reassess after significant changes, such as a new IIoT gateway, integrator access, PLC modernization or altered recovery arrangements. Periodic reviews complement these triggers rather than replacing them.
The secure OT connectivity principles recommend brokered access through a controlled gateway rather than direct external access to control assets. They also describe restricting functions and communication between zones.
Proposed evidence: an approved connection register, access-control configuration and an agreed technician-access test. Include denial of out-of-scope access and session termination.
The remote OT access guide in the OT, Industrial and Critical Infrastructure Security category explores these arrangements further.
Do not assume that a standard endpoint agent can be installed on every PLC or real-time system. Selection requires checking support, operational impact and maintenance conditions.
Proposed action: define the approved route for project files and updates, removable-media controls and verification of file origin and integrity.
Proposed evidence: platform compatibility, a test result and documented exceptions. An antivirus invoice does not demonstrate protection across the entire OT environment.
Agree which changes matter: a new connection, supplier access outside a maintenance window, project modification or communication loss. Identify who distinguishes scheduled maintenance from activity requiring a response.
Proposed evidence: a controlled alerting test with confirmation that the right person received it. A new IP address is not automatically an attack, but should be assessed against process and change information.
Recovery planning should cover more than office files. Include the appropriate controller projects, configurations, software versions and required engineering environment.
Proposed evidence: restoration in an agreed environment, with control engineers verifying configuration and required functions. Process restart should follow an approved commissioning or recovery procedure, not merely a “restore completed” message.
Illustrative CCyber scenario, not a real incident. A water treatment facility permits remote maintenance through an engineering workstation. The assessment investigates whether compromise of the maintenance account could allow unauthorized process changes.
Scenario: an unauthorized person uses maintenance access to perform an operation outside the approved task.
Potential consequence: loss of trustworthy control, a need to stop part of the process or a threat to water quality. The assessment must consider actual interlocks, alarms and independent measurements. We do not assume that every compromised account automatically results in contaminated water.
Requirement: access is restricted to agreed activities, changes need appropriate authorization and unwanted operations can be detected and addressed.
Verification: permission testing in a laboratory or another safely agreed scope, combined with an operator decision exercise. Do not deliberately alter the parameters of an operating treatment process.
Evidence: configuration version, test scope, result, action owner and remaining limitations. Testing one route does not constitute an assessment of the entire facility.
AI can support data analysis and anomaly detection, but integration also introduces risk. The joint principles for secure AI integration in OT address testing, oversight and safe failure arrangements.
Our recommendation: before automating connection blocking or device behaviour changes, test the consequences of false alarms and missing data. Response automation should not silently take over process safety decisions.
NIST described research combining a digital process model, machine learning and expert knowledge to detect attacks on a laboratory 3D printer. This demonstrates a research capability, not comprehensive protection for any industrial installation.
Our recommendation: check how accurately the model represents the device, which phenomena it reproduces and its limitations. Do not automatically extrapolate a simulation result to the production process.
Breach and Attack Simulation means simulating selected attacker activities to test protection. This article does not assume that BAS is mandatory for every OT assessment.
Our recommendation: begin in a laboratory with an agreed scope. Production testing requires process-owner authorization, impact assessment, stopping conditions and recovery arrangements. Do not run a standard IT testing profile against controllers without this preparation.
In ISO/IEC 27001:2022 Annex A, malware protection is referenced as A.8.7, while information transfer is A.5.14. Backups fall under A.8.13. Implementation guidance is developed in ISO/IEC 27002:2022, whose structure is visible in the public SIST preview.
A maintenance-file review can support assessment of these controls. It is not a certificate of PLC or plant security. The ISMS scope and Statement of Applicability matter.
IEC 62443-3-2 supports risk assessment during system design, while IEC 62443-3-3 specifies technical system security requirements and capability levels.
When commissioning work, identify the relevant part, system and criteria. A certified component does not automatically establish a secure integration. Zone diagrams should connect with requirements, configurations and verification.
Article 20 of NIS2 addresses management-body approval and oversight of cybersecurity risk-management measures. In Poland, Articles 8c-8d of KSC establish the manager’s accountability and duties. This is not an automatic penalty for every imperfect assessment or incident. The relevant obligation and grounds for liability must be established. See NIS2 and KSC.
Operating a PLC does not itself determine KSC applicability. For entities covered by the relevant transition period, important dates include self-registration by 3 October 2026 and implementation by 3 April 2027. Check organizational status and the official timetable.
DORA concerns the digital resilience of specified financial entities and includes requirements concerning ICT providers. Its scope is explained by ESMA.
It does not automatically apply to a water utility or manufacturing plant simply because their services are economically important. A DORA requirement in an OT engagement needs a specific role, service or obligation behind it, rather than being added to every critical-infrastructure audit.
We recommend linking process → risk scenario → requirement → safeguard → verification result → residual risk decision.
Each item should identify its scope, date, configuration version and owner. Retain failed tests and how findings were addressed. Do not present a new configuration as if it had been operating for months.
Distinguish readiness reviews, technical tests, audits against agreed criteria and certification. The label “OT audit” does not by itself establish what was examined or which conclusions can be drawn.
First: select one important process and bring together control engineering, maintenance, IT, security and the business owner. Agree the boundaries and safe working conditions.
Second: review the connection map, remote maintenance and configuration recovery. Address known serious threats promptly in coordination with operations rather than waiting for all documentation to be completed.
Third: approve priorities and deadlines. Report planned, implemented and verified safeguards separately. Do not measure improvement solely through the number of sensors installed.
Remote maintenance and segmentation are explored in the OT, Industrial and Critical Infrastructure Security category. Exercise planning can also draw on incident response and business continuity resources. These links lead to Polish-language material.
This article focuses on process risk assessment and evidence. Detailed network design and safeguard selection require assessment of the actual installation.
Through its cybersecurity project and implementation services, CCyber supports IT and OT risk assessment, segmentation, access control and audit preparation.
Start with a process whose loss would have the greatest impact on the organization. Prepare the installation description, available diagrams, supplier list and known limitations. The objective is an agreed protection plan and evidence, without testing that endangers people or production. Share technical information only after agreeing a secure channel.
That cannot be determined from internet connectivity alone. Review maintenance access, IT connections, supplier devices and file transfer as well. Claimed isolation must reflect the actual architecture.
No. It can provide some information, but does not independently establish process consequences, human safety implications or recovery arrangements. The scanning method also needs an OT impact assessment.
Do not copy an office-computer configuration onto every controller. Select mechanisms according to the platform and risk. Strong authentication may be enforced through a controlled administrative path, with device protection supported by communication and change restrictions.
Technical capability is not operational authorization. Before such automation, assess the consequences of disconnection, misclassification and missing inputs. The rules must account for safe process behaviour.
The scope should reflect the process and possible consequences. A small device count does not imply that control functions are unimportant. Start with a bounded review without presenting it as an assessment of the entire organization.
OT security in 2026 requires an understanding of the process, architecture and threats. PLC, DCS and SCADA perform different functions and should not receive one uniform set of safeguards without considering their use.
A useful risk assessment ends with a verifiable decision: what is protected, against which scenario, who owns the action and how the outcome will be checked without endangering the process. AI and new tools can support this work, but do not replace it.
Secure Remote Access to OT: Common Mistakes and Good Practices
Secure remote access to OT is not just enabling a VPN, RDP or a supplier tool. In an industrial environment, remote access must be justified, temporary, controlled, monitored and possible to disconnect immediately. The most common mistakes are permanent supplier access, no MFA, shared accounts, direct internet access to HMI, PLC or engineering stations, no segmentation, no logs, no approval procedure and no emergency access cutoff test. Good practice means access through an intermediate zone, jump server, MFA, named accounts, least privilege, operational approval, maintenance window, session recording, full logging and regular access review.
Prepared by: CCyber Editorial Team
Secure remote access to OT should be a controlled exception managed by process, not a permanent backdoor into the plant. The company should know who connects to the OT environment, why, for how long, from which device, through which channel, to which system and who approved the session. The greatest risks appear when suppliers have permanent VPN, RDP is exposed to the internet, accounts are shared, MFA is missing, access leads directly to HMI, PLC or engineering workstation, and nobody monitors sessions. Good practice is a model with no direct internet access to OT, IT and OT segmentation, intermediate zone, jump server, MFA, named accounts, time-bound access, approval by the process owner, logging, session recording and the ability to quickly disconnect remote access without stopping production.
July 2026
Remote access to OT means the ability to connect from outside the local industrial zone to systems that support production, automation, process technology, technical infrastructure or site safety. It may be used by an employee, IT provider, automation integrator, machine vendor, service technician, SOC operator or engineer working from another location.
The problem is that remote access can be both useful and risky. It enables service, diagnostics, supplier support, faster fault removal and work across many locations. But if poorly designed, it becomes the shortest path to systems that can stop production or affect human safety.
In IT, an incident may cause data loss, system downtime, information disclosure or ransomware. In OT, it may also stop a line, damage a machine, change a process parameter, reduce visibility, reduce control, threaten product quality or create safety risk.
This is why OT cannot simply copy office IT rules. Remote access must be designed with automation, maintenance, IT, security, production and technology vendors.
The machine vendor connects to check alarms, parameters, configuration, drive errors, logs or software version.
The integrator connects to SCADA, PLC, HMI or engineering workstation to perform a change, diagnostics or fix.
A plant engineer or central technical team connects from multiple locations to analyze installation status.
Data from historian, MES, BMS or monitoring systems is reviewed remotely by selected people or analytics systems.
The service team needs urgent access at night, over the weekend or during production downtime.
SOC, MDR or OT monitoring provider needs access to logs, sensors, consoles or telemetry data.
The most common issue is access that was once enabled for service and never turned off. The supplier has an account, VPN, LTE router or remote desktop tool, and the plant does not know when or why someone connects.
Directly exposing an OT system to the internet is very high risk. Even if access is password-protected, this setup increases attack surface.
RDP, VNC and remote desktop tools are convenient, but in OT they may provide too much access. If a user gets the engineering workstation desktop, they can do much more than diagnostics.
A password is not enough. In supplier and service environments, passwords may be shared, used by multiple people or stored insecurely. Without MFA, password compromise may mean entry into OT.
An account named “service”, “vendor”, “automation” or “support” is convenient, but destroys accountability. After an incident, the company does not know who made the change.
VPN often grants access to an entire subnet. In OT, this is too broad. A technician servicing one machine should not see the whole production network.
A remote user should not land directly in control systems. An intermediate zone, DMZ or jump server reduces risk and provides a place for logging, control, scanning and policy enforcement.
Many plants have different remote access channels: IT VPN, machine vendor router, 4G modem, service laptop, TeamViewer, AnyDesk, supplier cloud portal and diagnostic tunnel. Without a register, nobody sees the full risk.
If someone makes a change in OT, the company should know who, when, from which address, to which system and what was done. Without logs, there is no accountability.
During an incident, the plant must be able to quickly block remote access. This cannot require hours of searching for an administrator, supplier or router password.
Every remote access channel should have a justification. The question is not “can we connect?”, but “do we really need this access and what business problem does it solve?”.
Access should go through a controlled intermediate zone. A remote user should not connect directly to PLC, HMI or engineering workstation.
Every person should have a named account, MFA and assigned role. Supplier accounts should be separated from plant employee accounts.
Access should be limited to a specific machine, system, application or zone. Not the entire OT network.
Access should be active only during an approved maintenance window. After work ends, it should be disabled.
The company should have logs, alerts and, for high-risk actions, session recording.
The plant should be able to disconnect remote access without chaos, without stopping unnecessary systems and without creating human safety risk.
HMI, PLC, SCADA, engineering workstations and industrial routers should not be directly accessible from the internet. Any such exposure requires urgent analysis and usually removal.
MFA should cover VPN, jump server, access portal, supplier accounts and administrator access. Exceptions should be documented and accepted by the risk owner.
A jump server helps limit access, log sessions, record actions and separate the remote user from direct access to industrial systems.
Segment OT by function, line, process, location or criticality. Supplier access to one machine should not open a path to the entire plant.
Allow only communication needed for the specific work. Block unnecessary RDP, VNC, SSH, SMB, FTP, web management and other services.
Every service session should have a request, owner, purpose, time, scope and completion confirmation. For high-risk actions, require maintenance or production approval.
Not every task can be done at any time. OT changes should be agreed with production and assessed for process safety impact.
Logs should include user, time, source, target, session duration, protocol used and actions performed. Supplier and engineering workstation sessions should be recorded for high-risk access.
At least once a year, check whether the company can quickly disable supplier remote access, VPN or industrial router. The test should not endanger production.
Supplier contracts should describe MFA, named accounts, access scope, logging, incident reporting, subcontractors, remote tool updates and audit rights.
Night, weekend, long, unusual location or unusual target sessions should generate an alert.
A device used to access OT should be managed, updated, protected, malware-free and compliant with company requirements. A supplier’s private laptop should not freely access OT without control.
If the supplier only needs to read alarms or data, do not grant write, program change or parameter modification rights.
At least quarterly, check who has remote access to OT. Remove former employees, former technicians, inactive suppliers and old tunnels.
An automation supplier has permanent VPN access to the plant network. One of its accounts is compromised. The attacker logs in in the evening, scans the OT network, finds an engineering workstation and attempts to download project files. Then errors appear on HMI and unusual connections to several controllers are observed.
The contract describes service, but does not describe MFA, named accounts, logs, session recording, incidents or subcontractors.
The plant cannot check whether the supplier manages accounts, service devices and subcontractors.
The supplier may have an incident, but the customer may not learn about it in time.
After contract termination, the supplier account, router or tunnel still exists.
The supplier allows another company to perform remote service, but the plant does not know who actually has access.
A manufacturing company has 6 production lines. Each line has a different machine vendor. Over the years, vendors enabled their own remote access methods: one has VPN, another an LTE router, another TeamViewer on HMI and another a diagnostic modem. The plant knows that “vendors somehow connect”, but has no complete list.
The audit reveals 11 remote access channels, 4 permanent tunnels, 3 shared accounts, 2 tools without MFA and one router with no known owner. One supplier has access to the entire OT subnet even though it services only one machine.
The company introduces an access register, closes unused tunnels, moves suppliers through a jump server, enables MFA, defines maintenance windows and records high-risk sessions. After 90 days, remote access still works, but it is visible, controlled and can be disconnected. Production keeps supplier support and the board receives a real risk report.
ccyber.io helps industrial companies organize and secure remote access to OT without paralyzing service and maintenance. We combine automation, IT, security, production, supplier and board perspectives.
We can support your organization with:
The best first step is an OT Remote Access Readiness Workshop. In a short workshop, the company can determine who currently has OT access, which channels are most dangerous, what must be disabled immediately and what should be moved to a safer model.
No. VPN may be part of the solution, but VPN alone is not enough. MFA, scope limitation, segmentation, logging, supplier control and access cutoff capability are needed.
Permanent access should be an exception, well justified and controlled. A safer model is time-bound access activated for a maintenance window and approved by the OT owner.
It can be very risky if available directly or without control. Use a jump server, MFA, named accounts, session recording and function restrictions.
It can, but only if it is registered, approved, configured according to security requirements, covered by MFA, logging and cutoff procedure.
At least quarterly and after every change of supplier, production line, system, integrator or incident.
The owner of the OT process or system, usually maintenance, automation or production, in cooperation with IT and security.
For high-risk actions, yes. Recordings support accountability, change analysis, audits and incident investigation.
Start with a register: who has remote access to OT, how they connect, what they can access, whether MFA is enabled, whether the session is logged and who owns the access.
Secure remote access to OT is needed, but it must be controlled. The greatest risk is not remote access itself, but lack of visibility, no MFA, permanent tunnels, shared accounts, direct access to OT systems and no cutoff procedure.
A good architecture is based on segmentation, intermediate zone, jump server, named accounts, MFA, time-bound access, logging, session recording and regular access review.
The best rule is: remote access to OT should be treated like service work inside the plant. It must have purpose, approval, time, scope, supervision, activity record and safe completion.
IEC 62443 in Practice: Zones, Conduits and OT Network Segmentation
IEC 62443 helps organize OT security by dividing the environment into zones and communication conduits. A zone groups assets with similar risk and security requirements, while a conduit describes controlled communication between zones. In practice, this is not only about VLANs and firewalls, but about understanding processes, dependencies, risk, remote access, data flows, accountability and secure IT/OT communication rules.
Prepared by: CCyber Editorial Team
IEC 62443 in practice helps design OT security by dividing a plant, lines, systems and connections into zones and communication conduits. A zone is a group of assets with similar function, risk and security requirements, for example a production line, SCADA system, engineering workstations, process safety network or industrial DMZ. A conduit is a controlled communication path between zones, for example MES to SCADA, historian to DMZ, remote vendor to jump server or SCADA to PLC. OT network segmentation is not only about VLANs. It is a business and technical process: asset inventory, communication mapping, risk analysis, boundary definition, traffic limitation, monitoring, change management and testing.
July 2026
IEC 62443 is a series of standards for cybersecurity of industrial automation and control systems. In practice, it is used to organize security of OT, ICS, SCADA, PLC, DCS, HMI, MES, engineering workstations, historians, industrial networks and supplier remote access.
IEC 62443 is especially useful because it does not treat OT like a normal office network. It considers:
For this article, the key practical concepts are: zones, conduits, security levels, risk and segmentation.
A zone is a group of assets with similar function, risk and security requirements. A zone may be a physical part of the plant, a logical network area, a system group or a process function.
Examples of zones:
The key rule: zones are not defined only by IP addressing. A zone should follow risk, process function, criticality, ownership, trust level and incident impact.
A conduit is a controlled communication path between zones. It describes which systems can communicate, using which protocol, in which direction, for what purpose, through which control point and under which conditions.
Examples of conduits:
A conduit should have an owner and rules. Without that, the company does not know whether a given traffic flow is needed, safe and aligned with the process.
Answers the question: which assets have similar security requirements and should be treated together?
Answers the question: which communication between zones is needed and how do we control it?
Answers the question: how do we technically and organizationally separate zones and enforce communication rules?
Example: the SCADA network is a zone, SCADA to historian is a conduit, and segmentation is the firewall, allowlist, monitoring and rule that the historian cannot initiate traffic to PLCs.
In OT, one uncontrolled access path can have greater consequences than in classic IT. An attacker may start from a normal office computer, move through an administrator account, reach an engineering workstation and then affect control, quality, availability or process safety.
Segmentation helps limit:
Segmentation does not guarantee complete security, but it strongly reduces the impact of errors, incidents or compromise of one account.
A VLAN can be part of segmentation, but a VLAN alone is not enough. If there is no traffic control, monitoring, rules, owners and change process between VLANs, segmentation is only a logical network split, not a real security control.
In practice, OT segmentation means combining architecture, traffic rules, access control, monitoring, procedures and accountability.
You cannot design zones without knowing which assets exist. Inventory should include not only servers and computers, but also controllers, network devices, visualization systems, engineering workstations and remote access.
List:
Evidence to prepare: OT asset register with owner, location, function and criticality.
Segmentation cannot be designed only from the network perspective. You must know what happens in the physical process if communication is blocked, delayed or manipulated.
Ask:
Evidence to prepare: map of processes, lines and operational dependencies.
The most important segmentation document is the communication map. It shows who talks to whom, using which protocol, in which direction and for what purpose.
For every flow, record:
Evidence to prepare: IT/OT communication flow matrix.
Group assets by function, risk and security requirements. Do not mix systems with completely different criticality in one zone only because they are in the same cabinet or subnet.
Evidence to prepare: zone list with justification and owners.
After defining zones, specify which communication between them is allowed. The default rule should be: block everything that is not required and documented.
For each conduit, define:
Evidence to prepare: conduit matrix between zones.
Zones should have security requirements based on risk. Not every zone needs the same level of protection. A process safety zone, engineering workstations and critical production controllers will usually need stronger controls than a reporting zone.
Requirements may include:
Evidence to prepare: security requirements card for every zone.
Only now is it time for technology. First process, assets, zones and conduits. Then firewalls, VLANs, routing, jump servers and monitoring.
Technical controls may include:
Evidence to prepare: OT segmentation architecture design.
In OT, a wrong firewall rule may stop a line or break communication with a critical system. Testing is mandatory.
The test should verify:
Evidence to prepare: segmentation test report and exception list.
OT segmentation becomes outdated quickly if every outage, project or new line adds exceptions without control. Every conduit change should follow a process.
The process should include:
Evidence to prepare: change management procedure for OT zones and conduits.
Segmentation is not a one-time project. Traffic must be monitored, rules reviewed, exceptions removed, maps updated and real traffic compared with documentation.
Minimum maintenance:
Evidence to prepare: recurring OT segmentation maintenance report.
Includes email, office computers, user systems, internet, corporate applications and typical IT services. It should not have direct access to control systems.
A buffer between IT and OT. It can host data exchange systems, transfer servers, historian proxy, patch repository, jump server, monitoring and controlled integration points.
May include MES, production planning, reporting, quality systems and production integrations. This is often a boundary area between IT and OT.
Includes SCADA, HMI, OT application servers, internal historian and process supervision systems.
Includes PLCs, RTUs, controllers, industrial communication devices and systems directly involved in control.
Includes process safety systems, machine safety, SIS, ESD or other systems whose compromise may affect people, environment or installation. This zone requires especially careful separation.
Includes controlled supplier access through MFA, VPN, jump server, session recording, time-bound approval and logging.
Includes engineering workstations, PLC programming tools, SCADA configurations, project backups and maintenance environments. This is one of the riskiest zones because it enables changes in control systems.
Purpose: production plan, orders, materials, statuses.
Risk: ransomware or IT error may affect production planning.
Control: industrial DMZ, restricted protocols, data validation, no direct ERP connection to PLCs.
Purpose: orders, production parameters, process status.
Risk: incorrect data may affect process or quality.
Control: flow allowlist, validation, logs, direction limitation.
Purpose: supervision, commands, status reading.
Risk: unauthorized commands or operating mode changes.
Control: zone separation, industrial protocol monitoring, limiting communication sources.
Purpose: transferring production data to reporting.
Risk: uncontrolled traffic from IT to OT.
Control: preferred direction from OT to DMZ, no initiation from IT to control systems, monitoring.
Purpose: service, diagnostics, supplier support.
Risk: external access to OT environment.
Control: MFA, time-bound approval, jump server, session recording, no standing access.
Purpose: programming, diagnostics, configuration changes.
Risk: program change, incorrect configuration, malware on workstation.
Control: dedicated workstation, change control, project backup, logging, access only for authorized people.
Traffic between zones should be blocked unless it is explicitly allowed and justified.
Allow only the necessary source, destination, protocol, port and direction.
Every conduit should have a business or technical owner.
Remote access, updates, backup and engineering work should not mix with control traffic.
If data must pass between IT and OT, use DMZ, broker, intermediate server or another controlled mechanism.
Zone boundaries are natural monitoring points. Unusual traffic between zones should be visible.
A rule change can stop a process. In OT, testing and maintenance windows are more important than fast emergency changes.
Addressing and VLANs matter, but they do not replace process, risk, zone and conduit analysis.
Many plants have one large OT network where SCADA, HMI, PLCs, engineering workstations and suppliers see too much. This increases incident impact.
Direct connections from ERP, office laptops or reporting systems to OT create an easy attack path.
A DMZ is often the best place for controlled data exchange between IT and OT. Without it, integrations become random and hard to control.
A supplier should have access only when needed, through a controlled path and with logging.
If the company does not know which traffic is required, it cannot safely close unnecessary connections.
In OT, a rule change may have production impact. Every change must be tested and documented.
If nobody owns a zone, nobody makes decisions about risk, changes and exceptions.
Segmentation blocks some traffic, but monitoring shows whether someone is trying to cross zone boundaries and whether rules work.
OT networks change with every project, modernization and service action. Documentation must live with the change process.
A manufacturing plant has one large OT network. SCADA, HMI, engineering workstations, historians, several production lines and supplier remote access operate in the same address space. IT connects to MES and reporting. Documentation is outdated and some system traffic has no owner.
During the first review, the company discovers that a supplier can connect to more than one line, an engineering workstation has access to many PLCs, the historian communicates directly with the office network and the reporting system queries OT sources without a DMZ.
The company does not start by replacing the whole network. First, it creates a map of assets, flows, zones and conduits. It separates the SCADA zone, engineering workstation zone, production line zones, industrial DMZ and supplier access zone. Then it defines conduits, limits traffic, introduces a jump server for suppliers, removes unused connections and logs boundary traffic.
After 90 days, the plant still has a lot of work, but the biggest risks are visible. Instead of one flat network, it has the beginning of a zones and conduits architecture, documentation, owners and a further segmentation plan.
ccyber.io helps industrial companies translate IEC 62443 into a practical zones, conduits and OT segmentation project. We do not start from buying a firewall. We start from processes, assets, flows, risk and production dependencies.
We can support your organization with:
The best first step is an IEC 62443 Zones and Conduits Workshop. In a short workshop, the company can determine which zones exist today, which conduits are critical, where the biggest risks are, which connections should be restricted and how to prepare a realistic segmentation roadmap without stopping production.
A zone is a group of OT or IT/OT assets with similar function, risk and security requirements. It may include a line, SCADA system, engineering workstations, DMZ or process safety systems.
A conduit is controlled communication between zones. It defines who can communicate with whom, using which protocol, in which direction, for what purpose and under which conditions.
No. A VLAN can be part of segmentation, but traffic rules, firewalls, owners, monitoring, documentation, testing and change process are also needed.
Start with OT asset inventory, process map, communication flows, supplier remote access and IT/OT connections.
Not always in the same form, but in many plants it is a very good way to control data exchange between IT and OT without direct access to control systems.
Ideally the process or system owner, such as production, maintenance, OT, quality or IT. Security supports, but the owner must understand process impact.
At least annually and after every major change, modernization, new line, new supplier, incident or architecture change.
Not every project needs to end with certification. Many companies start with practical gap analysis, zones, conduits, risk management and roadmap, then decide whether formal assessment or certification is needed.
IEC 62443 helps organize OT security through a risk-based approach, zones and communication conduits. A zone answers which assets have similar security requirements. A conduit answers which communication between zones is needed and how it should be controlled.
In practice, OT segmentation is not only a network project. It is a joint project for production, OT, IT, security, maintenance, quality and suppliers. It must consider the physical process, availability, human safety, remote access, legacy systems, backup, monitoring and change management.
The best first step is not buying another firewall, but creating a map: assets, zones, conduits, flows, owners, risks and quick actions that reduce the biggest risk. Only then does technology support a real OT security architecture.
Ransomware in Manufacturing: How to Prepare a Plant for Downtime?
Ransomware in manufacturing is not only a problem of encrypted computers. For a plant, it means the risk of halted production lines, loss of access to MES, ERP, recipes, documentation, HMI panels, engineering workstations, quality systems, warehouse and suppliers. Plant readiness starts with defining minimum production capability, IT/OT dependencies, emergency procedures, backups, manual workarounds, communications and exercises.
Prepared by: CCyber Editorial Team
A manufacturing plant should prepare for ransomware as a real operational downtime scenario, not only as an IT issue. The key is to determine what minimum production can safely operate without some IT and OT systems, which lines are critical, which systems are required for safe startup, shutdown, quality, logistics and shipping, and who makes crisis decisions. Backup alone is not enough. The plant needs recovery tests, manual workarounds, emergency contact lists, safe IT/OT isolation, communication plan, tabletop exercises and a clear decision process for when production can safely return.
July 2026
Ransomware in a manufacturing plant is an attack that may block access to systems, encrypt data, steal information, stop production planning, prevent machine support, disrupt quality, warehouse, logistics or customer and supplier communication.
In a typical office, ransomware often means no access to computers, email and files. In manufacturing, it means more: possible line downtime, delivery delay, inability to release product, no access to recipes, missing quality documentation, no warehouse visibility or need for safe process shutdown.
Ransomware in manufacturing is simultaneously a problem of:
In IT, the main priorities are often confidentiality, integrity and availability. In OT and manufacturing, there is also safety of people, machines, processes, quality and physical continuity.
That is why a manufacturing ransomware plan must be prepared jointly by IT, OT, production, maintenance, quality, safety, logistics, legal, communications and the board.
Ransomware does not need to encrypt PLCs to stop a plant. Sometimes it is enough to encrypt the planning system, domain, engineering workstation, license server or quality documentation.
Evidence to prepare: map of systems and data required for minimum production recovery.
In a manufacturing plant, the objective is not always immediate return to full production. Often the first realistic target is minimum safe production capability: the smallest operating scope that allows production or maintenance of the most important processes without unacceptable risk.
Minimum production capability should answer:
Without this, the company may restore servers but still not be ready for production because planning, quality, recipes, trusted engineering workstations or OT safety confirmation are missing.
First, understand what production depends on. A server list is not enough. A dependency map between processes, systems, data, networks, suppliers and people is required.
The map should show:
Evidence to prepare: IT/OT dependency map for production and minimum operating capability.
During a crisis, not everything can be restored at once. The plant must know which systems return first and why.
Evidence to prepare: recovery priority list approved by production, OT, IT, quality and the board.
Not every downtime starts with a full stop. Sometimes only part of the systems should be stopped, and sometimes IT must be disconnected from OT. The plant must make these decisions before the incident.
The plan should define:
Evidence to prepare: safe production shutdown procedure for cyber incident scenarios.
Some processes can operate manually for a short time, others cannot. The worst time to determine this is the day of the incident.
Check:
Evidence to prepare: emergency work procedures for production, quality, warehouse and shipping.
Manufacturing backup must include more than office files. Configuration, programs, projects, workstation images and technical documentation must be backed up.
OT backup should be separated, tested and available even when domain, email or the main IT network is unavailable.
Evidence to prepare: OT backup register and recovery test report for a selected workstation or project.
The key question is not “do we have backup?”. The key question is “can we safely return to production from backup?”.
The test should verify:
Evidence to prepare: recovery test report with time, issues and remediation actions.
After ransomware, backups and workstations must not be connected to an environment that may still be infected. The plant should have a clean recovery network plan.
A clean environment should include:
Evidence to prepare: clean room recovery procedure for IT/OT.
In many ransomware incidents, the attack starts in IT and the risk is spread to OT. The plant must know when and how to disconnect environments.
The isolation plan should define:
Evidence to prepare: IT/OT isolation procedure and connection diagram between zones.
In manufacturing, the company often cannot restore everything alone. An integrator, machine vendor, SCADA vendor, DCS vendor, external automation engineer or license provider may be required.
For each supplier, check:
Evidence to prepare: OT supplier list, emergency contacts and service dependencies.
Production downtime after ransomware requires communication to employees, customers, suppliers, board, insurer, regulator and sometimes media.
Prepare message templates for:
The key: communication must be aligned with facts. Do not promise a production restart date unless you have technical, quality and operational confirmation.
Evidence to prepare: crisis communication plan for production downtime.
The plant should have a scenario not only for several hours, but also for several days of limited operation. Ransomware downtime may last longer if the domain, workstations, backups, OT and quality need to be rebuilt and validated.
Evidence to prepare: 7-day downtime scenario and minimum production capability plan.
Goal: check whether the company can quickly block the account, revoke sessions, stop spread and assess OT impact.
Goal: check whether production can run manually and how to record production, quality and materials.
Goal: check which connections must be cut, who makes the decision and how production operates after disconnection.
Goal: check whether the company has the image, licenses, projects, passwords, documentation and specialists.
Goal: check who approves safety, quality, parameters, data and restart decision.
Goal: check how the company communicates delays, supply risk, production status and recovery plan.
Evidence to prepare: tabletop and technical recovery exercise report.
Ransomware in manufacturing affects the whole plant. IT may lead system recovery, but production, OT, quality and the board must make operational decisions.
The company backs up files and ERP, but has no current PLC programs, SCADA projects, engineering workstation images, licenses or recipes.
Having a project copy does not mean it can be restored. Real recovery of selected workstations and configurations must be tested.
If MES, WMS or ERP does not work, operators and shift managers must know whether production can continue and how it should be documented.
Remote service access without MFA, logs, owner and end date may be an entry path or a risk during the incident.
In a crisis, nobody wants to decide to disconnect systems because they do not know the impact. Decisions must be practiced earlier.
Restoring copies into an environment where the attacker still has access may recreate the problem or cause re-encryption.
Production may technically restart, but product cannot be shipped if quality data, batch traceability, validation or documentation is missing.
Premature customer statements can cause harm. Communicate confirmed facts, impact scope and next steps.
If the company does not update plans, backups, segmentation, procedures and training after an incident, recurrence risk remains high.
A manufacturing plant uses ERP, MES, quality system, WMS, SCADA and several engineering workstations. Ransomware starts with IT account takeover and encrypts part of the office servers and planning system. Physical lines still run, but shift managers do not have access to the current plan, warehouse cannot see material status and quality cannot release batches.
The company initially assumes that restoring ERP is enough. After several hours, it turns out the problem is broader: MES depends on the domain, engineering workstations have old accounts, recipe documentation backup is outdated, and the SCADA supplier has remote access nobody can quickly disconnect.
After the incident, the plant prepares a minimum production capability plan. It defines critical lines, which documents must be available offline, how quality works manually, how to operate without MES for 48 hours, which OT backups are required and who decides on IT/OT isolation.
After 90 days, the company has an IT/OT dependency map, PLC and SCADA project backups, an engineering workstation recovery test, manual work procedures and a tabletop exercise. The plant is not immune to every attack, but has a much better chance to avoid chaos and return safely.
ccyber.io helps manufacturing plants prepare for ransomware and downtime in IT/OT environments. We combine cybersecurity, OT, business continuity, production, quality, supplier and board perspectives.
We can support your organization with:
The best first step is an OT Ransomware Readiness Workshop. In a short workshop, the plant can define which lines are critical, which systems they depend on, which backups are needed, what minimum production capability looks like and which decisions must be practiced before an incident.
Yes. It is enough to stop ERP, MES, WMS, documentation, quality, engineering workstations, domain accounts or supplier communication. Production depends on many IT and OT systems.
No. The company also needs copies of PLC, HMI, SCADA and DCS configurations, recipes, engineering workstation images, licenses, technical documentation and emergency procedures.
It is the smallest safe and operationally meaningful plant operating scope after an incident. It does not mean full production, but controlled return of the most important lines or processes.
The decision should be joint: production, OT, IT, quality, safety and the board. It should not be only a technical “the server works, so we restart”.
Sometimes yes, but only if manual procedures, quality control, production recording, access to the plan and a clear decision on acceptable duration exist.
It depends on the situation, but the plant should have a prepared and exercised IT/OT isolation procedure. During crisis, the impact of the decision must be known.
At least annually for key systems and after major changes. For the most critical lines, selected elements should be tested more often.
Start with an IT/OT dependency map, critical line list, OT backup review, supplier remote access, isolation procedure and a ransomware tabletop exercise.
Ransomware in manufacturing is an operational problem, not only an IT problem. It can stop lines, quality, warehouse, shipping, planning, documentation and customer communication. That is why a plant must prepare for downtime as a real crisis event.
The most important elements are IT/OT dependency map, minimum production capability, recovery priorities, OT backups, recovery tests, manual procedures, IT/OT isolation, supplier remote access, crisis communication and exercises.
The best rule is: do not ask only whether you can recover data. Ask whether the plant can safely, quality-wise and operationally return to production even when some systems are unavailable for several days.
IEC 62443 vs ISO/IEC 27001: Which One Should Industrial Companies Choose?
Industrial companies usually should not choose between IEC 62443 and ISO/IEC 27001. ISO/IEC 27001 builds an information security management system for the whole organization, while IEC 62443 helps secure OT, SCADA, PLC, DCS, zones, conduits, integrators and automation suppliers. The best approach is ISO/IEC 27001 for governance and IEC 62443 for the industrial environment.
Prepared by: CCyber Editorial Team
In industrial companies, the best answer is usually: use both standards, but for different purposes. Choose ISO/IEC 27001 as the information security management system for the whole organization: policies, risks, roles, audits, board oversight, suppliers and continual improvement. Choose IEC 62443 as the specialist standard for OT: zones, conduits, security levels, requirements for control systems, components, integrators and automation suppliers. ISO/IEC 27001 helps manage security. IEC 62443 helps secure the industrial environment.
July 2026
ISO/IEC 27001 is an international standard defining requirements for an information security management system, or ISMS. It helps an organization establish, implement, maintain and improve information security using a risk-based approach.
ISO/IEC 27001 covers, among other areas:
The greatest value of ISO/IEC 27001 is organizing security management across the organization. The standard helps answer: does the company have a repeatable system for managing information risk?
IEC 62443 is a family of cybersecurity standards for industrial automation and control systems, often referred to as IACS. It applies to OT environments where digital systems affect physical processes.
IEC 62443 is especially important for:
IEC 62443 helps answer: how do we secure control systems, automation and OT in a way that matches industrial risk?
ISO/IEC 27001 is recognized in B2B sales, tenders, customer audits and partner discussions. When customers ask for an information security certificate, they usually mean ISO/IEC 27001.
It is a strong choice when the company:
ISO/IEC 27001 is very useful for organizing information security management: roles, policies, risk assessments, documentation, corrective actions and management reviews.
In industry, ISO/IEC 27001 can help with:
ISO/IEC 27001 can be a good backbone for risk management and evidence. It helps create a risk register, risk treatment plan, policies, procedures and evidence needed in audits and regulatory requirements.
Important note: ISO/IEC 27001 helps, but does not automatically replace detailed NIS2, KSC or OT requirement analysis.
If the company has PLC, SCADA, DCS, HMI, engineering workstations, supplier remote access, industrial networks or production lines, IEC 62443 is the more natural technical and operational standard.
It is a strong choice when the company wants to secure:
IEC 62443 helps divide the OT environment into zones and conduits. This is very practical in OT because not every system should communicate with every other system.
Example:
This approach helps determine where industrial firewalls, jump servers, monitoring, protocol restrictions, MFA and access control are needed.
IEC 62443 distinguishes roles in the industrial ecosystem: asset owners, integrators, service providers and component manufacturers. This matters because OT security depends on many parties.
The standard helps define requirements for:
The best approach is not “IEC 62443 or ISO/IEC 27001”. The best approach is:
In practice:
Use ISO/IEC 27001 here.
Use IEC 62443 here.
Combine ISO/IEC 27001, IEC 62443, business continuity and operational practice here.
ISO/IEC 27001 covers the information security management system within a defined organizational scope. It can cover OT, but only if the company deliberately includes OT in the scope, risks and controls.
IEC 62443 is designed from the start for industrial environments, automation and control systems.
ISO/IEC 27001 uses management language: context, risk, policies, objectives, audit, management review and improvement.
IEC 62443 uses OT language: IACS, zones, conduits, security levels, control systems, components, integrators and industrial lifecycle.
ISO/IEC 27001 is widely used as a certifiable management system for organizations. The certificate can be important for customers, tenders and partners.
IEC 62443 can be used to assess systems, components, development processes and suppliers, but it is not the same type of organization-wide certificate as ISO/IEC 27001. In practice, it must be clear what is being assessed: a plant, system, component, integrator process or manufacturer process.
ISO/IEC 27001 requires an information security risk management process.
IEC 62443 guides risk assessment in the context of industrial systems, zones, conduits and target security levels.
ISO/IEC 27001 often works with confidentiality, integrity and availability.
In OT, priorities are often different: safety, process availability, control integrity, product quality, environmental protection and then data confidentiality.
Best choice: start with a short IT-OT risk assessment, then build ISO/IEC 27001 basics and IEC 62443 basics in parallel.
First actions:
Best choice: extend the existing ISMS with OT risks and use IEC 62443 for detailed industrial requirements.
Check:
Best choice: IEC 62443 as the technical priority for OT, ISO/IEC 27001 as governance and risk management.
Priorities:
Best choice: IEC 62443 for service and integration requirements, ISO/IEC 27001 for information security management in the company.
Priorities:
Best choice: IEC 62443-4-1 and IEC 62443-4-2 for product security and development process, ISO/IEC 27001 for organizational ISMS.
Priorities:
First determine whether OT is formally included in the information security management system. Many companies have ISO/IEC 27001 only for IT, office, data center or digital services, not for the plant and production control.
Evidence to prepare: ISMS scope and decision on which OT processes are included in the management system.
The OT risk assessment should include the physical process, safety, availability, product quality, environment, remote access, suppliers and IT-OT connections.
Evidence to prepare: OT risk register and production impact scenario map.
Use IEC 62443 to divide the OT environment into zones and conduits. This is a practical foundation for segmentation, traffic control and security requirements.
Evidence to prepare: zones and conduits model.
Do not create two separate documentation systems. Map IEC 62443 requirements to the risk register, risk treatment plan, policies, procedures and ISMS evidence.
Evidence to prepare: ISO/IEC 27001 and IEC 62443 matrix.
Do not try to implement everything at once. Start with actions that reduce the risk of production stoppage or incident movement from IT to OT the fastest.
Evidence to prepare: OT security roadmap linked to the ISMS.
ISO/IEC 27001 can include OT, but only when OT is actually in scope, in the risk register, in audits and in the risk treatment plan. The certificate alone does not guarantee SCADA segmentation or secure supplier remote access.
IEC 62443 can provide strong OT requirements, but without owners, budget, board decisions, risk register and recurring oversight, actions will remain isolated.
Separate ISO documentation and separate IEC documentation create chaos. Requirement mapping, one risk register and one roadmap are better.
OT has production constraints, safety, availability, legacy systems and physical impact risk. Standard IT methods such as aggressive scanning or fast patching must not be applied without agreement with production.
Integrators, maintenance teams, automation suppliers and device manufacturers strongly affect OT security. IEC 62443 helps assign requirements and responsibilities.
Without production, maintenance and automation teams, the risk assessment will be incomplete. IT and security do not always know which systems can really stop the process.
In OT, not everything can be fixed immediately. Some changes require a maintenance window, modernization or supplier approval. Residual risk must be consciously accepted by the right people.
A manufacturing company has an ISO/IEC 27001 certificate for headquarters, IT and office systems. The board assumes security is organized. During a customer audit, however, the customer asks about OT: IT-OT segmentation, supplier remote access, PLC program backups, zones, industrial traffic monitoring and OT incident response procedure.
It turns out that ISO/IEC 27001 certification does not cover production lines in detail. The risk register includes general cyber risk, but not scenarios such as production downtime, engineering workstation compromise, HMI loss or PLC program change.
The company does not abandon ISO/IEC 27001. It extends the approach. The ISMS is updated with OT risks, and IEC 62443 is used to create zones, review remote access, design segmentation and define integrator requirements. A shared IT-OT risk register, roadmap and board report are created.
After 90 days, the company has better control over production risk. ISO/IEC 27001 provides governance, while IEC 62443 provides OT language and requirements. The customer receives more credible answers, and the plant has a concrete security improvement plan.
ccyber.io helps industrial companies combine ISO/IEC 27001 and IEC 62443 into one practical cybersecurity programme. The goal is not to choose a standard for the standard’s sake. The goal is to reduce production downtime risk, improve governance, prepare customer evidence and build real OT resilience.
We can support your organization with:
The best first step is a short IEC 62443 vs ISO/IEC 27001 workshop for industry. It helps determine whether the company first needs an ISMS, OT risk assessment, zone model, certification readiness or a quick plan to secure the most critical IT-OT connections.
No. They serve different purposes. ISO/IEC 27001 is for information security management systems, while IEC 62443 is for industrial automation and control systems security.
Not always. A certificate helps demonstrate a management system, but does not automatically prove that OT has proper segmentation, secure remote access, zones or control system recovery procedures.
IEC 62443 is the better choice when the project concerns PLC, SCADA, DCS, HMI, integrators, remote access, OT segmentation, zones, conduits or requirements for control systems.
ISO/IEC 27001 is the better choice when the company needs a certifiable information security management system, policies, risk register, audits, management reviews and evidence for customers.
In many cases, yes. ISO/IEC 27001 can manage security at organizational level, while IEC 62443 can define requirements for OT and industrial systems.
Yes, especially if the company wants to secure OT quickly. However, without governance, owners, budget and reporting, actions may be hard to sustain. This is why connection with an ISMS is practical.
Yes. OT must be deliberately included in scope, risk register, audits, risk treatment plans, supplier management, incidents and business continuity.
Start with a short assessment: does the company have an ISMS, is OT in scope, which production processes are critical, what IT-OT connections exist and which risks may stop production.
In industry, the question “IEC 62443 or ISO/IEC 27001?” is often the wrong question. A better question is: which standard solves which problem?
Choose ISO/IEC 27001 for systematic information security management, risk, audits, documentation, accountability and customer evidence. Choose IEC 62443 for securing OT, control systems, segmentation, zones, conduits, integrators and automation suppliers.
The best model for an industrial company is combining both approaches. ISO/IEC 27001 provides governance, while IEC 62443 provides detailed industrial language and requirements. This means the company does not only have a certificate or documents, but materially reduces the risk of production downtime, OT incident and loss of customer trust.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.