ISA IC37: Operating and Maintaining Industrial Cybersecurity

ISA IC37 is the operations and maintenance specialist component of the ISA/IEC 62443 Cybersecurity Certificate Program. It focuses on keeping industrial cybersecurity controls effective after design and commissioning, when real systems accumulate patches, exceptions, account changes, vendor sessions, failures, replacement devices, new vulnerabilities, and operational workarounds. Security that is strong on handover can degrade quickly if maintenance is treated as routine IT administration.

The ISA IC37 page sits after the mandatory fundamentals step in the broader ISA certifications program. The relationship to ISA IC34 is especially important: operations should preserve the security intent of the architecture while adapting safely to changes in equipment, process, threat conditions, and business needs.

ISA IC37 preparation should be practical and lifecycle oriented. Candidates need to reason about monitoring, logging, patching, backups, incident response, troubleshooting, change control, audit readiness, and recovery in environments where uptime and safety matter. The strongest answer is rarely “apply the control immediately.” It is usually the response that understands urgency, operational consequence, evidence, authorization, and restoration together.

Operate from a trustworthy asset and configuration baseline

Maintenance is impossible when the organization does not know what it owns or how systems are expected to be configured. Asset records should include hardware, software, firmware, network identity, ownership, function, location, criticality, vendor support, and important dependencies. Configuration baselines help teams distinguish an authorized engineering change from drift or compromise. ISA IC37 candidates should see inventory as operational evidence, not administrative paperwork.

Baselines also support incident response and recovery. If a workstation behaves unexpectedly, responders need to know its approved software, accounts, communication peers, and role in the process. If a controller is replaced, engineers need trusted configuration backups and change records. Accurate baselines reduce the time spent reconstructing normal behavior during a high-pressure event.

Asset records should be connected to maintenance reality. An inventory that lists a controller but omits its firmware, engineering software dependency, backup location, vendor contact, and replacement constraints will not help much during an urgent vulnerability or failure. Candidates should think about what information operators need to make a safe decision under time pressure and ensure that the asset record supports that decision.

Patch and remediate without creating unsafe change

Industrial patching requires risk-based coordination. A vulnerability may be severe, but an untested update to a critical system can create an immediate availability or safety problem. Candidates should evaluate exploitability, exposure, consequence, vendor guidance, compensating controls, maintenance windows, rollback capability, and test results before choosing a treatment path.

The approved vulnerability management material is useful when adapted to operational technology. Discovery and prioritization matter, but remediation may involve segmentation, disabling a service, restricting access, application control, monitoring, or replacement rather than immediate patching. The process should document residual risk and revisit temporary measures so they do not become permanent exceptions.

Maintenance teams also need a disciplined approach to accounts and certificates. Contractor accounts that outlive a project, shared engineering credentials, expired certificates, and unmanaged service identities can quietly create persistent exposure. Reviews should be tied to employment changes, vendor contracts, asset replacement, and scheduled recertification. Strong operations remove access when the business need ends and maintain emergency access separately, with controls that make exceptional use visible and reviewable.

Monitor changes and communications for meaningful deviation

Operational monitoring should reveal activity that matters to the industrial environment: new devices, changed firewall rules, unusual remote sessions, unexpected protocol use, engineering downloads, repeated authentication failures, service disruption, or altered configurations. The approved security logging material provides useful context for selecting evidence that supports detection and investigation rather than collecting data without purpose.

Candidates should understand that monitoring quality depends on baselines and ownership. An alert is useful only when someone can determine whether it represents maintenance, malfunction, or malicious activity. Time synchronization, retention, access to logs, and escalation procedures affect investigative value. Industrial teams also need to protect monitoring systems so an attacker cannot easily erase the evidence required for response.

Version and patch decisions should be revisited when exposure changes. A vulnerability that was previously accepted because a device was isolated may become urgent after a remote-access project or network redesign creates a new path. Conversely, a severe public vulnerability on an unreachable asset may justify a controlled maintenance plan rather than immediate disruption. Risk-based maintenance depends on current architecture, not static severity labels.

Use change management to preserve security intent

Operational environments change constantly: production recipes, network paths, vendor devices, software versions, maintenance accounts, and support contracts all evolve. Change management helps evaluate whether a modification affects zones, conduits, security requirements, backups, monitoring, or recovery procedures. ISA IC37 candidates should recognize unauthorized or undocumented change as a security risk even when the change itself appears technically harmless.

Emergency change deserves special attention. Plants sometimes need rapid action to restore production, but emergency authority should not eliminate documentation and review. The team should record what changed, who approved it, what risk was accepted, and whether the environment needs follow-up testing. Post-event review closes the loop between operational urgency and long-term control.

Prepare incident response for operational constraints

Industrial incident response must protect people and process as well as information. Isolating a compromised system may be correct from a cyber perspective but dangerous if the asset supports a safety-critical or continuous process. The approved incident response lifecycle is useful when candidates add operational decision points, engineering authority, safety coordination, and vendor support.

Preparation determines whether those decisions can be made quickly. Contacts, escalation thresholds, evidence procedures, network diagrams, clean backups, replacement equipment, offline documentation, and defined containment options should exist before an incident. Exercises should include realistic degraded conditions so teams learn how cyber response interacts with process shutdown, manual operation, recovery, and regulatory reporting.

Incident exercises are valuable when they include engineering actions rather than only communications. Teams can practice isolating a conduit, restoring a known configuration, validating controller logic, switching to manual operation, or working through vendor escalation. These exercises reveal missing permissions, undocumented dependencies, and unrealistic recovery assumptions before a real incident forces the organization to discover them under pressure.

Protect backups as part of the recovery architecture

Backups are often treated as an IT function, but industrial recovery may require controller programs, engineering project files, workstation images, historian data, network-device configurations, certificates, licenses, and vendor-specific information. Candidates should understand what must be backed up, how often, where copies are stored, who can restore them, and how restoration is tested.

Resilience also depends on clean recovery. A backup captured after compromise can restore the attacker along with the system. Protected offline or otherwise isolated copies, version history, validation, and documented rebuild procedures reduce that risk. Recovery testing should verify not only that files can be retrieved but that the industrial function returns to a known and safe operating state.

Audit readiness improves when evidence is generated by normal work. Change tickets should reference affected assets, backup tests should record restoration results, vulnerability exceptions should show ownership and expiry, and incident records should capture lessons learned. When these records are created only before an audit, they are likely to be incomplete or inaccurate. Routine evidence also helps managers see trends and decide where additional engineering effort or replacement funding is justified.

Troubleshoot security events without losing process context

ISA IC37 includes operational diagnostics because many incidents begin as ambiguous symptoms: a device becomes unreachable, latency increases, an operator loses access, a service restarts, or network traffic changes. Candidates should gather evidence systematically and avoid making multiple untracked changes at once. Network paths, logs, recent maintenance, device health, process conditions, and security alerts all help narrow the problem.

The distinction between fault and attack may not be obvious initially. A failed switch can resemble denial of service; a misconfigured account can resemble credential abuse. Good troubleshooting preserves evidence while restoring safe operation. When teams jump directly to a cause without testing alternatives, they risk both extended downtime and missed compromise.

Continuous improvement should look for systemic patterns. Repeated emergency access, repeated expired certificates, recurring backup failures, or recurring firewall exceptions may indicate a design or ownership problem rather than isolated operator mistakes. The maintenance team should be able to escalate those patterns back into architecture, procurement, training, and governance so the program improves instead of repeatedly treating symptoms.

Keep the program auditable and continuously improving

Operations and maintenance generate the evidence that shows whether the cybersecurity management system is working. Patch records, access reviews, incident reports, change tickets, backup tests, training records, vulnerability decisions, firewall reviews, and exercise results can reveal both compliance and performance. ISA IC37 candidates should see audit readiness as the natural result of disciplined operations rather than a documentation scramble before an assessment.

Continuous improvement means using failures, incidents, near misses, audit findings, and technology changes to adjust the program. Controls that generate excessive exceptions may need redesign; recurring patch delays may indicate lifecycle or supplier problems; repeated remote-access issues may show that the architecture is too dependent on emergency processes. Strong maintenance keeps the ISA/IEC 62443 design alive as the environment changes.