Certified: The CompTIA SecOT+ Audio Course

In this episode, we’re going to work through a deceptively simple tool that solves a surprisingly large number of O T security problems: the RACI model, which helps teams define who is responsible for doing work, who is accountable for outcomes, who should be consulted, and who should be informed. For brand-new learners, role clarity can sound like management talk, but in operational environments role confusion is one of the fastest ways to create outages, delays, and risky workarounds. When something changes in a plant, the question is rarely whether the change should happen, but who is allowed to approve it, who will execute it safely, who must be involved so it does not break production, and who needs to know afterward. Without clear ownership, tasks fall through gaps, people step on each other, and emergency decisions become personal favors instead of disciplined actions. In O T security, where engineering, operations, safety, and security often share overlapping responsibilities, the RACI model becomes a practical way to reduce friction and make security support operations rather than collide with them. By the end, you should be able to explain what RACI means, why it matters in O T, and how it prevents the most common ownership failures that create long-term cyber risk.

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.

To understand the RACI model, it helps to define each letter in plain language and to keep the definitions consistent. Responsible is the person or team that does the work, meaning they perform the task or make the change. Accountable is the person who owns the outcome, meaning they are ultimately answerable for the result and they have the authority to ensure the work happens correctly. Consulted are the people whose input is required before the work is finalized, because their expertise affects safety, reliability, or compliance. Informed are the people who need to know that the work happened and what the result was, but they do not need to approve or shape the decision in real time. A beginner misunderstanding is to think Responsible and Accountable are the same thing, but they are often different in O T. For example, an engineer might be responsible for implementing a network change, while an operations leader might be accountable because the change affects uptime and must align with production plans. Another beginner misunderstanding is to treat Consulted as optional, when in O T consultation is often what prevents a well-intentioned change from breaking a critical process. The power of RACI comes from making these roles explicit before work begins, rather than discovering them during an outage.

The reason RACI is especially valuable in O T security is that O T environments are built from shared dependencies, which means one team’s change can affect another team’s safety and performance. Engineering may manage controllers, control networks, and vendor systems. Operations may manage schedules, staffing, and the day-to-day running of the process, including responding to alarms and anomalies. Security may manage identity, monitoring, and broader risk governance, often with responsibilities that span both business networks and operations networks. On top of that, safety teams may have authority over certain kinds of changes, and vendors may control parts of the environment through support agreements. In that world, unclear ownership can lead to two damaging patterns: either nobody acts because everyone is waiting for someone else, or people act unilaterally because they feel pressure to fix something quickly. Both patterns increase risk. RACI reduces risk by creating a shared agreement about how work moves from decision to execution, and it supports operations by making the process predictable and faster under stress. Beginners should see RACI as a coordination tool that prevents security from becoming an interruption at the last moment.

In O T, one of the most common ownership problems is the orphaned system, where a system exists and is used but no one feels responsible for maintaining it. This might be a legacy server that runs an important service, a shared switch that many systems depend on, or a vendor-provided component installed years ago. Orphaned systems become hotspots for risk because patches are delayed, access reviews are ignored, and monitoring is inconsistent. RACI helps by forcing the organization to assign responsibility and accountability explicitly, even if the system is old and unpleasant to manage. Responsibility might sit with a technical team that has the skills to maintain the system, while accountability might sit with a leader who can allocate time and resources to keep it healthy. Consultation might include safety and operations if the system affects production, and informed might include leadership and compliance teams if changes have reporting implications. The key is that the system no longer lives in a gray zone. Beginners should learn that assigning ownership is a security improvement because it turns neglected risk into manageable work.

Another common ownership failure in O T is the unapproved change that happens during troubleshooting, often with good intentions. When production is disrupted, teams feel pressure to restore service quickly, and a vendor or engineer might adjust configurations, open access pathways, or bypass normal controls to get things running. Sometimes this is necessary, but the danger is when the emergency action is not recorded, not reviewed, and not reversed when the emergency ends. Over time, emergency changes accumulate and the environment becomes fragile, with hidden dependencies and insecure pathways. RACI supports better behavior by defining who is responsible for emergency actions, who is accountable for approving them, who must be consulted even under time pressure, and who must be informed afterward. It also helps define the after-action process, where changes are reviewed, documented, and either made permanent with proper controls or removed. Beginners should see that RACI does not stop emergencies, but it keeps emergencies from turning into permanent disorder. Clear roles make it easier to act quickly while still maintaining accountability.

RACI also helps solve a subtler problem: the difference between authority to decide and expertise to execute. In O T security, the people who understand how a system works are not always the people who have the authority to accept the risk of changing it. For example, a security team might have expertise in access control and monitoring, but operations leadership may be accountable for uptime and must decide whether a change is acceptable during a critical production period. An engineer might be responsible for implementing a segmentation change, but a safety leader might need to be consulted because the change could affect how alarms propagate or how emergency responses are triggered. If these roles are not explicit, decisions can become personal conflicts instead of structured tradeoffs. RACI makes the separation normal: one group can own the decision, another can perform the work, and another can provide required input, all without implying disrespect. Beginners should learn that shared environments require shared decision-making, and RACI is one of the simplest ways to make shared decision-making predictable rather than chaotic.

When RACI is used well, it also reduces duplication, which is a common hidden problem in security programs. Without clear roles, multiple teams may implement overlapping controls, maintain separate records, or run parallel processes that create inconsistency. For instance, engineering might maintain one list of critical assets, security might maintain another, and operations might rely on a third unofficial list. During an incident, these lists conflict and time is wasted arguing about which is correct. RACI encourages consolidation by assigning responsibility for maintaining the authoritative registry and by defining who must be consulted when updates occur. It also defines who must be informed so that everyone is operating from the same picture. In O T, consistency is a security control because inconsistent information leads to inconsistent decisions. Beginners should appreciate that a clear RACI reduces wasted effort and improves reliability, which directly supports operations.

It is also important to recognize that RACI is not only for routine work; it is critical for incident response, where time pressure amplifies role confusion. During a suspected cyber event in O T, teams may need to decide whether to isolate a zone, whether to switch to a degraded operating mode, whether to allow emergency vendor access, and how to coordinate communications. If these decisions are debated from scratch each time, response slows and mistakes become more likely. A good RACI approach defines who leads incident coordination, who is accountable for operational decisions that affect production, who must be consulted for safety implications, and who is informed for regulatory and business communication. This clarity helps teams act quickly without stepping outside their authority. It also reduces the risk that someone takes an extreme action, like shutting down systems unnecessarily or ignoring a threat because they fear disrupting production. Beginners should learn that in O T, good incident response is as much about role clarity as it is about technical detection.

Another beginner misunderstanding is to treat RACI as a one-time exercise, like filling out a chart and then forgetting it. In O T environments, systems evolve, responsibilities shift, and vendor relationships change, so RACI must be maintained. When a new platform is introduced, roles must be reassessed. When a vendor contract changes, access responsibilities may shift. When a facility reorganizes, accountability may move to different leaders. A mature program reviews RACI assignments regularly and updates them as part of governance, which keeps the model aligned with reality. This maintenance also builds trust, because teams feel less ambushed by changes when responsibilities are clear. Beginners should remember that role clarity is not static. If the model is not updated, it becomes inaccurate, and inaccurate role maps can be worse than none because they create false confidence.

As we wrap up, the RACI model provides a practical way to create clear ownership across engineering, operations, and security in O T environments where shared dependencies make confusion costly. Responsible defines who does the work, accountable defines who owns the outcome and has final authority, consulted defines who must provide input to keep changes safe and reliable, and informed defines who needs awareness after the fact. In O T security, RACI reduces risk by preventing orphaned systems, limiting untracked emergency changes, clarifying decision authority, reducing duplication, and improving incident response speed and consistency. It supports operations by making security work predictable and by ensuring changes are coordinated rather than disruptive surprises. Most importantly, it helps teams collaborate without constant conflict by turning personal debates into structured roles and agreed decision flows. If you can explain how RACI turns shared responsibility into clear action and accountability, you will have a powerful tool for making O T security programs work in real environments.