IEC 62443 does not prescribe a single boilerplate document set, but an OT program aligned to the standard typically maintains a structured suite of documentation across governance, risk, architecture, operations, and lifecycle management. The exact list and depth depend on your asset base, regulatory context, and how much of the standard you are applying (e.g., 62443-2-1 for management systems, 62443-3-3 for system security requirements, 62443-4-2 for components).
1. Governance and program-level documentation
At the program level, you typically need:
- OT cybersecurity policy: High-level expectations for industrial control systems, networked equipment, and supporting infrastructure. Often separate from or an extension of corporate IT security policy.
- OT cybersecurity management system description: How you meet IEC 62443-2-1 style requirements: governance, roles, processes, and interaction with quality, safety, and IT.
- Roles and responsibilities: RACI or equivalent for engineering, operations, maintenance, IT, security, quality, vendors, and integrators.
- Risk management procedure: Methodology for cyber risk assessment in OT (including likelihood/impact criteria, safety and quality impact, risk acceptance rules).
- Exception and risk acceptance process: How nonconformities and compensating controls are documented, justified, approved, and periodically reviewed.
- Vendor and third-party access policy: Rules for remote support, temporary connections, contractor laptops, and service tools.
- Training and awareness plan: Required training by role (operators, engineers, system owners, admins, vendors) and how completion is recorded.
2. Asset, zone, and conduit documentation
IEC 62443 relies heavily on zones and conduits. Typical documentation includes:
- OT asset inventory: Authoritative list of control systems and related assets (PLCs, DCS, CNCs, HMIs, SCADA, MES interfaces, historians, network equipment, safety systems, lab systems where relevant). Must define ownership.
- Zone and conduit model: Documented zoning scheme, including security levels, trust boundaries, and conduits between zones. Usually captured in a standard template plus referenced diagrams.
- Logical network diagrams: Segmentation, VLANs, firewalls, DMZs, wireless, remote access, and interconnections to corporate IT, cloud services, labs, and vendors.
- Physical connectivity diagrams: Where necessary for critical systems, panel-level connectivity, fieldbus, serial, and out-of-band management paths.
- Data flow descriptions: Critical data flows between zones (e.g., recipe download from MES, quality data upload, remote diagnostics) and related security controls.
3. Risk assessment and security level justification
To align with IEC 62443, you typically document:
- OT cyber risk assessments: Structured assessments per zone, system, or plant area. Includes threat scenarios, vulnerabilities, consequence analysis (including safety, quality, production, environment), and risk ratings.
- Target security levels (SL-T): Justification of target security levels for zones and conduits, including assumptions, constraints (legacy systems, vendor support limits), and reliance on procedural controls.
- Gap analysis reports: Comparison of existing controls versus IEC 62443 requirements (e.g., 3-3 foundational requirements) and resulting remediation plan.
- Risk treatment plans: Planned technical, procedural, and organizational measures with owners, milestones, and residual risk documentation.
4. System and control design documentation
For systems within scope (new or existing), you generally maintain:
- Security design specifications for OT systems and projects, usually aligned with IEC 62443-3-3 or internal profiles derived from it. This often includes:
- Authentication and access control model (accounts, roles, least privilege, local vs AD/LDAP).
- Network segregation, firewall rulesets, jump hosts, and remote access patterns.
- System hardening baselines (OS, PLC, HMI, SCADA, appliances).
- Logging, time sync, and monitoring design.
- Backup, restore, and disaster recovery strategy.
- Configuration baselines for key platforms and devices (images, golden configurations, standard policies).
- Interface control documents for connections between OT, MES, ERP, QMS, historians, and vendor services, including protocols, ports, authentication, and data classifications.
- Use of cryptography and key management documentation where applicable (certificates for remote access, signed firmware, encrypted backups, etc.).
5. Operational procedures and work instructions
Many IEC 62443 requirements are operational and procedural. In regulated manufacturing, these procedures commonly sit inside existing quality or operations document control. Typical documents include:
- Account and access management procedures: Creating, modifying, and revoking OT accounts, shared account controls, password policies, access reviews, and emergency access handling.
- Change management process for OT: How changes to PLC code, recipes, network rules, server configurations, and applications are proposed, impact-assessed (including safety, quality, validation), approved, tested, and documented.
- Patch and update management procedures: Evaluation, testing, staging, and deployment of patches and firmware, including coordination with vendors and validation constraints.
- Backup and recovery procedures: Frequency, scope, storage location, restore tests, and responsibilities for controllers, servers, engineering workstations, and recipes.
- Log review and monitoring procedures: What logs are collected, who reviews them, how often, and how anomalies are escalated.
- Remote access procedures: How remote sessions are requested, approved, initiated, monitored, and closed, including temporary firewall rules and session capture where used.
- System hardening and commissioning procedures: Steps for deploying new OT assets: disabling unused services, setting accounts, applying standard configs, and recording security-relevant parameters.
- Decommissioning procedures: Secure removal or repurposing of assets, including data wiping, key and credential handling, and update of the asset inventory.
6. Incident and vulnerability management documentation
IEC 62443 expects structured handling of events and vulnerabilities, typically documented as:
- OT incident response plan: Integration with corporate IR, but tailored to plant realities (24/7 operations, limited downtime, safety interlocks, product quality risks).
- Playbooks or runbooks for common OT incident types (malware on HMI, loss of historian, unauthorized remote access, suspicious PLC change).
- Incident logging templates and reports: Standard forms or systems to record events, actions taken, root cause, and lessons learned.
- Vulnerability intake and assessment procedure: How advisories (e.g., from ICS-CERT, vendors, internal scanning) are triaged, risk-assessed, prioritized, and linked to remediation or accepted risk.
7. Supplier, integrator, and component documentation
Where you procure or integrate OT systems, typical supporting documentation includes:
- Security requirements for suppliers and integrators: Standard clauses or specifications derived from IEC 62443-2-4, -3-3, or -4-1/-4-2 as appropriate to your role (asset owner vs integrator vs component supplier).
- Security capability declarations for systems and components (where vendors provide mappings to IEC 62443-3-3/-4-2 requirements, or equivalent statements).
- Vendor remote support agreements: Defined security expectations, minimum technical controls, access windows, and logging requirements.
- Bill of materials and firmware/software lists for critical systems to support vulnerability tracking and lifecycle decisions.
8. Validation, testing, and evidence of effectiveness
In regulated environments, documentation of how you validate and keep controls effective is as important as the policies themselves. Common elements include:
- Test plans and protocols for security-relevant changes (e.g., network segmentation projects, new remote access platforms, firewall rule updates) including regression considerations for process control and quality.
- Factory or site acceptance test (FAT/SAT) templates with security checks baked in (accounts, logging, patch level, remote access disabled by default, alignment to zone design).
- Periodic review reports: Internal audits, self-assessments, or technical reviews against 62443-based control lists.
- Metrics and KPI definitions where used (e.g., time to revoke access, patch latency for critical assets, percentage of assets with documented baselines) and how data is collected.
9. Integration with existing quality and IT systems
In brownfield, regulated manufacturing environments, most of the above documentation will coexist with and reuse existing systems rather than replace them:
- Document control: OT cybersecurity documents are usually managed through existing QMS or corporate document control. You may need separate categories or tags for OT security to avoid confusion with purely IT or process documents.
- Change control: Cybersecurity-relevant changes should be routed through established engineering change and validation processes (e.g., change control boards, qualification protocols), rather than introducing a parallel workflow.
- Overlap with IT policies: Some topics (password standards, incident handling, acceptable use) may be covered by IT security policies. Where reused, you should maintain cross-references and document any OT-specific deviations or compensating controls.
- Legacy systems: For unmodifiable or unsupported assets, documentation needs to capture constraints and explicitly describe compensating procedural or network controls, as well as documented residual risk.
10. Practical considerations and tradeoffs
When building or rationalizing documentation for IEC 62443 alignment, typical tradeoffs and constraints include:
- Depth vs maintainability: Overly detailed documents become obsolete quickly and are not followed. Lean, role-focused documents that match real workflows tend to age better and stand up to scrutiny.
- Standardization vs site variability: Corporate templates support consistency, but plants often need local annexes for unique equipment, regulatory, or staffing realities.
- Evidence vs operational burden: Every procedural control must be realistically executable in a production environment with limited downtime and staffing. If evidence collection is too heavy, operators and engineers will bypass it.
- Replacement vs coexistence: Trying to replace existing MES, historian, or network management documentation wholesale with “IEC 62443 documents” usually fails due to validation costs, integration complexity, and operational disruption. It is more realistic to map existing documents and controls to IEC 62443 requirements, then address true gaps.
Ultimately, an IEC 62443-aligned OT program is evidenced not by the sheer number of documents, but by a coherent, current set of records that accurately reflect how systems are designed, operated, and changed. The documentation set should be tailored to your plants, risk profile, and regulatory obligations, and it must be kept under active configuration and change control.
