Proving OT segmentation to an auditor or insurer

To prove OT segmentation to an auditor or insurer, show evidence rather than a diagram: the zone map with each zone’s level and target security level, the firewall configuration export, a traffic log from the same firewall over a representative window, the findings where rules or traffic cross a boundary the design forbids, a decision with an owner for each finding, and a retest after the fixes. Hash and date every file, tie each item to the requirement the reviewer asks about, such as IEC 62443-3-3 SR 5.1 and SR 5.2 or NIST SP 800-82r3 section 5.2.3.1, and say plainly what the firewall evidence cannot show.

A network diagram shows what was designed. The firewall configuration shows what is allowed today. The traffic log shows what actually crossed. Only the last two can show that the design still holds after last month’s outage, vendor visit or temporary rule.

Segmentation evidence checklist

1. Scope. The sites, firewalls and zones covered, and the dates the evidence was taken.
2. Zone map. Each zone with what it holds, its Purdue level or IEC 62443 zone, and the target security level (SL-T) the asset owner set for it. IEC 62443-3-2.
3. Firewall configuration export. The full policy in evaluation order, with its SHA-256 and the date it was taken.
4. Traffic log. From the same firewall, matching that configuration, over a window that covers shifts, batch runs and maintenance, with its own SHA-256.
5. Findings. Every path where traffic or a rule crosses a boundary the design forbids, with the sessions and the allowing rule. Rules that would allow a bypass nobody has used yet are listed apart from live traffic.
6. Decisions. For each finding: fix it, accept the risk, or send it to the rule’s owner to recertify, with who decided, why and until when.
7. Changes and a retest. The change records, and a traffic log from after the change window showing each fixed path closed and the kept flows still passing.
8. Crosswalk and scope notes. Each requirement marked supported, partial or gap, and a plain list of what the evidence cannot see.

What auditors ask

An auditor works from a framework and traces each claim to evidence. For segmentation, these are the requirements most often in play:

Requirement	What it asks	Evidence that speaks to it
IEC 62443-3-3 SR 5.1	Control system networks segmented from other networks	Zone map, configuration, traffic crossing zones
IEC 62443-3-3 SR 5.2	Communication at zone boundaries monitored and controlled; deny by default from SL 2	The rules on each conduit, a logged deny at each boundary, the traffic log
IEC 62443-3-3 SR 1.13	Access via untrusted networks monitored and controlled	Every remote access path and where it lands
NIST SP 800-82r3 section 5.2.3.1	Firewall rules that permit connections only between adjacent levels or zones	Paths that skip a level, with their sessions
SP 800-53 SC-7 and AC-4, in the SP 800-82r3 OT overlay	Boundary protection and information flow enforcement	Findings per boundary, with the allowing rule
NIST CSF 2.0 PR.IR-01	“Networks and environments are protected from unauthorized logical access and usage”	All of the above, in one crosswalk

The IEC 62443 guide and the NIST SP 800-82r3 guide cover each requirement, and IEC 62443 vs NIST 800-82 maps one onto the other. Evidence supports these requirements; it does not certify against any of them.

What insurers ask

Cyber insurers that cover industrial sites often add OT questions to the application or a supplement. Typical ones ask whether the OT network is segmented from the internet and from the business network, whether remote access into OT requires multi-factor authentication for staff and third parties alike, and whether access to OT is logged and time-limited.

The form wants a yes or a no. Answer from the evidence above rather than from the design document. Where segmentation is partial, say which sites or boundaries, and what is planned. A one-page summary per site, with the open findings and the dates of the evidence, gives the underwriter something to read behind each answer.

What the firewall evidence cannot show

Be as clear about the gaps as about the findings. A reviewer who finds a gap you did not mention will doubt the rest.

• Traffic that never crosses the firewall. Hosts in one zone or on one switch talk without it. A flat site has nothing for the firewall to judge, so report it as not judged, never as a pass. See flat OT networks.
• Paths around the firewall. Cellular modems, vendor remote-access boxes and dual-homed workstations. Draw them on the zone map and say how they were checked.
• Controls on the hosts. Multi-factor authentication and session recording on the jump host, shared accounts, patching. These need their own evidence, such as the jump host’s settings and sign-in logs.
• Rules that do not log. No traffic on a rule without logging means unknown, not unused.
• A short window. A quarterly job or a vendor’s annual visit may not appear in one week of traffic.

Keep the evidence current

Segmentation drifts. Temporary rules stay, vendors get new paths, and a rule written for one host ends up allowing a subnet. Repeat the review on a schedule and after every significant change, and compare it with the last one. NIST CSF 2.0 (DE.CM-01) and IEC 62443-3-3 (SR 6.2) both ask for continuous monitoring, and a series of dated reviews, each with its decisions and its retest, shows it.

Fixes need the same care as findings. The change plan guide covers how to write each change with a rollback and how the retest proves it held.

How SegAudit produces the evidence

SegAudit reads the firewall configuration and traffic log you exported, offline on a workstation or a jump host, and produces the evidence above from the same two files:

• Audit report. Findings with the sessions and allowing rule behind each, scope notes for what the evidence cannot see, and a chain of custody with the SHA-256 of each source file.
• Compliance crosswalk. Supported, partial or gap for IEC 62443-3-3, NIST CSF 2.0 and the other frameworks the site answers to, with the status after the change package is in place.
• IEC 62443-3-2 worksheet. One row per conduit seen in the traffic, with the SL-T used.
• Review log. In the Asset Owner edition, each change is approved, held or accepted as a risk, and who decided and when is signed into a log you can show an auditor.
• Post-change verification. The next traffic log marks each change Verified, Regressed, Not applied or No traffic.
• Executive brief. One printable page per site.

A flat site is never reported as clean: the overview says the site runs as one flat network and shows “Can’t judge yet”.

In the Northline sample (a made-up three-site company that ships with SegAudit), the report’s chain of custody lists the SHA-256 of northline-panorama.xml and northline-traffic.csv, and the worksheet below it counts 43 observed conduits, 25 of which need a hop drop. SegAudit produces evidence and a crosswalk for your assessor. It does not certify against IEC 62443 or any other framework.

To see what SegAudit catches in one of your own exports, run the free Quick check. The sample deliverable shows the full report.

Common questions

Is a network diagram enough to prove segmentation?

No. A diagram shows the design. It cannot show a rule added during an outage or a vendor path nobody drew. The firewall configuration shows what is allowed, and the traffic log shows what crossed, so the two together are what show the design holds.

How much traffic should the evidence cover?

No standard sets a number. Cover the site’s normal cycle: shifts, batch changes and maintenance. A week shows what is in use; ask for 30 days or more before treating a rule as unused, so rarer flows show up.

What if the review finds gaps?

Most do. Gaps with an owner, a decision and a date are part of the evidence. Record each accepted risk with who accepted it and until when, and show the retest for the ones you fixed.

Who signs off the evidence?

The asset owner. A consultant or internal reviewer recommends; the people who run the site decide what to fix and what to accept, and their decisions are part of the record.