That's not always obvious from a statement of work. The scope might say "enterprise network" or "internal assessment" and never mention OT at all. Or it might reference OT but scope it as a separate engagement with a different team, different timeline, and no connection to the IT findings.
The result is a gap. Your IT environment gets tested. Your OT environment gets tested. But nobody tests the paths between them, which is exactly where the real risk lives.
Before your next assessment, ask your vendor these five questions. The answers will tell you whether they're actually testing what matters.
1. "Can you demonstrate an attack path from our IT network into our OT environment?"
This is the question that separates an IT pentest from one that actually addresses industrial risk. If the vendor tests IT and OT as isolated environments, they'll miss the pivot paths that real adversaries use. Compromised Active Directory credentials, lateral movement through a flat network segment, a poorly secured jump host. These are the paths that turn an IT compromise into an OT incident. If the answer is "that's outside our scope," you have a gap.
2. "Who on your team has hands-on experience inside control system networks?"
OT is not IT with different IP addresses. The protocols are different, the failure modes are different, and the consequences of getting something wrong are physical, not just digital. An operator who has worked inside SCADA environments, tested PLCs, or assessed HMIs and knows the difference between Modbus, DNP3, and EtherNet/IP brings a fundamentally different skill set than someone who specializes in web apps or Active Directory. Ask for specifics. If they can't name the person and describe their OT background, they're likely planning to send an IT generalist.
3. "What's your safety protocol for testing in a live operational environment?"
This is the question that reveals whether the vendor has actually done this before. A qualified team will have a clear answer: what they will and won't touch in a live environment, how they handle discovery of devices that could affect physical processes, what their communication plan looks like if something unexpected happens, and how they deconflict with your operations team.
If the answer is vague or mirrors their standard IT rules of engagement, they haven't thought about it deeply enough.
4. "How do you handle shared credentials and segmentation gaps between IT and OT?"
A list of vulnerabilities sorted by CVSS score doesn't tell you what an attacker can actually do. What matters is the chain: how an initial foothold in IT becomes lateral movement, becomes privilege escalation, becomes access to a control system. If your vendor delivers a spreadsheet of findings without connecting them into attack paths, you're left to figure out the actual risk yourself. Ask whether the report will show complete paths from IT entry point to OT impact, with the evidence behind each step.
A vendor who tests these will find them. A vendor who doesn't know to look for them will walk right past them on the way to writing up a missing patch.
5. "Will your report show me the full path from initial access to OT impact, or just individual findings?"
If your current vendor can't answer these questions, that's worth knowing before the next engagement, not after.
A vendor who can answer all five of these well has probably done this before. They'll name specific people with OT experience. They'll describe safety protocols without hesitation. They'll talk about attack paths, not just findings.
What good answers sound like
Shared service accounts, VPN tunnels for remote maintenance, historians connected to both sides, flat network segments that span the boundary. These are common in industrial environments and they're the exact misconfigurations that create high-consequence attack paths.