IEC 62443-3-2 Clause 4.7 – Document Requirements, Assumptions and Constraints

Living documentation and control

If assessment steps are not documented, there is nothing to verify, audit or prove. CRS and related assessment artefacts should be revised, amended, reviewed and approved, and held under a control scheme because they contain sensitive security information. They are living documents: when a zone or the SuC changes, related records must be updated.

Review risk-assessment documentation at least once a year, and also when significant SuC or geopolitical changes occur. Typical change triggers include:

• New policies or procedures → revisit the initial risk assessment
• New NVD entries or vendor advisories → update the Vulnerability Assessment Report; newly found vulnerabilities must be risk-assessed
• New threat intelligence → reassess affected threats (Threats)
• Like-for-like replacements → update asset inventory (MAC addresses, firmware versions)
• Patches → update the Cybersecurity Risk Assessment Report

See the full catalogue on Documentation.

Requirements in this ZCR

• ZCR 6.1 – Cybersecurity requirements specification (Clause 4.7.2)
• ZCR 6.2 – SUC description (Clause 4.7.3)
• ZCR 6.3 – Zone and conduit drawings (Clause 4.7.4)
• ZCR 6.4 – Zone and conduit characteristics (Clause 4.7.5)
• ZCR 6.5 – Operating environment assumptions (Clause 4.7.6)
• ZCR 6.6 – Threat environment (Clause 4.7.7)
• ZCR 6.7 – Organizational security policies (Clause 4.7.8)
• ZCR 6.8 – Tolerable risk (Clause 4.7.9)
• ZCR 6.9 – Regulatory requirements (Clause 4.7.10)

ZCR 6 – Document cybersecurity requirements, assumptions and constraints

Reference: ISA/IEC 62443-3-2, Clause 4.7

ZCR 6.1: Cybersecurity requirements specification

Clause: 4.7.2

Clear documentation keeps owners, integrators and suppliers working from the same target. ISA technical reports on related CRS content can supplement — they do not replace the minimum list in Part 3-2.

In practice the CRS is often a set of controlled spreadsheets or databases rather than one monolithic file — still assign information-security classification and access control. Grouping requirements aids readability, for example:

• Access control — identification and authentication of users; user roles and privileges; user administration
• Confidentiality, integrity and availability — grouped CIA requirements
• Monitoring and reporting — detection, logging and reporting expectations

Course materials also describe CRS content by themes such as scope and purpose of the system, physical and environmental security, general cybersecurity requirements, and zone/conduit-specific requirements — map those themes to ZCR 6.2–6.9 rather than treating them as a separate normative list.

At a minimum a CRS includes: a description of the system under consideration; zone and conduit drawings; zone and conduit characteristics; operating environment assumptions; threat environment; organisational security policies; tolerable risk; and regulatory requirements. It does not need to be a single document — spreadsheets and databases are common when controlled.

The CRS is the primary input to conceptual design and to the Develop & Implement phase of the automation solution security lifecycle. It typically carries assigned target security levels (SL-T) that design and implementation must meet (see Part 3-3 Security Levels). Downstream design teaching: Zone and Conduit Security Strategy | Conceptual Design Specification.

ZCR 6.2: SUC description

Clause: 4.7.3

A practical CRS checklist for the SuC description includes:

• Name
• High-level description
• Intended usage
• Architecture diagrams
• Network diagrams
• Security perimeter and access points
• System inventory
• Data flows
• Process flows

Preparation evidence on Prepare for an Assessment and the perimeter work in ZCR 1 feed this CRS section.

ZCR 6.3: Zone and conduit drawings

Clause: 4.7.4

ZCR 6.4: Zone and conduit characteristics

Clause: 4.7.5

Those fields exist for design, accountability and monitoring: they mark who owns the partition, where traffic enters, what would be lost if it fails, which SL-T and policies apply, and what outside factors (power, outer networks, physical layers) the design assumes. Final security-requirement lists typically wait until the detailed assessment in ZCR 5 is complete.

Characteristics checklist (every zone and conduit):

• Unique name / identifier
• Accountable organisation(s)
• Logical boundary (and physical boundary where applicable)
• Safety designation (e.g. safety-related vs non-safety)
• Logical and physical access points
• Data flows at each access point
• Connected zones and conduits
• Assets with classification, criticality and business value
• Target Security Level (SL-T)
• Applicable security requirements and policies
• Assumptions and external dependencies

Confirm your organisation has these characteristics documented for every zone and conduit before treating the CRS as complete for design hand-off.

ZCR 6.5: Operating environment assumptions

Clause: 4.7.6

ZCR 6.6: Threat environment

Clause: 4.7.7

Document threat sources, threat vectors, and the geo-political and physical environment. Cite where threat intelligence comes from — examples include:

• Cybersecurity & Infrastructure Security Agency (CISA)
• European Union Agency for Cybersecurity (ENISA)
• Local government agencies
• IACS product suppliers
• Anti-malware vendors
• Industry advisory groups (and related CERT / ISAC feeds)

Teaching depth on sources, capability and vectors: Threats.

ZCR 6.7: Organizational security policies

Clause: 4.7.8

ZCR 6.8: Tolerable risk

Clause: 4.7.9

ZCR 6.9: Regulatory requirements

Clause: 4.7.10

Key Takeaways

• The CRS is the design hand-off from risk assessment into build and buy decisions.
• Minimum CRS content spans SUC description through policies, tolerable risk and regulation.
• Every zone/conduit needs a characterised record — not only a coloured box on a diagram.
• Keep CRS and related reports under a control scheme; review at least yearly and on significant change.