Cyber-Physical, Mobile, IoT and Operational Technology Security

Introduction and Context

Information security increasingly concerns systems that do more than store, process, or communicate information. Cyber-physical systems (CPS), mobile devices, Internet of Things (IoT) platforms, and operational technology (OT) interact with the physical world. They open valves, regulate motors, deliver electricity, monitor patients, control vehicles, and manage industrial production. Consequently, a cyber incident can produce not only data loss and service disruption but also equipment damage, environmental harm, injury, or loss of life.

Traditional enterprise security often prioritizes confidentiality, followed by integrity and availability. In OT and safety-sensitive CPS, the priority may be different. Availability, deterministic performance, process integrity, and human safety can be more important than secrecy. A security control that is appropriate for an office computer—such as immediately installing an update or disconnecting a host—may be unsafe in a chemical plant or hospital if it interrupts a critical process.

This chapter examines the distinctive security requirements of mobile systems, IoT ecosystems, industrial control systems (ICS), critical infrastructure, and safety-sensitive CPS. It also develops a risk-based approach that combines technical safeguards, operational discipline, governance, and resilience.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish IT, OT, IoT, mobile, CPS, and ICS environments.

2. Explain why conventional enterprise security assumptions do not always apply to physical processes.

3. Analyze threats across devices, networks, applications, people, and supply chains.

4. Apply architectures such as defense in depth, zones and conduits, zero trust, and the Purdue model.

5. Select safeguards appropriate to availability, safety, latency, resource, and lifecycle constraints.

6. Evaluate a cyber-physical incident and recommend technically and managerially sound responses.

1. The Security Landscape of Connected Physical Systems

1.1 Important distinctions

Information technology (IT) primarily supports information processing, business applications, communication, and office productivity. Operational technology (OT) monitors or controls physical processes. OT includes programmable logic controllers (PLCs), distributed control systems (DCSs), supervisory control and data acquisition (SCADA) systems, remote terminal units (RTUs), safety instrumented systems, industrial networks, and building-management systems.

IoT is a broad term for connected sensors, actuators, appliances, vehicles, medical devices, and other embedded systems. IoT environments commonly combine constrained devices, wireless communication, cloud services, mobile applications, analytics, and device-management platforms.

A cyber-physical system integrates computation, communication, sensing, and actuation with physical processes. CPS is a conceptual category; an autonomous vehicle, smart grid, robotic production cell, and connected infusion pump may all be CPS.

Mobile security concerns smartphones, tablets, wearables, mobile applications, mobile operating systems, wireless interfaces, mobile identity, and enterprise mobility management. Mobile devices are significant because they are portable, sensor-rich, frequently connected, and often used to administer other systems.

The categories overlap. A technician may use a mobile device to access a cloud IoT platform that supervises an OT installation. Security analysis must therefore follow data flows and control paths rather than organizational labels.

1.2 Why cyber-physical security is distinctive

Several properties make these environments different from conventional IT:

• Physical consequences: Manipulating a temperature set point may cause overheating, not merely incorrect data.
• Timing constraints: A delayed control message can be as harmful as a false message.
• Long lifecycles: Industrial equipment may remain in operation for decades, while vendor support and cryptographic capabilities change.
• Limited maintenance windows: Production may operate continuously, making patching difficult.
• Legacy protocols: Many protocols were designed for reliability and interoperability rather than authentication or confidentiality.
• Resource constraints: Small sensors may lack memory, processing capacity, secure storage, or a conventional operating system.
• Safety dependencies: Security actions can affect safety systems, emergency shutdowns, and human operators.
• Heterogeneous ownership: Devices may be managed by manufacturers, contractors, facilities teams, cloud providers, and operators.
• High availability requirements: An outage can affect public health, energy, transport, water, or manufacturing supply chains.

A useful security objective is therefore not merely “keep attackers out.” It is to maintain trustworthy and safe operation under normal conditions, faults, human error, and deliberate attack.

2. A Risk Model for Physical and Connected Environments

Risk assessment should connect cyber events to operational consequences. A practical chain is:

Threat source → vulnerability or exposure → cyber event → process effect → safety, operational, financial, or societal consequence.

For example, a stolen engineering credential may permit unauthorized PLC programming; altered logic may disable a protective interlock; an overheated machine may cause production loss or injury.

A qualitative risk statement can be represented as:

Risk priority = likelihood × consequence

This is a prioritization model, not a physical law. Likelihood and consequence should be defined using an organizational scale, such as 1–5, and the result should not be interpreted as a precise probability. In CPS, consequence analysis should include safety, environmental, regulatory, mission, equipment, and recovery effects. A low-frequency event with catastrophic consequences may deserve priority over a frequent but minor event.

2.1 Asset and process modeling

Traditional asset inventories are insufficient if they list only IP addresses. A CPS inventory should include:

• physical process and safety function;
• sensors, actuators, controllers, HMIs, servers, and network components;
• firmware, software versions, configurations, and cryptographic keys;
• communication paths and trust relationships;
• vendor, owner, maintainer, and support status;
• dependencies on electricity, communications, cloud services, GPS, and time sources;
• safe state and recovery requirements.

Threat modeling should examine both misuse and failure. Methods such as STRIDE can help identify software threats, while attack trees, cyber-informed hazard analysis, bow-tie analysis, failure mode and effects analysis, and MITRE ATT&CK for ICS can connect attack techniques to process outcomes. No single framework replaces engineering judgment.

2.2 The CIA triad and its extension

Confidentiality remains relevant, particularly for personal, commercial, and operationally sensitive information. Integrity is often paramount because false sensor readings, unauthorized logic, or altered configuration can create unsafe states. Availability includes not only uptime but also timely and deterministic service.

Additional properties are essential:

• Authenticity: commands, identities, devices, and data sources are genuine.
• Accountability: actions can be attributed to users, systems, or processes.
• Resilience: the system can withstand, adapt to, and recover from disruption.
• Safety: security controls do not introduce unacceptable hazards.
• Determinism: time-critical behavior remains within required bounds.
• Recoverability: known-good configurations and operating procedures permit restoration.

3. Architecture and Defense in Depth

3.1 Purdue-style segmentation

The Purdue Enterprise Reference Architecture is commonly used as a conceptual model for industrial environments. At lower levels are physical processes and field devices; above them are controllers, supervisory systems, site operations, and enterprise systems. A demilitarized zone (DMZ) is typically placed between industrial and enterprise networks.

The model is useful for reasoning about trust boundaries, but it is not a universal blueprint. Modern architectures include wireless devices, edge computing, remote operations, cloud analytics, and distributed energy resources that do not fit neatly into fixed levels. Architecture must therefore be based on actual communication and control dependencies.

3.2 Zones and conduits

IEC 62443 uses the concepts of zones and conduits. A zone groups assets with common security requirements. A conduit controls communication between zones. For example, a safety-system zone, control zone, historian zone, and enterprise zone may have different requirements. A conduit can enforce firewall rules, protocol restrictions, authentication, monitoring, and unidirectional communication where appropriate.

Segmentation is effective only when it is maintained. A firewall rule allowing unrestricted traffic, a shared vendor account, or an unmanaged modem can defeat a formally correct architecture.

3.3 Zero trust in OT

Zero trust means that access is not trusted solely because a user or device is inside a network. Requests should be authenticated, authorized according to context, limited in scope, and monitored. In OT, zero trust must be adapted to process constraints. Continuous authentication or frequent rekeying may be impractical for a legacy controller, and an automated block may disrupt production. Compensating controls can include jump servers, strong operator authentication, allowlists, network enforcement, session recording, and carefully governed emergency access.

3.4 Defense in depth

A mature design uses multiple independent layers:

1. Physical: locked cabinets, controlled plant access, tamper evidence, and protected communications rooms.

2. Device: secure boot, signed firmware, unique credentials, disabled unused interfaces, and configuration control.

3. Network: segmentation, firewalls, protocol allowlists, secure remote access, and monitoring.

4. Application: authorization, input validation, secure APIs, logging, and safe failure behavior.

5. Process: change management, backups, maintenance procedures, training, and incident response.

6. Safety and resilience: independent protective functions, manual procedures, redundancy, and tested recovery.

Defense in depth does not mean accumulating controls without analysis. Controls should be independent enough that one failure does not expose the complete process, and they must be tested for unintended interactions.

4. Mobile Security

Mobile devices combine personal and organizational use, local storage, cameras, microphones, location data, biometric sensors, Bluetooth, Wi-Fi, cellular connectivity, and third-party applications. Their risk profile includes device loss, malicious applications, phishing, insecure wireless networks, SIM-related attacks, rogue accessories, compromised management accounts, and leakage through synchronization services.

4.1 Mobile threat areas

• Identity compromise: phishing, credential theft, malicious profiles, and weak device unlock mechanisms.
• Application risk: excessive permissions, insecure local storage, weak certificate validation, exported components, and supply-chain compromise.
• Endpoint exposure: loss or theft, unpatched operating systems, rooting or jailbreaking, and unapproved peripherals.
• Communication threats: rogue access points, Bluetooth abuse, cellular interception, and insecure APIs.
• Administrative abuse: excessive mobile-device-management privileges or poorly protected enrollment mechanisms.
• Operational misuse: using an unmanaged phone to issue control commands or photograph sensitive plant information.

4.2 Safeguards

Organizations should use mobile-device management or unified endpoint management, hardware-backed key storage where available, encryption, strong screen locks, timely updates, application allowlists for high-risk roles, remote lock and selective wipe, certificate-based authentication, and separation of personal and corporate data. Mobile applications should follow secure development practices and avoid storing tokens or sensitive data in plaintext.

A device used for OT administration should be treated as a privileged endpoint, not as an ordinary smartphone. Administrative access should require a managed device, phishing-resistant multifactor authentication, least privilege, approved applications, restricted network paths, and comprehensive logging. A mobile device should not bypass the safety and change-control procedures of the plant.

5. IoT Security Across the Lifecycle

IoT security is an ecosystem problem. The device is only one component; other components include firmware, gateways, mobile applications, cloud APIs, data stores, identity services, update infrastructure, installers, and analytics models.

5.1 Device-level safeguards

Important controls include:

• unique per-device identity rather than shared default passwords;
• secure boot and authenticated firmware updates;
• hardware-protected keys and protected debug interfaces;
• least-functionality configuration;
• encrypted communication appropriate to device capability;
• secure provisioning and decommissioning;
• tamper detection where the threat model requires it;
• accurate time or alternative mechanisms for replay protection;
• vulnerability disclosure and supported update processes.

Security cannot be added reliably at the end of a device’s life. Procurement requirements should specify support duration, update responsibility, vulnerability notification, software bills of materials (SBOMs), secure disposal, and evidence of testing.

5.2 Data and platform security

IoT platforms should enforce tenant isolation, API authorization, rate limits, input validation, key rotation, audit logging, and controlled data retention. Telemetry should be classified because sensor data can reveal production rates, occupancy, health information, or physical security patterns. Data minimization is especially important when devices collect location, audio, video, or biometrics.

Artificial intelligence can improve anomaly detection, predictive maintenance, and behavioral baselining. However, AI outputs are not automatically trustworthy. Attackers may poison training data, evade classifiers, or exploit false positives. In a safety-sensitive environment, AI should support—not silently replace—validated control logic and qualified human decision-making. Models require version control, monitoring, explainability appropriate to the use case, and a safe fallback.

6. Industrial Control and Safety Systems

An ICS typically includes field instruments, PLCs or RTUs, supervisory control, HMIs, engineering workstations, historians, and communication networks. OT protocols may be proprietary or open, routable or serial, and vary greatly in security capability. Some older protocols lack robust authentication, encryption, or integrity protection.

6.1 Engineering constraints

Security controls must respect scan cycles, latency, deterministic communication, vendor certification, process compatibility, and maintenance windows. A patch that is safe in a test environment may change timing or behavior in production. Every change should therefore be tested against a representative configuration, approved by operations and safety personnel, scheduled appropriately, and reversible.

Where patching is impossible, compensating controls can include isolation, application allowlisting, protocol filtering, virtual patching at network boundaries, removal of unused services, restricted physical access, read-only media procedures, enhanced monitoring, and replacement planning. Compensating controls reduce but do not eliminate risk.

6.2 Safety-security interaction

Safety instrumented systems are designed to reduce process risk through independent protection layers. Cybersecurity architecture must preserve their independence and prevent security mechanisms from disabling protective functions. Safety and security teams should jointly analyze common-cause failures, remote access, shared networks, maintenance tools, and emergency procedures.

A secure system should have defined safe states, but “safe” is process-dependent. Closing a valve may be safe in one process and dangerous in another. Incident response plans must specify who can authorize shutdown, which systems may be disconnected, how manual control is established, and how evidence is preserved without delaying urgent safety action.

7. Critical Infrastructure and Resilience

Critical infrastructure sectors—including energy, water, transportation, healthcare, communications, finance, and emergency services—are interdependent. A telecommunications outage may affect electric-grid control; a power outage may disable water treatment; compromised GPS may affect transport and timing systems.

Resilience planning should address:

• dependency mapping and single points of failure;
• backup communications and power;
• manual or degraded operating modes;
• offline backups of configurations and engineering documentation;
• alternate suppliers and replacement equipment;
• recovery priorities and restoration sequencing;
• exercises involving operators, executives, emergency services, vendors, and regulators.

A backup is useful only if it is protected from compromise and restoration has been tested. For OT, backups should include controller logic, HMI projects, recipes, network configurations, firmware, certificates, license information, and documented procedures. Version integrity and provenance should be verified before restoration.

8. Governance, Regulation, and Professional Responsibility

Relevant guidance includes the NIST Cybersecurity Framework 2.0, NIST SP 800-82 for ICS security, ISA/IEC 62443 for industrial automation and control systems, ISO/IEC 27001 for information-security management, and sector-specific requirements. ISO/SAE 21434 is relevant to road-vehicle cybersecurity, while medical-device regulation and guidance apply to connected clinical equipment. Legal obligations vary by jurisdiction and sector.

Governance should assign clear accountability among asset owners, process engineers, IT, security, safety, procurement, vendors, and senior management. Important policies include vulnerability handling, remote access, identity management, change control, third-party assurance, incident reporting, retention, privacy, and safety escalation.

Ethical duties are particularly strong when systems can affect human life. Organizations should not conceal material hazards, deploy insecure devices knowingly without mitigation, or collect personal data merely because collection is technically possible. Responsible vulnerability disclosure requires coordinated communication, risk reduction, and avoidance of unnecessary public detail before mitigations are available.

9. Incident Response for Cyber-Physical Environments

A conventional incident-response sequence—preparation, detection and analysis, containment, eradication, recovery, and lessons learned—must be adapted for physical processes.

Preparation includes asset and dependency inventories, contact lists, playbooks, offline backups, network diagrams, forensic capability, and exercises. Detection combines security telemetry with process alarms, operator observations, engineering deviations, and physical inspection.

Containment must distinguish between stopping malicious communication and stopping the physical process. Disconnecting a controller may remove attacker access but also eliminate visibility or automatic protection. Decisions should involve the incident commander, operations, safety authority, and technical specialists.

Eradication may require rebuilding engineering workstations, replacing credentials and certificates, validating controller logic, inspecting firmware, and checking for persistence in vendor tools. Recovery should proceed from known-good states, with staged validation and heightened monitoring. Lessons learned should examine not only the exploited vulnerability but also architectural, procurement, training, and governance weaknesses.

10. Illustrative Case: Compromise of a Water-Treatment Facility

Background

A regional water utility operates a treatment plant with PLCs controlling chemical dosing, pumps, and filtration. An engineering contractor uses remote access for maintenance. The plant has a corporate network, an OT network, a historian, and a vendor-managed remote-access appliance.

Problem

An attacker compromises a contractor credential through phishing. The account has broad remote access and is protected only by a password. The attacker enters the remote-access appliance, observes process screens, and changes a dosing set point. An operator notices an abnormal trend and switches the affected process to manual control. Water quality is not distributed outside permitted limits, but the plant must reduce throughput while validating the system.

Analysis

The immediate cyber weakness is inadequate authentication and excessive privilege. Architectural weaknesses include insufficient separation between vendor access and control functions, limited session monitoring, and incomplete review of remote accounts. Process risk is significant because an apparently small configuration change can affect public health. The operator’s ability to detect the abnormal trend and use manual control is a resilience strength.

Approach and solution

The utility disables the compromised account, preserves logs, and restricts remote access without disconnecting essential control networks. Operations and safety personnel validate chemical concentrations and controller logic. The organization then introduces phishing-resistant multifactor authentication, time-limited vendor access through a monitored jump server, approval for each maintenance session, role-based permissions, command and configuration logging, network segmentation, and offline backups of PLC programs.

The utility also performs a threat-led exercise, reviews all vendor accounts, establishes a recurring access-certification process, and requires contractors to report credential compromise promptly. It does not rely solely on adding a firewall; it improves identity, architecture, monitoring, process detection, and recovery.

Outcome and learning points

The plant avoids unsafe water distribution and resumes normal throughput after validation. The case demonstrates that cyber risk is process risk; remote access is a major control point; human operators and manual modes are part of security resilience; and technical controls must be integrated with safety and operational governance.

11. Challenges and Limitations

No control eliminates risk. Segmentation can be undermined by undocumented connections. Multifactor authentication may not protect an already compromised privileged session. Encryption can complicate monitoring and may be unavailable on legacy protocols. Asset discovery tools can overload fragile devices. AI detection can produce false alarms or miss novel attacks. Patching can introduce instability, while postponing patches preserves vulnerabilities.

Risk assessments also suffer from incomplete inventories, uncertain dependency information, vendor opacity, and difficulty estimating low-frequency catastrophic events. Organizations should document assumptions, distinguish evidence from judgment, and revisit assessments after process, technology, supplier, or threat changes.

Best-Practice Checklist

• Maintain a process-aware asset and dependency inventory.
• Separate enterprise, OT, safety, guest, and vendor access according to risk.
• Eliminate shared and default credentials; use strong, role-based authentication.
• Restrict remote access to approved, monitored, time-limited paths.
• Establish secure boot, signed updates, key management, and device retirement processes where feasible.
• Test patches and configuration changes before production deployment.
• Preserve offline, verified backups of logic, configurations, documentation, and credentials.
• Monitor both cyber indicators and physical-process anomalies.
• Integrate cybersecurity, safety, engineering, privacy, procurement, and emergency planning.
• Exercise manual operation, recovery, and crisis communication.
• Require suppliers to provide vulnerability handling, support commitments, and component transparency.
• Treat AI as an assistive capability requiring validation, governance, and safe fallback.

Chapter Summary

Cyber-physical, mobile, IoT, and OT systems connect digital decisions to physical consequences. Their security objectives extend beyond confidentiality, integrity, and availability to include authenticity, determinism, resilience, recoverability, and safety. Effective protection begins with process-aware asset identification and threat modeling, then applies defense in depth through physical safeguards, device security, segmentation, controlled conduits, identity management, monitoring, secure development, and tested recovery.

Mobile devices and IoT platforms expand the attack surface through portability, wireless communication, cloud dependence, constrained hardware, and complex supply chains. Industrial and critical-infrastructure environments add legacy technology, long lifecycles, high availability requirements, safety dependencies, and difficult maintenance conditions. Zero trust and modern security practices must therefore be adapted rather than applied mechanically.

The most effective programs integrate engineering, cybersecurity, safety, operations, procurement, governance, and incident response. Resilience depends on known-good backups, manual or degraded modes, trained personnel, dependency planning, and realistic exercises. Security is ultimately successful when it preserves trustworthy, safe, and recoverable physical service.

Key Terms

Cyber-physical system: A system integrating computation, communication, sensing, and actuation with physical processes.

Operational technology: Hardware and software that monitors or controls physical devices, processes, and events.

Industrial control system: A collection of control components such as PLCs, SCADA systems, HMIs, RTUs, and industrial networks.

Internet of Things: Connected physical devices that sense, communicate, compute, or act through networks and platforms.

Mobile-device management: Centralized administration and enforcement of security policies on mobile endpoints.

Programmable logic controller: An industrial computer that executes control logic for machinery or processes.

SCADA: Supervisory control and data acquisition, generally involving remote monitoring and control.

HMI: Human-machine interface used by operators to observe and interact with a process.

Purdue model: A conceptual hierarchical model for organizing industrial systems and networks.

Zone: A group of assets with similar security requirements.

Conduit: A controlled communication path between security zones.

Defense in depth: Use of multiple complementary security layers so one failure does not cause total compromise.

Zero trust: A security approach that continuously evaluates access rather than trusting network location.

Safety instrumented system: An independent or specially designed system that reduces process risk by implementing protective actions.

Secure boot: A mechanism that permits execution only of authenticated software.

SBOM: A software bill of materials identifying components included in a software product.

Compensating control: An alternative safeguard used when a preferred control cannot be implemented.

Resilience: The capability to withstand, adapt to, and recover from disruption.

Attack surface: The set of points through which a system may be attacked.

Incident response: Organized activity for detecting, containing, resolving, and learning from security incidents.

Review Questions

Short Answer Questions

1. Why can availability have a different meaning in OT than in conventional IT?

2. What are zones and conduits in industrial security architecture?

3. Identify four security risks specific to mobile devices.

4. Why are IoT ecosystems more extensive than the individual device?

5. What is the purpose of a safety instrumented system?

Long Answer Questions

1. Explain how cyber-physical consequences change the use of confidentiality, integrity, and availability as security priorities.

2. Discuss how defense in depth should be implemented in an industrial control environment.

3. Compare conventional enterprise patching with patch management for legacy OT systems.

4. Explain the security lifecycle requirements for IoT devices from procurement through retirement.

5. Discuss how incident response should be adapted when a cyber event may affect human safety.

Analytical / Application Questions

1. A factory permits engineers to connect personal laptops directly to PLC networks during maintenance. Analyze the risks and design a safer remote-maintenance architecture.

2. A hospital deploys wireless infusion pumps managed through a cloud platform. Develop a threat model covering devices, applications, identities, communications, and patient safety.

3. A power utility cannot patch a legacy controller for six months because of production constraints. Recommend and justify compensating controls, monitoring, and a transition plan.

Suggested Standards and Further Reading

NIST, Cybersecurity Framework 2.0.

NIST, SP 800-82, Guide to Operational Technology Security.

ISA/IEC 62443 series, Security for Industrial Automation and Control Systems.

ISO/IEC 27001, Information Security Management Systems.

ISO/SAE 21434, Road Vehicles—Cybersecurity Engineering.

MITRE ATT&CK for ICS knowledge base.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes many OT environments from conventional enterprise IT?

A. OT systems never use networks

B. OT systems can produce physical and safety consequences

C. OT systems do not require authentication

D. OT systems contain only cloud applications

Correct Answer: B. OT systems can produce physical and safety consequences

Question 2

In the zones-and-conduits model, a conduit is primarily used to:

A. Group assets with identical physical functions

B. Replace all safety systems

C. Control communication between security zones

D. Store offline backups

Correct Answer: C. Control communication between security zones

Question 3

Which is the strongest example of a mobile device being treated as a privileged endpoint?

A. Allowing any personal phone to access PLCs

B. Requiring a managed device and phishing-resistant multifactor authentication

C. Disabling all device logging

D. Using a shared administrator password

Correct Answer: B. Requiring a managed device and phishing-resistant multifactor authentication

Question 4

What is a major IoT lifecycle security requirement?

A. Using one password for every device

B. Providing authenticated firmware updates and secure decommissioning

C. Avoiding device inventories

D. Allowing permanent vendor access

Correct Answer: B. Providing authenticated firmware updates and secure decommissioning

Question 5

Why may immediate patching be inappropriate for an industrial controller?

A. Patches are never useful in OT

B. A patch may affect timing, compatibility, or process safety

C. Industrial systems cannot contain vulnerabilities

D. OT systems do not use software

Correct Answer: B. A patch may affect timing, compatibility, or process safety

Question 6

Which control most directly limits vendor remote-access risk?

A. Permanent unrestricted VPN access

B. A monitored jump server with time-limited approved sessions

C. A shared contractor account

D. Disabling all audit records

Correct Answer: B. A monitored jump server with time-limited approved sessions

Question 7

What is the principal purpose of secure boot?

A. To increase wireless range

B. To permit execution only of authenticated software

C. To replace network segmentation

D. To provide physical access control

Correct Answer: B. To permit execution only of authenticated software

Question 8

Why should AI-based anomaly detection not silently replace validated safety logic?

A. AI cannot process sensor data

B. AI models may produce false positives, false negatives, or be manipulated

C. Safety systems never use data

D. AI always disables encryption

Correct Answer: B. AI models may produce false positives, false negatives, or be manipulated

Question 9

Which item is especially important in an OT backup?

A. Only employee photographs

B. Only public website content

C. Controller logic, configurations, and engineering documentation

D. Unverified temporary files

Correct Answer: C. Controller logic, configurations, and engineering documentation

Question 10

During a cyber incident in a safety-sensitive plant, containment decisions should primarily consider:

A. Only whether network traffic can be stopped

B. Only the cost of downtime

C. Effects on process safety, visibility, control, and recovery

D. Whether logs can be deleted

Correct Answer: C. Effects on process safety, visibility, control, and recovery