InfoSec Made Easy
OT Security Leadership | NCSC Guidance Series
Why every OT connectivity decision must start with a formal risk conversation — not a technical one
There is a moment that every security leader in an operational technology environment eventually faces. A business leader walks in with a compelling case: real-time analytics, remote monitoring, predictive maintenance, integration with the enterprise data platform. The benefits are real, the pressure is genuine, and the timeline is already set. The question that lands on your desk is not "should we connect this?" — it has already been decided. The question is "how do we connect this?"
That moment is exactly where Principle 1 of the NCSC's Secure Connectivity Principles for Operational Technology is designed to intervene. The principle is deceptively simple: before you design, before you architect, before you choose a vendor or write a firewall rule, you must be equipped to make a genuinely risk-informed decision about whether, how, and where connectivity is permitted in your OT environment. And that decision must be documented well enough that someone can audit it later.
For CISOs and security leaders managing OT environments, this principle is not just a compliance checkbox. It is the foundation on which every subsequent security decision rests. Get this right, and the eight principles that follow become coherent and defensible. Skip it, and you are building security controls on top of decisions that were never properly risk-assessed to begin with.
Why OT Connectivity Decisions Are Different
In IT environments, the consequences of a misconfigured connection are serious but typically contained to data: data exposure, data theft, service disruption. In OT environments, the stakes are categorically different. A cyber intrusion into an OT network can cause physical harm to people, environmental damage, and disruption to essential services that communities depend on. The NCSC guidance is explicit about this, noting that exposed and insecure OT connectivity is actively targeted by both opportunistic attackers and sophisticated state-sponsored actors.
This elevated risk profile changes what responsible connectivity decision-making looks like. In IT, a reasonable business case might be sufficient to justify a new integration. In OT, a reasonable business case is necessary but not sufficient. You also need a formal assessment of cyber risk, operational risk, obsolescence risk, and supply chain risk — all of which must be weighed against the business benefit before any design work begins.
The NCSC guidance frames this as a requirement for a formal business case, stored centrally and referenced throughout the design process. This is not bureaucracy for its own sake. It is the mechanism that ensures connectivity decisions are evaluated consistently, that the reasoning is auditable, and that senior accountability is established before any technical work begins.
💡 Pro Tip: Define risk thresholds in your business case before design work begins. This sounds like extra work up front, but it is the single most valuable thing you can do. When a vendor proposes a connectivity approach that pushes against your boundaries, you have a documented, agreed standard to measure it against — not a judgment call made under pressure. Thresholds also make escalation cleaner: anything that exceeds the threshold goes to the senior risk owner before it goes to implementation.
What the Business Case Must Document
The NCSC guidance specifies a minimum set of elements that every OT connectivity business case must address. These are not suggestions — they represent the baseline of informed decision-making for any new or modified connection into an OT environment.
Requirement: Is the connection actually required? What specific operational outcome does it enable? This forces clarity on whether the connection is genuinely necessary or whether it is a convenience that has been framed as a necessity.
Business Benefit: What measurable benefit accrues from the connectivity? This should be specific enough that it could be evaluated after implementation — not a vague claim about efficiency, but a concrete outcome like reduced maintenance cost, faster fault detection, or improved regulatory reporting.
Risk Tolerance: What level of cyber and operational risk is acceptable in pursuit of this benefit? This is where your organization's risk appetite becomes concrete. It is the answer to the question: "If this connection is exploited or fails, how much operational disruption, safety risk, or data exposure are we prepared to accept?"
Potential Impacts: What are the realistic consequences if this connectivity is compromised? This requires thinking about the OT system in question, the processes it controls, the people it affects, and the downstream dependencies. A compromised connection to a building management system has a different impact profile than a compromised connection to a water treatment control system.
Introduced Dependencies: Will the connection make your OT system reliant on external services or systems it was not previously dependent on? This matters enormously for isolation planning. If a critical OT process can only function when an external connection is active, you have created a dependency that will constrain your response options during an incident.
Senior Accountability: Who is the named senior risk owner for this connectivity? This is not the engineer who implements it. It is the business leader who is accountable if something goes wrong. Establishing this upfront changes the nature of the conversation and ensures that risk ownership lives in the right place in the organization.
📋 Example: Business Case in Practice
A water utility is evaluating a remote monitoring connection to allow a vendor to access SCADA systems for predictive maintenance. The business case documents: the requirement (reduce on-site maintenance visits by 40%), the benefit ($200K annual reduction in site attendance costs), the risk tolerance (no direct command capability; read-only telemetry access only), potential impacts (if compromised, vendor could gain visibility into system state but not alter setpoints), introduced dependencies (maintenance scheduling now relies on vendor connectivity availability), and senior accountability (Operations Director as named risk owner). This documented case becomes the reference point for every subsequent design decision — and the standard against which the vendor's proposed solution is evaluated.
The Obsolescence Problem: A Risk That Often Gets Overlooked
One of the most practically important aspects of Principle 1 is its treatment of obsolete products — what most practitioners call legacy systems. OT environments routinely contain equipment that is years or decades old, running software that no longer receives security updates and hardware that was never designed with modern network connectivity in mind. The NCSC guidance is frank about what this means: obsolete products should be treated as untrusted and should not be used to implement security controls.
This creates a genuine challenge for security leaders. You cannot simply declare all legacy OT systems off-limits for connectivity — in most cases, that would halt operations. But you also cannot connect them to modern networks and pretend they carry the same security properties as current-generation equipment. The business case framework is the mechanism for navigating this tension explicitly and deliberately, rather than letting it get resolved by default in favor of operational convenience.
The NCSC guidance identifies three specific ways that obsolete products compound security risk. First, they no longer receive security updates, which means known vulnerabilities accumulate over time with no vendor remediation. Second, they lack modern security capabilities — current authentication mechanisms, modern cryptographic standards, and current logging and monitoring features may be entirely absent. Third, maintaining the specialized knowledge needed to manage these systems is expensive and pulls resources away from modernization — creating a cycle where investment in legacy maintenance actually delays the improvements that would reduce risk.
There is also a subtler form of obsolescence that the guidance specifically names: self-established obsolescence. This occurs when an organization chooses not to apply available updates due to operational constraints — a patch that requires downtime, a firmware update that has not been tested in the specific OT configuration, a software version that is not compatible with older hardware. The result is the same as vendor-end-of-life: a device in a known vulnerable state, with no path to remediation, that becomes a liability when connectivity is extended to it.
💡 Pro Tip: Map every asset in your OT environment against vendor support status before any connectivity expansion. Assets at or past end-of-life get flagged as requiring compensating controls and a documented remediation timeline before new connectivity is approved. This turns a vague "legacy risk" problem into a specific, actionable list that can be managed and reported on. If the business case for new connectivity includes an obsolete asset, that fact must be explicitly documented — and the compensating controls must be specified before design begins, not after.
Operational Risk: The Other Half of the Equation
Security leaders sometimes focus so narrowly on cyber risk that operational risk gets underweighted in connectivity decisions. The NCSC guidance is deliberate about requiring both to be considered, and it identifies four specific operational risk factors that must be assessed before any new OT connection is approved.
The first is unintended process or safety impacts. Could the new connectivity introduce risks to the OT system's core functions or compromise its safety mechanisms? This is particularly important in environments where the OT system has safety instrumented systems — connections that introduce timing dependencies or communication overhead could, in edge cases, affect the responsiveness of safety functions.
The second is loss of connectivity. If the communications link fails or becomes unavailable, what happens to the OT process? This is a question about operational dependency, not security. But the answer has direct security implications: if critical processes depend on external connectivity, then any security event that disrupts that connectivity — whether it is an attack or a defensive response — becomes a safety or operational event too.
The third is new interdependencies and single points of failure. Are you creating dependencies on systems or services that were not designed for resilience? A business system outage that causes an OT process to shut down is a real scenario that has played out in real environments. The connectivity decision that creates that dependency is the one where operational risk must be weighed explicitly.
The fourth is manual fallback capability. If connectivity is lost, can operations continue manually? Is there a documented and tested procedure for that scenario? This question often reveals that organizations have built connectivity dependencies into their OT processes without maintaining the manual capabilities that previously provided resilience. Recovering manual operating procedures is not glamorous work, but it is essential for maintaining operational resilience in an environment where connectivity will, at some point, be disrupted.
Building a Risk Management Framework That Actually Works
Principle 1 does not just require a one-time risk assessment per connection. It calls for a comprehensive risk management framework that governs all connectivity decisions consistently over time. This framework serves two purposes that the NCSC guidance articulates clearly.
First, it ensures that connectivity decisions are evaluated against organizational risk appetite and threat context. Risk appetite is not a fixed constant — it can legitimately vary based on the criticality of the OT system, the maturity of compensating controls, and the current threat environment. A framework provides the structure to make those calibrations consistently and to document the reasoning when appetite thresholds are stretched.
Second, it ensures that cyber, safety, and physical risks are consistently considered together rather than separately. In many organizations, these risk domains are managed by different teams with different reporting lines. The risk management framework is the mechanism that forces them to be evaluated holistically for each connectivity decision, rather than allowing each domain to sign off in isolation without seeing the full picture.
The NCSC guidance aligns this framework with established standards, including ISO/IEC 27001 and ISA/IEC 62443-3-2, the latter of which is specifically designed for industrial automation and control systems risk assessment. The IEC 62443 Zones and Conduits model is also referenced as a practical tool for designing secure OT architecture — grouping assets with similar security needs into zones and defining controlled communication paths between them.
For security leaders who are building or maturing an OT security program, implementing this framework is foundational work that precedes everything else. Without it, every subsequent principle in this series becomes harder to implement consistently — because the decisions about what connectivity exists, why it was approved, and what risk was accepted will not be documented in a way that can be built upon.
Supply Chain Risk: The Dimension Most Organizations Underestimate
The final dimension of Principle 1 that deserves focused attention is supply chain risk. OT environments rarely exist in isolation — they typically involve a wide range of third parties in design, integration, and ongoing maintenance. Each of those relationships represents a potential entry point for connectivity risk, and each deserves the same risk scrutiny as the OT system itself.
The NCSC guidance asks five questions that every organization should be able to answer for each significant OT supplier. Can you influence the security controls in the supplier's solution? Does your contract allow you to define and enforce minimum security requirements? Do you have full visibility into what technologies are embedded in the supplied product — including hidden or undocumented components? How trustworthy is the supplier's own security posture? And does the supplier have a track record of responding to security issues responsibly?
These are not questions that can be answered after a system is deployed. They need to be part of the procurement and contracting process — which means they need to be in scope for the business case assessment that Principle 1 requires. If you cannot answer them favorably for a given supplier, that is risk that needs to be documented and either mitigated or accepted by the named senior risk owner before the connection is approved.
📋 Key Ideas: What Strong Principle 1 Implementation Looks Like
- Every proposed OT connection — new or modified — triggers a formal business case before design work begins.
- Business cases are stored in a central, auditable location and referenced throughout the design and review process.
- Named senior risk owners are assigned for all connectivity, not just high-risk connections.
- Obsolete assets are identified and flagged, with compensating controls documented before connectivity is approved.
- Operational risk factors — loss of connectivity, manual fallback, safety impacts — are explicitly addressed alongside cyber risk.
- Supply chain risk is assessed as part of the business case, not as an afterthought during implementation.
- Risk thresholds are defined in the business case so design decisions can be measured against agreed limits throughout the lifecycle.
What This Means for Regulatory Compliance Professionals
For those working in regulated sectors — energy, water, transportation, financial market infrastructure — Principle 1 maps directly to the audit trails and documented risk assessments that regulators increasingly expect to see. Regulations like NIS2 in Europe, the TSA Security Directives for pipelines and rail, and sector-specific frameworks for critical national infrastructure all require organizations to demonstrate that connectivity decisions were made with documented risk consideration.
The business case framework that Principle 1 describes is not just good security practice — it is the kind of documented evidence that regulators want to see when they ask how your organization assessed and managed the risks of increased OT connectivity. Organizations that implement this principle properly will find regulatory examinations significantly less stressful, because the evidence of informed decision-making already exists and is retrievable.
For aspiring CISOs, there is a career lesson embedded in this principle as well. The ability to frame OT connectivity decisions as structured risk trade-offs — with documented business benefit, quantified risk tolerance, identified impacts, and named accountability — is a skill that distinguishes security leaders from security technicians. Learning to operate at this level of structured risk governance is how technical professionals become organizational leaders.
💠Final Thought
Principle 1 is not about slowing down the business. It is about making sure that when you say yes to connectivity — and you will say yes, because the operational benefits are real — you say yes knowing exactly what risk you are accepting, who owns it, and what you will do if things go wrong. The organizations that get OT security right are not the ones that refuse connectivity. They are the ones that connect deliberately, document rigorously, and treat every new link into their OT environment as a risk decision that deserves the same scrutiny as any other significant business investment. That discipline starts here, with Principle 1, before the first line of architecture is drawn.
This article is part of the InfoSec Made Easy series on the NCSC Secure Connectivity Principles for Operational Technology. Read the full series at www.infosecmadeeasy.com.