OT/ICS Security Selling to the Plant Manager and CISO — 60-Min Training

The scenario that frames the whole training

Open the session with a deal the room recognizes, because the failure pattern in industrial cybersecurity is remarkably consistent and the training lands harder when it starts from a loss rather than a framework.

A rep works a global food and beverage manufacturer. The CISO is engaged, has budget line-item approval for an industrial visibility platform, and wants coverage across twenty-two production sites. The rep runs three calls with the security team, builds a business case around unknown assets and regulatory exposure, and gets verbal commitment. Then the deal goes to the plant leadership review, and the VP of Manufacturing asks one question: "What happens to the line if this thing touches a controller?" The rep does not have a crisp answer. The rep says the platform is "agentless and lightweight." That is not the answer the room needs. The deal moves to "next fiscal year" and never comes back.

That loss is not a pricing loss, a feature loss, or a competitive loss. It is a buyer-model loss. The rep sold to one buyer in a market that has three, and the buyer who was never sold is the one with the veto.

The training exists to make three things automatic for every seller in the room. First, that operational technology environments are governed by availability and safety, not confidentiality — an inversion of every instinct an IT security seller has built. In enterprise IT, a security control that degrades performance ten percent is an acceptable trade. On a production line, a control that introduces any nonzero probability of a controller fault is not a trade at all; it is a non-starter, because the downside is not a slow application but a stopped line, a spoiled batch, or a safety incident involving a person.

Second, that the discovery conversation has to be run with all three buyers present or it produces a partial picture that collapses later. A CISO's description of the OT environment is almost always incomplete, not because the CISO is careless but because the asset inventory genuinely lives with engineering, in spreadsheets, drawings, and the heads of people who have run the site for fifteen years.

Third, that the proof event is not a demo. It is a limited deployment at one real production site, scoped narrowly, with the plant manager as a named participant in the review. Anything else — a lab environment, a vendor-hosted sandbox, a slide deck of another customer's dashboard — leaves the veto holder unconvinced, because the objection was never about whether the software works. It was about whether the software is safe to attach to a running plant.

Run this scenario as a five-minute open. Ask the room to raise hands if they have lost a deal to a stakeholder who was never on a call. Most hands go up. That is the training's premise established without a single slide of theory.

How the three-buyer mechanism actually works

The mechanic worth teaching is that each of the three buyers evaluates a different object, on a different timescale, against a different definition of failure. Sellers who use one message across all three sound generic to all three.

The CISO evaluates portfolio risk and program coverage. The question underneath every CISO question is: can I represent our industrial exposure to the board and the auditors with something better than a guess? The CISO's failure mode is an incident they could not see coming or a regulator asking a question they cannot answer. Their timescale is the fiscal year and the audit cycle. They respond to coverage, integration with the existing security operations stack, and the ability to roll site-level findings into an enterprise view. They are usually the economic buyer, or at minimum the person who can create a budget line.

The plant manager or OT operations leader evaluates production continuity. The question underneath every question is: does this create a new way for my line to stop? Their failure mode is unplanned downtime, and it is measured in dollars per hour with a number they know by heart. Their timescale is the shift and the production week. They respond to passive collection, deployment that does not require touching control-system configuration, a named rollback path, and evidence from a peer facility. They rarely have budget authority. They almost always have veto authority, formally or informally, and pretending otherwise is how deals die at the ninety percent mark.

The chief engineer or controls engineer evaluates technical compatibility and truthfulness. Their question is: does this actually parse our protocols and understand our equipment, or does it produce a list of IP addresses and call it an asset inventory? Their failure mode is being handed a tool that generates noise their team has to triage. Their timescale is the project and the maintenance window. They respond to protocol specificity — Modbus, DNP3, EtherNet/IP, PROFINET, OPC UA, BACnet, IEC 61850 — and to vendor-platform depth across the equipment that is actually installed, whether that is Rockwell, Siemens, Schneider Electric, ABB, Emerson, Yokogawa, or Honeywell. This buyer is the hardest to bluff and the most valuable to win, because an engineer who believes you becomes the internal validator for the other two.

The practical coaching point inside this mechanism is sequencing. Sellers instinctively start with the CISO because the CISO takes the meeting. That is fine as an entry point and wrong as a strategy. The move is to use CISO access to earn an introduction to operations within the first two calls, framed as a request the CISO benefits from: "The part of this I do not want to get wrong is the deployment method, because that is what determines whether your plant leadership supports it. Can we get your operations counterpart into the next conversation so we scope it their way from the start?" That framing makes the multithread the CISO's idea, not a flanking move around them.

Teach the room a hard gate: no proof-of-value is scoped until an operations stakeholder has been in a live conversation. Not cc'd on an email. In a conversation. Reps will push back that this slows the cycle. It does, by one or two weeks early, and it removes the four-to-eight week stall that happens when operations enters late and asks to restart the evaluation on their terms.

The numbers that make discovery specific

The discovery block is where most of the 60 minutes should go, because discovery quality is the variable sellers actually control. Give the room a fixed sequence with the specific numeric probes that make each question productive rather than conversational.

Site and line scope. How many production sites, and how many are in scope for year one versus the full program? Deals scoped as "all sites" almost never start; deals scoped as "these three, then expand on results" start quickly. Push for a phase one of two to five sites. Ask which single site is the reference — the one where a win becomes the internal case study.

Known versus suspected asset count. Ask for the official inventory number, then ask what the engineer thinks the real number is. The gap between those two numbers is the entire value conversation. In most brownfield environments the engineer's estimate is meaningfully higher than the documented count, because devices get added during projects and never make it back to the spreadsheet. Do not attach a fabricated percentage to this. Ask them for their own estimate and use their number — it is more persuasive than any benchmark you could cite, and it is theirs, so they will defend it internally.

Protocol list. Get the actual list, in writing, before any technical validation. Most multi-site manufacturers run five or more industrial protocols because plants were built or acquired in different decades with different vendors. A platform that covers three of their five is a partial answer, and the chief engineer will find the gap during the proof if you do not find it during discovery.

Equipment vendor mix. Which control-system vendors dominate, by site? Protocol support and vendor-platform depth are different things — parsing EtherNet/IP is not the same as understanding a specific PLC family's firmware versions and known vulnerabilities. Ask which vendors matter most and be honest about relative depth.

Downtime cost per hour. Ask the plant manager directly. They know it. This number is the denominator for every business-case slide you will build, and it is also the reason the passive-collection conversation matters — if an hour of downtime is expensive, the risk tolerance for anything that touches a controller is effectively zero.

IT-OT boundary and data flow. How does industrial telemetry reach the security operations center today, if at all? Is there a demilitarized zone between the enterprise network and the plant network? Who owns the firewall rules between them — IT or engineering? That ownership question predicts how hard the integration project will be.

Existing contracts and timing. What is in place now, when does it renew, and what is the notice period? A twelve-month runway on an incumbent contract means your realistic entry is a complementary deployment at a site the incumbent does not cover, not a displacement.

Compliance drivers. Which frameworks are actually in play — IEC 62443, NIST SP 800-82, NERC CIP for electric utilities, TSA security directives for pipeline operators? Regulatory pressure is the most reliable budget accelerant in this category, and it varies enormously by sector. A pipeline operator and a discrete manufacturer have completely different urgency profiles.

Coach the room to run this as a single 60- to 75-minute joint session rather than three separate calls. Send a one-page pre-read 48 hours ahead listing the eight areas above, so each buyer arrives knowing which parts are theirs. The pre-read does double duty: it demonstrates that you understand the buying committee, and it prevents the session from becoming a security conversation that operations sits through silently.

On pricing, teach the shape rather than fabricated list prices. Industrial security platforms in the enterprise are generally priced on deployed footprint — per site, per monitored device, or per collection appliance — with annual subscriptions and material multi-year discounts. Per-site pricing is simpler to forecast and favors sites with high device density; per-device pricing punishes exactly the large, complex plants that need the platform most. Get the pricing model on the table in the first commercial conversation and model both structures against their actual footprint. Never quote a competitor's price from memory in front of a customer; if you do not have current, verifiable pricing, say the model and let procurement surface the number.

Trade-offs, alternatives, and where each one breaks

Sellers lose credibility fastest when they present their approach as strictly dominant. Teach the room the real trade space so they can navigate it honestly, and so the chief engineer stops testing them.

Passive network monitoring versus active querying. Passive collection via a span port or network tap introduces no traffic onto the control network and is the default expectation in most plants. Its limitation is real: passive collection only sees devices that talk during the observation window, so a device that communicates rarely may take days or weeks to appear, and firmware detail is limited to what the protocol reveals. Selective active querying — using the vendor's own native protocol, at a controlled rate, during a maintenance window — fills those gaps and produces richer inventory data. The honest positioning is that passive is the safe baseline and selective active is an option the plant controls, scheduled on their terms, never on by default. Reps who claim passive alone gives complete firmware-level inventory get caught by the engineer.

Displacement versus complementary deployment. If an incumbent is deployed and mid-contract, a displacement pitch generates resistance from the person who chose the incumbent. The alternative is a complementary deployment at sites the incumbent does not cover — which most multi-site programs have, because rollouts stall. This gets you deployed, produces comparative data on your terms, and puts you in position at renewal. The trade-off is a smaller initial deal and a longer path to the full footprint.

Standalone OT platform versus extending the existing IT security stack. Some organizations will try to extend endpoint and network tooling they already own into the plant. That approach is cheaper on paper and genuinely adequate for the enterprise-adjacent layers of the environment. It breaks at the control layer, where industrial protocol semantics matter — knowing that a message is a program download to a controller rather than generic traffic on a port is the whole point. Position on the layer, not on vendor superiority: "Your existing stack covers levels three and up well. The question is what sees level two and below."

Central rollup versus site autonomy. The CISO wants one enterprise console. Plant leadership often wants site-local visibility that does not depend on a corporate connection and does not expose plant data upward without control. Deployment architecture has to answer both, and the answer affects licensing, appliance count, and network design. Surface it in discovery rather than discovering it during the security architecture review.

Spend ten minutes of the training running this diagram as a live exercise. Give the room two customer profiles — a discrete manufacturer with continuous production and no maintenance windows, and a water utility with scheduled outage windows and a regulatory deadline — and have them walk each profile through the decision tree out loud. The point is not the diagram. The point is that reps who can articulate the trade-off sound like practitioners, and practitioners get the engineer's trust.

The pitfalls that kill these deals, and the specific fix for each

Close the training with the failure catalog. Each pitfall gets a name, a symptom sellers can recognize in their own pipeline this week, and one concrete corrective action.

Selling confidentiality to an availability buyer. Symptom: your deck leads with data exposure and breach cost. Fix: rewrite the first three slides around production continuity and safety, and let the compliance material follow. The plant manager does not lose sleep over exfiltrated engineering drawings. They lose sleep over a stopped line.

Leading with asset counts. Symptom: the demo's headline number is "we found 4,000 devices you didn't know about." Fix: convert every discovery finding into a consequence — this device is directly reachable from the enterprise network, this controller runs firmware with a known advisory, this connection crosses the boundary in a way nobody documented. Counts impress nobody who lives in the plant. Consequences do.

Skipping the engineer. Symptom: the technical validation is run entirely with the security team. Fix: require the controls engineer in the technical session and let them try to break your protocol claims. If your product genuinely covers their protocol set, this is the fastest trust you will ever build. If it does not, you learn it in week two instead of week ten.

Proving in a lab. Symptom: the proof-of-value runs in a vendor sandbox or on a test bench with a sample controller. Fix: one real production site, narrow scope, passive collection, plant leadership named in the review. A sample controller proves the software runs. It proves nothing about whether it is safe to attach to their plant, which is the actual objection.

Overpromising active scanning safety. Symptom: a rep says active discovery is "totally safe" to close a technical objection. Fix: never say that. Say what is true — active querying uses the vendor's own protocol, is rate-controlled, and is run only in a window the plant approves. Any claim of zero risk on a live control network is a claim the engineer knows is false, and it costs you the room.

Single-threading through the CISO. Symptom: every meeting has the same one attendee. Fix: the hard gate above — no proof-of-value scoping until an operations stakeholder has joined a live call. Track multithreading as a stage-gate field in the CRM, not as a coaching suggestion, because suggestions do not survive quarter-end pressure.

Accepting a procurement-only endgame. Symptom: at proposal stage the buyers disappear and procurement runs the close. Fix: make joint attendance a condition of any commercial concession. The line to teach: "I can bring pricing structure to the table, and I need the operations and security leads on the call when we do it, because the structure depends on the deployment footprint we agreed to." That is not a stall tactic; it is true.

Treating the close as the finish. Symptom: the account team disengages after signature and reappears at renewal. Fix: write the first-year milestones into the kickoff — site one deployed and inventoried, telemetry flowing to the security operations center, a quarterly review that both the CISO and plant leadership attend. In this category the renewal conversation is won by whether the second and third sites actually got deployed, and rollout stalls are the leading cause of flat renewals. Assign an owner to rollout pace at kickoff, not at month ten.

Citing benchmarks you cannot source. Symptom: a rep quotes a percentage from a report they have not read. Fix: use the customer's own numbers — their downtime cost, their estimated asset gap, their protocol list. Customer-supplied numbers are more persuasive than industry averages and cannot be challenged by a competitor with a different report. When you do cite published research, name the publisher and the year and be ready to send the document.

Run the last ten minutes as roleplay. One person plays the plant manager and delivers a single line: "Tell me why this won't stop my line." Every seller in the room answers in under sixty seconds. Repeat until the answers stop containing the words "lightweight" and "agentless" and start containing a described collection method, a rollback path, and a reference site. That drill is the highest-value ten minutes of the session.

Related questions

Who is the real economic buyer in an OT security deal?

Usually the CISO, since the budget line typically sits inside the security program. But economic authority and veto authority are separate. Plant leadership rarely holds the budget and frequently holds the ability to stop a deal, so both must be sold.

How long should an OT security proof-of-value run?

Long enough to observe normal production variation at one real site — typically several weeks, not several days. Passive collection needs time to see infrequently communicating devices. Scope it to one site with written success criteria agreed by all three buyers before deployment.

Can we win while an incumbent contract is still active?

Yes, through complementary deployment at sites the incumbent has not reached. Multi-site rollouts commonly stall, leaving uncovered facilities. Deploy there, generate comparative data, and enter the renewal cycle already installed rather than pitching displacement from outside.

What compliance frameworks should sellers know by name?

IEC 62443 for industrial automation security, NIST SP 800-82 for ICS security guidance, NERC CIP for bulk electric system operators, and TSA security directives for pipeline operators. Sector determines which one drives urgency and budget timing.

Should the training cover technical demo skills?

Only lightly. Sixty minutes is better spent on buyer modeling, joint discovery, and trade-off articulation. Deep demo mechanics belong in a separate sales engineering session where the audience can actually run the console.

FAQ

What is the single biggest reason these deals stall?

The plant manager entering the process late. Once operations is introduced after a technical evaluation is already underway, they often ask to restart on their terms, which adds weeks and frequently pushes the deal past the budget cycle. Multithreading early is the highest-leverage habit the training can install.

How do we answer "will this affect my controllers?" without overclaiming?

Describe the mechanism, not a guarantee. Passive collection observes a mirrored copy of traffic and injects nothing onto the control network. If selective active querying is in scope, say it is rate-controlled, uses the equipment vendor's native protocol, and runs only during a window the plant schedules. Then offer a peer reference at a comparable facility.

Should the CISO or the plant manager see the demo first?

Together, if possible. Separate demos produce two different understandings of the same product and force you to reconcile them later. If schedules make a joint session impossible, run the engineer first — their technical validation is the credential that makes the other two conversations easier.

How should sellers handle a request to extend existing IT security tools into the plant?

Acknowledge that the existing stack covers the enterprise-adjacent layers well, then move the conversation to the control layer, where industrial protocol semantics decide whether you can distinguish routine traffic from a controller program change. Frame it as a coverage-layer question, never as a claim that their current investment was wrong.

What should a seller do when the protocol list includes something the platform does not cover?

Say so immediately and scope around it. Propose phase one at sites where coverage is complete, and be explicit about the gap and any roadmap status you can actually verify. Engineers forgive a gap disclosed early and never forgive one discovered during a proof.

How do we make the renewal safe from day one?

Write the rollout schedule into the kickoff plan with a named owner and dated site milestones, and establish a quarterly review that both the security and operations leaders attend. Renewals in this category track deployment progress more than product satisfaction — a platform installed at one site out of a promised eight renews badly regardless of how well it works.

Sources

• https://www.cisa.gov/topics/industrial-control-systems
• https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories
• https://csrc.nist.gov/pubs/sp/800/82/r3/final
• https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• https://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx
• https://www.tsa.gov/for-industry/surface-transportation-cybersecurity
• https://www.enisa.europa.eu/topics/critical-information-infrastructures-and-services
• https://www.ncsc.gov.uk/collection/operational-technology
• https://attack.mitre.org/matrices/ics/
• https://www.nist.gov/cyberframework

Related on PULSE

• Hardware Security Module (HSM) Selling to the CISO and Cryptography Lead — 60-Min Training
• CNAPP Selling to the Cloud Security Architect — 60-Min Training
• API Security Selling to the Head of Platform Engineering — 60-Min Training
• Email Security Selling Against Phishing and BEC — 60-Min Training
• Cloud Security Posture Management (CSPM) Selling to the Cloud Architect — 60-Min Training
• Managed Security (MSSP) Selling — 60-Min Training