IEC 62443 Gap Analysis: The Complete 2026 Guide

An IEC 62443 gap analysis compares how your site actually secures its industrial automation and control systems (IACS) today with the requirements of the parts of the standard that apply to you. For most asset owners, that means IEC 62443-2-1 for the security program, IEC 62443-3-2 and 3-3 for the systems and their zones, and IEC 62443-2-4 for the integrators and maintenance providers who work on those systems.

The result is not a pass or fail. You get a gap register, a maturity rating for the program, target versus achieved security levels for each zone, and a prioritized roadmap. In our experience, a single site typically takes 2 to 8 weeks.

Below is how we run an IEC 62443 gap analysis as auditors. For background on each part, see IEC 62443 parts explained.

Scoping an IEC 62443 gap analysis: which parts apply

Agree on scope in writing before the first interview. Answer two questions: which sites and control systems are in, and which role your organization plays. An asset owner is assessed against different parts than a product supplier.

• IEC 62443-2-1 (security program). Policies, procedures and practices across all your control systems. Most interview time goes here.
• IEC 62443-3-2 (risk and zones). Whether you have identified the system under consideration, partitioned it into zones and conduits, and documented target security levels.
• IEC 62443-3-3 (system requirements). The 51 system requirements under seven foundational requirements, used to judge what each zone achieves.
• IEC 62443-2-4 (service providers). Which capabilities you require from integrators and maintenance providers, and whether they deliver them.

Leave IEC 62443-4-1 out unless you build products. For an asset owner, 4-2 matters only on the procurement side, as the source of component capability claims.

Then define the boundary precisely: sites, control systems, Purdue levels, safety instrumented systems in or out, and every remote access path. In our experience, a vague boundary is one of the most frequent reasons an IEC 62443 gap analysis overruns.

Pick the baseline edition before the first interview

IEC 62443-2-1 Edition 2.0, published on 7 August 2024, replaces the 2010 edition. The change matters for any IEC 62443-2-1 gap analysis. The new edition restructures requirements into security program elements (SPEs), removes duplication with an information security management system (ISMS), and defines a maturity model for evaluating requirements. It is written for asset owners, a term that includes the IACS operator.

The eight SPEs give the assessment a natural structure:

• SPE 1 Organizational security measures
• SPE 2 Configuration management
• SPE 3 Network and communications security
• SPE 4 Component security
• SPE 5 Protection of data
• SPE 6 User access control
• SPE 7 Event and incident management
• SPE 8 System integrity and availability

If your program was built on the 2010 edition, don’t re-score old checklists. Map existing controls to the SPEs first. The 2024 edition also recognizes that many legacy systems are unsupported, so a program may cover only a subset of requirements with compensating measures. Record those measures as evidence rather than scoring legacy systems as plain failures. The official abstract is on the IEC webstore page for IEC 62443-2-1:2024.

Write the editions into the scope statement so findings stay traceable: 2-1:2024, 3-2:2020, 3-3:2013 (still current) and 2-4:2023. ISA’s US version of 2-4 remains ANSI/ISA-62443-2-4-2018.

Interviews and evidence sampling

An IEC 62443 gap assessment is an evidence exercise, not a questionnaire. Interviews tell you what people believe happens. Records and observation show what actually does.

Interview the people who run the plant, not only those who write policy: operations, control engineers, OT network administrators, maintenance, process safety, procurement, and at least one key integrator. Hold some interviews at the engineering workstation so people can show what they describe.

For each population (changes, accounts, hosts, backups, remote sessions), pick the sample yourself from the last 6 to 12 months. Our usual practice is 5 to 10 items per population, or every item when there are fewer than ten. A sample chosen by the site team proves only that they can find good examples. On live networks, compare the inventory with passive captures or switch tables rather than actively scanning controllers.

Area	What to check	Evidence to request
Governance and roles	Named OT security owner; management accepts residual risk; OT staff trained	Role assignments, latest risk acceptance record, training completion for sampled staff
Asset inventory and configuration	Inventory matches the network; baselines exist; changes are approved	Inventory export, passive capture or switch tables, 5 to 10 recent change records
Zones and conduits	Drawings match reality; every conduit has a documented purpose	Zone and conduit drawings, firewall rule export, walk-down notes for one boundary
Hardening and patching	Unused services disabled; patch and malware status known; exceptions covered	Status for sampled hosts, vendor patch qualification, exception list
Accounts and remote access	Leavers removed; shared accounts controlled; remote sessions approved and logged	Account list checked against leavers, remote access log for one month
Backup and recovery	Controller and server backups exist; restores tested	Backup job logs, last restore test result
Logging and incident response	Key events collected and reviewed; OT incident plan exercised	Log source list, sample alerts with triage notes, last exercise report
Service providers (2-4)	Security requirements in contracts; provider practices verified	Contract clauses, provider evidence, access records for provider staff
Zone security levels (3-2, 3-3)	SL-T documented per zone; SL-A assessed against it	Target security level record, requirement-by-requirement evidence for one zone

Rating the program against a maturity model

A yes/no IEC 62443 gap analysis hides most of what a plant manager needs to know. A requirement can be written into policy and never practiced, or practiced informally by one engineer. A maturity rating separates those cases.

For the security program, use the maturity model that IEC 62443-2-1:2024 defines and apply its level definitions as written. Don’t import level names from another framework, and don’t assume the 2-1 scale is interchangeable with the 2-4 scale. Our guide to IEC 62443 maturity levels explains how the models are used. Two rules keep ratings defensible:

• Rate what you can evidence, not the level described in the interview.
• Rate each requirement separately, then summarize by SPE, so one strong area doesn’t lift a weak one.

Rating service providers under 2-4

IEC 62443-2-4 uses maturity levels that the ISA Global Cybersecurity Alliance describes as ML1 Initial, ML2 Managed, ML3 Defined/Practiced and ML4 Improving. Decide which capabilities and level you require from each provider, then check whether they meet them. IEC TS 62443-6-1:2024 sets out an evaluation method for 2-4.

SL-T vs SL-A: the zone-level gaps

The program rating shows how well you manage security. The zone comparison shows whether each system meets the level your risk assessment demands. Three values matter:

• SL-T (target): set per zone through the IEC 62443-3-2 risk assessment and documented in the cybersecurity requirements specification.
• SL-C (capability): what the components and system can deliver when configured correctly, usually taken from supplier claims.
• SL-A (achieved): what the zone actually delivers as installed and operated.

In an IEC 62443 gap analysis, we record SL-T and SL-A per foundational requirement for each zone, not as one number. A zone might meet SL 2 for restricted data flow but only SL 1 for identification and authentication control. SL 2 protects against intentional violation using simple means with low resources, generic skills and low motivation.

A frequent pattern is SL-C above SL-A: components support individual accounts and secure protocols, but the site still uses shared logins and default settings. Closing that gap is usually cheaper than replacing hardware. If no 3-2 risk assessment exists, there is no SL-T to compare against. Record that as a gap in its own right rather than inventing targets during fieldwork.

Outputs: the gap register and remediation roadmap

An IEC 62443 gap analysis should produce two working outputs plus a short executive summary for leadership.

The gap register has one row per gap: requirement reference and edition, SPE or zone, current state, evidence reference, maturity rating or SL-A against SL-T, consequence, owner, action, any compensating measure, and target date.

The remediation roadmap ranks gaps by consequence and exposure, not by finding count. A practical grouping:

• 0 to 90 days: fixes needing no outage, such as account cleanup, remote access approvals and restore tests.
• 3 to 12 months: segmentation changes, monitoring and provider contract updates.
• Next planned outage or turnaround: changes needing downtime or vendor qualification.

Tie hardware and network changes to the outage calendar early, or a twelve-month plan quietly becomes three years. Our guide to building a gap analysis remediation plan covers ownership and tracking.

How long an IEC 62443 gap analysis takes

Duration depends on the number of control systems, zones and providers in scope more than on headcount. These ranges are typical practitioner estimates from our experience, not published benchmarks:

• Small single site with one main control system and a few zones: about 2 to 4 weeks elapsed, including 2 to 4 days on site.
• Medium site with several control systems, or with a safety system in scope: about 4 to 8 weeks.
• Multi-site program assessed through a sample of representative sites: about 3 to 6 months.

Add time if the asset inventory or network drawings are out of date, because the IEC 62443 gap analysis then becomes a discovery exercise before any rating starts.

Mistakes that undermine the result

• Mixing editions. Scoring some areas against the 2010 structure and others against the 2024 SPEs makes findings untraceable.
• Reviewing documents only. A policy proves intent. Records and observation prove practice.
• Skipping providers. Integrators and maintenance contractors often hold the most privileged remote access.
• Rating SL-A without SL-T. Without a target, there’s nothing to measure “achieved” against.
• Interviewing only IT. Operators, maintenance staff and control engineers know where the workarounds are.
• Active scanning in production. Use passive methods unless the asset owner has approved a test window.
• Gaps without owners. A register with no owners or dates is a report, not a plan.

For a structured starting point for your IEC 62443 gap analysis, the IEC 62443 Toolkit ($149) includes a conformance, maturity and evidence section and an SL-T/SL-C/SL-A gap workbook among its 117 editable templates (82 Word, 35 Excel). It is written against IEC 62443-2-1:2024 for asset owners and service providers, not product suppliers seeking 4-1. It supplies the documented layer; your team still operates the processes and keeps the records, and no template set can certify anyone.

IEC 62443 gap analysis FAQs

Is an IEC 62443 gap analysis the same as an audit?

No. An audit tests conformity against agreed criteria. A gap analysis is diagnostic: it measures current state, rates maturity and security levels, and feeds a remediation plan. Many organizations run the gap analysis first and an internal audit once major gaps are closed.

Which edition of IEC 62443-2-1 should we assess against?

Use IEC 62443-2-1:2024 (Edition 2.0) unless a contract or regulator names another. It replaced the 2010 edition and introduced the SPE structure and maturity model, so a 2010-based assessment won’t line up with the current text.

Do we need a 3-2 risk assessment before starting?

Not to start, but you need one to finish. The 2-1 program assessment can run without it. Without documented SL-T values, though, SL-A results have no reference point, so treat a missing risk assessment as a priority gap.

Does a gap analysis lead to certification?

Certification is voluntary, and an IEC 62443 gap analysis certifies nothing, but it is a sensible preparation step. ISASecure’s ACSSA program (version 1.0.0 effective 17 February 2026) covers an operating IACS against 2-1, 2-4, 3-2 and 3-3, the same parts scoped here.