IEC 62443

Asset owner manages IACS user and service accounts with least privilege, individual accountability where feasible, role-based access, periodic review and removal upon role change or departure.

• IACS user account register with roles and last review date
• Shared/operator account justification and compensating controls
• Quarterly access review records
• Joiner-mover-leaver process for IACS access
• Privileged account inventory (engineering, admin, vendor)
• Vendor account expiry policy

• Shared operator console account with no logging of individual operator
• Default vendor accounts and passwords still in use
• No revocation when control engineer transfers or leaves

Asset owner plans, tests and maintains the ability to recover IACS function after a cybersecurity incident or other disruption, including configuration backups for controllers, HMI images, historian data and engineering workstations, with documented RTO and RPO.

• IACS BCP/DRP document with RTO/RPO per system tier
• PLC and HMI configuration backup procedure and storage
• Offline backup evidence (immutable or air-gapped)
• Restore test report at least annually
• Spare hardware register (PLCs, network gear, IO modules)
• Manual operation procedure when IACS is unavailable

• PLC programs only on engineer laptop with no central backup
• Backups stored on same network as production, encrypted by ransomware
• No restore test ever performed end to end

Asset owners establish, implement and maintain a documented Cyber Security Management System covering scope, policy, risk analysis, risk treatment, training, business continuity, physical security, network segmentation, access control, monitoring, incident response and management review specific to IACS environments.

• CSMS manual covering IACS scope and OT specifics
• Approved IACS security policy signed by asset owner executive
• CSMS scope statement listing sites, plants, control systems in scope
• Management review minutes for CSMS effectiveness annually
• RACI matrix for IACS security roles (asset owner, integrator, supplier, maintenance)
• CSMS performance metrics dashboard (incidents, vulnerabilities, training completion)

• IT security policy reused for OT with no IACS-specific adaptations
• CSMS scope excludes safety instrumented systems or remote engineering workstations
• No defined responsibility split between asset owner and integrator/supplier

Asset owner maintains an incident response capability tailored to IACS, including detection, triage, containment, eradication, recovery, lessons learned, communication with regulators, and exercises that include OT-specific scenarios such as ransomware on engineering workstation or malicious PLC logic change.

• IACS incident response plan separate from or integrated with corporate IR
• OT-specific playbooks (ransomware, PLC tamper, HMI lockout, SIS bypass)
• Tabletop exercise reports with OT operations attendance
• Contact list for OT vendors, integrators, ICS-CERT
• Forensic readiness procedure for PLCs and historians
• Post-incident review template

• Corporate SOC has no visibility into OT and no OT runbooks
• No exercise involving plant operations leadership
• Forensic capability assumes Windows servers, not PLCs or relays

Asset owner integrates cybersecurity into management of change processes so that hardware, software, firmware, network, or logic changes to IACS are risk-assessed, approved, tested and documented including effect on security posture.

• MOC procedure referencing cybersecurity review step
• Change records showing security risk assessment outcome
• Cybersecurity sign-off role identified in workflow
• Pre and post change verification evidence
• Emergency change process with retrospective review

• MOC process exists for safety but cybersecurity not a required review
• Firmware updates treated as maintenance, no MOC
• Vendor remote changes applied with no MOC entry

Asset owner segments IACS networks into zones and conduits based on risk, separating IACS from corporate IT via DMZ, restricting traffic to documented purposes, and protecting safety systems from other control systems.

• Network architecture diagram showing Purdue levels and zones
• DMZ design between Level 3.5 and corporate
• Firewall ruleset with business justification per rule
• Conduit register listing protocols, endpoints, security measures
• SIS segregation evidence (air gap or dedicated firewall)
• Annual firewall rule review report

• Flat OT network with no segmentation between process areas
• ICS DMZ exists but with any-any rules
• SIS sharing network with BPCS, violating ISA 84 and 62443

Asset owner protects control rooms, marshalling cabinets, PLCs, RTUs, network equipment and engineering workstations from unauthorised physical access, tampering and environmental damage.

• Cabinet lock and seal inventory
• Control room badge access logs
• CCTV coverage map of critical IACS areas
• Tamper-evident seal inspection records
• Environmental monitoring (temperature, humidity) for control rooms
• Visitor and contractor escort log

• PLC cabinets left unlocked on plant floor
• Engineering workstations in shared offices without restriction
• No tamper detection on remote RTU enclosures

Asset owner operates a documented IACS patch management process covering vulnerability monitoring, applicability analysis, vendor approval, test, deployment during outages, and risk acceptance for unpatchable systems.

• IACS patch policy and procedure
• Vendor patch approval matrix per product
• Patch test environment description
• Patch deployment log per asset
• Compensating controls register for unpatchable assets
• Vulnerability watch list (ICS-CERT, vendor advisories)

• Patches deferred indefinitely with no compensating controls
• No isolated test environment, patches applied directly to production
• Legacy XP, Windows 7 systems with no documented risk acceptance

Asset owner performs high-level and detailed cybersecurity risk assessments of IACS considering threats, vulnerabilities, consequences to safety, environment, production and reputation, and documents risk treatment decisions before commissioning and on significant change.

• High-level risk assessment report per site or process
• Detailed risk assessment per zone aligned to 62443-3-2
• Threat catalogue covering ransomware, insider, nation-state, supply chain, safety bypass
• Consequence severity matrix including HSE impact
• Risk treatment plan with owner and due date
• Reassessment trigger procedure (MOC, incident, vulnerability disclosure)

• Safety consequences not considered alongside cyber consequences
• Risk assessment static and never refreshed after plant modifications
• Inherent risk recorded but residual after countermeasures missing

Asset owner provides role-based IACS cybersecurity training to operators, engineers, maintenance staff, contractors and managers, with content tailored to OT realities and refresher cadence defined.

• Training matrix by role (operator, control engineer, network admin, integrator)
• Course content covering OT-specific risks (USB, vendor remote access, safe state)
• Attendance records with signatures
• Annual refresher schedule
• Contractor induction including IACS security briefing

• IT phishing training only, nothing OT-specific
• Contractors and OEM engineers exempted
• No refresher beyond initial induction

IACS service providers (integrators, maintenance providers) establish a documented security program addressing personnel, processes and technical practices delivered to asset owners during integration, commissioning and ongoing maintenance.

• Service provider security program document
• Certification or attestation (TUV, ISASecure SP)
• Personnel competency records for delivery staff
• Tools and methodology library list
• Customer-facing security capability statement

• Integrator pitches 62443 capability with no documented program
• Personnel not trained on customer-specific environment
• Reuses IT security program without OT adaptation

Service provider ensures personnel deployed on IACS engagements are vetted, trained and supervised, with background checks proportionate to access level and competency verified for tasks performed.

• Background check policy and records for project staff
• Training records mapped to roles
• Competency assessment per task type (PLC programming, network commissioning)
• Subcontractor management procedure
• Confidentiality agreements signed

• Subcontractors deployed without same checks as employees
• Competency assumed from CV with no verification
• No record of who actually performed work onsite

Service provider applies secure architecture practices when designing IACS solutions, including zones, conduits, defence in depth, secure remote access, least functionality and adherence to asset owner security requirements.

• Reference architecture catalogue
• Design review checklist with security items
• Customer security requirement traceability matrix
• Hardening guides per product family
• Peer review evidence on design packages

• Designs reuse legacy patterns with flat networks
• Customer security requirements not captured at FEED stage
• Hardening left to commissioning team with no central guidance

Service provider implements secure wireless and remote access mechanisms when providing IACS services, including MFA, jump servers, session recording, time-limited access and explicit asset owner approval.

• Remote access architecture with jump host and MFA
• Session recording configuration evidence
• Approval workflow before remote session
• Time-bound account creation evidence
• Wireless deployment standard (WPA3, certificate auth)

• Vendor uses TeamViewer or AnyDesk with shared password
• No session recording, no audit trail of vendor actions
• Wireless deployed with WPA2-PSK and shared key never rotated

Service provider applies malware protection on its own tools, removable media and delivery devices used at customer sites, and supports asset owner anti-malware controls during commissioning and maintenance.

• Endpoint protection on all engineering laptops
• Removable media scanning kiosk procedure
• USB whitelist policy
• Engineering laptop encryption
• Pre-deployment image scan evidence

• Engineering laptops without EDR or with outdated signatures
• USBs brought to site without scanning
• Same laptop used across multiple customer sites without sanitisation

Service provider supports IACS backup and restore capability including controller program backups, system images, configuration archives and procedures handed over to asset owner with restore test evidence.

• Backup design document part of project deliverables
• Restore test report signed by asset owner
• Configuration baseline archive on handover
• Backup procedure handover document
• Storage media security on transfer

• Backups taken at SAT but not handed to asset owner
• No restore test performed, only backup creation
• Configuration not under version control

Document the Cybersecurity Requirements Specification capturing per-zone and per-conduit security requirements, SL-T, assumptions and constraints used as input to design, procurement and acceptance.

• CRS document approved by asset owner
• Mapping of CRS to FR1 to FR7 requirements
• Procurement specs referencing CRS
• Acceptance test plan traceable to CRS
• Change control over CRS

• No CRS produced, requirements communicated verbally to integrator
• Procurement does not include CRS, vendor delivers default config
• Acceptance tests do not verify CRS items

Define the System Under Consideration including boundary, components, functions, supporting infrastructure and external interfaces as the basis for risk assessment and zone/conduit definition.

• SUC boundary document with diagram
• Asset inventory within SUC
• Interface register (network, physical, human, supply)
• Process and function description
• Stakeholder list (asset owner, integrator, vendor, regulator)

• SUC boundary fuzzy, missing safety system or historian
• Interfaces to corporate IT or vendors omitted
• Asset inventory incomplete for embedded devices

Perform an initial high-level cybersecurity risk assessment on the SUC to identify worst-case unmitigated consequences and prioritise areas needing detailed analysis and zoning.

• HLRA report with consequence categories (HSE, production, financial, reputation)
• Worst-case scenario register
• Initial security level target SL-T proposal
• Stakeholder workshop minutes
• Approval sign-off by asset owner

• HLRA done by IT without process safety SME participation
• Worst case bounded only by IT impact, not process consequence
• No traceability from HLRA to subsequent detailed assessment

Partition the SUC into zones (groupings with common security requirements) and conduits (communications between zones), based on function, risk, criticality, ownership and physical or logical boundaries.

• Zone and conduit diagram
• Zone descriptor (function, assets, criticality, SL-T)
• Conduit descriptor (protocols, endpoints, controls)
• Justification for grouping decisions
• Mapping to Purdue model levels

• Entire plant treated as one zone
• Safety system in same zone as basic process control
• Conduits documented at firewall level only, missing serial and wireless

For each zone and conduit perform detailed risk assessment identifying threats, vulnerabilities, existing countermeasures, likelihood, consequence and resulting risk against tolerable risk, leading to target Security Level SL-T.

• Per-zone risk assessment report
• Threat catalogue applied to zone
• Vulnerability inventory (CVEs, configuration, design)
• Risk matrix output with risk rating
• SL-T statement per zone and conduit
• Risk treatment recommendations

• SL-T assigned by gut feel with no risk math
• Vulnerabilities not refreshed against current advisories
• Tolerable risk threshold never defined

The IACS shall provide the capability to identify and authenticate all human users and enforce the authentication on all interfaces providing access to the IACS, including operator HMI, engineering workstation and remote access.

• Authentication mechanism documentation per interface
• Identity store inventory (AD, local, application)
• MFA implementation evidence on engineering and remote
• Password policy aligned to SL-T
• Test evidence of failed unauthenticated access attempt

• HMI shared operator account with sticker password
• Engineering workstation auto-login to admin
• Remote access without MFA

The IACS shall provide the capability to enforce a configurable limit on consecutive invalid access attempts for human users, with response actions consistent with operational availability needs.

• Lockout policy configuration
• Operational impact assessment for lockout (avoid HMI lockout during emergency)
• Compensating controls where lockout disabled (e.g. monitoring, alarm)

• Lockout disabled because once locked out an operator at a refinery
• No alternative monitoring of brute force attempts

The IACS shall provide the capability to identify and authenticate software processes and devices communicating across conduits or to control system components.

• Device certificate inventory (OPC UA, IEC 62351)
• Service account register with use case
• Mutual authentication evidence between historian and PLC where supported
• Certificate lifecycle process
• Hardening guide entries for service accounts

• OPC UA configured in anonymous mode
• Service accounts shared across applications
• No certificate management for OT

The IACS shall provide the capability to manage authenticators including initial issuance, change, revocation, default authenticator handling and protection in storage and transit.

• Password policy document
• Default credential change evidence on commissioning
• Password vault for service accounts
• Authenticator rotation procedure
• Audit of weak/default passwords

• Default vendor passwords remain on devices in production
• Service account passwords shared in plaintext spreadsheet
• Password change disruptive so never done

Where password-based authentication is used the IACS shall enforce configurable password strength including minimum length, complexity, history and lifetime appropriate to SL-T.

• Password policy parameters per system
• Group policy or device config screenshots
• Exception register where weaker policy is accepted with compensating controls

• PLC max password length 4 to 8 chars, no policy enforced
• HMI password never changed since commissioning
• No policy difference between operator and admin

The IACS shall provide the capability to enforce authorisations assigned to all human users for controlling use of the IACS to support segregation of duties and least privilege.

• Role definitions (operator, engineer, supervisor, admin, viewer)
• Permission matrix mapped to roles
• Access control list export per system
• Least privilege review evidence
• Segregation of duties analysis (programmer vs approver)

• All users on HMI given administrator
• No distinction between view and control on remote sessions
• Engineering and approval performed by same individual

The IACS shall provide the capability to control execution of mobile code (scripts, macros, applets) used within the control system or on engineering workstations.

• Mobile code policy
• Application whitelisting configuration on EWS
• Macro execution policy
• Browser plugin restriction

• Engineering workstation general-purpose with arbitrary script execution
• Office macros enabled with no signing requirement

The IACS shall provide the capability to lock or terminate sessions after a configurable period of inactivity, balanced against operational safety considerations especially for HMIs in continuous monitoring.

• Session timeout configuration per interface
• Justification for HMI exemptions
• Auto re-authentication procedure
• Logout audit log

• No session timeout anywhere because operators object
• Remote sessions persist for days

The IACS shall provide the capability to generate audit records for security-relevant events including access control, configuration change, authentication, system events and operator actions on safety-critical commands.

• Audit policy listing events
• Sample audit log extract
• Log aggregation architecture
• Retention period configuration
• Time synchronisation evidence (NTP/PTP)

• PLCs do not log set-point or program changes locally
• No central log aggregation from OT, logs lost on device reboot
• Time not synchronised, correlation impossible

The IACS shall provide the capability to protect the integrity of transmitted information, especially for control commands and safety-relevant communications, using cryptographic or other appropriate mechanisms.

• Protocol inventory with integrity mechanism (TLS, IPSec, IEC 62351)
• Cryptographic key management procedure
• Justification where integrity protection is not feasible
• Monitoring for protocol anomalies

• Plain Modbus or DNP3 in production without integrity protection
• Engineering protocols (S7, EtherNet/IP) unauthenticated
• No anomaly detection on control protocols

The IACS shall provide the capability to protect against installation and execution of malicious code through anti-malware, application whitelisting, removable media controls and integrity verification where compatible with control function.

• Endpoint protection coverage report on Windows-based OT
• Whitelisting evidence for embedded devices and EWS
• Removable media policy
• Signature/baseline update process compatible with OT outage windows

• AV deployed without OT vendor approval, breaking control function
• No protection on engineering workstations because vendor never tested AV
• USB controls absent

The IACS shall provide the capability to verify intended operation of security functions and report when verification fails, including periodic self-tests, configuration baselines and integrity checks.

• Baseline configuration register
• Configuration drift detection report
• Self-test or health-check logs
• Verification frequency aligned to SL-T

• No baseline captured at commissioning
• Configuration drift never measured
• Security control failures (firewall down) not alarmed to operator

The IACS shall provide the capability to detect, record, report and protect against unauthorised changes to software, firmware, configuration and information at rest within the control system.

• File integrity monitoring on EWS and historian
• Firmware version inventory and verification
• PLC program checksum monitoring
• Configuration management database

• No detection of PLC program change outside change window
• Firmware version not tracked, rogue updates undetected
• EWS file system unmonitored

The IACS shall provide the capability to protect the integrity of sessions, defending against hijack, replay and man-in-the-middle attacks, particularly for operator and engineering sessions.

• TLS or VPN on remote and engineering sessions
• Session token implementation review
• Replay protection evidence on industrial protocols where supported

• RDP exposed without NLA
• Engineering tools talk to PLC over cleartext with no session controls
• Replay attacks on industrial protocols possible

The IACS shall provide the capability to protect the confidentiality of information at rest and in transit when required by risk assessment, including process recipes, intellectual property and personally identifiable information.

• Data classification scheme covering OT data
• Encryption at rest on historian or recipe storage
• Encryption in transit for sensitive flows
• Key management procedure

• Recipe and batch data assumed not sensitive, no protection
• Historian replication across plants in cleartext

The IACS shall provide the capability to purge information from components when no longer needed including disposal of media, decommissioned PLCs and engineering laptops carrying program logic and credentials.

• Decommissioning procedure for OT assets
• Disposal records (PLC, drives, removable media)
• Sanitisation method (NIST 800-88) where applicable

• Decommissioned PLCs sold or scrapped with logic still loaded
• Engineering laptops returned to IT without OT-specific wipe

The IACS shall provide the capability to logically segment networks and restrict data flow between zones based on the principle of least communication necessary.

• Network segmentation design referencing zones from 62443-3-2
• Firewall rule documentation per conduit
• Annual rule review
• Unidirectional gateway deployment where applicable

• Logical segmentation absent within OT (single broadcast domain)
• Firewall rules between IT and OT permit any-any
• SIS network shared with BPCS

The IACS shall provide the capability to monitor and control communications at zone boundaries, providing deny-by-default policy and alarming on attempted boundary violations.

• Boundary device inventory (firewalls, data diodes)
• Default deny ruleset evidence
• Boundary alarm escalation procedure
• Monitoring integration with SOC or OT NOC

• Default allow rule at boundary
• Boundary alarms only logged, not actioned
• No monitoring of unidirectional gateway state

The IACS shall provide the capability to prevent general-purpose person-to-person messaging (email, IM, browsing) from devices used to perform control functions where required by SL-T.

• EWS and HMI software inventory excluding email/browser
• Group policy restricting outbound web
• Justification where exceptions exist

• Engineering workstations used for general email and browsing
• Operators reading email on HMI consoles

The IACS shall provide the capability to make audit records accessible to authorised humans or automated tools for analysis in support of incident detection and response.

• Log forwarding configuration to SIEM or OT monitoring
• Operator and analyst access procedure
• Retention and protection policy

• Logs exist only on individual devices and aren't aggregated
• Access to logs requires onsite physical access
• No analyst monitoring OT logs

The IACS shall provide the capability to continuously monitor security-relevant events using mechanisms appropriate for control system environments such as passive network monitoring and asset inventory tools.

• OT monitoring platform deployment (Dragos, Nozomi, Claroty, Tenable.OT)
• Asset inventory output
• Anomaly detection alerts and triage process
• Monitoring coverage map (which zones, which sensors)

• Monitoring deployed on corporate IT only, OT blind
• OT sensor present but no analyst triage
• Coverage gaps at remote substations or skids

The IACS shall provide the capability to operate in a degraded mode or maintain essential functions during a denial-of-service event, including network floods, broadcast storms and application-layer DoS.

• DoS test report from FAT/SAT
• Rate limiting and storm control configuration on OT switches
• Resource exhaustion test on PLCs/HMIs
• Degraded mode operating procedure

• No DoS testing performed during commissioning
• Broadcast storm protection disabled on switches
• PLCs known to fail under network scan tools

The IACS shall provide the capability to back up user-level information and system-level information without affecting the normal operation of the control system, and protect backup integrity and confidentiality.

• Backup schedule per system
• Backup integrity verification (hash, restore test)
• Offsite or immutable storage evidence
• Restore time measurement vs RTO

• Backups confirmed but never tested by restore
• Backup network connected to production, ransomware can reach it
• Restore time unmeasured

The IACS shall provide the capability to be configured according to recommended network and security configurations and maintain them across normal operation, restart and recovery.

• Hardening standard per device family
• Configuration baseline backup
• Drift detection process
• Vendor hardening guides referenced

• Devices deployed with vendor defaults, no hardening applied
• Hardening applied once but lost after firmware update or replacement
• No reference baseline to compare against

Product supplier maintains a process to receive, triage, remediate and disclose security defects including coordinated disclosure with researchers and customers, advisories, and CVE assignment.

• PSIRT charter and contact
• Vulnerability disclosure policy
• Sample security advisory
• CVE coordination evidence
• Time to fix metrics
• Customer notification process

• No PSIRT, researchers ignored
• Advisories delayed by months
• Customers find out via ICS-CERT, not vendor

Product supplier applies secure-by-design principles including defence in depth, least privilege, secure default configurations, security architecture review and attack surface minimisation.

• Design review with security checklist
• Defence in depth justification
• Secure default configuration documentation
• Attack surface analysis

• Default credentials shipped enabled
• All ports open by default
• No defence in depth, single layer protection

Product supplier provides documentation to asset owners and integrators describing secure configuration, hardening, account management, removal/disposal and integration security considerations.

• Security configuration guide per product
• Hardening guide
• Decommissioning guide
• Integration security guide
• Default credential and port listing

• No hardening guide
• Default credential documentation buried or absent
• Decommissioning not addressed

Product supplier follows secure coding standards, performs code reviews, uses static and dynamic analysis tools and manages cryptographic implementations to avoid common weaknesses.

• Coding standard document
• SAST/DAST tool reports
• Code review records
• Crypto library inventory
• Compiler hardening flags

• No code review process for safety-critical firmware
• SAST run only ad hoc
• Custom crypto implementations

Product supplier defines and maintains a documented Security Development Lifecycle covering organisation, responsibilities, training, security expertise, third-party component management and security plan for each product.

• SDL process document
• Security training records for developers
• Per-product security plan
• Third-party/open source component inventory (SBOM)
• ISASecure SDLA or equivalent certification

• SDL described in marketing but no procedure or evidence
• No SBOM, third-party components unmanaged
• No security training for embedded developers

Product supplier specifies security context, threat model and security requirements for the product, traceable to design and verification activities.

• Threat model document per product
• Security requirements specification
• Traceability matrix to design and test
• Security context for intended deployment

• No threat model exists for legacy products
• Requirements informal and unverified

Product supplier provides security updates for products including evaluation of compatibility, controlled distribution, signing, and clear documentation of remediated vulnerabilities for asset owners.

• Update release process
• Code signing implementation
• Update distribution channel
• Update documentation for asset owners
• Compatibility matrix

• No signed updates, asset owner cannot trust file authenticity
• Updates released without release notes describing security fixes

Product supplier conducts security verification testing including security functional tests, threat mitigation tests, vulnerability scanning, penetration testing and protocol robustness testing.

• Security test plan
• Vulnerability scan reports
• Penetration test report
• Protocol robustness/fuzzing report (Achilles, ISASecure CRT)
• Test coverage report

• Only functional testing, no security testing
• Protocol fuzzing skipped, products fail under malformed packets

Components (embedded devices, host devices, network devices, software applications) shall provide the capability to identify and authenticate all human users seeking access to the component.

• Component authentication mechanism documentation
• Vendor declaration of conformance to CR 1.1
• ISASecure component security assurance (CSA) certificate

• Embedded device without authentication on local interfaces
• Default admin with no enforced change at first use

Components shall provide the capability to protect integrity of transmitted information through cryptographic mechanisms or equivalent appropriate for the component class and SL-C.

• Protocol support matrix with TLS/IPSec/IEC 62351
• Crypto module list and FIPS or equivalent
• Vendor SL-C declaration

• Component supports only legacy protocol with no integrity
• Crypto disabled by default

Components shall provide the capability to maintain essential functions under DoS conditions and recover automatically where feasible, particularly for embedded devices controlling physical processes.

• Robustness test report (e.g. ISASecure CRT)
• Watchdog/auto-recovery configuration
• Vendor declaration of failure modes

• Component crashes under network scan
• No watchdog, requires manual power cycle

Embedded devices (PLCs, RTUs, IEDs) shall support the capability to be updated with security patches in a manner consistent with availability requirements, including signed firmware and rollback protection.

• Signed firmware documentation
• Rollback protection mechanism description
• Update procedure tested during outage
• Vendor advisory archive

• Firmware updates unsigned
• Update interrupts process with no graceful path
• Vendor no longer supports device with patches

Physical and logical access controls. Control from IEC 62443 framework, domain: IEC 62443: Access Management.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Personnel risk assessment. Control from IEC 62443 framework, domain: IEC 62443: Access Management.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Electronic access perimeter management. Control from IEC 62443 framework, domain: IEC 62443: Access Management.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Interactive remote access security. Control from IEC 62443 framework, domain: IEC 62443: Access Management.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Revocation of access procedures. Control from IEC 62443 framework, domain: IEC 62443: Access Management.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Critical asset identification and inventory. Control from IEC 62443 framework, domain: IEC 62443: Asset Identification & Governance.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

System security categorization. Control from IEC 62443 framework, domain: IEC 62443: Asset Identification & Governance.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Security governance structure. Control from IEC 62443 framework, domain: IEC 62443: Asset Identification & Governance.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Roles and responsibilities for critical systems. Control from IEC 62443 framework, domain: IEC 62443: Asset Identification & Governance.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Security policy for operational technology. Control from IEC 62443 framework, domain: IEC 62443: Asset Identification & Governance.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Incident response plan for operational disruptions. Control from IEC 62443 framework, domain: IEC 62443: Incident Response & Recovery.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Recovery plan for critical systems. Control from IEC 62443 framework, domain: IEC 62443: Incident Response & Recovery.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Reporting obligations to authorities. Control from IEC 62443 framework, domain: IEC 62443: Incident Response & Recovery.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Coordination with sector-specific agencies. Control from IEC 62443 framework, domain: IEC 62443: Incident Response & Recovery.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Exercises and drills for OT incidents. Control from IEC 62443 framework, domain: IEC 62443: Incident Response & Recovery.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Supply chain risk management for critical components. Control from IEC 62443 framework, domain: IEC 62443: Supply Chain & Configuration.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Configuration management for OT systems. Control from IEC 62443 framework, domain: IEC 62443: Supply Chain & Configuration.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Change management procedures. Control from IEC 62443 framework, domain: IEC 62443: Supply Chain & Configuration.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Vulnerability assessment for critical systems. Control from IEC 62443 framework, domain: IEC 62443: Supply Chain & Configuration.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Security patch management for OT. Control from IEC 62443 framework, domain: IEC 62443: Systems Security.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Malware prevention for operational systems. Control from IEC 62443 framework, domain: IEC 62443: Systems Security.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Network security monitoring. Control from IEC 62443 framework, domain: IEC 62443: Systems Security.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

System security hardening. Control from IEC 62443 framework, domain: IEC 62443: Systems Security.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring

Ports and services management. Control from IEC 62443 framework, domain: IEC 62443: Systems Security.

• OT asset inventory
• Zone and conduit diagram
• Patch register
• Remote access policy

• Unmanaged OT assets
• Flat networks
• Limited OT monitoring