IEC 62443-3-2 – Prepare for an Assessment

Objectives

Preparation succeeds when the team can:

1. Understand the system within the agreed scope (SuC + industrial process + environment).
2. Visualise credible consequences and evaluate associated cybersecurity risk.
3. Make informed risk-treatment decisions against the asset owner’s risk appetite and constraints.

Applies to future systems (engineering stages — mainly documentation) and existing systems (running plant — documentation, tools, and walkthrough).

Step 1 – Treat the assessment as a project

Plan timeline, deliverables, constraints, assumptions, and boundaries up front. Scope defines what is assessed and how the work will be performed.

1.1 Define scope

1. Identify requirements — what the assessment must answer (e.g. support zone/conduit design, meet regulation, refresh the security-program risk view).
2. Specify devices / systems in scope — provisional SuC boundary; equally important: what is out of scope.
3. Select collection methods — documentation analysis, automated discovery (only where safe), site walkthrough / interviews.
4. Document the plan — constraints, assumptions, boundaries, roles, schedule, and expected outputs.

1.2 Context to capture early

• Current cybersecurity practices and procedures
• Provisional SuC
• Industrial processes being controlled (safety, quality, availability drivers)
• Environment and other factors that affect risk appetite (regulation, exposure) — at a level needed for assessment design, not a full threat study yet

Step 2 – Assemble the necessary information package

Before fieldwork or detailed scoring, lock down:

1. Goals of the risk assessment — written and agreed.
2. IACS and associated assets — start the asset model / inventory (see Step 4).
3. Project-specific constraints — regulations, corporate policies, tolerable residual risk expectations.
4. Organised evidence — architectures, device lists, configurations, known vulnerabilities, process/data-flow views.
5. Roles and responsibilities — who owns the SuC, who collects data, who decides risk acceptance (see Roles; Part 2-1 expects risk-assessment methodology, roles, and training to be defined).
6. Training requirements — assessors understand OT process risk, not only IT scanning.

Step 3 – Build the diagram and flow evidence set

If drawings do not exist (common on older sites), recreate them. Incomplete diagrams are a preparation deliverable, not an excuse to skip scope.

3.1 System architecture diagrams

• Show components, physical locations, and connectivity.
• Every IACS hardware element should appear on at least one architecture drawing.
• Prefer layout aligned to the ISA/IEC 62443 Reference Model (ISA-95 levels).
• Where possible, use photos of actual components rather than generic icons.
• Colour-code or vary line types by network / segment; include a legend.

3.1.1 Label architecture with zones and conduits

Architecture drawings start as equipment, locations and connectivity. Before the detailed risk workshop, overlay the ZCR 3 security model so the team can see partitions and conduits on the same picture:

1. Mark the SUC perimeter and every access point that crosses it (aligns with ZCR 1).
2. Draw closed boundaries around asset groups that share security requirements — zones (business vs IACS, safety, temporary/mobile, wireless, remote access as required by ZCR 3.2–3.6).
3. Name each conduit between zones (and to external networks): what traffic is allowed, which devices realise the conduit (firewall, DMZ host, wireless AP, VPN), and what fails if that path is lost.
4. Keep the labelled drawing with the Cybersecurity Requirements Specification evidence — zone drawings and conduit descriptions are expected under ZCR 6 (for example ZCR 6.3).

3.2 Network diagrams (physical and logical)

• Individual routers, switches, firewalls, and peer relationships
• Media types (Ethernet, serial, wireless), speeds and standards where relevant
• Switch port assignments and ACLs / access control intent
• VLANs — membership and how traffic is managed between them
• Hosts attached to each network device
• Detail matters: everything in scope must be protectable, so everything should be visible

3.3 Supporting views

• Process flow
• Data flow
• Business / operating processes that the SuC supports

Multiple documents may be needed; some may be outdated. Creating or correcting them is part of preparation, not a side task.

Step 4 – Build the asset inventory

Maintain a list/database of IACS/SCADA hardware (physical and virtual) and software. Classify components using the ISA/IEC 62443 types:

• Host devices
• Embedded devices
• Network devices
• Software applications (including OS, applications, databases, firmware as subclasses)

See Part 4-2 Annex A for category examples and Part 2-1 CM 1.1 for the ongoing inventory baseline expectation. Different types present different security challenges; mitigating assets (firewalls, AV, SIS, alarm systems, etc.) deserve explicit flags.

4.1 Hardware attributes (minimum useful set)

• Device / system name, Asset ID, device type, function
• Network interfaces and addresses
• Manufacturer, model, serial number
• Operating system / firmware version
• Responsible organisation / individual
• Physical location
• Notes / comments

4.2 Virtual hardware attributes

• VM name, VM type, function
• Network interface and address
• Host name / ID and host type
• OS and version
• Responsible organisation / individual; custodian (administrator)
• Notes / comments

4.3 Software attributes

• Name; type (OS, application, database, firmware, …); function
• Host name and host type (physical/virtual, workstation, controller, …)
• Vendor and version
• Responsible organisation / individual
• Licence information: count, location, expiration
• Update / patch process

4.4 Inventory sources (complementary — not substitutes)

Combined approach: use all three for existing systems. For systems still in engineering, lean on documentation so security is designed in before start-up.

Step 5 – Criticality assessment

A cyber criticality assessment ranks how important each device or grouping is to the corporation and to the industrial process (safety, environment, production, quality, compliance). It is not the full likelihood × consequence risk score — it prioritises where understanding and protection effort must concentrate when the SuC is large.

Record criticality against inventory items (or logical groups) so later zone partitioning and detailed assessment can focus proportionate effort.

Step 6 – Site walkthrough and physical security review

For installed systems, schedule a facility walkthrough to:

• Visually inspect installations and operating environment
• Compare drawings against reality
• Review physical security posture relevant to cyber risk
• Interview operations / maintenance personnel
• Discover assets missed by scans and documents (disconnected, isolated, underestimated)

Plant distances and real operating constraints are rarely visible from a laptop. Treat the walkthrough as discovery for understanding, not a checklist formality.

Step 7 – Preparing the detailed (ZCR 5) workshop

Once zones and conduits are defined and a detailed assessment is required (ZCR 4), treat the detailed workshop as its own facilitation exercise — in addition to the SuC evidence package above. Three tasks matter most:

7.1 Schedule a facilitator

Effective workshops are led by someone with a degree of independence from the design and operation of the control system, control networks and related IT systems, and with specialty training for leading cyber risk assessments. Work with that facilitator to estimate duration before calendars lock in.

7.2 Establish the team

Include people with the skills and attitudes that produce sound recommendations:

• Facilitator trained in cyber risk assessment
• Scribe trained on the recording tool or worksheets in use
• Automation / controls engineer(s)
• Network engineer(s)
• Cybersecurity subject-matter expert
• Process safety subject-matter expert
• Operator(s) experienced with the process under consideration

Part 2-1 expects security roles and responsibility training to be defined in advance — see SP and Risk Assessment and Roles.

7.3 Prepare workshop materials

Required:

• Network diagrams
• System architecture diagrams
• Previously conducted vulnerability assessments

Optional (strongly useful when available):

• Previous Process Hazard Analyses (PHAs) for processes controlled by the system
• Data-flow diagrams
• Control-system inventory lists
• Process Flow Diagrams (PFDs)

Step 8 – Freeze the package and enter Clause 4

Exit criteria for “ready to assess”:

• Written goals, in/out scope, constraints, assumptions
• Roles, responsibilities, and training confirmed
• Architecture + network (+ process/data flow) diagrams adequate for SuC definition
• Classified inventory with criticality flags
• Discovery method record (docs / tools / walkthrough) and known gaps
• For detailed workshops: facilitator, team roster and materials ready

Continue with Clause 4, starting at ZCR 1 – Identify the SUC (confirm perimeter and access points from this evidence), then initial / detailed risk assessment (ZCR 2 onward).

Key Takeaways

• Treat the assessment as a project: scope (including out-of-scope), methods, roles, and training first.
• Architecture, network, process, and data-flow diagrams plus a classified inventory are the core SuC evidence set.
• Label architecture drawings with zones, conduits, perimeter and access points before the detailed workshop.
• Documentation, safe automated discovery, and walkthroughs are complementary — not substitutes.
• Cyber criticality ranks importance; it is not the full risk score.
• Detailed (ZCR 5) workshops need an independent trained facilitator, a cross-functional team and prepared diagrams/VA packages.
• This preparation is the practical path to ZCR 1; Clause 4 then carries the normative risk workflow.

Cybersecurity vulnerability assessment types

A cybersecurity vulnerability assessment (CVA) identifies and classifies security weaknesses in the IACS and related networks. Choose the type based on invasiveness, cost and risk to a live process: