Industrial switchgear and control infrastructure

Assess

IEC 62443 Readiness Review

Establish the assessment boundary, applicable lifecycle context, available evidence and the next engineering work needed for an IEC 62443 programme or project.

Book a Call Review the readiness guide

IEC 62443 readiness assessmentengineering readiness reviewindustrial cybersecurity assurance

What a readiness review decides

A readiness review is an early-stage engineering assessment. It establishes what can be supported by the current scope and evidence, then identifies the work needed before a more detailed assurance decision.

It does not score an organisation against the whole IEC 62443 series. The relevant publications and requirements depend on the role, system boundary, contractual basis and lifecycle stage.

Questions examined

What is your organisation's role?
What system, service, product or project is inside the boundary?
Which IEC 62443 publications and responsibilities may apply?
What evidence exists, and what is unavailable or unverified?
What should happen next: gap assessment, risk assessment or engineering work?

Readiness focus by organisational role

The review follows the responsibility your organisation holds within the agreed boundary.

Asset Owner / Operator

Owns or operates the industrial system and remains accountable for operational risk, governance and acceptance decisions.

Typical organisations

Utilities and infrastructure operators · Process and manufacturing site operators · Owners of operational technology estates

Common trigger

A programme, site or project needs a clear responsibility boundary, risk basis and evidence plan.

IEC 62443 context

• IEC 62443-2-1 for the asset owner security programme
• IEC 62443-3-2 and 3-3 for system risk, design requirements and verification

Relevant technical capabilities

Assess Risk Segment Assure

Problems this role often needs to resolve

IEC 62443 Requirements and Evidence Poor Asset Visibility Project Cybersecurity Assurance

• Governance, policy and accountable roles
• System inventory, boundaries and criticality
• Risk assessment and target security levels
• Supplier oversight and service-provider controls
• Operational procedures, maintenance and evidence

Start with a readiness review

System Integrator / IACS Service Provider

Designs, integrates, commissions or maintains industrial automation systems within an agreed customer and project scope.

Typical organisations

Control system integrators · Automation and electrical contractors · IACS maintenance and support providers

Common trigger

Customer requirements must be translated into delivery processes, engineering records and acceptance evidence.

IEC 62443 context

• IEC 62443-2-4 for security programme requirements for IACS service providers
• IEC 62443-3-2 and 3-3 where the scope includes system risk, design or verification

Relevant technical capabilities

Assure Assure Document Segment

Problems this role often needs to resolve

Supplier Package Integration Project Cybersecurity Assurance IEC 62443 Requirements and Evidence

• Service-provider security policies and accountable roles
• Secure engineering and change processes
• Remote access, account and maintenance controls
• Customer requirement flow-down
• Project records, testing and handover evidence

Discuss engineering support

Product Supplier / Product Developer

Develops or supplies industrial automation products and is responsible for the product lifecycle and stated component capabilities.

Typical organisations

Industrial software developers · Control and protection product suppliers · Component and embedded-device developers

Common trigger

A product roadmap, customer requirement or assurance review needs a defined development and component evidence baseline.

IEC 62443 context

• IEC 62443-4-1 for the secure product development lifecycle
• IEC 62443-4-2 for technical security requirements of IACS components where applicable

Relevant technical capabilities

Assure Document Assure

Problems this role often needs to resolve

IEC 62443 Requirements and Evidence Project Cybersecurity Assurance

• Product and component boundary
• Secure development lifecycle governance
• Security requirements, threat modelling and design review
• Vulnerability handling, updates and security guidance
• Component capability claims and verification evidence

Discuss a gap assessment

OEM / Machine Builder / Package Supplier

Delivers a machine or packaged system that combines products, integration work and project-specific interfaces.

Typical organisations

Machine builders · Skid and package-system suppliers · OEM engineering and delivery teams

Common trigger

A packaged system must meet customer requirements and integrate into the site without unclear responsibility or evidence gaps.

IEC 62443 context

• IEC 62443-2-4 where the organisation performs integration or service-provider activities
• IEC 62443-3-2 and 3-3 for the packaged system where system responsibilities are in scope
• IEC 62443-4-1 and 4-2 only where the organisation develops products or claims component capabilities

Relevant technical capabilities

Assure Assure Document Segment

Problems this role often needs to resolve

Supplier Package Integration Project Cybersecurity Assurance Insecure Remote Access

• Clarify product, subsystem and integration roles
• Define the package boundary and external interfaces
• Flow customer requirements into supplier and design records
• Review remote access, accounts, hardening and recovery
• Plan FAT, SAT and handover evidence

Start with a readiness review

The applicable IEC 62443 publications and requirements depend on the organisational role, system or product boundary, lifecycle stage, contractual requirements and agreed scope. These references do not state certification or compliance.

Readiness, gap assessment and risk assessment are different

Work	Question it answers	Typical output
Readiness review	Do we have a defensible scope and enough evidence to proceed?	Readiness record and prioritised next steps
Gap assessment	How does the current state compare with agreed requirements?	Requirement-by-requirement gap register and roadmap
Cybersecurity risk assessment	Which credible scenarios create unacceptable risk, and how should they be treated?	Risk register, treatment plan and residual-risk record

Move to the IEC 62443 gap assessment when the requirements are agreed, or to the OT cybersecurity risk assessment when threat scenarios and treatments need detailed evaluation.

Evidence review and classification

Useful inputs

A general description of your organisation, system or project and the decision you need to make
Available customer requirements, architecture records and supplier documentation
A representative who can explain current practices and constraints; missing records can be identified during the review

Review sequence

Agree the purpose and boundary
Discuss current practices and sample available evidence
Identify readiness gaps and priorities
Review the report and agree next steps

Missing evidence is not automatically evidence of a failed control. The report distinguishes a document that cannot be produced from a control known to be absent or ineffective.

Worked example: an undocumented remote-support route

Evidence available

A network drawing shows a vendor connection, but it has no revision status. The support procedure refers to approval and logging, while no recent access record is available during the review.

Readiness finding

Record the architecture and procedure evidence as unverified, not as proof that access is uncontrolled. Identify the owner and evidence needed to establish the current route and operating practice.

Next work

Trace the installed path, sample account and log configuration, then decide whether a control gap, a documentation correction or a separate risk assessment is required.

This is a worked technical example, not a completed Meridian client engagement.

Deliverables and limits

You receive

Concise readiness report with scope, assumptions and limitations
Key gaps and observations, separating missing evidence from known control weaknesses
Prioritised recommendations and next engineering steps
Follow-up review meeting to discuss the findings

Outside the review

Formal certification, accreditation or guaranteed compliance
A requirement-by-requirement gap assessment or detailed cybersecurity risk assessment
Intrusive testing, implementation or verification of every technical control

A sampled readiness review cannot demonstrate that every technical control is effective, assign target security levels without a risk basis or provide certification. Share only a general outline in the initial enquiry; confidential evidence transfer is agreed separately.

Related support and guidance

Discuss an IEC 62443 readiness review

Use the 30-minute introductory call to outline the system, decision, project stage and evidence currently available. Keep sensitive site details out of the booking form.

Book a Call