“We follow industry standards” and “we meet our regulatory obligations” are different claims. An organization can use a good security framework without satisfying a sector-specific requirement. It can also pass a compliance review while carrying operational risk that the review did not address.
Governance establishes who makes decisions, accepts risk, funds work, and owns outcomes. Compliance demonstrates that applicable obligations are met. Security and resilience concern what the organization can actually prevent, detect, withstand, and recover from. These activities should support one another, but none is a substitute for the others.
This introductory map uses U.S. examples, followed by an international perspective. It is not an exhaustive legal register or a determination that a particular facility is in scope. Sources were reviewed in October 2026; amendments, effective dates, national implementation, and contracts must be checked for the actual organization.
For the operational context, see the map of OT verticals. The companion protocol overview explains the technology layer; this article asks who requires what, and why.
Four kinds of obligation
| Category | What makes it binding? | Example |
|---|---|---|
| Law or regulation | An applicable jurisdiction, regulated activity, entity, system, and effective requirement | A covered drinking-water utility's statutory risk-assessment and emergency-planning duties |
| Regulatory standard, order, directive, or license condition | Approval or issuance by the relevant authority, within its defined scope | Enforceable NERC CIP requirements for applicable entities and systems; TSA directives for designated operators |
| Contractual requirement | Agreed procurement terms, customer obligations, or applicable contract clauses | A supplier must meet specified security requirements and provide evidence before acceptance |
| Voluntary framework, standard, or guidance | Organizational choice, unless incorporated into one of the categories above | NIST CSF, ISA/IEC 62443, or a CISA performance goal used to structure improvement |
An internal policy can also be mandatory for staff without being legislation. A voluntary standard can become contractually binding. A regulator may recognize a standard as one acceptable method without requiring every organization to buy a certificate for it.
A standards body is not necessarily a regulator. ISA, IEC, ISO, and industry associations develop standards and specifications. Authorities such as FERC, NRC, EPA, TSA, and the Coast Guard have different statutory roles. Auditors and certification bodies assess defined scopes; they do not all have the same enforcement authority.
Cross-industry foundations: ISA/IEC 62443 and NIST
The ISA/IEC 62443 series, also written ISA-62443, is a broad industrial automation and control-system cybersecurity foundation. It addresses the lifecycle and shared responsibilities of asset owners, product suppliers, integrators, and maintenance/service providers.
| Part | Main question it helps answer |
|---|---|
| 62443-2-1 | What security program does the asset owner need? |
| 62443-2-4 | What security capabilities and processes should service providers supply? |
| 62443-3-2 | How should the system be assessed, divided into zones and conduits, and assigned risk-based requirements? |
| 62443-3-3 | What system security requirements and security levels apply? |
| 62443-4-1 | How should a supplier develop and maintain products securely? |
| 62443-4-2 | What technical security capabilities are required of components? |
The series is not a universal legal mandate, a protocol, or proof that an entire site is secure. A component certificate has a defined scope; it does not certify every integration decision or the asset owner's operational program. Security levels are not interchangeable with functional-safety integrity levels or generic audit maturity scores.
NIST CSF 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover. NIST SP 800-82 Rev. 3 provides OT-specific security guidance. These are useful starting points, but neither automatically creates a legal obligation for every private OT operator. Adoption through law, a contract, or policy changes the obligation.
Other useful references include CISA's Cybersecurity Performance Goals, a voluntary baseline for prioritizing improvement, and ISO/IEC 27001, which specifies requirements for an information security management system. ISO/IEC 27001 certification is an option with a defined organizational scope, not proof that every industrial control or physical recovery path has been validated. Neither reference replaces sector-specific obligations.
Electricity: NERC CIP is a scoped, enforceable program
In the United States, FERC-approved NERC Critical Infrastructure Protection (CIP) Reliability Standards are mandatory and enforceable for applicable entities and assets within their defined scope. NERC and the Regional Entities operate compliance monitoring and enforcement within the broader regulatory structure.
The key qualifier is applicable. NERC CIP is not a blanket cybersecurity law for every electrical device, distribution installation, generator, or building with a switchboard. Entity registration, functions, asset applicability, exclusions, and BES Cyber System categorization matter. Requirements differ by standard and impact category; lower-impact systems are not simply “outside cybersecurity.”
The CIP family addresses topics including categorization, security management, personnel, electronic and physical access, system management, incident response, recovery, configuration change, information protection, and supply-chain risk. Do not copy a high-impact checklist onto every facility and call the applicability work finished.
Version status matters. NERC's official listing distinguishes standards that are mandatory and subject to enforcement from those subject to future enforcement. A published replacement is not necessarily the version enforced today.
Source: NERC CIP standards and enforcement status.
Nuclear: a different regulatory path
U.S. nuclear power reactor cybersecurity has specific NRC requirements, including 10 CFR 73.54 for applicable licensees and applicants. The scope concerns protection of digital computer and communication systems and networks associated with defined safety, security, emergency-preparedness, and supporting functions.
NRC regulatory guides, such as RG 5.71, describe approaches the staff considers acceptable; the distinction between the regulation, an approved licensee plan, and a guidance document is important. Do not assume NERC CIP alone establishes a nuclear facility's cybersecurity obligations or that every nuclear-related organization has identical requirements.
Sources: NRC cybersecurity and 10 CFR Part 73.
Water and wastewater: mandatory planning is not a universal control checklist
Safe Drinking Water Act section 1433, amended by America's Water Infrastructure Act, requires U.S. community drinking-water systems serving more than 3,300 people to prepare or update risk and resilience assessments and emergency response plans, and certify completion to EPA. Cybersecurity is part of those requirements, with recurring review and certification duties.
That does not make every EPA cybersecurity recommendation individually mandatory. EPA tools and templates can help meet the planning obligations; they are not interchangeable with the statute. Nor should the drinking-water provision be described as applying automatically to every wastewater facility. State requirements, permits, other legal duties, and contracts need separate consideration.
Governance question: who is accountable for incorporating the assessment's findings into the response plan, maintaining recovery dependencies, and exercising the plan with operators?
Source: EPA's AWIA / SDWA section 1433 overview.
Pipelines, rail, aviation, and maritime: don't treat transport as one regime
TSA issues Security Directives and Emergency Amendments with mandatory requirements for the owners and operators to which they apply. Pipeline and rail cybersecurity directives are examples. Applicability can depend on designation, operator category, the specific directive, and its current revision; an industry-wide recommendation is not the same instrument.
Aviation also has specialized security and safety oversight. Do not assume that a pipeline directive's controls, deadlines, or reporting rules apply unchanged to an airport or airline.
For maritime operations, the U.S. Coast Guard's Cybersecurity in the Marine Transportation System final rule establishes requirements for covered U.S.-flagged vessels and covered facilities under its specified scope. The rule became effective in July 2025, with phased implementation. Effective date and individual compliance deadlines are different things; use the current implementation timeline rather than assuming every provision became due at once.
Sources: TSA directives and amendments and Coast Guard maritime cybersecurity resources.
Chemical, refining, and other hazardous processes: safety and cyber obligations overlap
OSHA Process Safety Management, including 29 CFR 1910.119, imposes requirements for covered highly hazardous chemical processes. Applicability depends on the process, substances, quantities, and exclusions. Management of change, operating procedures, training, mechanical integrity, and emergency planning can intersect directly with control-system work.
This is a process-safety regulation, not a complete OT cybersecurity framework. Related environmental and accident-prevention requirements may also apply. ISA/IEC 62443 can support cyber-risk work alongside those duties, while functional-safety standards address a different engineering concern.
Be careful with historical program lists. CISA's CFATS page currently states that the program's statutory authority expired on July 28, 2023. Do not present CFATS as an active universal chemical-sector mandate based on an old slide deck. Check its current status and the facility's other obligations.
Sources: OSHA PSM and CISA CFATS status.
Pharmaceuticals, food, and healthcare: scope follows the regulated activity and information
| Vertical | Examples of mandatory obligations when in scope | What not to assume |
|---|---|---|
| Pharmaceutical and other FDA-regulated production | Applicable manufacturing/quality regulations and 21 CFR Part 11 for covered electronic records and signatures | Part 11 is not a cybersecurity certification for every PLC. Predicate recordkeeping requirements and the use of electronic records matter. |
| Food production | Applicable FSMA preventive-controls requirements, including food-safety planning for covered facilities | Food-safety compliance and OT cybersecurity are not the same program, even when temperature controls, recipes, and records connect them. |
| Healthcare | HIPAA Security Rule duties for covered entities and business associates handling electronic protected health information; other requirements can apply to devices and facilities | Every hospital HVAC controller is not automatically a HIPAA system merely because it is in a hospital. Evaluate data, dependencies, and system scope. |
FDA guidance documents and HHS advice should be distinguished from the underlying regulations. A quality team's product-release decision can also remain necessary after an IT or OT system is technically restored.
Sources: FDA's Part 11 scope guidance, FSMA preventive controls for human food, and HHS Security Rule.
Manufacturing, defense suppliers, buildings, and other verticals
There is no single U.S. cybersecurity regulation that applies identically to all manufacturers or all building-management systems. A useful first pass is to ask which additional roles the organization performs.
- Defense suppliers: applicable contract clauses can impose information-protection and incident-reporting duties. DFARS 252.204-7012 addresses covered contractor information systems and covered defense information. Determine the actual contract, information flows, system boundary, and any applicable assessment or certification clauses; a machine is not in or out of scope solely because someone calls it OT.
- Buildings and campuses: locally adopted building, electrical, fire, elevator, and other codes, permits, procurement terms, and the authority having jurisdiction can create mandatory obligations. A communication standard such as BACnet does not itself establish a whole-building cyber compliance program.
- Mining, metals, agriculture, and dams: operating permits, worker-safety rules, environmental obligations, ownership, location, and the asset's use shape the obligations. A hydroelectric dam may have different duties from a non-power water-control structure. Do not use the sector label as the applicability decision.
- Communications and data centers: the service being provided, customer commitments, government contracts, and jurisdiction can add duties to facility power and cooling operations. A generic assurance report does not establish that a specific cooling dependency has been tested.
Requirements for contractors can be just as consequential as direct regulation. “Voluntary standard” does not excuse ignoring a standard that the organization committed to in a signed contract.
Source example: DFARS 252.204-7012.
Outside the United States: jurisdiction changes the answer
The EU's NIS2 Directive sets cybersecurity risk-management and reporting requirements for covered entities across specified sectors. Energy, transport, health, drinking water, wastewater, digital infrastructure, and certain manufacturing activities are among the relevant areas. Scope includes entity and sector criteria, exceptions, and national implementation; it is not simply “every organization that uses OT.”
Because it is a directive, the applicable Member State's transposing law, regulator, and implementation status need checking. Do not assume identical national procedures or treat a proposed rule as already binding. Operators in other jurisdictions likewise need their own national and local applicability reviews. Even NERC standards outside the U.S. involve the relevant jurisdiction's adoption and enforcement arrangements.
Source: European Commission NIS2 FAQs.
Turn the map into an obligations register
For each requirement or adopted standard, record:
- Authority and source: the law, approved standard, directive, license, contract clause, or internal policy—not just a vendor summary.
- Applicability decision: the jurisdiction, regulated entity/activity, assets and data in scope, exclusions, and who approved the decision.
- Current version and dates: publication, effective date, implementation milestones, and the next review date.
- Accountable owner: the person who funds and accepts the work, plus the team that operates the control.
- Evidence and cadence: what proves the obligation is met, where evidence is retained, and when it must be refreshed.
- Operational connection: which process, hazard, service dependency, and recovery decision the requirement supports.
A fictional example: an applicable electricity operator may need evidence supporting a specific CIP recovery requirement. A smaller facility outside that scope may still choose a recovery exercise under ISA/IEC 62443 or NIST guidance. Both need a credible recovery capability; they do not necessarily owe the same evidence to the same authority.
Use the recovery explorer to practice the operational distinction between “restored” and “released for service.” It is a learning model, not a compliance assessment. The goal is not a longer list of acronyms: it is a clear account of which obligations apply, who owns them, and what evidence shows that the physical service can be trusted.