An OT Security Service Provider Still Needs an Internal Counterpart. Who Should That Be?

Begin with the service you actually purchased

Read the agreed scope with the provider. Establish what happens during normal operation and during an incident. Initial alert review, investigation, technical recommendations, implementation support, and recovery can be separate services. Ask the provider to explain the handoffs using a situation your plant team would recognize.

Write down the customer responsibilities beside the provider's work. If the provider needs accurate asset information, access approvals, local investigation, or decisions about operational impact, identify who supplies each one. A service meeting attended by an available employee is not enough if that employee cannot obtain the information or decisions the service needs.

The UK's National Cyber Security Centre recommends clearly defining provider and customer responsibilities, including incident reporting arrangements. Use that division of work to inform the internal position. The contract explains the service; the hiring brief explains who inside your business will make its dependencies work.

Use a responsibility map people can read

Treat this as a starting point for a conversation with your provider. Replace the example responsibilities with your actual arrangement and name both a primary contact and a backup. The map should also show which internal leader makes a decision when the people involved disagree.

The internal owner needs working access to the business

The role requires relationships with plant engineering, operations, IT, security, and whoever manages the supplier agreement. It needs enough technical understanding to ask useful questions and enough organizational support to get an answer. A coordinator who can schedule meetings but cannot recognize an unresolved technical question will need help from someone who can.

Consider a fictional provider that reports unusual remote access to a system during a production shift. The internal counterpart checks which local team can confirm whether the activity is expected, brings the evidence to the designated incident lead, and follows the agreed escalation path. The operations and engineering owners remain responsible for decisions within their authority. The counterpart keeps the handoffs moving.

Give an existing employee time to do it

An existing security or engineering employee may be well placed to own the relationship. Look at the recurring work before assigning it: service reviews, unresolved findings, access requests, site coordination, evidence requests, and incident preparation. Decide which of their current responsibilities will be reduced or reassigned.

If every service request waits behind production work, the problem may be capacity. If the employee cannot evaluate technical recommendations, the problem may be experience. If nobody can authorize action, the problem may be governance. A new hire helps when the role and its authority address the actual gap.

Interview with a real handoff in mind

Ask candidates to describe a finding they carried from an outside provider to an internal decision. Explore what information was missing, which people had to participate, and how the outcome was recorded. Look for an ability to explain the work clearly to both technical specialists and people responsible for operations.

Also ask how they handled an unresolved recommendation. Useful evidence includes clarifying the concern, identifying the person who could decide, and documenting the next action. Simply forwarding reports does little to show how the candidate would handle the responsibilities in this role.

Rehearse the arrangement before you need it

Run a discussion with the provider and internal contacts using a plausible incident scenario. Confirm how each person would be reached, which decisions they could make, and who covers their absence. The exercise can expose missing responsibilities while there is still time to assign them and include any resulting staffing need in the hiring plan.