IEC 62443-2-1 Clause 5 – Conformance and Assessment | Automation Engineering Body of Knowledge

ISA/IEC 62443-2-1:2024 Clause 5 explains what it means for an asset owner (and related roles) to claim conformance with Security Program requirements, how assessment measures that claim, what evidence typically looks like, and how risk evaluation and profiles shape which requirements are assessed.

5.1 Overview – conformance versus assessment

Reference: ISA/IEC 62443-2-1, Clause 5.1

Formal vocabulary for conformance, conformity and assessment comes from sources such as ISO/IEC 17000. The ISA/IEC 62443 series adds role-specific guidance so asset owners, service providers and product suppliers understand how assessment works in this series. That guidance does not replace ISO/IEC 17000 definitions.

Teaching definitions (aligned with Clause 5.1)

Conformance / conformity — the role has evaluated the applicable requirements, applied and documented the corresponding methods where they apply, mitigated associated security risks, and can show conformity of the identified processes with supporting evidence.
Assessment — the role has measured that conformity through verification and/or validation (internal or through a third-party process aligned with the series), again backed by evidence.

Conformity assessments may be self-assessments by the asset owner, service provider or product supplier, or assessments by a qualified independent third party. How third parties are credentialled varies widely and is out of scope for Part 2-1. The detailed design of assessment processes themselves is also out of scope.

How Part 2-1 assessment sits with other series assessments

Asset owners may combine several complementary pictures:

As-deployed control systems / IACS / Automation Solutions against ISA/IEC 62443-3-3 — conformance at the time of assessment.
As-provided integration and maintenance services against IEC 62443-2-4 — conformance when those services were provided.
Evaluations that combine Security Levels with organisational Maturity Levels to describe composite SP protection for the IACS.
Assessment of the IACS / Automation Solution against Part 2-1 itself — verifying that an SP exists to sustain security posture, covering both technical components and organisational processes.

Using security-certified products, correctly installed and maintained by capable service providers, strengthens that picture — it does not replace the asset-owner SP. Product suppliers may pursue assessment against 3-3 / 4-1 / 4-2; service providers against 2-4.

5.2 Conformity evidence (Table 2)

Reference: ISA/IEC 62443-2-1, Clause 5.2 and Table 2

Proof can take many forms. Most requirements point assessors toward methods such as verifying technology use, capability and configuration; checking supporting processes; and validating capabilities through testing.

Typical evidence families (teaching paraphrase of Table 2 themes) include:

Evidence family	Examples used in teaching / assessment
As-built & config records	Inventories, settings exports, patch status, similar live-system facts.
Agreements & legal papers	Contracts, subcontractor terms, signed statements, screening records, approvals.
People & roles	Org charts, job descriptions, assignment history for IACS-related duties.
Product information	Design notes, datasheets, knowledge articles, scan-tool docs.
UI captures	Screenshots showing configured behaviour.
Security assessment outputs	Risk, incident and vulnerability reports.
Security test packs	Test plans/results proving security properties of a product or installed system.
Service ways of working	How staff install, harden and maintain the Automation Solution.
Activity records	Checklists, threat models, architecture drawings, spreadsheets of review results.
System-generated reports	Automatic reports produced by the IACS.
Training design	Syllabi and course outlines showing what was taught.
Training attendance	Rosters, certificates or HR records of who completed which course and when.
User-facing docs	Manuals and instructions for operating and maintaining the IACS.
Independent test results	Tests by suitably trained people on a known configuration that verify specific expectations.

Remember: from ML 2 upward, process documentation is already part of the maturity claim (see Maturity Levels). Assessment still expects you to state whether each requirement is met and at which ML.

5.3 Requirements evaluation and profiles

Reference: ISA/IEC 62443-2-1, Clause 5.3

5.3.1 Overview – applicability and justification

Before a conformance assessment, the asset owner evaluates each applicable requirement for how it guides mitigation of the risk that requirement addresses. If a requirement is judged not to apply, the owner must justify that decision and provide evidence showing specifically why it does not apply and how the related security risk is otherwise mitigated (or already managed to a tolerable level).

5.3.2 Evaluation of risk to requirements

Which cybersecurity risks need mitigating is normally decided in the asset owner’s risk management process aligned with ISA/IEC 62443-3-2 (including risk-response ideas from 62443-1-1 / 3-2). Completing that risk work remains critical to IACS security even when no formal conformance assessment is run.

Requirements apply where identified risks must be driven to a tolerable level.
They may not apply where evidence shows the risk is already tolerable without that control.
Meeting a requirement means the associated risks have been mitigated or accepted — with supporting evidence. If the owner is not prepared to accept residual risk, the requirement is not met.

5.3.3 Profiles

Industries and verticals may need a common subset and wording of 62443 requirements. IEC TS 62443-1-5 describes how to create a security profile: select requirements from one or more series parts, map them to sector context, and optionally set minimum security or maturity levels. Published profiles give a comparable basis for assessment.

5.3.4 Selecting what the asset owner assesses

In practice, owners prepare for conformity assessment by selecting requirements via:

a security profile they claim against; or
the outcome of an IACS-specific cybersecurity risk assessment that identifies which requirements are needed to reach tolerable risk.

A requirement may be out of scope simply because the live system has no such technology (for example no wireless or no safety instrumented system addressed by that requirement). Risk management stays essential whether or not assessment proceeds.

Key takeaways

Conformity is evaluated, applied, documented practice with evidence; assessment measures that claim.
Self-assessment or independent assessment are both allowed; credentialling and process design detail sit outside Part 2-1.
Part 2-1 assessment verifies an SP that sustains posture; pair it with 3-3 / 2-4 / product assessments and ML+SL composite views where useful.
Table 2 catalogues typical evidence families (config, legal, people, product, tests, training, etc.).
Non-applicable requirements need justified, evidenced risk treatment; profiles (1-5) enable sector-comparable subset assessment.

IEC 62443-2-1 Clause 5 – Conformance and Assessment