On this page
- Choose the correct published document
- What Part 3-2 addresses
- Define the assessment deliverable
- Example: adding remote maintenance to a production line
- Keep system assessment and product development distinct
- Common buying questions
- Primary sources and edition check
- Explore more standards buying guides
The verified European product is EN IEC 62443-3-2:2020. Genorma identifies it as published and confirmed in July 2026; IEC identifies the international base as IEC 62443-3-2:2020, edition 1.0. A confirmation date does not change the edition year in the purchase reference. European catalogue record; IEC base publication.
Choose the correct published document
EN IEC 62443-3-2:2020 — Security risk assessment for system design
The link below opens the exact published catalogue product named here.
Confirm the final price, taxes, available language, delivery format and permitted users at the merchant checkout. No fixed price is quoted here.
What Part 3-2 addresses
The public scope covers defining the industrial automation and control system under consideration, organising it into zones and conduits, assessing their risks, establishing target security levels and documenting security requirements. IEC published scope.
For procurement, ask the provider what inputs it needs to perform that work. The system boundary, operating context, connections and responsibilities must be understood before an assessment can describe the required design response. A quotation based only on a network diagram may need further discovery before it can address the whole proposed system.
Define the assessment deliverable
| Purchasing issue | Question for the assessor or designer |
|---|---|
| System boundary | Which equipment, services and connections are included and excluded? |
| Operating context | What operation, maintenance and remote-access arrangements will be examined? |
| Zones and conduits | How will the proposed grouping and connections be recorded and explained? |
| Risk and targets | What assumptions support the proposed requirements and target levels? |
| Handover | Who receives the documented requirements and acts on them during design? |
Ask how the final output will be usable by the design team. A presentation of findings can be useful, but the buyer may also need a record linking the defined system, assumptions and proposed requirements. Make that expected handover visible in the request for quotation so bidders describe comparable work.
Example: adding remote maintenance to a production line
Imagine a factory buying remote-maintenance capability for an existing production line. One bidder proposes a gateway installation. Another proposes a system-design security assessment before selecting the connection arrangement. The buyer should decide whether it is procuring a component, an integration service, an assessment or a combination.
A useful brief could name the systems the remote service will reach, the people who can use it and the intended operating arrangements. It could ask who owns the assessment assumptions and who will carry the resulting requirements into the design. If the line includes several suppliers’ equipment, identify the information needed from each. This is a hypothetical purchasing exercise, not a network design or a conclusion about an acceptable security level.
Keep system assessment and product development distinct
For the product developer’s secure development process, see EN IEC 62443-4-1. For an organisational ISMS, see EN ISO/IEC 27001. For cloud-service guidance, see ISO/IEC 27017. Choose the scope that matches the work rather than treating the shared word “security” as equivalence.
A target for system design and evidence about a supplied component are different questions to put in the brief. Ask the supplier what its evidence covers and how it relates to the proposed assessment boundary. Do not assume a product-level claim completes the assessment of every connection and operating arrangement in the installation.
- Identify the agreed European 2020 publication or international base in the order.
- Provide current boundary and interface information, or commission the discovery work explicitly.
- Separate assessment, design, installation and continuing support in the quotation.
- Name the recipient and owner of the documented security requirements.
- Check permitted access for the engineers, asset owners and assessors consulting the text.
Common buying questions
Is the 2026 confirmation a new 2026 edition?
No. Genorma retains the published reference EN IEC 62443-3-2:2020 and reports a confirmation stage in 2026. Copy the actual edition designation rather than changing the year.
Does this buy a security certificate for a component?
The publication’s scope is the system-design risk assessment. If component evaluation or certification is part of your purchase, specify the separate task, basis and claimed boundary.
Is this an assessment of functional safety?
Its scope is cybersecurity for industrial automation and control systems. Keep any separate functional-safety assessment and its evidence visible in the engineering brief; do not merge the two merely because both concern risk.
Primary sources and edition check
Publication and purchase records checked on 7 October 2026. The examples and procurement questions are original guidance. Detailed implementation requires the applicable licensed text and decisions for the actual project.
Explore more standards buying guides
Browse standards by reference and subject to compare related document choices.
Editorial information
How this page is maintained
No documented technical review of this version is recorded. Sources and an update date are not a conformity assessment.
Scope: Industrial automation and control-system security risk assessment for system design, with system boundaries, zones/conduits and requirements handover.
View registered primary sources
Keep this guide useful
Your reading list and topic feeds
Saves stay on this browser. Feeds cover guidance on this website, not every change to a standard.