CUP FIELD TOOLS · IEC 62443 system assurance

A system change is planned. What remains unproven?

Review one industrial system or change, with a defined operational boundary. Identify which requirements and responsibilities apply, then connect the installed configuration to evidence and open actions.

12 chapters · 36 detailed verifications · Initial and detailed review modes · No account required

Start the evidence review →

WHY USE IT?Make the installed-system claim reviewable.

A product certificate or segmentation drawing leaves integration questions unanswered. Organise the risk rationale, implementation evidence and operational handover so the asset owner can see what still needs to be demonstrated.

YOUR REVIEW PATH

Scope → Evidence → Action

A focused review with an accountable outcome.

System boundaryDefine the reviewed scope

Review ↗

Implementation evidenceChallenge the supporting records

Review ↗

Operational acceptanceAssign the unresolved actions

Review ↗

Your exportable action plan

Missing records · Owners · Next steps

Illustrative review flow. Select a checkpoint to explore it.

How to use this review

Bring the right people: asset-owner, integrator, product-supplier, operations and safety roles. Record roles and non-sensitive references.

Define one decision. Record the baseline, applicable basis and accountable owner. Identify uncertain applicability before treating requirements as settled.
Challenge the evidence. Work through twelve questions. Reference existing records, explain what they demonstrate and leave unsupported conclusions open.
Take an action plan to the review. Export a report or CSV, assign owners and dates, and save a review file to update later.

The first pass identifies missing work. It does not complete the underlying assessment, tests or regulatory review. Use “Not applicable” only with a recorded rationale.

SCOPE AND REFERENCE BASIS · REVIEWED 1 NOVEMBER 2026

Agree the basis before relying on the result.

Choose the parts and editions for the actual role and deliverable: asset-owner programme (2-1), service-provider processes (2-4), system design risk assessment and requirements (3-2/3-3), or product development and component capabilities (4-1/4-2). Confirm current editions and contractual scope using the official catalogue and licensed texts. This is an installed-system evidence review, not a clause checklist or security-level calculator.

CUP’s questions are original engineering review prompts, not a reproduction of standard clauses, a complete legal checklist, a certification or legal advice. Record the applicable text, edition, jurisdiction and review date; seek qualified interpretation where needed.

BEFORE YOU START · YOUR DATA

Use references, keep sensitive information in your own systems.

This worksheet runs in your browser. Answer the checkpoints, reference your existing records and export the resulting action plan when you need it.

Saved in this browser · No upload of worksheet entries to CUP · Use non-sensitive references only. Downloaded files contain your entries; check them before sharing.

Read how saving, deletion and exports work

What to enter: fictional or non-sensitive review references, job roles and short action descriptions. For example, “Review record R-042” and “Accountable review owner”.
What to leave out: passwords, keys, tokens, personal data, IP addresses, network diagrams, unpublished vulnerability details, incident details and confidential system, product or supplier information. Keep the evidence itself in your organisation’s approved systems.
Where entries are saved: automatically in this browser profile on this device, when local storage is available. Worksheet entries and imported review files are not uploaded to CUP. There is no account-based backup or synchronisation. Other people using the same profile, and software with access to it, may be able to read them. This is not an encrypted vault.
How to remove them: choose “Clear saved review” in the workspace. Clearing this site’s browser data also removes the local review. Download a copy first if you need to keep it. Browser data can be lost or cleared.
Exports and sharing: downloaded reports, CSV and review files contain your entries and are not encrypted by this tool. Printing or saving a PDF creates another copy. Check every copy before sharing and store it according to your organisation’s rules. Clearing the worksheet does not delete downloads, backups or copies you have shared.

The worksheet supports an evidence review. Your authorised team remains responsible for verifying evidence and deciding the appropriate next decision. See the site privacy notice for information about visiting CUP.

Before design or procurement

Agree the scope, responsibilities and evidence to request before accepting a supplier or solution claim.

Before release or deployment

Check the current baseline and unresolved conditions with the authorised decision owner.

After a material change

Reopen the review when the use, configuration, evidence, legal basis or supporting assumptions change.

Build your action plan →

Twelve evidence checkpoints

Read or print this table without JavaScript. Guided saving and exports require JavaScript. Keep sensitive evidence in approved systems; use non-sensitive references here.

IEC 62443 system assurance · original CUP review prompts
Checkpoint	Evidence to assemble	Decision to resolve	Review notes
01 · System under consideration	System boundary, intended operation, assets, interfaces and lifecycle stage. Detailed verifications (3) Suggested review roles: Asset owner; system architect. Lifecycle: System and change definition. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. System boundary approved Evidence to request: System definition reference. Document only when: Assets and external dependencies are bounded. Operating state described Evidence to request: Operational context record. Document only when: Essential functions and intended operation are explicit. Change scoped Evidence to request: Change-impact record. Document only when: The reviewed modification is distinguished from the entire facility.	Which system and change are being assessed?	Evidence assembled
02 · Roles, parts and editions	Asset-owner, service-provider and product-supplier roles; applicable parts, editions and contractual scope. Detailed verifications (3) Suggested review roles: Asset owner; integrator; product supplier. Lifecycle: Role and contractual scope. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Roles separated Evidence to request: Responsibility register. Document only when: Asset-owner, service-provider and product-supplier roles are identified. Parts and editions selected Evidence to request: Applicability register. Document only when: Selected parts and editions have a role-specific rationale. Deliverables bounded Evidence to request: Contractual assurance scope. Document only when: Product and installed-system claims are distinguished.	Which requirements apply to which party and deliverable?	Evidence assembled
03 · Risk and operational consequences	Risk assessment, process and safety dependencies, credible threat paths and treatment owners. Detailed verifications (3) Suggested review roles: Risk assessor; operations/safety owner. Lifecycle: Consequence and threat assessment. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Operational harm examined Evidence to request: Consequence assessment. Document only when: Relevant process and safety effects inform the review. Threat paths considered Evidence to request: Threat scenario record. Document only when: Credible routes to the consequences are examined. Treatment authority identified Evidence to request: Risk decision reference. Document only when: Residual uncertainty has an accountable owner.	What operational harm drives the security requirements?	Evidence assembled
04 · Zones and conduits	Segmentation rationale, grouped assets, inter-zone flows and documented assumptions. Detailed verifications (3) Suggested review roles: Network/system architect; operations. Lifecycle: Zone/conduit design and review. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Asset grouping justified Evidence to request: Zone rationale. Document only when: Grouping follows assessed risks and operational constraints. Conduits described Evidence to request: Flow review reference. Document only when: Relevant communications cross identified boundaries. Shared dependencies reviewed Evidence to request: Dependency assessment. Document only when: Common services do not silently bypass the model.	Do zones and conduits reflect the actual system and its risks?	Evidence assembled
05 · Target security requirements	Risk-derived target requirements, applicable foundational requirements and accepted exceptions. Detailed verifications (3) Suggested review roles: Security architect; asset risk owner. Lifecycle: Target requirement selection. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Target requirements justified Evidence to request: Risk-to-requirement profile. Document only when: The target follows the assessed risks. Foundational requirements considered Evidence to request: Requirement selection record. Document only when: The relevant protection needs and exclusions are explicit. Target and evidence distinguished Evidence to request: Assurance claim review. Document only when: A target is not described as an achieved system result.	What protection is required for each assessed zone and conduit?	Evidence assembled
06 · Implemented boundary controls	Deployed configurations, permitted flows, authentication and authorisation design. Detailed verifications (3) Suggested review roles: Integrator; control/network owners. Lifecycle: Installed-control verification. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Deployed rules matched Evidence to request: Configuration verification. Document only when: Installed controls match the approved design. Authority bounded Evidence to request: Access enforcement review. Document only when: Permissions match the intended operational tasks. Boundary behaviour tested Evidence to request: Approved verification record. Document only when: Results cover alternate routes and rejected actions.	What enforces the required boundaries in the installed baseline?	Evidence assembled
07 · Component and development evidence	Supplier capabilities, product development evidence, supported versions and integration constraints. Detailed verifications (3) Suggested review roles: Product supplier; integrator. Lifecycle: Product capability and integration review. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Capability evidence applicable Evidence to request: Product capability review. Document only when: Evidence covers the actual component version. Development evidence scoped Evidence to request: Supplier development record. Document only when: Its scope and limitations are understood. Integration gap assessed Evidence to request: Integrator gap review. Document only when: A component certificate does not stand in for system acceptance.	Do selected components support the system requirements under actual use?	Evidence assembled
08 · Integration and acceptance	Allocated responsibilities, installation records, acceptance tests and residual deviations. Detailed verifications (3) Suggested review roles: Integrator; site acceptance authority. Lifecycle: Installation and system acceptance. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Installation baseline recorded Evidence to request: As-built record. Document only when: Acceptance refers to the installed configuration. Site tests representative Evidence to request: Site acceptance results. Document only when: Relevant dependencies and conditions are exercised safely. Deviations owned Evidence to request: Acceptance deviation record. Document only when: Open issues have an explicit treatment and accepting role.	Who verifies the integrated system and accepts unresolved gaps?	Evidence assembled
09 · Operational access and service providers	User and service identities, maintenance windows, remote routes and revocation evidence. Detailed verifications (3) Suggested review roles: Access administrator; service provider. Lifecycle: Maintenance access and offboarding. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Privileges justified Evidence to request: Access review reference. Document only when: Users and service identities match necessary tasks. Remote routes mediated Evidence to request: Remote-access assessment. Document only when: Supplier connections remain within the intended boundaries. Revocation demonstrated Evidence to request: Access termination record. Document only when: Expired work and departing personnel lose usable access.	Can each maintenance privilege be justified and withdrawn?	Evidence assembled
10 · Monitoring and vulnerability response	Log coverage, alert ownership, vulnerability intake, triage and incident procedures. Detailed verifications (3) Suggested review roles: Monitoring/response owner; asset owner. Lifecycle: Operation and vulnerability response. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Events observable Evidence to request: Logging coverage review. Document only when: Relevant activity can be reconstructed. Response owned Evidence to request: Alert escalation procedure. Document only when: An accountable responder can act on alerts. Vulnerabilities triaged Evidence to request: Vulnerability response sample. Document only when: Findings reach an owned operational decision.	Can the operator detect, interpret and act on relevant security events?	Evidence assembled
11 · Change, recovery and continuity	Patch decisions, change authorisation, backup scope, restore results and degraded-operation limits. Detailed verifications (3) Suggested review roles: Change/recovery owner; operations/safety. Lifecycle: Change, continuity and restoration. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Change risk reviewed Evidence to request: Change authorisation record. Document only when: Patching and configuration changes consider operational constraints. Restoration exercised Evidence to request: Restore exercise reference. Document only when: Backups have a demonstrated recovery path. Degraded operation bounded Evidence to request: Continuity assessment. Document only when: Dependency failure and emergency access have reviewed limits.	Can the system be changed and recovered within its operational constraints?	Evidence assembled
12 · Assurance boundaries and reassessment	Claims, requirement coverage, limitations, corrective actions and review triggers. Detailed verifications (3) Suggested review roles: Asset assurance owner; integrator. Lifecycle: Assurance review and lifecycle change. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Claims bounded Evidence to request: Assurance argument index. Document only when: Each claim states scope and limitations. Corrective actions tracked Evidence to request: Action register. Document only when: Unproven items retain owners and closure criteria. Reassessment triggered Evidence to request: Lifecycle review record. Document only when: Topology, support or process changes can reopen the argument.	What remains unproven and who owns the next review?	Evidence assembled

PRIMARY REFERENCES · REVIEWED 1 NOVEMBER 2026

Check the source and its applicability.

Public catalogue and guidance links support orientation. Licensed standards and legally authentic texts govern their respective requirements. This worksheet does not establish equivalence between standards and regulations.

IEC — standards family and roles

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

IEC 62443-3-2:2020 — public catalogue

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

Joint agency guidance — secure OT connectivity

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

All six worksheets →Comparative evidence map →