OT Security Compliance Checklist: IEC 62443, NERC CIP, TSA, and the Incident Response Requirements
Operational technology compliance is not one framework. A pipeline operator answers to TSA security directives, a utility to NERC CIP, a manufacturer to its customers and IEC 62443, and everyone to the incident reporting clocks that come with those regimes. This checklist walks the frameworks one at a time, then the preparedness items every OT operator needs regardless of which regulator is asking.
Key takeaways
- Compliance frameworks overlap on one thing: incident response. Every OT regime that matters, NERC CIP, TSA directives, IEC 62443-based customer requirements, assumes you can detect, report, and recover. The response plan is the common denominator.
- Start from the reporting clock, not the control catalog. The fastest way to fail an audit or a real incident is to discover the reporting obligation during one. Know your clocks before anything else.
- IEC 62443 zones and SLs structure the technical work. Segment the network, assign security levels, and audit against them; customers increasingly contract on the SLs, not on adjectives.
- The universal checklist is short. A plan aligned to NIST 800-61, a tested contact tree, tabletops that include operations, evidence handling that survives a claim, and a way to get expert help fast.
- Check your readiness in five questions. The OT threat-hunt readiness calculator turns this checklist's core items into a scored starting point.
The framework map, in one table
| Regime | Who it applies to | What it demands on incident response |
|---|---|---|
| NERC CIP | US bulk electric system entities (scope by category) | A formal incident response plan (CIP-008), reporting of incidents and disruptive events to CISA and NERC inside defined windows, and recovery plans under CIP-009 exercised regularly |
| TSA Security Directives | Pipeline and rail owners/operators | Report incidents to CISA inside the directive's window, name a cybersecurity coordinator, and maintain (and exercise) an incident response plan (the directives) |
| IEC 62443 | Industrial operators and their suppliers, increasingly by contract | Security levels per zone and conduit, with response and monitoring requirements that scale with the SL you commit to (the standard) |
| NIST guidance | Everyone, as the de facto baseline | SP 800-61 for the incident response lifecycle, SP 800-82 for securing OT itself |
Two notes on scope. NERC CIP applies by registration and by category, so a generator and a marketer face different obligations; check your registration, not a blog's summary (including this one). TSA directives have evolved through renewals since 2021; the pipeline framework page tracks what the current directives require. And water utilities sit under EPA and state obligations after the 2021-2024 enforcement back-and-forth, with AWIA risk assessments for larger systems; treat your state regulator as the source of truth.
The reporting checklist (do this first)
- Know your clocks. CIP-008, the TSA directives, and sector rules each define what counts as a reportable incident and how fast the call goes to CISA (and, for CIP entities, to the E-ISAC). Write them on one page. During an incident is the wrong time to read the standard.
- Name the coordinator. TSA directives require a designated cybersecurity coordinator, a 24/7 contact. CIP requires identified responders. If the named person left, that is a compliance gap and an operational one.
- Decide the escalation path before the incident. Detection at the plant floor to the person who makes the report call, with authority to make it at 2am. The incident commander role maps directly onto this.
- Template the report. What happened, when detected, what systems, what is affected. The template is also your evidence checklist.
The technical checklist (IEC 62443 structure, any framework)
- Zone and conduit diagram. Document the network as zones (plant areas, cells) and the conduits between them. Every framework's technical expectations hang off this picture, and it is the artifact assessors ask for first.
- Assign security levels per zone. SL 1 through 4, based on threat and consequence. Customers in automotive, manufacturing, and critical supply chains increasingly write the required SL into contracts; know which zones you have committed to.
- Inventory the assets inside each zone. You cannot defend (or report on) what you have not inventoried. PLCs, HMIs, engineering workstations, historians, and the connections nobody remembered.
- Control the conduits. Firewalls and unidirectional gateways between IT and OT, with documented exceptions. The IT/OT boundary is where most OT incidents enter and where most audits look.
- Patch and exception management. OT patching is constrained by uptime and vendor certification; document the compensating controls for unpatchable systems instead of leaving blanks.
The incident response checklist (every framework's common denominator)
This is the part regulators test with questions and attackers test with events.
- A written IR plan that includes OT specifically. Containment in OT means production trade-offs (you may need to shut a line to isolate a host), and the plan must say who owns that call. The plan template is NIST 800-61 aligned and adaptable to OT environments.
- A contact tree that includes the outside parties. Regulator reporting contacts, the carrier's hotline, panel rules if you carry cyber insurance, and an IR firm that knows OT. A plan whose tree stops at internal staff fails at the first real incident.
- Evidence handling that survives a claim. Preserve before you reimage. Volatile data, logs, and images feed the investigation, the insurance claim, and the regulator report; destruction of evidence is the one mistake that makes all three worse. Our first-hour guidance covers the order.
- Tabletops that include operations. A cyber tabletop where the plant floor has no seat tests half the problem. Six scenarios that find real OT gaps include the IT/OT boundary case that most plans get wrong.
- A way to get expert help fast. Retainer with pre-agreed SLAs (what they cost and what drives it), or per-incident capability with response commitments in writing. Sector-specific capability matters: OT/ICS response firms are documented by the frameworks they actually work in.
Compliance is not readiness, and the audit will not say so
You can pass a CIP audit and still lose the plant. Frameworks certify that documents, controls, and reports exist; incidents test whether people, plans, and response capacity work under pressure. The checklist that closes the gap is the response one above: tested plan, real contact tree, evidence discipline, and named expert help. Run the five-question readiness check to see which items are already solid and which are paper.
Frequently asked questions
Which OT compliance framework applies to us? Depends on sector and registration: NERC CIP for bulk electric system entities, TSA directives for pipeline and rail, IEC 62443 mostly through customer and procurement requirements, EPA and state rules for water. Many operators face two or more at once, which is why the incident response checklist treats the common denominator first.
Is IEC 62443 certification mandatory? Not by statute in most jurisdictions; it becomes effectively mandatory through customer requirements, procurement scoring, and some national schemes. Operators adopt the zoning and SL structure because it is the most widely recognized OT security architecture, certified or not.
Do we need a separate IR plan for OT? You need OT-specific content in the plan: production trade-offs, IT/OT escalation boundaries, safety-first containment, and regulator clocks. One plan with an OT section beats two plans that disagree about who decides.
Who can help with OT incident response? Firms with real ICS capability, not IT security generalists who list OT as a keyword. The OT/ICS directory documents firms by framework coverage (IEC 62443, NERC CIP, TSA) and sector, with the evidence attached to each claim.
Score the preparedness items in five questions.
Run the OT threat-hunt readiness check →Framework requirements summarized here are starting points, not compliance advice; the standards and your regulator own the details. Last verified: October 2026. Have a correction or addition? Request inclusion or a correction →
Continue reading
Best Incident Response Companies 2026: Ranked by What's Documented, Not What's Claimed
Search for the best incident response companies and you get two things. Vendor blogs that rank themselves first. And listicles that rank by adjectives. Neither survives contact with a real incident. What survives is evidence: which firms carriers' claims teams keep re-hiring, what the firms document about their own capability, and how their claims check out. This page ranks the market's most-documented IR firms. It tells you exactly what the ranking can and cannot say.
Best Operational Technology (OT) Incident Response Firms 2026: Ranked by What's Documented, Not Claimed
Search for OT security companies and you get two bad options. Vendor listicles rank whoever pays them. Vendor blogs rank themselves. The OT market deserves better, because a wrong pick costs production hours. This page lists the OT incident response firms we could verify from their own published services. It puts them in the order the evidence supports. Where the evidence is thin, it says so.