How to Audit OT Security Against IEC 62443 (Practical, Evidence-Driven Guide)

111

To audit OT security against IEC 62443, first define the System Under Consideration (SUC) and partition it into zones and conduits. Then select which IEC 62443 parts apply to your role (asset owner, integrator/service provider, or product supplier). Collect objective evidence for governance and operations (IEC 62443-2-1), supplier/service-provider practices (IEC 62443-2-4), risk assessment and target security levels (IEC 62443-3-2), system security requirements and levels (IEC 62443-3-3), and component security capabilities (IEC 62443-4-2) supported by secure development lifecycle controls (IEC 62443-4-1). Finally, score gaps by impact on safety/availability, assign owners, implement corrective actions, and re-test for closure.

Why IEC 62443 audits fail (and what “good” looks like)

Most IEC 62443 “audits” fail for one of these reasons:

• They start with a checklist but no scope model. Auditors ask for “all OT controls everywhere,” which produces noise, not insight.
• They confuse product requirements with asset owner requirements. Teams try to “pass 62443-4-2” at the plant level, when that part is about component security capabilities.
• They treat cybersecurity as IT-only. In OT, safety and availability are primary outcomes, and the audit must validate how security is operated under real production constraints.
• They can’t produce objective evidence. “We do backups” or “We have segmentation” doesn’t pass. Audits require artifacts: configurations, tickets, logs, test results, and records.
• They don’t connect to zones/conduits and security levels. IEC 62443 expects you to define the system under consideration, partition it, assess risk, and set target security levels per zone/conduit.

What “good” looks like:

• Clear definition of the System Under Consideration (SUC) and its zones and conduits.
• An audit criteria matrix that maps policies + procedures + technical controls to the correct IEC 62443 parts.
• Evidence that controls are implemented and operating (not just written).
• A risk-based finding list with owners, deadlines, and re-test results.

---

Which IEC 62443 documents matter for audits (by role)

IEC 62443 is a series, not a single checklist. Your audit must match the right parts to the right responsibility.

The “most-audited” parts in real OT programs

Asset owner / operator (you run the plant)

• IEC 62443-2-1:2024 — security program requirements for IACS asset owners (policies/procedures and program governance).
• IEC 62443-3-2:2020 — security risk assessment for system design: define SUC, zones/conduits, risk per zone/conduit, set target security levels (SL-T).
• IEC 62443-3-3:2013 — system security requirements (SRs) and security levels for the system.
• IEC TR 62443-2-3:2015 — patch management guidance in IACS environments (often used as audit criteria even though it’s a Technical Report).

Integrator / service provider (you build/maintain OT systems for others)

• IEC 62443-2-4:2023 — security program requirements for IACS service providers (integration and maintenance processes, and how you deliver security as a service).

Product supplier (you build components/products)

• IEC 62443-4-1:2018 — secure product development lifecycle requirements.
• IEC 62443-4-2:2019 — technical security requirements for IACS components (capabilities organized around the seven Foundational Requirements).
• IEC TS 62443-6-2:2025 — evaluation methodology supporting repeatable evaluation of components against IEC 62443-4-2.

The seven Foundational Requirements (FRs) you’ll see repeatedly

IEC 62443-4-2 lists seven FRs: Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability.
These FRs are the backbone for technical auditing—especially when you assess systems (3-3) and components (4-2).

---

Audit types: internal readiness vs supplier audit vs certification readiness

Before you start collecting evidence, decide what kind of audit you’re running. Same standard; different outcomes.

1) Internal readiness audit (most common for asset owners)

Goal: identify gaps, build a risk-based remediation plan, and prove improvement.

Output:

• risk-ranked findings
• corrective actions (CAPs)
• a repeatable “audit pack” of evidence

2) Supplier/service provider audit (vendor governance)

Goal: validate that integrators and managed service providers meet IEC 62443-2-4 expectations—especially for remote access, change control, incident handling, and secure maintenance.

Output:

• supplier scorecards
• contract requirements and remediation timelines
• approval/conditional approval decisions

3) Certification readiness assessment (product or system)

Important nuance: IEC publishes standards; certification is typically executed through independent schemes.

Output:

• “audit-like” evidence pack aligned to the scheme
• remediation plan to close gaps before formal evaluation

---

The audit method: a practical 9-step playbook

Here’s a repeatable method that works across manufacturing, utilities, O&G, and pharma:

1. Define objective and success criteria
2. Define SUC + zones/conduits + target security levels
3. Build criteria matrix (what requirements apply)
4. Collect evidence artifacts (prove operation)
5. Interview + walkthrough (validate reality)
6. Technical verification (sample and test)
7. Score and write nonconformities (risk-based)
8. Create corrective action plans (CAPs)
9. Re-test, report, and institutionalize

---

Step 1 — Define audit objective and “done” criteria

A strong audit objective is explicit about scope and outcome. Examples:

• “Assess Site A packaging line OT against IEC 62443-2-1 program controls and IEC 62443-3-3 technical controls for SL2 target zones.”
• “Audit integrator remote support practices against IEC 62443-2-4 for all maintenance activities performed on our OT DMZ and SCADA zones.”
• “Validate that critical components used in our OT meet IEC 62443-4-2 capability level claims and have supporting IEC 62443-4-1 secure development evidence.”

Define “done” up front

For each requirement in scope, define what counts as:

• Conformant (objective evidence exists and is current)
• Partially conformant (policy exists; operation inconsistent; evidence missing)
• Not conformant (no control or clear failure)
• Not applicable (with justification)

If you don’t define these states, your audit becomes opinion-driven.

---

Step 2 — Define the SUC, zones, conduits, and security levels

IEC 62443-3-2 explicitly calls for:

• defining the System Under Consideration (SUC)
• partitioning into zones and conduits
• assessing risk per zone and conduit
• establishing target security level (SL-T) per zone/conduit
• documenting security requirements

Practical scoping rules for the SUC

Your SUC should be defined by process function and consequence, not by VLAN alone. Include:

• SCADA servers and operator HMIs that affect production
• engineering workstations and project repositories
• remote access gateways/jump hosts (often your highest-risk pathway)
• OT identity dependencies (AD, local admin patterns)
• backups and restore paths for OT services

Minimal zone model (start here)

• Enterprise IT
• OT DMZ
• SCADA / operations zone
• Engineering zone
• Cell/Area zone(s)

Map conduits:

• IT ↔ OT DMZ
• OT DMZ ↔ SCADA
• SCADA ↔ Engineering
• SCADA/Engineering ↔ Cells

Security levels (how to use them in audits)

Your audit should verify that:

1. SL-T (target) is defined for each zone/conduit (via risk assessment)
2. Controls implemented in that zone/conduit plausibly meet the target level (via 3-3 SRs)
3. Any “compensating controls” for legacy systems are documented and justified

---

Step 3 — Build your audit criteria matrix (what you will test)

This is where most teams improve audit speed by 2× to 5×.

Create a matrix with 4 columns

1. IEC 62443 reference (part + clause or requirement ID)
2. Control intent (plain language)
3. Evidence required (artifacts, logs, configs)
4. Test method (interview, document review, technical sampling)

How to pick which parts apply (quick decision table)

Your goal	Use these IEC 62443 parts	Why
Audit OT security program governance	2-1	Policies, procedures, roles, continuous improvement
Audit system risk model and segmentation design	3-2	SUC, zones/conduits, risk per zone, SL-T
Audit technical controls in the deployed system	3-3	System security requirements (SRs) by FR
Audit integrators / maintenance providers	2-4	Service provider security program processes
Audit components/products used in OT	4-2 + 4-1	Component capabilities + secure development lifecycle
Audit patching discipline	TR 2-3	OT patch management guidance and practices

---

Step 4 — Evidence collection: the OT audit artifact checklist

IEC 62443 audits succeed when evidence is pre-assembled. Build an “audit pack” folder per site/system.

A. Governance and program evidence (typical for IEC 62443-2-1)

IEC 62443-2-1 is about the asset owner security program requirements.
Collect:

• OT security policy and scope statement
• roles/responsibilities (RACI), including operations vs engineering vs IT boundaries
• risk assessment procedure and frequency
• change management procedure for OT (including emergency change)
• incident response plan with OT-specific steps
• training records (OT role-based training, contractor training)
• vulnerability and patch governance approach (including OT exceptions)
• backup policy, restore testing records
• supplier management requirements and reviews

B. Architecture and segmentation evidence (IEC 62443-3-2 / 3-3)

IEC 62443-3-2 requires zones and conduits and risk assessment outputs.
Collect:

• network diagrams: logical + physical; zones/conduits labeled
• data flow diagrams for critical applications (HMI, historian, engineering tools)
• firewall rulebases for conduits (exported configs or screenshots with rule IDs)
• remote access architecture showing termination points (OT DMZ, jump hosts)
• inventory of critical assets mapped to zones
• SL-T documentation per zone/conduit and justification

C. Operational proof (controls are running, not just written)

This is the “make or break” evidence:

• sample tickets: access approvals, change approvals, emergency changes
• remote access session logs (who/when/what)
• authentication logs (MFA enforcement evidence where applicable)
• backup job results and restore test evidence
• monitoring/alerting evidence: what is collected and reviewed
• endpoint hardening baselines for jump hosts / EWS
• asset discovery results and exception list

D. Supplier and service provider evidence (IEC 62443-2-4)

IEC 62443-2-4 defines requirements for IACS service providers’ security programs.
Collect:

• contracts/SOW clauses: security obligations, incident notification, access control
• service provider onboarding and offboarding workflow
• maintenance work instructions, secure remote support procedures
• personnel screening/training records (as contractually allowed)
• evidence of how service provider controls tools, credentials, and updates

E. Component/product evidence (IEC 62443-4-1 / 4-2)

IEC 62443-4-1 is secure development lifecycle requirements for product suppliers.
IEC 62443-4-2 defines component technical security requirements and capability levels.
Collect:

• vendor security datasheets / capability claims mapped to 4-2
• supplier SDL evidence (4-1) if you’re auditing suppliers directly
• vulnerability handling process evidence and patch advisories
• bill of materials (SBOM) or component inventory statements (if provided)
• independent evaluation artifacts if applicable (e.g., assessment reports)

If you’re evaluating components, IEC TS 62443-6-2 provides evaluation methodology guidance for 4-2 repeatability.

---

Step 5 — Interviews and walkdowns that actually find gaps

In OT, interviews must be tied to observable evidence. Every interview question should end with: “Show me.”

Interview targets (minimum set)

• OT operations lead (production priorities, outage constraints)
• controls engineer (EWS, PLC changes, project files, backups)
• OT network/security (segmentation, remote access, monitoring)
• maintenance supervisor (contractors/vendors, on-site practices)
• IT identity/admin (AD dependencies, privileged access boundaries)
• key integrator or OEM (service provider controls)

Questions that map well to IEC 62443 intent

Zones/conduits and risk (3-2):

• “Show the zone/conduit diagram. When was it last updated?”
• “Which conduits are deny-by-default? Which are exception-based—and why?”

System security requirements (3-3):

• “Who can perform engineering changes? How is access restricted and logged?”
• “How do you detect and respond to security events in OT zones?”

Program governance (2-1):

• “What is your OT security program cadence? Who reviews risk and approves exceptions?”
• “Show evidence of restore tests and incident tabletop exercises.”

Service providers (2-4):

• “How do you grant vendor access? Is it time-bound? Is it recorded? Show logs.”

---

Step 6 — Technical verification: what to validate hands-on

Audits become credible when you validate a sample of controls end-to-end.

Sampling strategy (practical)

Pick:

• top 1–3 critical production areas
• 1 remote access path
• 1 engineering workflow
• 1 backup/restore workflow
• 1 monitoring workflow
• 1 vendor maintenance workflow

Then test evidence across the chain.

What to verify (high-value technical checks)

1) Remote access control (common major nonconformity)

Validate:

• where remote access terminates (OT DMZ vs direct-to-OT)
• MFA enforcement
• named accounts (no shared vendor accounts)
• time-bound access (JIT) and approvals
• session logs/recordings

This maps strongly to program governance (2-1), service provider practices (2-4), and system requirements (3-3).

2) Segmentation and conduit enforcement

Validate:

• firewall rules match documented conduits
• rules are scoped to required ports/destinations
• exceptions have owners and expiry dates
• engineering access to cell/area zones is controlled

Zones/conduits are explicitly called out in 3-2.

3) Identity and privilege boundaries in OT

Validate:

• how admin rights are granted on EWS, servers, jump hosts
• whether shared local admin exists across zones
• whether vendor accounts are tied to individuals
• whether privilege is separable for engineering vs support tasks

4) Integrity of engineering workflows (high consequence)

Validate:

• where PLC/DCS project files live
• who can change them
• versioning and backups
• change approval evidence for recent modifications
• ability to roll back safely

5) Patch and vulnerability workflow (OT-realistic)

IEC TR 62443-2-3 provides patch management guidance in IACS environments.
Validate:

• vulnerability intake (advisories, vendor notifications)
• risk-based patch decision process with operations sign-off
• compensating controls for unpatchable assets (segmentation, allowlisting, monitoring)
• evidence of patch testing/validation and deployment records

6) Logging, monitoring, and response

Validate:

• what logs are collected (remote access, servers, firewalls)
• retention period
• alert triage workflow and evidence of review
• incident response playbook that includes OT containment steps

7) Backup and recovery (audit it like you mean it)

Validate:

• backup coverage for critical OT systems
• last successful backup dates
• restore testing evidence (not just “backup succeeded”)
• protection against ransomware-style deletion (where feasible)

---

Step 7 — Scoring, nonconformities, and risk-based prioritization

IEC 62443 audits become actionable when findings are categorized consistently.

Use a simple 4-level finding taxonomy

• Major nonconformity: control missing or clearly ineffective; credible path to significant operational impact
• Minor nonconformity: control partially implemented; limited scope or inconsistent execution
• Observation: improvement opportunity; not strictly required or not yet a failure
• Not applicable: documented justification

Add a business-impact tag to every finding

Tag each finding as primarily affecting:

• safety
• availability
• quality
• environmental exposure
• compliance/contractual risk

This is the fastest way to turn audit results into funded action.

Score gaps with a repeatable formula

For each finding:

• Likelihood L (1–5) based on exposure + control weakness
• Impact I (1–5) based on OT consequence
• Effort E (1–5) to remediate
• Priority index:

This prevents your remediation plan from being dominated by “big projects” while ignoring easy wins that reduce high risk.

Step 8 — Corrective action plans (CAPs) that close fast

A CAP that closes quickly has five elements:

1. Control objective (what you are trying to achieve)
2. Implementation steps (technical + procedural)
3. Owner + due date (single accountable person)
4. Evidence of completion (what you will show the auditor)
5. Re-test method (how you prove it works)

CAP examples that map well to IEC 62443 expectations

Finding: Vendor remote access is persistent and unrecorded.
CAP: Terminate vendor access in OT DMZ, require MFA + named accounts, implement time-bound approvals, enable session logging/recording; update vendor procedure and contract language.
Evidence: architecture diagram, MFA policy, sample access ticket, session log/recording excerpt, firewall rule changes.

Finding: Zones/conduits diagram is outdated; conduit rules not reviewed.
CAP: Establish zone/conduit review quarterly, tag each conduit rule with owner and expiry, export firewall configs for audit pack.
Evidence: updated diagrams, rule review minutes, change tickets, rulebase exports.

Finding: No restore tests for critical OT servers.
CAP: Perform quarterly restore tests for top-tier OT services; document RTO/RPO; store results.
Evidence: restore test report, screenshots/logs, updated backup SOP.

---

Step 9 — Re-test, report, and build an audit-ready operating rhythm

Re-test is not optional

Your audit should schedule closure testing:

• 30 days for quick wins (access, logging, documentation, approvals)
• 60–180 days for segmentation changes and workflow redesign
• longer for architecture migrations (new DMZ, tool standardization)

Reporting format: write it for two audiences

Executive summary (1–2 pages):

• top 5 risks and business impact
• what improved since last audit
• what needs funding and downtime windows
• residual risk position

Technical appendix (auditable):

• criteria matrix and results
• evidence index (where artifacts live)
• finding write-ups with CAPs
• re-test results

Build the “audit cadence”

To stay audit-ready:

• quarterly access reviews (especially vendors)
• quarterly conduit/rule reviews
• monthly vulnerability intake review
• quarterly backup restore tests
• annual zone/conduit risk review (or after major changes)

This aligns naturally with IEC 62443-2-1’s emphasis on maintaining and continually improving a security program.

---

Common pitfalls and how to avoid them

Pitfall 1: Auditing “everything everywhere”

Fix: define the SUC and focus on zones/conduits tied to critical processes.

Pitfall 2: Treating component standards as plant controls

Fix: use 4-2 for components and supplier conversations, 3-3 for deployed system requirements, 2-1 for program controls.

Pitfall 3: Passing documentation but failing operations

Fix: require operating evidence—tickets, logs, session records, restore tests.

Pitfall 4: Ignoring service providers

Fix: audit integrators/vendors against 2-4 and enforce contract clauses tied to evidence.

Pitfall 5: Not aligning to security levels

Fix: document SL-T per zone/conduit and show how implemented controls support it.

---

Templates: criteria matrix, evidence tracker, and report outline

Template 1 — Audit criteria matrix (starter)

Use this as a spreadsheet header:

Control area	IEC 62443 reference	Requirement intent	Evidence required	Test method	Result	Notes

Populate control areas like:

• governance (2-1)
• zones/conduits and SL-T (3-2)
• system technical requirements (3-3)
• patch management (TR 2-3)
• service provider controls (2-4)
• component assurance (4-1/4-2)

Template 2 — Evidence tracker (audit pack index)

/OT_Audit_Pack/  01_Scope_and_SUC/  02_Zones_Conduits_SL-T/  03_Policies_Procedures_(2-1)/  04_Service_Providers_(2-4)/  05_Technical_Controls_(3-3)/  06_Patch_and_Vuln_(TR2-3)/  07_Backup_and_Recovery/  08_Remote_Access/  09_Logging_and_Monitoring/  10_Findings_and_CAPs/  11_Retest_Evidence/

Template 3 — Finding write-up format (auditor-friendly)

• Finding ID / Title
• IEC 62443 reference
• Condition (what is happening)
• Criteria (what is required)
• Cause (why it happened)
• Consequence (business impact)
• Corrective action plan (CAP)
• Owner / Due date
• Evidence to close
• Re-test result

---

KPIs for IEC 62443 audit readiness

If you want to be audit-ready continuously (not once a year), track:

• % of critical zones with documented SL-T and current zone/conduit diagrams
• % of vendor access that is time-bound, MFA-protected, and logged (and reviewed quarterly)
• of conduit firewall rules with owners + expiry dates
• restore test success rate and median restore time for critical OT services
• % of high findings closed within SLA (e.g., 90 days)
• % of service providers assessed against 2-4 requirements annually
• % of critical components with documented security capability evidence (4-2)

---

FAQ

Do we need to “comply with all of IEC 62443” to pass an audit?

No. Effective audits scope the SUC, define zones/conduits, and select applicable parts and requirements. IEC 62443-3-2 expects this kind of scoping and documentation approach.

What’s the difference between IEC 62443-3-3 and IEC 62443-4-2?

IEC 62443-3-3 defines system security requirements and security levels for the overall system.
IEC 62443-4-2 defines component technical security requirements and capability security levels for individual components like embedded devices, network devices, and software applications.

What should an asset owner audit first?

Start with the controls that reduce multiple scenarios at once: remote access governance, segmentation (zones/conduits), engineering workstation protections, backups/restore testing, and monitoring. Use 2-1 for program controls and 3-2/3-3 for system design and technical requirements.

How do we audit service providers and integrators?

Use IEC 62443-2-4 as the process and capability baseline for IACS service providers—then require objective evidence: procedures, access workflows, training, and incident handling.

Is there an evaluation methodology for 4-2 component requirements?

Yes—IEC TS 62443-6-2:2025 provides an evaluation methodology intended to support repeatable and reproducible evaluation results for components against IEC 62443-4-2.