IEC 62443 Readiness Guide and Project Checklist
Prepare for an IEC 62443 readiness review with practical checks for system boundaries, risk decisions, supplier responsibilities and FAT/SAT evidence. Record what is known, what is missing and who will act.
Use this guide to prepare
- SuC boundary evidence
- zones and conduits workshops
- SL-T discussions
- FAT/SAT verification
12
4
7
FAT/SAT
Overview
What IEC 62443 readiness needs before detailed assessment starts.
Who this guide is for
For engineering, OT cybersecurity, project, assurance, vendor, and integrator teams.
Why IEC 62443 readiness matters
Reduces late rework by clarifying scope, evidence, and verification early.
Readiness workflow
01
Define
Confirm the SuC, owners, interfaces, and evidence baseline.
02
Structure
Map zones, conduits, communication paths, and trust boundaries.
03
Assess
Connect security levels and risk scenarios to operational context.
04
Verify
Plan FAT, SAT, handover, residual risk, and close-out evidence.
Understand the IEC 62443 structure
The IEC 62443 series covers different organisational, system, service-provider and product concerns. Select the relevant publications from the client role and scope; do not treat the whole series as one universal checklist.
| Area | What it covers | Why it matters |
|---|---|---|
| General | Terms, concepts, and models | Creates a shared language for IT, OT, engineering, and assurance teams |
| Policies and procedures | Cybersecurity management and governance | Supports organisational security processes and responsibilities |
| System | Risk assessment, system requirements, security levels, zones, and conduits | Most relevant to project architecture and system design |
| Component | Product and device security requirements | Useful for assessing PLCs, HMIs, switches, software, and embedded devices |
For project teams, the most commonly relevant areas are
- IEC 62443-3-2 for risk assessment, SuC definition, zones, conduits, and security levels
- IEC 62443-3-3 for system security requirements and foundational requirements
- IEC 62443-4-2 for component security requirements
- IEC 62443-2-4 for service provider and integrator requirements
Define the System under Consideration
The System under Consideration (SuC) defines the boundary of the system being assessed. It should show the control functions in scope, connected services, important dependencies, external interfaces and explicit exclusions.
If the SuC is vague, risk scenarios, zone boundaries, security-level decisions and evidence ownership will also be vague.
The SuC should identify
- control panels
- PLCs and safety PLCs
- HMIs and operator stations
- SCADA servers and clients
- engineering workstations
- historians and reporting systems
- industrial switches and routers
- firewalls and remote access equipment
- vendor equipment connected to the control system
- links to corporate IT, cloud platforms, or third-party networks
- interfaces to other control systems or packages
- backup, recovery, and maintenance infrastructure
Questions to answer
- What system is being assessed?
- Where does the system boundary start and end?
- Which assets are inside the scope?
- Which assets are outside the scope?
- Which systems does it communicate with?
- Who owns the system?
- Who maintains it?
- Who has remote or local access?
- What drawings, schedules, and records support the boundary definition?
Useful evidence
- network architecture drawings
- control system architecture drawings
- panel layouts
- asset registers
- IP address schedules
- switch schedules
- firewall rule sets
- remote access procedures
- vendor package interface details
- system functional design specifications
- backup and recovery procedures
Identify zones and conduits
IEC 62443 uses zones and conduits to structure security architecture.
A zone is a group of assets with similar security requirements.
Example zones may include
- safety instrumented system zone
- basic process control system zone
- SCADA zone
- engineering workstation zone
- historian zone
- industrial DMZ
- vendor package zone
- corporate IT zone
Assets in the same zone should normally have similar risk, function, ownership, and security requirements.
A conduit is a controlled communication path between zones.
Examples include
- firewall connection between SCADA and corporate IT
- remote access path through a jump host
- data transfer from a control system to a historian
- vendor support connection
- interface between package PLCs and the main control system
- connection between safety and non-safety systems
Why zones and conduits matter
- understand trust boundaries
- reduce unnecessary connectivity
- define firewall and access control requirements
- identify high-risk interfaces
- support risk-based segmentation
- provide a clear basis for testing and verification
Preparation checklist
- current or proposed network diagrams
- asset list grouped by function
- communication matrix
- protocol list
- firewall rule export or proposed rule table
- remote access path description
- vendor connection details
- interface list between control system packages
- trust boundary assumptions
Prepare for security level discussions
Security-level discussions must follow the risk assessment and apply to the relevant zone or conduit. Record the threat assumptions, consequence basis and product or operating constraints behind the decision.
Do not copy a blanket target from another site or treat a product capability claim as evidence that the installed system achieves the same result.
| Term | Meaning |
|---|---|
| SL-T | Target Security Level. The desired security level for the system, zone, or conduit |
| SL-A | Achieved Security Level. The level actually implemented and verified |
| SL-C | Capability Security Level. The level a product or system is capable of supporting |
| Level | General meaning |
|---|---|
| SL 1 | Protection against casual or accidental misuse |
| SL 2 | Protection against intentional misuse using simple means |
| SL 3 | Protection against intentional misuse using more specialised skills and resources |
| SL 4 | Protection against highly capable attackers with significant resources |
Questions to answer
- What would happen if this system was unavailable?
- What would happen if the system was manipulated?
- What would happen if data from the system was exposed?
- Is the system safety-related?
- Is the system connected to corporate IT?
- Is remote access provided?
- Are third-party vendors involved?
- Is the system part of critical infrastructure?
- What is the expected threat environment?
- What level of security can the selected products actually support?
An SL-T target is only useful if it can be designed, implemented, tested, and evidenced.
A project should avoid setting high security targets without considering
- product limitations
- legacy equipment
- operational constraints
- maintenance requirements
- cost and programme impact
- available evidence
- testing capability
Understand the foundational requirements
IEC 62443-3-3 defines seven foundational requirements.
These provide a useful structure for reviewing security controls.
| Foundational Requirement | Practical meaning |
|---|---|
| FR1 Identification and authentication control | Confirming who or what is accessing the system |
| FR2 Use control | Controlling what authorised users and systems can do |
| FR3 System integrity | Protecting systems from unauthorised change or corruption |
| FR4 Data confidentiality | Protecting sensitive data from unauthorised disclosure |
| FR5 Restricted data flow | Controlling communication paths and segmentation |
| FR6 Timely response to events | Detecting, logging, and responding to cybersecurity events |
| FR7 Resource availability | Maintaining system availability and resilience |
How to use them in a project
- design review questions
- vendor questionnaires
- procurement requirements
- FAT cybersecurity checks
- SAT cybersecurity checks
- evidence matrices
- gap assessments
- hardening reviews
Prepare for cybersecurity risk assessment
IEC 62443 risk assessment should be practical, evidence-based, and tied to the defined SuC.
A typical process includes:
- 1define the SuC
- 2identify assets
- 3identify threats
- 4identify vulnerabilities
- 5assess likelihood
- 6assess consequence
- 7evaluate risk
- 8define risk treatment
- 9agree security requirements
- 10verify implemented controls
Inputs required
- asset inventory
- network drawings
- system architecture
- data flow diagrams
- operational context
- remote access details
- user and role information
- backup and recovery arrangements
- patching and antivirus approach
- known vulnerabilities
- previous audit findings
- incident history
- safety and operational consequence information
Output should include
- clear scope statement
- list of assessed assets and interfaces
- risk scenarios
- risk ratings
- recommended mitigations
- assigned actions
- owners and due dates
- link to security levels or security requirements
- evidence required for closure
Risk assessment should not end as a static document. It should drive design changes, implementation work, and verification.
Connect IEC 62443 to project delivery
IEC 62443 should be introduced early in the project lifecycle.
Late cybersecurity review often causes avoidable rework.
Concept and FEED stage
- define high-level SuC scope
- identify major interfaces
- identify remote access assumptions
- define initial zones and conduits
- identify applicable standards and client requirements
- include cybersecurity in procurement strategy
Detailed design stage
- develop network architecture
- define firewall and routing requirements
- agree user and role model
- define backup and recovery arrangements
- specify logging and monitoring requirements
- review vendor package security
- map requirements to evidence
Build and configuration stage
- harden devices and operating systems
- configure accounts and permissions
- configure firewalls and switches
- apply secure remote access controls
- document backups
- record software and firmware versions
- prepare test procedures
FAT stage
- asset list accuracy
- user account configuration
- password and authentication settings
- firewall rules
- network segmentation
- disabled unused services
- backup and restore process
- antivirus or allowlisting status
- event logging
- remote access controls
- security-relevant alarms
- configuration records
SAT and handover stage
- installed system matches approved design
- site network connections match agreed architecture
- remote access is controlled and documented
- backups are completed and recoverable
- account ownership is transferred correctly
- residual risks are recorded
- cybersecurity actions are closed or formally accepted
- operations team receives required documentation
Build a verification evidence pack
IEC 62443 readiness depends heavily on evidence.
The project team should avoid relying on verbal confirmation where objective records are available.
| Evidence area | Example records |
|---|---|
| Scope | SuC definition, architecture drawings, interface list |
| Assets | asset register, IP schedule, software list, firmware list |
| Segmentation | zones and conduits diagram, firewall rules, switch config |
| Access control | user list, role matrix, account ownership record |
| Remote access | remote access procedure, jump host configuration, approval records |
| Hardening | hardening checklist, disabled services list, baseline configuration |
| Backup and recovery | backup schedule, restore test evidence, recovery procedure |
| Monitoring | log source list, alarm/event records, monitoring configuration |
| Vulnerability management | patch records, vulnerability review, exception register |
| Testing | FAT/SAT test sheets, punch list, action tracker |
| Handover | final documentation pack, residual risk register, acceptance record |
Common gaps found during IEC 62443 readiness reviews
These issues are common because many industrial systems were designed for reliability and availability before cybersecurity was treated as a core engineering requirement.
- unclear SuC boundary
- incomplete asset register
- poor separation between IT and OT networks
- flat control system network
- unmanaged remote access
- shared local administrator accounts
- weak password management
- incomplete backup evidence
- no restore test evidence
- undocumented vendor connections
- outdated drawings
- unclear firewall ownership
- limited logging
- missing patch and vulnerability process
- cybersecurity not included in FAT/SAT
- no formal residual risk acceptance
Readiness checklist
First agree the applicable requirements, lifecycle stage, system boundary and responsible organisations. These are original preparation prompts for industrial control system projects, not IEC clauses or a compliance test.
For each row record a status (evidence available, incomplete, not reviewed, or not applicable with a reason), evidence reference, owner and next action. A document being available does not establish that a control is effective. Keep working records in your approved project system, not in a public enquiry form.
| Area | Preparation check | Example evidence |
|---|---|---|
| System under consideration | Agree purpose, boundary, interfaces and exclusions. | Scope record and boundary drawing. |
| Assets and interfaces | Identify equipment, software, owners and required connections; mark unknowns. | Asset inventory and interface register with sources. |
| Zones and conduits | Record why assets are grouped and which inter-zone flows are required. | Zone model, flow register and assumptions. |
| Cybersecurity risk assessment | Record method, operating consequences, controls and remaining assessment work. | Risk register and workshop record. |
| SL-T decisions | Link target security level decisions to risk assessment, rather than selecting a blanket level. | Decision rationale by zone/conduit. |
| Cybersecurity requirements | Trace applicable requirements to responsibilities, design and verification. | Requirements and evidence matrix with applicability reasons. |
| Supplier responsibilities | Agree who provides, reviews and accepts evidence. | Responsibility matrix and supplier evidence request. |
| Remote access | Identify support routes, account owners, approvals and access removal. | Access-path register and support procedure. |
| Account management | Review roles, privileged access and shared-account constraints. | Role/account review and exceptions, without passwords. |
| Backup and recovery | Confirm backup scope and how restoration will be demonstrated safely. | Restore-test record or scheduled test action. |
| FAT evidence | Agree factory checks, expected results, configuration baseline and limitations. | Traceable FAT procedures, results and evidence references. |
| SAT evidence | Identify checks requiring installed interfaces or site conditions and safe test constraints. | SAT plan, results and deferred checks. |
| Handover evidence | Check that the receiving team can use the final records and maintain controls. | As-built records, operating procedures and handover review. |
| Assumptions | Identify decisions based on incomplete information and how to verify them. | Assumption owner, verification method and due stage. |
| Deviations | Record departures from agreed requirements and the decision authority. | Deviation rationale and residual-risk review. |
| Outstanding actions | Assign an owner, due date/stage and closure evidence. | Prioritised action register and closure review. |
For example, a PLC upgrade may have a network drawing and supplier FAT results, but no evidence of site recovery testing. Review the drawing and FAT coverage separately and assign the recovery demonstration to an agreed SAT or operational test stage. Do not mark the whole system ready because one supplier test passed.
This checklist does not prove IEC 62443 compliance or certification, replace a detailed risk assessment, or authorise intrusive testing on a live system.
Practical implementation roadmap
A realistic IEC 62443 readiness roadmap may look like this:
- 1define the SuC
- 2gather architecture and asset evidence
- 3identify zones, conduits, and trust boundaries
- 4review remote access and third-party interfaces
- 5perform risk assessment
- 6agree SL-T expectations
- 7map requirements to design controls
- 8implement hardening, segmentation, access control, and backup controls
- 9verify controls during FAT and SAT
- 10close or accept residual risks
- 11maintain records through operation and future change
Key takeaway
IEC 62443 readiness is mainly about clarity, evidence, and risk-based engineering.
A project team should be able to show
- what system is in scope
- which assets and interfaces matter
- how the system is segmented
- what security level is being targeted
- what controls are required
- how those controls will be verified
- what evidence proves the system has been implemented as intended
The earlier this work starts, the easier it is to avoid late rework and produce a defensible cybersecurity assurance pack.
Related support and guidance
Related services
Start here if you are unsure what applies or where to begin. Establish the boundary, applicable lifecycle context, available evidence and next engineering work before a detailed IEC 62443 assessment or project decision.
Choose this when you need a detailed view against agreed requirements. Requirement-by-requirement review of current arrangements and evidence against an agreed IEC 62443 baseline, producing a classified gap register and remediation roadmap.
Need an independent readiness review?
Meridian can review the system boundary, applicable lifecycle context and available evidence, then record the gaps and next engineering actions.