Certified: The CompTIA SecOT+ Audio Course

In this episode, we’re going to focus on a part of O T security that can feel invisible until it breaks: stakeholder management, which is really the art of building trust, communicating clearly, and getting change accepted without turning every improvement into a conflict. For brand-new learners, it’s easy to assume security succeeds mainly through technical correctness, like choosing the right controls or spotting the right threats. In real Operational Technology (O T) environments, success also depends on people agreeing that the changes are necessary, safe, and worth the effort, because many controls require behavior change, scheduling change, or new routines that touch the production floor. When stakeholders don’t trust the plan or don’t understand why it matters, they resist, delay, or quietly work around it, and those workarounds often create the very risk the program was trying to reduce. The goal here is to understand who the key stakeholders are, why trust is fragile in O T settings, and how communication choices can either increase change acceptance or accidentally trigger pushback. By the end, you should be able to describe how stakeholder management protects operations by making security improvements predictable, respectful, and sustainable.

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 begin is with what a stakeholder actually is, because beginners sometimes treat the word as a label for executives only. A stakeholder is anyone who is affected by a decision, depends on the outcomes of a decision, or has authority over whether the decision can be implemented. In O T, that includes operators who run the process, engineers who design and maintain control systems, maintenance teams who keep equipment reliable, safety personnel who manage hazards and protective systems, and security teams who manage cyber risk and governance. It also includes leadership who owns business objectives and budgets, plus vendors and integrators who may have deep access and expertise. Stakeholders can be supportive, skeptical, or neutral, and those attitudes often come from lived experience with outages, rushed changes, or past “security projects” that broke something and then disappeared. A beginner-friendly mindset is to assume that every stakeholder cares about safety and stability, but they may have different fears about what security will do to their day. Stakeholder management starts by respecting those fears as real signals, not obstacles to bulldoze.

Trust is the central currency in stakeholder relationships, and in O T environments trust tends to be earned slowly and lost quickly. Operations teams often trust what is predictable, because predictability supports safe execution, stable schedules, and consistent quality. Security teams often trust what is controlled and observable, because control and observability reduce uncertainty and reduce the chance of unseen compromise. These are not opposing values, but they can clash when security introduces changes that feel unpredictable to operations, or when operations refuses changes that feel necessary to security. Trust is damaged when a change causes downtime without clear explanation, when security requests feel disconnected from production reality, or when exceptions are granted informally and inconsistently. Trust is strengthened when security shows up early in planning, listens to operational constraints, and delivers improvements that reduce risk without creating surprise disruptions. For beginners, it’s helpful to remember that trust is built from repeated small experiences, not from one persuasive meeting. If stakeholders repeatedly experience security as considerate and competent, change acceptance becomes easier over time.

Communication is how trust is built, but in O T it has to be the right kind of communication, not just more communication. A common mistake is to explain security in purely technical terms, because many stakeholders are not deciding based on technical elegance, they are deciding based on operational impact. Another common mistake is to communicate only when security wants something, which makes security feel like an interrupter rather than a partner. Effective communication in O T connects the security request to an operational outcome the stakeholder cares about, such as reducing the chance of a line stoppage, preventing misleading measurements, or ensuring that recovery after an incident is faster and safer. It also communicates what will not happen, such as what safeguards are in place to prevent disruption, what testing will occur, and what fallback exists if something goes wrong. Beginners should recognize that clarity is a safety feature, because unclear communication leads to assumptions, and assumptions lead to risky decisions on the floor. Communication that supports change acceptance is specific, calm, and grounded in the realities of how the plant runs.

Another important part of communication is choosing the right level of detail for each stakeholder group, because too much or too little detail can both create resistance. Operators often need to know what will change in their workflow, what symptoms to expect, and what to do if something behaves differently. Engineers often need to know what dependencies are being touched, what traffic flows might change, and how the change will be validated. Safety stakeholders need to know how the change interacts with hazards and protective layers, and whether any safety-related function could be affected. Leadership often needs to know how the change reduces risk and what resources or downtime it requires, because they are balancing multiple priorities. Security sometimes tries to deliver one message to everyone, but that usually fails because it either overwhelms some audiences or feels vague to others. A beginner-friendly rule is to keep the core story consistent while adjusting the supporting details to match what each group must decide. When people receive the detail they need, they feel respected, and respect is a foundation for acceptance.

Change acceptance is not just about agreeing in theory; it is about stakeholders being willing to live with the change day after day. In O T, many changes have long tails, meaning they introduce ongoing routines like access reviews, additional steps for remote support, new approval requirements, or new monitoring procedures. Stakeholders ask themselves whether the change will make their work harder, slower, or riskier, and they also ask whether the change will actually reduce the problems they fear most. This is why security needs to explain not only the security benefit but also the operational benefit, such as fewer mystery outages, clearer troubleshooting data, or faster restoration during incidents. It also helps to acknowledge tradeoffs honestly, because pretending a change has no cost makes stakeholders suspicious. Beginners should learn that change acceptance improves when security shows it understands the operational cost and has a plan to minimize it. When stakeholders see that security is making the change as easy as possible while still meaningful, they are more likely to support it and less likely to create workarounds.

A major reason stakeholders resist security changes is fear of downtime, especially unplanned downtime, and that fear is rational in industrial environments. Many production systems cannot be restarted casually, and even short interruptions can cause scrap, missed shipments, or unstable process conditions. This means the security program must treat uptime risk as part of the security design, not as an annoying constraint. Stakeholder management here involves making downtime risk visible and manageable through planning, testing, and staged deployment. For example, security can propose changes that start in less critical zones, validate behavior, and then expand carefully, rather than demanding a wide, sudden rollout. Security can also coordinate changes with existing maintenance windows and ensure rollback plans exist if something does not behave as expected. Beginners should see how this builds trust: when stakeholders experience security as careful and operationally literate, they become more willing to approve deeper improvements later. The most effective stakeholder conversations are often the ones that begin with operational safety and continuity, because those are shared priorities that everyone understands.

Stakeholder management also includes handling the reality that O T environments have strong informal power structures, not just formal job titles. The person who approves a change on paper may not be the person who can make it succeed in practice. A veteran operator might be the one everyone listens to during a crisis. A senior controls engineer might have the deepest understanding of legacy dependencies. A maintenance supervisor might control whether work can be scheduled without disrupting production. If security ignores these informal influencers, change acceptance may fail even if formal approvals are obtained. The goal is not to play politics, but to respect how work actually gets done and to involve the right people early enough that they feel ownership rather than surprise. Beginners should understand that stakeholder management is partly about mapping the real decision network, which includes both authority and influence. When informal leaders support a change, adoption becomes smoother because their support signals safety and practicality to everyone else.

Trust and communication become even more important when vendors and third parties are involved, because vendor needs often create the most contentious security debates. Vendors may request persistent remote access, shared accounts, or broad network visibility to support troubleshooting, and operations may want to grant it because uptime is the priority during failures. Security may see those requests as creating major exposure, especially if the vendor environment is outside the organization’s direct control. Stakeholder management means finding a path that supports operations while still reducing unnecessary risk, such as time-limited access, clear approvals, detailed logging, and controlled pathways that limit what remote sessions can reach. It also means setting expectations in calm times, not only during emergencies, because emergency decisions are usually riskier. Beginners should learn that stakeholder management is not about saying no to vendors; it is about turning vendor access into a governed process that preserves accountability. When vendors understand the rules and operations understands the protections, trust can increase rather than decrease.

Communication during incidents is a special case where stakeholder management can either stabilize the situation or increase chaos. During an incident, operations needs clear guidance on what is safe to do, what symptoms to watch, and what actions are being taken to contain risk. Leadership needs clear impact framing, such as whether production is stable and what recovery options exist, without overly technical detail that confuses decisions. Security needs information from engineering and operations to understand whether what looks like an attack might actually be an operational failure, because the response differs. Poor communication can lead to contradictory actions, like one team isolating a network path while another is relying on that path to stabilize the process. Stakeholder management here is about setting clear roles, using consistent terminology, and keeping messages focused on decisions and outcomes rather than speculation. Beginners should see that communication discipline during incidents is part of resilience, because it prevents fear from driving unsafe actions. Trust built before an incident pays off here, because teams cooperate faster when they already believe the program respects operations.

Another aspect of stakeholder management is managing expectations about what security can and cannot do, because unrealistic expectations create disappointment and resistance. If leadership believes security tools will detect every threat instantly, they may be angry when uncertainty remains during a real event. If operations believes security changes will never affect workflows, they may be angry when a control adds steps to remote support. Honest expectation-setting explains that security reduces risk but cannot eliminate it, and it explains that some friction is the cost of reducing exposure, but the friction will be designed to be as small and predictable as possible. This is also where evidence and benchmarking help, because stakeholders trust progress more when they can see tangible results over time, such as fewer uncontrolled access paths, clearer incident response routines, or improved recovery readiness. Beginners should learn that expectations are part of trust, because trust is not only believing people mean well; it is believing their promises match reality. When security communicates with humility and clarity, stakeholders are more likely to accept the inevitable uncertainties without turning against the program.

Change acceptance also depends on feedback loops, which means security must listen after changes are implemented and adjust when legitimate operational issues arise. In many environments, security makes a change, declares success, and moves on, while the people who live with the change quietly struggle, creating workarounds that reintroduce risk. A healthier approach treats implementation as the start of learning. If a control causes repeated friction, security should ask whether the friction is necessary, whether a process can be simplified, or whether additional training or tooling can remove pain without reducing protection. This does not mean every complaint should override security, but it does mean stakeholder concerns should be handled respectfully and systematically. Beginners should understand that listening is not weakness; it is risk management, because ignored frustration turns into bypass behavior. When stakeholders feel heard, they are more willing to report problems and less likely to solve them in risky ways. Over time, this creates a culture where security and operations co-own improvements instead of treating them as imposed burdens.

Finally, stakeholder management is about building a shared story of why the program exists and how success is measured, because shared stories align daily choices. In O T, success should be framed around safe operations, reliable uptime, and predictable recovery, with cybersecurity controls positioned as protective supports for those outcomes. When that story is consistent, it becomes easier to justify investments, schedule maintenance work, and resist risky shortcuts, because the decision is anchored in shared priorities. Stakeholders also need to see that the program is fair, meaning rules apply consistently, exceptions are governed, and decisions are made transparently rather than through favoritism. Fairness strengthens trust because people are more willing to accept constraints when they believe the constraints are applied evenly and for a clear purpose. Beginners should see that stakeholder management is not separate from security; it is how security becomes a stable operational practice. If you can build trust through respectful communication, tailor messages to stakeholder needs, involve real influencers early, manage vendor access with accountability, and maintain feedback loops that reduce friction without losing control, you will be able to guide O T security change in a way that people accept and sustain.