Start with the system and the outcome
Operational technology (OT) includes programmable systems that monitor or affect the physical environment. In a utility, that may include control systems, substations, water treatment processes, communications links, building controls, or the supporting engineering workstations. These environments have performance, reliability, and safety needs that differ from a typical office network. NIST’s SP 800-82 Rev. 3 describes those differences and provides guidance for securing OT.
Before opening a requisition, name the operational outcome: maintain an asset inventory, improve remote-access controls, review network segmentation, support incident response, assess a project design, or help bring a site into a security program. A statement like “improve OT security” is a direction, not yet a job.
Describe the environment candidates will encounter
Give enough context for qualified people to recognize relevant experience without exposing sensitive details in a public posting. Specify the sector and type of environment, approximate scope, and where the role sits between security, engineering, operations, and IT. List representative technologies or protocols when appropriate, along with the expected mix of plant-floor, network, cloud, and enterprise systems.
Asset visibility is a practical starting point. The joint CISA and partner agencies’ OT asset inventory guidance recommends defining scope, assigning responsibility, and collecting useful asset attributes such as role, criticality, manufacturer, model, operating system, location, and supported communications. That suggests useful interview evidence: has the person built or maintained an inventory, worked with asset owners to validate it, or turned incomplete records into an actionable baseline?
Separate essential skills from useful extras
For each must-have, explain the task it supports. Examples might include experience with industrial control systems; network architecture and segmentation; vulnerability management adapted to operational constraints; identity and remote access; logging and incident coordination; or translating security requirements for engineers and operators. Mark vendor products, certifications, and sector-specific exposure as required only when the assignment truly depends on them.
Then state the level of responsibility. Is the person expected to advise, design, configure, assess, coordinate, or own delivery? Will they have production access, or provide analysis under an engineer’s change-control process? Clarity prevents a senior architect specification from being used for a hands-on analyst—or the reverse.
Make safety and operating constraints explicit
Ask operations leaders to describe change windows, approval paths, outage restrictions, site access, travel, on-call expectations, and incident escalation. A control that is routine in an enterprise environment may require additional coordination in a live operational environment. Candidates should be assessed on how they plan work with system owners, document assumptions, and escalate risk—not on whether they promise fast changes without understanding operational impact.
Also define the engagement’s boundary: deliverables, duration, work location, background or access steps, reporting line, and who supplies technical direction. For a temporary assignment, identify a named counterpart and an expected knowledge-transfer outcome.
Use a work sample that mirrors the role
A structured discussion or scenario can test judgment without asking a candidate to reveal confidential information. For example: “A site’s asset list is incomplete and a maintenance window is approaching. What information would you gather, who would you involve, and how would you communicate unresolved risk?” Score the same observable elements for each candidate: questions asked, respect for safety and authorization, prioritization, clarity, and ability to distinguish assumptions from verified facts.
NIST announced that an initial public draft of SP 800-82 Rev. 4 was published in September 2026, with comments due November 30, 2026. Treat the draft as a developing reference, not a finalized replacement for the current published guidance. The broader lesson for hiring is durable: define the actual system and mission, then assess evidence against the work.
A short intake checklist
- What operational outcome must this role deliver in its first 90 days?
- Which systems, sites, and teams are in scope?
- What access, change authority, travel, schedule, or on-call duties apply?
- Which skills are essential on day one, and which can be learned?
- How will the team judge safe, useful progress?
- Who will provide technical direction and accept the handoff?
A focused intake makes the search fairer and more efficient: candidates can judge the opportunity accurately, hiring teams compare relevant evidence, and the person who joins arrives with a realistic picture of the work.