OT Change Management Lab

A browser-based training lab where you act as the change manager for a fictional chilled-food distributor. Over three OT changes you classify the change, assess risk, choose approvers, plan testing, rollback, the window, communications and verification, and then see a seeded outcome of what happened. It trains judgement about process weight, not tool syntax.

In operational technology a change can affect physical processes and product, many systems have long lifecycles and vendor-qualified versions, and some can only be reached on site. Testing often needs a copy of the controller or a staging mirror, rollback may need a known-good program and a person on site, and maintenance windows are tied to production and freeze calendars. The lab builds those habits.

In ITIL change enablement terms, a standard change is pre-authorised, low risk and follows a documented procedure, so it does not need case-by-case approval. A normal change is assessed and authorised by the right approvers or a change advisory board before it is scheduled. An emergency change is needed urgently to stop active or imminent harm, and is approved by a faster path, then reviewed afterwards. Urgency from a requester alone does not make a change an emergency.

It opens a new conduit into a Level 3 zone that reaches every site's control networks. In IEC 62443 terms a conduit between zones should be designed and reviewed. The architect owns the design, operations owns what the vendor can touch, and information security owns third-party access policy. A single approver for a change with a large blast radius is one of the penalised mistakes.

A good rollback is a known-good state that has been tried, with a stated time to restore and a way to run the process by hand in the meantime. In the PLC change that means a fresh, checksummed program export that has been reloaded on a spare CPU. An uninstall that has never been run, or a file on one laptop, is a hope, not a rollback.

Each change hides a few risks, such as a reused tag, a rule that is wider than needed or a downstream job that breaks. The seed fixes the dice. Choosing tests, rollback, windows and approvers that address a risk makes it much less likely to fire, and a good rollback or verification limits the damage if it does. The same seed, level and plan always give the same outcome.

Rookie shows a hint at each step and a "watch for" list of hidden dependencies, and has the lowest chance that an unmitigated risk fires. Pro hides the hints, but a good test plan reveals a hidden dependency as you choose it. Elite hides everything until the outcome and raises the chance that an unmitigated risk fires.

A Markdown change record per change, with type, risk, approvers, window, test, rollback, communications, verification, the simulated outcome and the process findings, and a CSV register of all three. Downloading and copying documents is Pro. You can read the same records on the debrief page.

The terms follow ITIL change enablement. The controls echo NIST SP 800-53 configuration management (CM-3 configuration change control, CM-4 impact analyses, CM-5 access restrictions for change), ISO/IEC 27001 Annex A 8.32 change management, and IEC 62443 for zones and conduits. The lab is a training exercise, not a compliance checklist.

No. Northmere Cold Chain, its people, systems and the northmere.example domain are invented, any IP range is from the RFC 5737 documentation space, and every outcome is simulated in your browser. Nothing here connects to a real controller or network.