← Home

IEC 62443-3-2 – Documentation

A cybersecurity risk assessment is only as useful as the records that support it. A common teaching mantra is: if you did not document it, you did not do it — without records there is nothing to verify, audit or prove. Assessment outputs feed design through the Cybersecurity Requirements Specification (CRS) and must sit under a control scheme (revise, amend, review, approve, and restrict access to sensitive security information).

These are living documents. Zone or SuC changes, new policies, new threat or vulnerability information, patches and like-for-like asset replacements all drive updates. Review risk-assessment documentation at least once a year, and sooner when the SuC or geopolitical situation changes significantly.

Teaching note: Paraphrased for learning from IACS risk-assessment practice and related ISA/IEC 62443 concepts (especially Part 3-2 Clause 4 / ZCR 5–7). Not a verbatim extract of the standard — always refer to published text for normative wording.

Reference: ISA/IEC 62443-3-2:2020, Clauses 4.6.14 and 4.7–4.8
Related: Prepare for an Assessment | Cyber Risk Concepts | Clause 4 – Zone, Conduit and Risk Assessment | ZCR 5.13 – Document results | ZCR 6 – CRS | ZCR 7 – Asset Owner Approval | Automation Solution Security Lifecycle

Document catalogue

The table lists documents typically created or maintained through Part 3-2 preparation, assessment and CRS hand-off. Each name links to the AEBOK page that explains it in depth.

Document Purpose Should entail
System architecture diagrams
Also ZCR 1 – Identify the SUC 		Depict the System under Consideration so scope, perimeter and connectivity are shared and auditable.
  • IACS components, physical locations and connectivity
  • Security perimeter and access points
  • Every in-scope hardware element on at least one drawing
  • Legend for networks / segments; keep under change control
Network diagrams Show physical and logical network structure used for zoning, conduits and vulnerability discovery.
  • Routers, switches, firewalls and peer relationships
  • Media types, VLANs, ACLs / access intent
  • Hosts attached to each network device
  • Enough detail that everything in scope is visible and protectable
Asset / system inventory
Also Part 2-1 Configuration Management 		Maintain a classified list of IACS hardware and software that underpins risk, zoning and CRS asset records.
  • Host, embedded, network and software application types
  • Identity attributes (name, ID, vendor, model, versions, location, owner)
  • Network interfaces and addresses
  • Update on like-for-like swaps (new MAC / firmware) and patch events
Data-flow and process-flow diagrams Explain what moves where and which industrial process the SuC supports — essential for consequence thinking.
  • Process flow for the controlled plant or unit
  • Data flows between systems and across access points
  • Business / operating processes the SuC supports
Initial cybersecurity risk assessment Establish worst-case unmitigated risk for the whole SuC and decide whether detailed assessment is required.
  • Scope covering the entire SuC
  • Worst-case financial and HSE consequences if the IACS is compromised
  • Team with process knowledge; reuse PHA / prior CRA where applicable
  • Comparison input for ZCR 4
Vulnerability Assessment Report Record discovered weaknesses so they can feed detailed risk assessment and later refresh.
  • Scope; as-found system architecture
  • Dates, location, participants and assessment process
  • Prioritized findings by class (assets, policy/procedure, architecture/design, configuration/maintenance, physical, software, communication/network)
Cybersecurity Risk Assessment Report Provide the risk profile and recommendations from detailed (zone/conduit) assessment.
  • Scope; dates, locations and participants
  • High-risk threats and vulnerabilities; detailed worksheets
  • How likelihood and consequence were determined
  • Prioritized recommendations; protect with information-security classification
Zone and conduit drawings
Also ZCR 6.3 		Show security partitioning for the whole SuC and assign every asset to a zone or conduit.
  • Zones and named conduits across the SuC
  • Every asset assigned to a partition
  • Alignment with labelled architecture / network drawings
Cybersecurity Requirements Specification (CRS) Hand off mandatory countermeasures and general security requirements into Develop & Implement (with SL-T).
  • Mandatory security countermeasures from detailed risk assessment
  • Policy, standards and regulatory requirements
  • Minimum content of ZCR 6.2–6.9 (may be multiple controlled files or databases)
  • Assigned SL-T for design; see automation solution lifecycle
SUC description (CRS) Give designers a shared high-level picture of what is being protected.
  • Name, high-level description, intended usage
  • Architecture and network diagrams
  • Security perimeter and access points
  • System inventory; data flows and process flows
Zone and conduit characteristics (CRS) Characterise each partition beyond a coloured box — ownership, boundaries, SL-T and dependencies.
  • Unique name/ID; accountable organisation(s)
  • Logical / physical boundaries; safety designation
  • Access points and data flows; connected zones/conduits
  • Assets (classification, criticality, business value); SL-T; policies; assumptions and external dependencies
Operating environment assumptions (CRS) Record the physical and logical context the design relies on.
  • Site layout, rooms, cabling, site security plans
  • Networks, protocols and interfacing OT/IT systems
  • Supporting utilities and safety systems that shape the operating context
Threat environment (CRS)
Also Threats 		Describe current and emerging threats that affect the SuC, with cited intelligence sources.
  • Threat sources and threat vectors
  • Geo-political and physical environment
  • Named intelligence sources (e.g. CISA, ENISA, local government, IACS suppliers, anti-malware vendors, industry advisory groups)
Organizational security policies (CRS) Carry organisation policy expectations into the design package so they are not lost.
  • Countermeasures and features that implement organisational security policies
  • Baseline policy requirements applicable to the SuC
Tolerable risk statement (CRS)
Also ZCR 4 – Risk Comparison 		State the acceptance bar used for initial and residual risk comparisons.
  • Organisation’s tolerable risk for the SuC
  • Consistent with the corporate risk matrix / appetite used in ZCR 4 and ZCR 5
Regulatory requirements (CRS) Ensure applicable cybersecurity compliance obligations travel with the design package.
  • Cybersecurity regulatory requirements that apply to the SuC
  • Traceability from obligation to CRS content
Asset owner approval record Record accountable management review and approval of assessment results and CRS intent.
  • Review by management accountable for process safety, integrity and reliability
  • Approval of risk assessment outcomes (and CRS as design intent)
  • Clear separation of workshop facilitation from risk-acceptance authority
Living documentation: Keep these artefacts under a document control scheme. Examples of change triggers include new policies or procedures (initial risk), new NVD or vendor vulnerability information (VA report), new threat intelligence (reassess), like-for-like replacements (inventory MAC/firmware), and patches (risk assessment report). Review at least annually and after significant SuC or geopolitical change.

Key Takeaways