Certified: The CompTIA SecOT+ Audio Course

In this episode, we’re going to take the word risk and turn it into something you can actually reason about without needing advanced math or years of experience. Beginners often hear that risk equals likelihood times impact, and they either accept it as a slogan or they get stuck trying to make it precise. In operational technology, you need a practical model because decisions are real, budgets are limited, and changes can affect safety and uptime. Modeling likelihood and consequence is not about predicting the future perfectly, it is about comparing scenarios so you can choose what to address first and what to monitor. OT makes this harder because the consequences can be physical, the systems can be old, and the constraints can be strict, so you cannot simply copy the approach used in office environments. The good news is that you can build useful models using common-sense variables as long as you stay disciplined about what you are measuring and what you are assuming. When you learn to think in terms of likelihood and consequence, you start seeing why certain controls matter, why certain weaknesses are urgent, and why some scary-sounding issues are not actually top priority in a specific plant.

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 good place to start is understanding what likelihood really means in OT risk discussions. Likelihood is not a single magical probability number that you can look up and trust, because real-world attacks and failures depend on context. In practice, likelihood is your best estimate of how plausible it is that a specific bad thing will happen within a certain timeframe, given the environment and the threat landscape. That estimate is shaped by variables like how exposed the system is, how attractive the target is, how capable the attacker might be, and how easy it is to exploit weaknesses. Likelihood also depends on how often the environment creates opportunities, such as frequent remote access, frequent vendor connections, or frequent configuration changes. Beginners sometimes confuse likelihood with vulnerability severity, but a severe vulnerability on a system with no practical path to exploitation may have lower likelihood than a moderate weakness on a highly exposed path. In OT, you also consider accidental causes that can lead to similar outcomes, like misconfigurations or maintenance errors, because risk is about harmful outcomes, not just malicious intent. When you treat likelihood as a structured estimate rather than a guess, you can talk about it clearly and improve it over time.

Exposure is one of the strongest drivers of likelihood, and it is worth defining carefully. Exposure is about how reachable an asset or system is, and how many pathways exist that could be used to interact with it. In OT, exposure can include network pathways from business systems into control zones, remote access services used for support, portable media used to move files, and even physical access to cabinets and consoles. More pathways usually means higher likelihood because each pathway is a chance for mistakes or misuse. Exposure also includes how tightly those pathways are controlled, such as whether access is time-limited, whether authentication is strong, and whether activity is monitored. A remote access path that is always on and poorly monitored creates a very different likelihood profile than a path that requires approvals and is enabled only during planned windows. Beginners often focus on whether something is connected to the internet, but in OT the more common risk is internal connectivity and trusted pathways that attackers can abuse after gaining an initial foothold. Exposure is therefore not just a yes or no question, it is a gradient that can be reduced by design choices. When you reduce exposure, you often reduce likelihood without having to change the asset itself.

Threat actor capability and intent are also variables that shape likelihood, but they are often misunderstood. Beginners sometimes imagine a single type of attacker, like a mysterious hacker, but in reality threats range from opportunistic criminals to insiders to highly capable groups. A low-capability attacker might exploit common weaknesses if they are easy and widespread, while a high-capability attacker might patiently pursue a specific target because of its strategic value. In OT, some threat actors may aim for disruption, some may aim for extortion, and some may aim for long-term access and intelligence. Likelihood increases when an environment is attractive and when the pathways and weaknesses match the attacker’s capabilities. This is why an OT site connected to a larger enterprise network can inherit likelihood from enterprise exposure, because attackers might enter through common IT pathways and then move toward OT. It is also why some risks are seasonal or situational, like during major maintenance periods when many vendors are connected and many changes are happening. When you model likelihood, you are implicitly modeling the match between an attacker’s opportunity and the environment’s weaknesses. You do not need to name every group, but you do need to think about capability levels and motivations in a realistic way.

Now let’s turn to consequence, because consequence is what makes OT risk feel different from many other kinds of cybersecurity. Consequence is the size and nature of harm if the scenario happens, and in OT that harm can touch people, equipment, the environment, production, and quality. It is not just about data loss or inconvenience, it can be about physical safety and sustained operational disruption. Consequence also has time dimensions, because a short disturbance can be manageable while a prolonged disruption can become a crisis. A plant might survive a brief loss of visibility, but a day-long loss might force shutdowns or create unsafe conditions. Consequence is also shaped by how reversible the harm is, because some harms can be repaired quickly while others require long replacement cycles or regulatory reporting. Beginners often think consequence is only financial, but in OT it often includes safety and compliance outcomes that cannot be reduced to dollars without losing meaning. Modeling consequence therefore starts with identifying categories of harm and understanding which categories dominate for a specific asset or process. Once you know what kind of harm matters most, you can prioritize controls that reduce those harms directly.

A useful consequence model includes both direct and indirect effects, because OT incidents often cascade. The direct consequence might be a controller being unavailable, but the indirect consequence could be a safety interlock triggering, a production line stopping, and downstream processes being forced into abnormal operation. Indirect effects can include supply chain disruption, customer impact, and reputational damage if the event becomes public. There can also be secondary safety risks, such as rushed manual operations or maintenance actions taken under pressure that increase the chance of human error. Beginners sometimes imagine a clean, single effect, like a system goes down and then it comes back up, but real OT incidents can create a chain of small disruptions that compound. This is why consequence modeling benefits from thinking in terms of what depends on the asset and what happens when the system behaves incorrectly, not only when it stops. Integrity failures, where the system runs but with wrong data or wrong logic, can have severe consequences because they can quietly produce unsafe or defective outcomes. When you consider cascading effects, you get a more honest picture of what hurts most and why. That honesty is what helps decision-makers invest in the right protections.

Recovery capability is a major consequence modifier, meaning it can reduce the impact even if the event happens. Two facilities might face the same likelihood of a ransomware event affecting systems that support operations, but the consequences can be dramatically different depending on backups, restore procedures, and tested recovery paths. In OT, recovery is not just restoring files, it can include restoring known-good configurations, validating that control logic is correct, and bringing processes back safely. If recovery is slow, consequence increases because downtime extends and the organization may be forced into risky workarounds. If recovery is fast and reliable, consequence decreases because the incident becomes a disruption rather than a catastrophe. This is why resilience investments can be so valuable, because they change consequence even when you cannot fully change likelihood. Beginners sometimes focus on preventing every incident, but prevention is never perfect, so consequence reduction through recovery is a realistic and powerful strategy. Modeling consequence should therefore include how long it would take to restore safe operation, not just what would be lost. When leaders understand that time-to-recover is a controllable variable, they can make better decisions.

Now we can bring likelihood and consequence together in a way that drives real decisions. The main purpose of combining them is prioritization, because you want to focus first on scenarios that are both plausible and harmful. In OT, a high-consequence scenario with low likelihood might still deserve attention if the consequence is catastrophic, especially for safety-critical systems. Conversely, a high-likelihood scenario with low consequence might be managed through routine controls and monitoring rather than urgent investment. The blend is where risk discussions become practical, because you can explain why you are working on segmentation first, or why you are improving remote access controls before tackling lower-impact issues. Beginners often get stuck because they want one single risk number, but in practice you need a ranking and a narrative. A risk model should help you say, these are the top risks because they are plausible in our environment and would cause these specific harms. It should also help you identify quick wins, where a control change can reduce likelihood significantly without creating operational disruption. When your model produces clear priorities, it has done its job.

It is also important to recognize that risk variables interact, which means changing one variable can influence others. For example, increasing connectivity for remote monitoring can increase exposure and therefore likelihood, but it might also improve detection and response, which can reduce consequence. Tightening access controls can reduce likelihood, but if done poorly it can slow response and increase consequence during emergencies. That is why risk modeling in OT must consider tradeoffs, not just one-direction improvements. Beginners sometimes assume every security control is a pure benefit, but in OT a control can introduce friction that affects operations, so you need to model how it will behave during normal work and during abnormal events. A practical risk model includes these considerations by asking, what changes when we implement this control, and how might people work around it. Workarounds can increase likelihood by creating shadow access paths or undocumented changes, which is why good controls are designed with usability in mind. Risk modeling therefore is not only technical, it is also behavioral and operational.

Another useful concept is uncertainty, because many risk variables in OT are not known with confidence. You might not know the full asset inventory, you might not know all remote access paths, and you might not know how old some vulnerabilities are because firmware versions are unclear. When you lack confidence, your risk estimate is less reliable, and uncertainty itself becomes a factor. One practical way to handle uncertainty is to treat it as a driver for investigation, meaning you prioritize actions that reduce uncertainty when the potential impact is high. For example, if you are unsure whether a critical zone has an undocumented conduit to the business network, you might prioritize validating that boundary because the consequence of being wrong is large. Beginners should understand that risk models are built from information, and improving information quality can improve decisions even before you implement new controls. This is why discovery, mapping, and documentation are so often early priorities in OT security programs. When uncertainty decreases, both likelihood and consequence estimates become clearer, and teams can argue less and act more. A good risk model makes gaps visible so they can be closed.

Finally, modeling likelihood and consequence should lead to a repeatable way of talking about risk that is honest, calm, and actionable. The model should help you choose controls that reduce exposure, improve detection, and strengthen recovery for the scenarios that matter most. It should also help you communicate tradeoffs, like why a certain patch cannot be applied immediately but a compensating control reduces likelihood in the meantime. Over time, as the environment changes, you revisit the variables and update your estimates, because risk is not static in OT. The biggest beginner mistake is treating risk as a one-time calculation, when it is really a way of thinking that gets sharper as you learn more about the environment and as you measure what works. When you can explain what makes a scenario plausible, what makes it harmful, and what changes would reduce either side of the equation, you are doing real risk management. That is how likelihood and consequence become practical tools rather than abstract terms, and that is what drives better decisions in OT security.