How to Scope an OT Penetration Testing as a Service Program

An effective OT penetration testing as a service program starts with a precise scope. The scope must account for operational safety, production continuity, industrial architecture, critical process consequences, and the decisions stakeholders need to make after testing.

A generic IT statement of work is rarely sufficient. OT environments include legacy systems, specialized protocols, long equipment lifecycles, and dependencies that may not tolerate conventional testing. The objective should not be to run as many tests as possible. It should be to determine which credible attack paths can reach critical systems, whether existing controls interrupt those paths, and which actions will reduce risk without destabilizing operations.

This guide provides a practical framework for defining that scope.

What should OT penetration testing as a service include?

OT penetration testing as a service is a managed assessment that identifies and validates exploitable paths affecting industrial environments. A well-scoped service should connect technical findings to operational consequences rather than deliver an isolated list of vulnerabilities.

The program should define:

• The facilities, environments, zones, and asset classes under assessment
• The critical operations and consequences the assessment will consider
• The architecture and security data used to model the environment
• The adversary behaviors and attack paths to evaluate
• The production safety constraints governing execution
• The controls whose effectiveness will be validated
• The required technical, engineering, and executive deliverables
• The process for remediation validation and reassessment

The distinction matters because asset visibility and vulnerability scanning do not prove that an attacker can reach a critical OT asset. Penetration testing should add exploitability, connectivity, control, and consequence context.

1. Define the business and operational objectives

Begin with the decisions the assessment must support. A request to “test the OT network” is too broad to guide a safe and useful engagement.

More useful objectives include:

• Determine whether credible paths reach designated critical OT zones
• Validate whether segmentation controls restrict unintended pathways
• Identify exploitable combinations of vulnerabilities and control gaps
• Evaluate whether existing safeguards interrupt modeled adversary activity
• Prioritize remediation according to reachable operational consequences
• Establish a baseline for measuring attack-path reduction over time

Each objective should have an owner and an expected decision. For example, an engineering leader may need evidence to approve a firewall rule change, while a CISO may need a defensible view of risk across multiple sites.

Scope should also identify what the engagement will not claim. Incomplete source data, excluded facilities, or unmodeled asset classes should be documented as limitations rather than treated as implicit coverage.

2. Identify critical assets and operational consequences

A strong OT penetration testing scope works backward from what the organization cannot afford to lose. Ask operations, engineering, safety, and security stakeholders to identify the systems and functions associated with unacceptable consequences.

Relevant categories may include:

• Safety-related systems
• Controllers and process control equipment
• SCADA servers and operator workstations
• Engineering systems
• Historians and supporting infrastructure
• Boundary security controls
• Systems supporting essential production or service delivery

Do not rank targets by technical severity alone. A moderate technical weakness on a reachable system may be more important than a critical vulnerability on an isolated asset. The scope should define consequence criteria such as loss of view, loss of control, interruption of a critical process, equipment stress, or environmental and safety impact.

These criteria create a common language for prioritization. They also help prevent the final report from becoming a vulnerability inventory without operational context.

3. Set safe testing boundaries

Safety constraints must be explicit before execution begins. Traditional testing techniques can introduce unacceptable risk when applied directly to fragile or availability-sensitive OT systems.

The scope should document:

• Whether testing will occur through simulation, controlled live validation, or both
• Systems and techniques excluded from live interaction
• Approved assessment windows and coordination requirements
• Conditions that require work to pause
• Stakeholders authorized to approve scope changes
• Evidence handling and reporting requirements
• Assumptions used when direct validation is not appropriate

For many environments, a cyber digital twin provides a safer foundation. Architecture, asset, configuration, vulnerability, and control data can be assembled into a model where adversary techniques and attack paths are evaluated without testing production systems directly.

This approach should still be governed by evidence quality. The provider should explain which data supports the model, where assumptions were required, and how model confidence affects each conclusion. For more context, see how [digital twins enable safe OT security testing](https://frenos.io/blog/how-digital-twins-are-changing-ot-security-testing).

4. Specify the data needed to build the assessment model

Perfect visibility should not be a prerequisite, but data requirements must be clear. A service provider should be able to ingest available OT data and identify material gaps without representing partial input as complete coverage.

Potential sources include:

• Network diagrams and zone definitions
• Asset inventories and asset attributes
• Network flow and communication records
• Firewall configurations and policy exports
• Vulnerability and configuration findings
• Existing assessment results
• Security architecture documentation
• Known criticality and consequence classifications

The statement of work should identify mandatory data, optional data, acceptable formats, data owners, and validation steps. It should also define how the provider will reconcile conflicting sources.

The output of this stage should be more than an asset list. It should be a high-fidelity model of assets, relationships, trust boundaries, vulnerabilities, and controls that supports attack-path analysis. This is why [asset visibility alone is not enough](https://frenos.io/blog/beyond-asset-visibility-how-digital-twins-and-ai-reasoning-agents-are-transforming-ot-security-posture-management).

5. Define the attack paths and adversary behaviors to test

An OT penetration testing as a service scope should state which paths and behaviors will be evaluated. Otherwise, “comprehensive testing” can mean different things to the provider, security team, and plant stakeholders.

Define scenarios according to:

• Critical destinations and operational consequences
• Known architecture and trust relationships
• Relevant adversary behaviors
• Vulnerabilities with plausible exploit conditions
• Security controls expected to prevent or interrupt progression
• Threat intelligence applicable to the organization and sector

The scope should include end-to-end analysis where the available data supports it. Testing isolated vulnerabilities does not reveal whether multiple weaknesses can be chained into a consequential path.

MITRE ATT&CK for ICS can provide a useful vocabulary, but technique coverage should not become the only success measure. The more important question is whether a realistic sequence could reach a critical objective in this specific environment.

6. Define evidence and prioritization requirements

AI-generated conclusions should not be accepted without supporting evidence. Require the provider to show why an attack path is considered viable and what conditions must be present for it to succeed.

For each prioritized path, request:

• The originating condition and targeted critical asset or zone
• The sequence of assets, vulnerabilities, and control boundaries involved
• The evidence supporting each step
• Exploitability assumptions and confidence levels
• The existing controls expected to interrupt the path
• The potential operational consequence
• Recommended mitigation and compensating control options

Prioritization should account for reachability, exploit conditions, control effectiveness, asset criticality, and potential consequence. CVSS or vulnerability count alone should not determine the remediation queue. For a deeper treatment of this issue, review [exploit conditions in OT vulnerability prioritization](https://frenos.io/blog/exploit-conditions-in-ot-vulnerability-prioritization).

7. Require deliverables for engineering and leadership

A useful engagement should produce outputs tailored to the people who must act on them.

Technical and engineering deliverables

• Validated or evidence-supported attack-path diagrams
• A prioritized list of exploitable conditions
• Affected assets, zones, and control boundaries
• Supporting evidence and assumptions
• Engineering-relevant mitigation options
• Retest criteria for each priority finding

Program and executive deliverables

• Summary of material operational risk
• Critical paths and potential consequences
• Control strengths and weaknesses
• Scope coverage and known limitations
• Prioritized investment recommendations
• Baseline metrics for future assessments

Ask the provider to distinguish facts, modeled conclusions, and assumptions. Transparent reasoning makes AI-supported analysis easier for security and engineering teams to review.

8. Establish measurable acceptance criteria

The engagement should be evaluated against agreed outcomes, not report length. Useful acceptance criteria include:

• Percentage of designated critical zones represented in the model
• Number of critical paths evaluated and supported by evidence
• Percentage of prioritized findings mapped to an owner
• Number of paths interrupted after remediation
• Change in reachable critical assets between assessments
• Time from validated finding to mitigation decision
• Percentage of findings successfully reassessed

These metrics shift attention from finding volume to proven risk reduction. They also give leadership a consistent way to track improvement across sites and assessment cycles.

9. Plan remediation validation and reassessment

A one-time assessment can establish a baseline, but industrial environments change. New vulnerabilities, architecture changes, configuration drift, and evolving adversary behavior can create new paths or reopen old ones.

Define the follow-up process during initial scoping:

1. Assign owners to validated findings.
2. Select remediation or compensating controls.
3. Update the model with the planned changes.
4. Reassess affected attack paths.
5. Record whether the path was interrupted or merely altered.
6. Schedule broader reassessment based on risk and environmental change.

This turns penetration testing as a service into a validation cycle rather than a periodic reporting exercise. It complements existing teams and controls by showing where remediation work will have the greatest effect.

Questions to ask an OT penetration testing provider

Use these questions during provider evaluation and scope review:

1. How is your methodology purpose-built for OT rather than adapted from IT testing?
2. How do you prevent assessment activity from affecting production systems?
3. Which data sources do you require, and how do you handle incomplete data?
4. How do you validate complete attack paths instead of listing vulnerabilities?
5. How do you account for asset criticality and operational consequences?
6. What evidence supports each prioritized finding?
7. How are assumptions and confidence levels documented?
8. Which deliverables are designed for engineering teams?
9. How do you validate that remediation interrupted a path?
10. Can the assessment be repeated as architecture, threats, and controls change?

A provider should answer these questions precisely. Broad promises of complete coverage are not a substitute for documented inputs, boundaries, methods, and limitations.

OT penetration testing scope checklist

Before approving the engagement, confirm that the scope includes:

• [ ] Named facilities, zones, and asset classes
• [ ] Defined critical operations and consequences
• [ ] Business and technical objectives
• [ ] Documented data sources and known gaps
• [ ] Safety constraints and excluded activities
• [ ] Specified attack scenarios and critical destinations
• [ ] Evidence and confidence requirements
• [ ] Exploitability-based prioritization criteria
• [ ] Engineering and executive deliverables
• [ ] Acceptance metrics
• [ ] Remediation ownership
• [ ] Reassessment and retesting terms

The broader [OT penetration testing checklist](https://frenos.io/blog/ot-penetration-testing-checklist-complete-guide-for-before-during-after-2025) can support preparation before, during, and after an engagement.

Scope for proof, not finding volume

The best OT penetration testing as a service scope asks a focused set of questions: Which paths can reach critical systems? What evidence proves those paths are viable? Which controls can interrupt them? What should the organization fix first?

Frenos uses agnostic data ingestion, cyber digital twins, AI-powered adversary simulation, and evidence-based attack-path validation to assess OT defenses without testing live production systems. The goal is not to replace existing security tools or teams. It is to turn fragmented findings into operational context and defensible remediation priorities.

Request a demo to see attack paths in your OT environment and assess defenses without production impact.