Episode 55 — Control and Treat OT Risk: Controls Catalogs, Documentation, and Acceptance Criteria
In this episode, we’re going to move from identifying and analyzing OT risk into the part that actually changes outcomes: controlling and treating risk. For beginners, risk can feel like something you measure and discuss, but not something you can shape, almost like bad weather you have to endure. In OT, risk is shaped by design choices, operational habits, and the controls you put in place, and treating risk means choosing what to do about it in a disciplined, repeatable way. Sometimes you reduce risk by implementing a control, sometimes you transfer parts of the risk through contracts or insurance, sometimes you avoid risk by changing the design or removing a pathway, and sometimes you accept risk because the cost or danger of change is greater than the risk you are living with. The challenge is that OT constraints make some controls hard to implement quickly, and the consequences of poorly planned changes can be severe. That is why control selection needs to be tied to criticality, failure modes, and realistic operational windows. By the end of this lesson, you should understand how control catalogs help you choose controls without guessing, why documentation makes controls durable, and how acceptance criteria turn risk decisions into clear commitments rather than vague comfort.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
A helpful starting point is to define what a control is in OT risk treatment, because the word can mean different things. A control is any measure that reduces the likelihood of a harmful event, reduces the consequence if it happens, or increases your ability to detect and respond before harm escalates. Controls can be technical, like segmentation and authentication, but they can also be procedural, like change management, access approvals, and backup testing. They can also be physical, like restricted access to control cabinets, and they can be organizational, like role clarity and incident response coordination. Beginners often imagine controls as products, like buying a tool and turning it on, but in OT many of the strongest controls are disciplined workflows that keep the environment predictable. Controls also have side effects, and in OT, side effects matter because a control that increases downtime risk or complicates emergency response can create new hazards. That means controls must be chosen and designed with safety and operations in mind. A control is therefore not just a security idea; it is a change to the system of work and the technical environment. Treating risk is the skill of choosing controls that truly reduce risk without introducing unacceptable new problems.
Controls catalogs are useful because they provide a structured set of control options that have been used successfully in many environments. A catalog is not a mandate to implement everything, and it is not a checklist that proves you are secure, but it is a menu that helps you avoid blind spots. In OT, a catalog can remind you to consider areas like identity and access, network segmentation, monitoring, configuration management, backup and recovery, third-party access, physical protection, and incident response readiness. Beginners sometimes think a catalog is for compliance only, but it can be valuable for practical engineering decisions because it creates common language between security and operations. When you say we need to strengthen restricted data flows or improve timely response to events, you are pointing to a known control area rather than inventing a new concept. Catalogs also help with consistency across sites, because they provide a shared set of control categories that can be adapted to local constraints. In practice, the catalog is a starting point, and the real work is choosing which controls matter most for the scenarios and assets you care about. When you use a catalog thoughtfully, it speeds up decision-making and reduces the chance of overlooking a critical control area.
Choosing controls in OT should start with the risk scenario and the failure path, not with what is easiest or most popular. If the scenario involves unauthorized changes to control logic, then controls that limit who can change logic, monitor for changes, and separate engineering tools from broader access become high priority. If the scenario involves ransomware affecting the ability to operate or recover, then controls like network segmentation, least privilege, and tested backups become essential. If the scenario involves misuse of remote support, then controls around remote access approval, strong authentication like Multi-Factor Authentication (M F A), session monitoring, and time-bounded access become critical. Beginners sometimes choose controls based on what they have heard in general cybersecurity talk, but OT controls must be matched to the process context and the constraints. This is why criticality matters, because the same control might be essential for a safety-related zone and less necessary for a low-impact monitoring system. It is also why operational feasibility matters, because a control that cannot be maintained will eventually be bypassed. A good control choice is one that breaks the failure path at a realistic point and is sustainable in daily operations. When controls are aligned with real scenarios, they become meaningful rather than decorative.
Control design in OT often involves compensating controls, which are controls that reduce risk when the ideal control is not possible. For example, if you cannot patch a legacy device quickly because of vendor constraints, you might compensate by isolating the device, restricting network access to it, and monitoring its behavior. If you cannot eliminate remote access because vendors require it, you might compensate by requiring approvals, limiting access windows, and logging all sessions. Beginners sometimes hear compensating and think it means less secure, but compensating controls can be very effective when they are chosen deliberately and layered properly. The key is to be honest about what the compensation does and does not achieve, and to ensure that the compensating controls are actually enforced, not just written down. In OT, compensating controls are common because legacy systems are common, and waiting for perfect conditions can leave risk unmanaged for years. Compensating controls also support safety because they can reduce exposure without forcing risky changes to fragile systems. When you understand compensating controls, you stop thinking in absolutes and start thinking in practical risk reduction under constraints.
Documentation is the part of risk treatment that turns a control from a one-time project into a durable capability. Without documentation, controls drift as people change roles, vendors change, and systems evolve. Documentation includes policies that define expectations, processes that define how decisions are made, standards that define minimum requirements, and Standard Operating Procedures (S O P s) that define how tasks are performed. In the context of risk treatment, documentation also includes control descriptions, control owners, and evidence requirements, meaning how you prove the control is working. Beginners sometimes think documentation is just for audits, but in OT it is often for recovery and coordination, because when something goes wrong, people need to know how the system is supposed to be protected and how to respond. Documentation also reduces the risk of inconsistent control application across sites, because it provides a reference that can be trained and repeated. Another important role of documentation is defining exceptions, because OT systems often require exceptions for legacy constraints, and unmanaged exceptions become hidden risk. When documentation is clear and maintained, it helps teams implement controls consistently and adjust them safely over time. Controls without documentation are fragile because they depend on memory and goodwill, which are unreliable during stress.
A risk treatment plan should connect controls to specific risks and acceptance criteria so the organization can track progress without guessing. An acceptance criterion is a clear condition that must be met for a control to be considered implemented and effective enough to treat a risk. For example, if the risk is uncontrolled remote access, an acceptance criterion might include that all remote access sessions are time-limited, require approval, use strong authentication, and are logged in a way that can be reviewed. If the risk is unverified recovery capability, an acceptance criterion might include that backups exist for critical configurations and that restores have been tested successfully within an acceptable time window. Beginners often assume a control is implemented once it is installed, but in OT, a control is only meaningful if it works under real operational conditions. Acceptance criteria prevent vague completion claims, because they force you to define what good looks like. They also help align stakeholders, because operations can agree on what is feasible and security can agree on what reduces risk. When acceptance criteria are clear, it becomes easier to know when to move on and what to improve next. This turns risk treatment into a disciplined program rather than a set of ad hoc projects.
Risk acceptance is a part of risk treatment that beginners often find uncomfortable, because it can sound like choosing to be unsafe. In reality, acceptance is sometimes the most responsible choice when a change would introduce greater risk, such as creating downtime risk on a safety-critical system, or when the cost of mitigation is far greater than the realistic risk. The key is that acceptance must be explicit and documented, not implicit through inaction. In OT, accepting risk should involve understanding the scenario, understanding the constraints, identifying compensating controls where possible, and defining a review period because risk is not static. Acceptance criteria apply here too, because you should define what conditions must remain true for the acceptance to be valid, such as maintaining segmentation, monitoring for changes, or ensuring that vendor support remains available. Beginners should also understand that risk acceptance is a leadership decision, not a quiet decision made by someone who is too busy to address a problem. When acceptance is formal, it becomes part of governance, and it can trigger future investment plans to reduce the risk when conditions allow. Formal acceptance reduces chaos because it prevents surprises and makes responsibility clear. It also supports honest reporting, because you can explain why a risk exists and what is being done to manage it.
Control effectiveness is another part of treatment that often gets overlooked, because it is easy to implement a control and then assume it works forever. In OT, controls can degrade as networks change, as exceptions accumulate, and as vendors introduce new pathways. Monitoring and periodic validation are therefore part of risk treatment, because they ensure controls remain aligned with the environment. For example, segmentation rules might drift, remote access accounts might proliferate, or logging might break silently after an upgrade. Beginners sometimes think the only way to measure controls is through incidents, but you can measure controls through evidence, such as access review records, change records, backup test results, and monitoring coverage. Control validation should be designed to be sustainable, because a validation process that is too heavy will be skipped. This is where controls calendars and routine reviews become useful, because they create predictable cadence. When controls are validated regularly, risk treatment remains real instead of theoretical. In OT, where long lifecycles and slow change are common, steady validation is what keeps controls trustworthy.
Another crucial aspect of treating OT risk is coordinating controls across teams so controls do not conflict with operations. A control that blocks access might reduce likelihood but increase consequence if it prevents legitimate emergency response. A control that requires complex approvals might be bypassed during urgent work, creating shadow pathways. This is why control design must consider usability and emergency conditions, not just normal operations. Beginners might think security always wins, but in OT, the best control is one that supports safe operations while reducing exposure. This can involve designing break-glass access that is controlled and logged, designing maintenance workflows that keep pathways temporary, and ensuring that the right people are involved in approvals so work is not stalled unnecessarily. It also involves clear communication, because confusion creates risk, and controls that are misunderstood are often misused. When controls are coordinated, they become part of the operational rhythm rather than an obstacle. That coordination reduces the chance of chaotic workarounds, which is a major source of hidden risk. Treating risk is therefore also about aligning people, not just configuring technology.
Finally, controlling and treating OT risk is about building a repeatable system for moving from risk discovery to risk reduction with clear decisions along the way. Controls catalogs help you choose options without missing important areas, but selection must be driven by scenarios, criticality, and feasibility. Documentation makes controls durable by turning expectations and procedures into shared reference, and acceptance criteria make progress measurable and defensible. Risk acceptance, when necessary, must be explicit and tied to conditions and review, not left to silence and drift. Over time, control validation ensures the program remains real, because OT environments change and controls can weaken without warning. For beginners, the most important takeaway is that risk treatment is not a single action, it is a disciplined practice of choosing controls that break realistic failure paths while respecting safety and reliability. When that practice is consistent, the organization becomes calmer because surprises shrink, decisions become clearer, and recovery becomes more confident. That is what it means to treat OT risk in a way that actually changes outcomes rather than simply producing reports.
