Write Your OT Recovery Plan Before You Need It

Jori VanAntwerp

CEO and Founder at EmberOT || Web

For over two decades, Jori has enabled industrial and IT organizations to be successful in reducing risk, increasing compliance, and improving their overall security efforts. He has had the pleasure of working with companies such as Gravwell, Dragos, CrowdStrike, FireEye, McAfee, and is now CEO & Founder at EmberOT, a cybersecurity startup focused on making security a reality for critical infrastructure.

November is CISA’s Critical Infrastructure Security and Resilience Month. It’s a good reminder that recovery gets built on the calm days, long before an incident puts it to the test.

Anyone who has played an RPG knows the particular sting of a party wipe. You walked in with your best gear and your strongest spells, the fight turned, your healer went down, and you reached into the bag for the one item that revives a fallen party member. Empty. You spent all your gold on swords and never stocked the thing that brings you back from zero. The fight was lost back in the last town, at the shop you walked right past.

Recovery works the same way in OT. You build an OT recovery plan on the quiet days, well before you need it. This is a good month to talk about that, because the calendar is finally pointed at the half of the job we tend to shortchange.

The Month Is Pointed at the Right Thing

Hot on the coattails of Cybersecurity Awareness Month in October, November is Critical Infrastructure Security and Resilience Month, CISA’s annual push to get operators thinking past the front door.

This year, CISA wants every organization to “know its infrastructure and dependencies, understand the risks that matter most, make practical plans, and track progress so they can respond and recover quickly when something goes wrong” (note their use of the word “when” rather than “if” in that last part).

Most of what we spend time and budget on in OT is keeping attackers out: closing exposures, watching the perimeter, hardening the edge. That work is half the job, and I am not waving it off. The other half is what happens after something gets through, or a controller fails, or an update goes sideways on a Tuesday afternoon. Can you bring the process back, in the right order, fast enough that it never becomes a headline? That’s resilience.

Resilience is the calm side of security. A team that knows it can recover works with confidence instead of holding its breath. The goal here is simple: do the quiet work ahead of time that keeps a bad day survivable. No fear required.

Four Things to Build into Your OT Recovery Plan

CISA’s four practices for the month line up cleanly with what resilience actually takes in an OT environment.

1. Know your systems and what they depend on

You can’t recover what you can’t see, and you cannot recover it in the right order if you don’t know what leans on what. Dependency mapping is the least glamorous work in OT and the first thing everyone wishes they had done the moment an outage hits. Which controllers depend on which servers. Which processes share a power feed. Which systems quietly rely on a single engineering workstation nobody ever documented. Visibility into how your environment actually communicates, whoever you get it from, is the foundation the rest of this stands on.

2. Prioritize the risks that matter most

Be honest about which processes the business genuinely cannot run without, and which ones can sit down for a while without anyone outside the fence noticing. Put your preparation where the consequence is highest. A clear read of what truly matters beats a plan that treats everything as equally critical.

3. Write the recovery plan, and write the order

This carries the most weight and should not be skipped. An OT recovery plan documents the systems, dependencies, personnel, and procedures needed to restore industrial operations safely and in the right order. Recovery in OT runs as a sequence. Bring the wrong system back first and you can energize into an unsafe state, re-trigger the condition that took you down, or spend hours chasing a process that won’t stabilize because the thing it depends on isn’t back yet. A real plan goes past “restore from backup.” It covers who does what, in what order, with what fallback to manual operations, and how you confirm each step worked before moving to the next. A recovery plan that lives only in one senior engineer’s head is a single point of failure with a pulse.

4. Test it, then improve it

A plan you have never run is a guess. The only way to know it works is to walk it when nothing is on fire. Tabletop it. Say the sequence out loud. Find the step where the backup was never actually being written, or the call list went stale two years ago, or the manual fallback depends on a procedure nobody has practiced since commissioning. Those are cheap to fix on a calm day and painfully expensive to discover mid-incident.

Order of Operations

If you take one thing from this, make it the order of operations. Prevention asks how to keep the incident from happening. Resilience asks what comes back first when it happens anyway, and second, and third. That sequence is the real deliverable, and it falls straight out of your dependency map, which falls straight out of seeing your own environment clearly. You can start on that today without a single new purchase order.

Put Your OT Recovery Plan to the Test

The genuinely good news is that resilience isn’t a budget contest. An operator with a modest program and a well-practiced recovery sequence will have a far better day than one with an expensive tool stack and a plan nobody has ever opened. The work is knowable, and it’s doable. See your environment. Map what depends on what. Write the recovery order down. Walk it on a calm day.

We named this company after the bird that rises from its own ashes, and we did that on purpose. The phoenix doesn’t rise because the fire was gentle. It rises because coming back is built into what it is. Use this month to build that into your program, while the shop is still open and the bad day is still hypothetical.

No noise. Just signal.

~Jori 🤘🔥