# ICS Penetration Testing: Planning and Safe Execution

> A penetration test on an industrial control system is fundamentally different from an IT pentest: the target is a live production environment where a scan can…

- Canonical URL: https://wiki.aspotomasyon.com/article/ics-penetration-testing
- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)
- Category: Industrial Cybersecurity
- Published: 2026-08-11 · Updated: 2026-09-13
- Reading time: 5 min · Language: English

A penetration test on an industrial control system is fundamentally different from an IT pentest: the target is a live production environment where a scan can trip a watchdog, a malformed packet can stop a controller, and the test itself can become the incident. Done responsibly, ICS penetration testing is one of the most valuable security exercises a plant can run — it validates the defenses with evidence and produces the priority list that risk assessments can only guess at. Done irresponsibly, it creates the outage it was meant to prevent. The discipline is in the planning.

![Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg)

*Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.*

## Types of ICS Security Testing

| Test type | What it does | Risk profile |
| --- | --- | --- |
| Architecture review | Documented analysis of network design, zones, rule sets, and configurations against the security standard. | None (offline) |
| Configuration review | Hardening audit: accounts, services, patches, device defaults — from evidence, not testing. | None–low (may need read-only access) |
| Passive monitoring | Observe traffic and behavior without sending anything. | None |
| Active testing in a lab | Exploit and validate attacks against replicas of the production systems. | None to production |
| Active testing on production | Real scans and attacks against the live system. | High — needs exceptional justification and controls |

The standard approach: architecture and configuration review plus passive monitoring plus lab testing on a replica — which together deliver most of the value with almost none of the risk. Full active testing on live production is reserved for the situations where it is genuinely necessary, and is executed with the controls below.

## Planning: The Rules of Engagement

1. **Scope in writing** — the test plan lists: target systems (by IP/asset), test types permitted, tools allowed, and — critically — the systems *excluded* (safety systems, SIS, protection relays, anything whose interruption is unacceptable). The SIS is never a test target on a live plant.
2. **Authorization** — signed authorization from the accountable owner (plant manager/OT owner) covering the dates, the scope, and the acceptance of defined risks; the authorization names the decision authority for aborting.
3. **Baseline and abort criteria** — before testing: recorded baseline of controller statuses, alarms, and historians. Abort criteria defined: any safety event, any unexplained controller trip, any process deviation — the test stops and the plant takes priority.
4. **Timing** — outside production-critical windows (planned shutdowns and low-load periods are the norm), with operations informed shift by shift; the control room is told a test is running and who to call.
5. **Personnel** — the testers work with a plant-side coordinator (who knows the process and the people); testers are never alone in the control network.
6. **Testing methodology** — passive first, then gentle active (non-destructive scans with conservative timing — no aggressive scanning of controllers), with every action logged.

## Safe Execution Techniques

- **Prefer lab replicas** — build the replica (virtualized or spare hardware) with the same firmware and configuration; most exploitation and validation happens there, with the production test reduced to confirming what the lab proved.
- **Respect protocol fragility** — industrial protocols have strict timing; slow scans, single-connection tests, and no fuzzing on production. Fuzzing belongs exclusively in the lab.
- **Read-only first** — enumeration and observation before any active interaction; many findings (default credentials, exposed services, unencrypted protocols) are visible without touching anything.
- **Watch the process** — the plant coordinator monitors process and alarm status continuously during active testing; the test pauses at the first anomaly, and the cause is confirmed before resuming.
- **Credentials by agreement** — testing with and without credentials answers different questions; both are valid, but the credentials used must be provided by the plant under controlled terms, never guessed from documentation lying around.

## Reporting and Remediation

The report separates findings by severity and by *exploitability on the live plant*: a finding may be real but only exploitable in the lab; the report states the production exposure honestly. Every finding gets: evidence, the affected systems, the risk in the plant's language (not CVSS alone — what happens to production if exploited), and remediation options ranked (quick wins: disable services, change credentials; structural: segmentation, monitoring; strategic: program improvements). Findings feed the risk register and the remediation backlog with owners and dates; a pentest without a remediation plan is an expense, not an investment.

## Frequency and Program Fit

ICS testing is not a one-off: architecture/config review annually or after major changes, passive monitoring continuously (see the OT monitoring article), and active testing on a cycle justified by the risk picture (typically every 1–3 years for critical plants). The test program should be a standing line item, planned with the production calendar, and its findings reviewed by management — the test is the evidence the security program reports against.

## Summary

ICS penetration testing is planning and safety discipline first, technique second: written scope with excluded systems (never the SIS), signed authorization, abort criteria, lab-first testing, conservative live testing with a plant coordinator, and findings reported with production impact and remediation owners. The value is evidence-based priorities; the risk is controlled by the rules of engagement. Test to learn, and the plant gets stronger; test without discipline, and the test becomes the incident.

## Apply this to your project

- Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.
- Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.
- Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.

[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.

![Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg)

*Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.*

## Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

- [NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)
- [ISA — ISA/IEC 62443 series](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)

---

Cite the canonical article: https://wiki.aspotomasyon.com/article/ics-penetration-testing (ICS Penetration Testing: Planning and Safe Execution, ASP OTOMASYON, updated 2026-09-13).