What a Plant Manager Should Ask Their Team About OT Security
You don't need to be a security specialist to lead a plant that's well protected. You do need to ask the right questions, listen carefully to the answers, and notice when the answer is "I'm not sure." These twelve questions are a practical way to start that conversation with your operations, controls and IT staff.
Knowing what you have
1. Do we have an accurate, current inventory of our control system assets?
Every other security activity depends on this. If the team can't say which controllers, HMIs, servers, switches and programming workstations are on the network, along with their firmware and software versions, then patching decisions, vulnerability alerts and incident response all become guesswork. Ask when the inventory was last checked against what's actually on the network, not just against a spreadsheet.
2. How is the control network separated from the business network?
Segmentation limits how far a problem can spread. A good answer describes specific boundaries, such as an industrial DMZ and firewalls with documented rules. A worrying answer is "we have a firewall" with no one able to say what it allows, or a mention of computers that sit on both networks at once.
3. What's connected to the outside world, and who approved it?
Cellular modems on remote equipment, vendor cloud services and forgotten remote desktop connections are common blind spots. You want a list of every external connection, its purpose and its owner.
Controlling access and change
4. How do vendors and remote staff get into our control systems?
Remote access is one of the most common entry points into OT environments. Ask whether access goes through a controlled gateway, whether it requires multi-factor authentication, whether sessions are approved and time-limited, and whether anyone can see what a vendor did during a session. Shared accounts and always-on connections are red flags.
5. Who can change PLC logic or control system configuration, and how would we know if it changed?
Unauthorized or accidental logic changes can affect product quality, equipment and safety. A strong answer names a small group of authorized people, explains how changes go through management of change, and describes how the team would detect a change that didn't follow that process.
6. When we can't patch, what do we do instead?
Many control systems can't be patched quickly, or at all, without vendor approval and a planned outage. That's normal. What matters is that the team has a process for assessing vulnerabilities and applying compensating controls such as tighter segmentation, restricted access, allow-listing and monitoring until a fix can be applied.
Being ready when something goes wrong
7. Are our backups complete, offline and actually tested?
Backups of controller logic, HMI projects, historian configurations and server images are what turn a crisis into a recovery. Ask when a restore was last tested, whether copies are kept offline or isolated from the network, and how long a restore would take. An untested backup is a hope, not a plan.
8. Do we have an OT incident response plan, and have we practised it?
A plan written for the corporate IT environment rarely covers what to do when an HMI shows strange behaviour or a controller stops responding. Ask who makes the call to isolate the plant network, how operations would continue manually, who contacts vendors and authorities, and when the team last ran a tabletop exercise.
9. Would we notice unusual activity on the control network?
Many organizations have strong monitoring on their business network and almost none on their OT network. Ask whether anyone watches control network traffic, what would trigger an alert, and who would respond. Passive OT monitoring can provide this visibility without touching the process.
People, priorities and ownership
10. How do our vendors and contractors meet our security expectations?
Integrators, OEMs and service contractors often have deep access to your systems. Ask whether contracts include security requirements, whether vendor laptops are checked before connecting, and whether vendor accounts are removed when work ends.
11. Do operators and controls staff know what a security problem looks like?
The people closest to the process are often first to notice something odd. Ask whether they've had OT-specific awareness training, whether they know who to call, and whether they feel comfortable reporting something that might turn out to be nothing.
12. Who owns OT security here, IT or OT?
This may be the most important question. In many organizations, IT assumes OT handles plant security and OT assumes IT does. Ask for a clear answer about who's accountable for the control network, the boundary firewalls, remote access and incident response, and how the two teams work together. Shared responsibility only works when it's written down.
How to use these questions
These questions work best as the start of an ongoing conversation, not a one-time audit. A few suggestions:
Ask for evidence, not reassurance. "Yes, we have that" is a start; seeing the inventory, the firewall rules or the last restore test is better.
Reward honest gaps. If people are punished for saying "we don't know," you'll stop hearing about problems.
Prioritize by consequence. Focus first on the systems where a failure would hurt people, the environment or production most.
Revisit regularly. Plants change constantly. Ask again after major projects, vendor changes or staff turnover.
If several answers come back uncertain, that's not a failure. It's useful information about where to invest next.
How QBits Networks can help
If these questions surface more uncertainty than you'd like, a passive-first OT security assessment can provide independent answers to many of them, from asset inventory and segmentation to remote access. For the questions about readiness, OT incident response readiness work can help your team build and practise a plan that fits the plant. Tell us what you need through our contact page and we'll scope it with you.