Certified: The CompTIA SecOT+ Audio Course

In this episode, we’re going to focus on a step in OT risk assessments that sounds administrative but actually determines whether the entire assessment will be useful: scoping. If you are new to cybersecurity, it is tempting to think scoping is just deciding what to look at, like drawing a circle on a map and saying everything inside matters. In operational technology, scoping is more like drawing the borders of a country you plan to protect, then identifying which roads cross those borders, which neighborhoods are most sensitive, and where you can realistically enforce rules. If the scope is too small, you miss the real pathways risk uses to reach critical systems. If the scope is too large, the assessment becomes vague, slow, and frustrating, and nothing actionable comes out of it. OT makes scoping harder because systems overlap, vendors connect in, and business networks often touch industrial networks in ways that are not obvious at first glance. A well-scoped assessment gives you a defendable boundary, meaning you can reasonably say what is inside, what is outside, and what controls apply at the edges. When you can defend your boundaries, you can defend your systems.

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.

The first concept to learn is that scope is not just a list of devices, it is a statement about a system. In OT, the system includes assets, the networks that connect them, and the dependencies that enable them to function safely. For example, if you include controllers and sensors in scope but ignore the engineering workstation that programs them, you have scoped out a major pathway for change and compromise. If you include a production zone but exclude the remote access gateway that reaches into it, you have scoped out one of the most likely entry points. Beginners often scope by what is physically located in a plant, but modern OT often includes external dependencies like remote monitoring services, update repositories, time synchronization, and centralized identity services. Scoping therefore needs to start with the question, what are we trying to protect, and what must be true for that protection to work. The scope statement should describe the purpose, such as assessing cyber risk to a specific process line, a specific site, or a specific class of systems across sites. When the purpose is clear, the scope can be shaped to produce decisions that matter rather than a report that no one can act on.

A practical way to build scope is to start from critical outcomes and work backward to the assets and pathways that influence them. If the critical outcome is safe and reliable operation of a particular process, then the scope should include the control systems that directly regulate that process, the safety-related systems that prevent harm, and the supporting systems that enable monitoring and maintenance. This includes not only the control devices, but also the interfaces people use to interact with them, like operator workstations and engineering tools. It also includes the networks and communication paths that connect those components, because risk travels along connectivity and trust. Beginners sometimes assume that a device is in scope if it is technically part of OT, but a better rule is that it is in scope if it can change the behavior, visibility, or recoverability of the process. That approach naturally includes dependencies that are easy to overlook, like configuration backups, patch distribution paths, and authentication services. When you scope based on outcomes, you create a boundary that aligns with what the organization actually cares about. This is the first step toward a defendable assessment.

Networks are a central part of OT scoping because they define how assets interact and how an attacker or mistake can move. A common mistake is to scope only a network segment labeled OT and ignore the surrounding segments that connect to it, such as business networks, remote access zones, or vendor connectivity paths. In practice, the boundary you can defend is often not the entire OT environment, but the chokepoints where traffic crosses from one trust area to another. That is why scoping should identify zones of similar trust and the conduits that connect them, even if you do not use those exact terms. If you want to assess risk to a control zone, you should include the conduit that links it to the business zone, because that conduit shapes likelihood and determines which controls matter. You should also include any pathways that bypass the intended conduit, like a maintenance laptop that bridges networks or a wireless connection that provides alternate access. For beginners, it helps to imagine water flow, where you do not only care about the pool, you care about the pipes that feed it and drain it. Risk flows through connectivity, and scoping that ignores flow will miss the real problem.

Boundaries are not only network boundaries, they are also trust boundaries, which can be more subtle. A trust boundary is where the assumptions about who or what is trusted change, such as where a vendor system connects to a plant system, or where a shared service controls authentication for multiple zones. In OT, trust boundaries often appear in remote support scenarios, where an external party needs access for legitimate work, but that access must be controlled to prevent unintended exposure. They also appear in data flows, such as historian data being sent to corporate analytics, where the direction of flow matters and where reverse paths can create risk. A good scope identifies where trust shifts and ensures those interfaces are included, because those are the points where controls must be strongest. Beginners sometimes treat trust as a binary, like internal equals safe and external equals unsafe, but real OT environments include internal threats, compromised internal systems, and accidental misuse. Trust boundaries are therefore places where you apply controls because trust can be wrong. When scope includes trust boundaries, risk assessment becomes actionable, because it highlights where to enforce access control, monitoring, and segmentation.

Scoping also needs to define what kinds of risk you are assessing, because OT risk can include cybersecurity, safety, reliability, and compliance dimensions that overlap. If the purpose is specifically cyber risk to operational continuity, you will focus on scenarios that could disrupt or manipulate control. If the purpose includes safety risk, you may need to coordinate with safety teams and include systems that enforce safety functions. If the purpose includes supply chain or vendor dependency risk, you may need to include procurement and vendor management processes as part of scope, not just technical assets. Beginners sometimes think risk assessment is only about technical vulnerabilities, but scoping can include processes like change management and incident response readiness if those processes strongly influence consequence. The key is to be explicit, because if you do not define the risk dimensions, stakeholders will assume different things and the assessment will feel incomplete to everyone. A good scope statement clarifies whether the assessment covers availability, integrity, confidentiality, or some combination, and how those priorities are weighted. In OT, availability and integrity often dominate, but confidentiality can still matter depending on the environment. Being clear about what you are assessing prevents scope creep and keeps the work focused.

Another practical scoping decision is choosing the level of detail, because you can assess at the site level, system level, or asset level. A site-level assessment might focus on architecture, segmentation, remote access, and governance, producing broad improvements that apply across many systems. A system-level assessment might focus on a specific process area or production line, producing more targeted mitigations and more detailed understanding of dependencies. An asset-level assessment might focus on specific critical devices or applications, often when a particular asset is known to be fragile or exposed. Beginners often assume more detail is always better, but in OT, too much detail can stall progress because collecting perfect information can take longer than implementing high-value controls. The right level of detail depends on the decision you need to make and the resources available to act on findings. If leadership needs to decide whether to invest in segmentation or monitoring, a broader assessment might be appropriate. If a plant needs to reduce risk to a specific bottleneck process, a more focused system-level assessment might be better. Scoping is therefore also about aligning depth with decision needs.

Scoping must also account for constraints, because you should only include boundaries you can realistically defend and control. If an assessment includes systems that the organization does not own or cannot influence, such as a vendor-managed cloud service with limited visibility, you can still include it, but you must be clear about what control levers exist. In OT, constraints include maintenance windows, vendor support limitations, safety requirements, and staffing realities. A defendable boundary means you can define what controls apply at the boundary and who is responsible for enforcing them. For example, if a vendor requires remote access, you may not be able to eliminate the pathway, but you can defend it with time-limited access, approvals, strong authentication, and monitoring. If a legacy system cannot be patched, you can defend its boundary by isolating it, restricting traffic, and monitoring changes. Beginners sometimes interpret constraints as excuses, but in risk assessment, constraints are inputs that shape which mitigations are feasible. Scoping that ignores constraints produces recommendations that will be ignored, which wastes time and erodes trust.

A key part of scoping is identifying and documenting assumptions, because every boundary choice includes assumptions that can be wrong. You might assume a network segment is isolated, but a temporary connection could exist during maintenance. You might assume a data flow is one-way, but a misconfiguration could allow reverse connectivity. You might assume an asset inventory is complete, but unmanaged devices might exist. These assumptions matter because they directly affect likelihood and consequence estimates. In practice, a good scoping approach includes a short list of assumptions and then identifies which assumptions are high-risk if wrong. Those high-risk assumptions become priorities for validation, because validating boundaries is part of making them defendable. For beginners, this is an important mindset: uncertainty is not a failure, it is something you manage deliberately. A scoped assessment should include a plan to reduce uncertainty where it matters most, because doing so improves the quality of the risk decisions that follow. When assumptions are explicit, stakeholders can correct them early rather than discovering them during an incident.

Scoping also affects how you communicate results, because stakeholders need to know what the assessment covers and what it does not. If a risk assessment focuses on network segmentation and remote access but does not include physical security or supply chain risk, that should be stated clearly so the results are not misinterpreted. Communication matters because OT environments often have multiple overlapping assessments, like safety reviews, reliability studies, and compliance audits. If the scope is unclear, people may assume a risk was evaluated when it was not, which can create dangerous gaps. A clear scope statement also helps justify why certain issues were not addressed, which prevents the assessment from being seen as incomplete. It also helps focus follow-up work, because remediation efforts should align with the assessed boundary and the priorities found within it. Beginners should understand that scoping is part of honesty in risk management, because it sets expectations and prevents false confidence. A defendable scope produces defendable conclusions.

Finally, scoping is successful when it produces boundaries that can be protected through real controls and coordination. When you can describe the OT environment as zones with controlled conduits, defined remote access pathways, and clear ownership, you have created a structure that security can actually manage. The risk assessment can then evaluate those boundaries, find weak links, and recommend improvements that are feasible within constraints. If the scope is too fuzzy, the findings will be generic, like improve security awareness or patch systems, which do not tell you where to start or what to prioritize. If the scope is too narrow, you might secure one system while leaving the pathways around it open, which creates a false sense of safety. A well-scoped OT risk assessment balances focus with completeness by including the assets that matter, the networks that connect them, and the trust boundaries where controls must be strongest. When those boundaries are defendable, security becomes a practical discipline rather than a theoretical one. That is why scoping is not a formality in OT risk assessments, it is the step that makes the entire exercise meaningful.