Episode 56 — Track Inherited Risk and Maturity Indicators: What You Own Versus What You Inherit
In this episode, we’re going to focus on a kind of OT risk that often confuses beginners because it does not feel like something you caused, and it does not feel like something you can fix quickly: inherited risk. Inherited risk is the risk you receive because of the systems, designs, decisions, and constraints that already exist when you take responsibility for an environment. In OT, inheritance is common because equipment has long lifecycles, vendors have strong influence, and plants evolve through expansions and upgrades that leave behind layers of legacy choices. This means you may own responsibility for outcomes even when you do not own the original design, the original configurations, or the original tradeoffs. That can feel unfair, but it is also empowering once you learn to separate what you can change now from what you must manage over time. Maturity indicators help with that separation, because they are signals that tell you whether your program is becoming more capable and more predictable, even if you still carry inherited weaknesses. The goal here is to help you track what you own versus what you inherit, and to use maturity indicators to show progress without pretending the environment is perfect. When you can explain inherited risk clearly, you can prioritize realistically and communicate honestly.
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 defining inherited risk in concrete terms rather than treating it as a vague label. Inherited risk can include legacy devices that cannot be patched or upgraded easily, flat network designs that were built before segmentation became common, and remote access pathways that were created for convenience and never redesigned. It can include vendor dependencies that require certain access methods, proprietary systems that limit visibility, and documentation gaps that make recovery harder. It can also include organizational inheritance, like unclear ownership, informal change practices, and a culture of workarounds that developed because production pressures were constant. Beginners sometimes assume inherited risk means old equipment, but you can inherit risk from modern systems too, such as a new deployment that was rushed and left with weak defaults. Inherited risk is therefore not about age; it is about constraints and decisions that are already in place and that shape your current risk posture. The key is to identify what you cannot change quickly without major disruption and then treat it as a known condition that must be controlled through boundaries, compensating controls, and long-term planning. When you name inherited risk precisely, you stop blaming the past and start managing the present. That shift turns inherited risk into a category you can act on.
Understanding what you own versus what you inherit requires clear thinking about control levers, meaning what you can directly change and what you can only influence. You may not be able to change the firmware of a legacy controller immediately, but you can often change the network pathways that reach it, the accounts that can access it, and the monitoring that watches for unusual behavior. You may not be able to redesign the entire plant network at once, but you can often strengthen one boundary, reduce one unnecessary conduit, or create a controlled remote access landing zone. You may not be able to rewrite vendor code, but you can require vendor session logging, time-limited access, and vulnerability notification processes. Beginners sometimes think ownership equals physical ownership, like who bought the device, but in risk management, ownership is about responsibility for controls and decisions. You own the decision to accept, mitigate, or plan replacement, even if you did not create the constraint. This is why the phrase what you inherit matters, because it explains why some risks cannot be solved quickly, but it does not remove responsibility for managing them. A mature program distinguishes between immediate controls and long-term remediation, and both are forms of ownership.
Inherited risk is often easiest to see through the lens of technical debt, which is a concept that translates well into OT. Technical debt is the accumulation of design and maintenance shortcuts that were taken for good reasons at the time, like speed and cost, but that create long-term fragility. In OT, technical debt might include undocumented connectivity, shared accounts, unstandardized configurations, and patch backlogs created by constrained maintenance windows. It might also include inconsistent segmentation, where some zones are well separated and others are not, making the environment uneven and unpredictable. Beginners may assume debt is always a mistake, but debt is often a tradeoff, and the problem is not that debt exists, it is that debt must be managed deliberately. When you track inherited risk, you are essentially tracking where debt exists, what consequence it carries, and what the plan is to reduce it over time. That plan might involve compensating controls now and redesign later, or it might involve replacement during a scheduled modernization cycle. Treating inherited risk as debt helps you talk about it without blame and without panic. It becomes a backlog that can be prioritized rather than a shameful secret.
Now let’s talk about maturity indicators, because this is how you show progress even when inherited risks remain. A maturity indicator is a measurable sign that your OT security program is becoming more capable, more consistent, and more resilient. Importantly, maturity indicators are not the same as outcome metrics, like the number of incidents, because incidents can be rare or influenced by reporting changes. Maturity indicators focus on capabilities, such as whether you know what assets you have, whether remote access is controlled, whether changes are documented, and whether recovery has been tested. Beginners often think maturity is a vague concept, but in practice it is visible in repeatability and predictability. For example, if access reviews happen on schedule and exceptions are tracked, that is a maturity indicator. If backups are tested regularly and restores succeed within expected time, that is a maturity indicator. If network boundaries are documented and monitored, that is a maturity indicator. These indicators matter because they show you are building the ability to manage risk, not just reacting to it.
A key maturity indicator in OT is visibility, because without visibility you cannot distinguish inherited risk from unknown risk. Visibility includes knowing what assets exist, what firmware and software versions they run, what zones they reside in, and what communication paths connect them. It also includes knowing where remote access exists, which vendor pathways are active, and which management tools can make changes. Beginners sometimes think visibility is just an inventory list, but in OT, visibility is also about dependencies, such as which engineering workstation programs which controllers and which historian feeds which business systems. Improving visibility does not eliminate inherited risk, but it reduces uncertainty, and uncertainty is a risk driver because it hides weak links. As visibility improves, you can also identify which inherited risks are truly critical versus which are simply outdated but well isolated. That distinction prevents wasted effort and helps prioritize realistic improvements. Visibility maturity can be tracked through coverage, accuracy, and change awareness, meaning how often the inventory matches reality and how quickly you notice new assets and new connections. When visibility becomes reliable, the entire risk program becomes more grounded.
Another maturity indicator is control consistency, meaning whether key controls are applied predictably across systems and sites. In OT, inconsistency is itself a risk because it creates surprises, and surprises lead to wrong assumptions during incidents. For example, if one site uses time-limited vendor access and another uses permanent shared accounts, the organization inherits uneven risk that is hard to manage centrally. Control consistency includes access control standards, change management practices, monitoring coverage, and backup practices. Beginners might assume consistency means forcing every site into the same mold, but OT environments differ, so consistency should focus on outcomes and minimum requirements rather than identical implementation. A mature program defines what must be true, such as that remote sessions are approved and logged, even if the exact tooling varies. Consistency also includes exception handling, because exceptions are inevitable, and maturity is shown when exceptions are documented, reviewed, and bounded in time. If exceptions are unmanaged, inherited risk grows quietly, and progress becomes difficult to prove. When consistency improves, the organization becomes easier to defend because controls are not random.
Recovery readiness is another powerful maturity indicator because it reflects resilience, not just prevention. OT systems can be disrupted by many causes, including cyber events, hardware failures, and misconfigurations, and recovery capability determines whether disruption becomes disaster. A mature program tracks whether backups exist for critical configurations, whether restoration procedures are documented, and whether restore tests are performed and successful. Beginners often assume backups exist because someone said they do, but maturity is demonstrated when restores are tested and validated under realistic constraints. Recovery readiness also includes knowing what order to restore systems, who coordinates restoration, and how to verify that control logic and configurations are correct after restoration. This is especially important in OT because an incorrect restore can be unsafe, even if it brings a system back online. Recovery maturity can improve even when inherited risks remain, because you can often strengthen backups and procedures without touching fragile devices. When recovery readiness improves, consequence decreases across many scenarios, which is a practical win. It also builds confidence, which reduces panic and unsafe improvisation during incidents.
Change discipline is another maturity indicator that directly affects inherited risk, because uncontrolled change is how environments accumulate hidden weaknesses. In OT, changes happen during maintenance, upgrades, and troubleshooting, and the risk is not only the change itself but the loss of knowledge about what changed. A mature program tracks whether changes are documented, approved appropriately, and recorded with enough detail to support troubleshooting and recovery. It also tracks whether emergency changes are reviewed afterward so temporary shortcuts do not become permanent exposure. Beginners sometimes think change management is bureaucratic, but in OT it is a safety and reliability practice because it keeps the environment explainable. When change discipline improves, inherited risk stops growing as quickly, because new debt is not added silently. This creates a stable foundation for reducing old debt, because you are not constantly chasing new undocumented changes. Change discipline also supports security by making unauthorized changes easier to detect, because there is a baseline of what should happen. When change becomes predictable, the environment becomes defendable.
A mature approach to inherited risk also includes a clear strategy for long-term remediation, because some inherited risks cannot be solved with compensating controls alone. For example, a legacy system that cannot be patched and has insecure protocols may be isolated, but at some point replacement may be the only way to reduce risk further. Long-term remediation includes modernization planning, lifecycle management, vendor transition planning, and budgeting based on criticality. Beginners sometimes assume remediation is purely technical, but in OT it is often a project management and governance challenge because upgrades require coordination, validation, and training. Maturity is shown when the organization can plan these changes without chaos, with clear milestones, and with clear risk reduction goals. It is also shown when leadership understands that some risk is inherited and that reducing it takes time, not because teams are slow, but because safety and reliability require discipline. A well-managed remediation roadmap is itself a maturity indicator because it demonstrates control of the future, not just awareness of the past. When you can show a roadmap with priorities tied to criticality, you can defend why some inherited risks remain today. That honesty builds trust in the program.
Finally, tracking inherited risk and maturity indicators is about building a narrative of progress that is accurate, calm, and useful for decisions. Inherited risk explains why the environment has weaknesses that cannot be eliminated overnight, but maturity indicators show whether the organization is becoming more capable of managing those weaknesses safely. The most important beginner takeaway is that owning risk does not always mean you caused it, it means you are responsible for managing it with realistic controls, documentation, and long-term planning. When you separate what you can change now from what you must manage over time, you avoid both blame and paralysis. When you track maturity through visibility, control consistency, recovery readiness, and change discipline, you can demonstrate improvement even before major modernization is complete. Over time, those maturity gains reduce likelihood and consequence across many scenarios, while the remediation roadmap steadily reduces inherited weaknesses. That combination is what a strong OT security program looks like: honest about what it inherits, clear about what it owns, and disciplined about becoming more capable year after year.
