Oil and gas SCADA compliance has no single mandatory cybersecurity rulebook - unlike the power sector. Instead, operators navigate a stack of overlapping obligations: TSA security directives that carry legal force for designated pipelines, API 1164 as the industry's own SCADA security standard, IEC 62443 as the international foundation both are built on, and NIST guidance stitching it all together. This guide maps the whole landscape - what each standard covers, who it binds, what the compliance process actually looks like step by step, what audits cost, and what all of it means when you are choosing a SCADA platform for wells, gathering systems, or pipelines.
One of 60+ guides in our SCADA security and compliance series.
The first thing to get straight about oil and gas SCADA compliance is which documents bind you legally and which bind you commercially. For most of its history, pipeline cybersecurity in the US ran on voluntary guidelines - TSA held the statutory authority but exercised it through recommendations. That changed in 2021, when the Colonial Pipeline ransomware incident, documented in CISA advisory AA21-131A, shut down the largest refined-products pipeline in the country and TSA issued its first mandatory security directives within weeks.
Today the stack looks like this:
One adjacent regime worth naming: PHMSA's control room management rules (49 CFR 192.631 and its Part 195 counterpart) govern how SCADA control rooms operate - alarm management, fatigue, shift handover. They are safety regulations rather than cybersecurity ones, but auditors and inspectors increasingly look at SCADA operations and SCADA security in the same visit, so keep both files in order.
API 1164, "Pipeline Control Systems Cybersecurity," is the standard the US pipeline industry wrote for itself; like other API standards, the full text is published by the American Petroleum Institute and available for purchase through API's standards program. The third edition, published in 2021, was a near-total rebuild: earlier editions read like a SCADA security checklist, while the third edition adopts ISA/IEC 62443 as its foundation and broadens scope from SCADA hosts to the full pipeline control environment - field devices, local control, and the connections between them.
Its signature idea is the profile-based approach: rather than one flat list of requirements, it defines pipeline-specific security profiles derived from IEC 62443, so an operator can apply a baseline profile broadly and enhanced requirements where risk is higher. That structure makes it practical for real fleets, where a rural well pad and a mainline compressor station do not warrant identical controls. We cover the standard in depth - scope, profiles, and how conformance is demonstrated - in our dedicated guide to API 1164 third edition.
No formal certification scheme exists for API 1164. Conformance is demonstrated through assessments - self-performed or third-party - and through the evidence trail your program produces. That makes documentation quality a first-class deliverable, not an afterthought.
The TSA security directives are the only part of this stack with direct legal force for private pipeline operators. Issued in 2021 and revised repeatedly since, they come in two strands. The first (the SD Pipeline-2021-01 series) requires a cybersecurity coordinator reachable around the clock, reporting of cybersecurity incidents to CISA within 12 hours, and an annual vulnerability self-assessment. The second (the SD Pipeline-2021-02 series) began as a prescriptive list of technical mandates, drew heavy industry criticism for its IT-centric assumptions, and was reissued in 2022 in performance-based form: operators write their own TSA-approved Cybersecurity Implementation Plan, maintain an incident response plan, and run a continuing assessment program against their own plan.
The four pillars of that implementation plan - network segmentation between IT and OT, access control with multi-factor authentication, continuous monitoring and detection, and risk-based patching - will look familiar: they are the same control families API 1164 and IEC 62443 describe. That convergence is good news. A program built honestly against API 1164 largely writes your TSA plan for you. The full requirements, history, and practical steps are in our companion guide to the TSA pipeline security directives.
The ISA/IEC 62443 series of standards is where the concepts come from. It divides responsibility between asset owners (part 2-1), systems and integrators (the 3-x parts), and product vendors (parts 4-1 for development process and 4-2 for component requirements), and it rates systems by security level - SL1 through SL4 - according to the sophistication of attacker they are designed to resist. Zones and conduits, its model for segmenting industrial networks, is the formal version of the IT/OT separation TSA now demands.
For an oil and gas buyer, IEC 62443 is most useful as a vendor yardstick. A vendor who can articulate which security level their architecture targets, and how their development and support practices align with 62443-4-1, has done real work; a vendor who answers with a marketing page has not. Merobix, for example, maps its platform controls to IEC 62443 and runs a SOC 2 readiness program, with independent penetration testing as part of its ongoing validation program - the specifics are documented on the security page. That is the shape of answer to expect from any vendor: a mapping and evidence, not a logo.
For the architectural fundamentals - security levels, segmentation, outbound-only gateways - see our broader guide to securing SCADA on OT networks.
NIST SP 800-82 (now in revision 3, the Guide to Operational Technology Security) is the US government's operational guide to industrial control system security - free, detailed, and vendor-neutral. It does not compete with API 1164 or IEC 62443; it explains them, maps to them, and provides the architecture patterns (DMZs, monitoring placement, incident handling for OT) that the standards assume you know. The NIST Cybersecurity Framework sits one level up: its functions - govern, identify, protect, detect, respond, recover - are the vocabulary boards, insurers, and TSA assessors share. Most mature oil and gas programs use the CSF for structure and reporting, API 1164 and IEC 62443 for technical substance, and 800-82 as the how-to manual.
| Standard | Binding? | Applies To | Core Focus | Buyer Action |
|---|---|---|---|---|
| TSA Security Directives | Yes - for TSA-designated critical pipelines | Owners/operators of critical hazardous liquid and gas pipelines | Implementation plan, incident reporting, assessments | Confirm designation status; build the four-pillar plan |
| API 1164 (3rd ed.) | No - industry standard | Pipeline control systems and SCADA broadly | Pipeline-specific security profiles built on IEC 62443 | Use as the blueprint for your program and gap assessments |
| IEC 62443 | No - international standard | Asset owners, integrators, and product vendors | Security levels, zones/conduits, vendor requirements | Demand a security-level and 4-1/4-2 mapping from vendors |
| NIST SP 800-82 r3 | No - guidance | Anyone operating ICS/OT | Practical architecture and operations guidance | Use as the implementation manual and training reference |
| NIST CSF | No - framework | Whole organization | Program structure and risk communication | Use for executive reporting and insurer questionnaires |
| PHMSA CRM (49 CFR 192/195) | Yes - safety regulation | Pipeline control rooms | Alarm management, fatigue, procedures | Keep SCADA operations records audit-ready alongside security |
Whatever mix of the above applies to you, the working process is remarkably consistent. Here is the sequence we see operators follow successfully:
On cost: honest answer, it varies enormously. Third-party gap assessments for a focused SCADA scope commonly land in the low tens of thousands of dollars; large multi-asset programs cost multiples of that, and remediation (segmentation hardware, monitoring tooling, engineering time) is usually the larger line item. A full program build typically runs six to eighteen months. Treat any vendor who quotes you a precise number before scoping as a red flag.
Regulation is only half the pressure. Large utilities and midstream operators now audit their SCADA vendors and service providers directly - security questionnaires running to hundreds of items, requests for evidence of MFA and role-based access, audit-log samples, penetration-test summaries, SOC 2 reports or readiness documentation, and right-to-audit clauses in contracts. If you sell gas to a utility or operate assets for a partner, expect their security team in your inbox. The practical preparation is the same evidence discipline as above: keep your architecture diagrams, access-control matrix, and assessment results current, and demand the same from every vendor in your chain so you can pass their answers through.
Your SCADA platform either generates compliance evidence for you or becomes the gap your auditor finds. For oil and gas specifically, require:
This is the checklist Merobix was built against: an outbound-only gateway polling wells and pipeline sites locally, TOTP and passkey MFA with granular roles and step-up authentication for high-risk actions, Ed25519-signed telemetry envelopes with replay detection, chained audit records, and SIEM delivery for security events - see how it fits pipeline operations in our pipeline SCADA monitoring guide, or walk through it live with an engineer.
The one-paragraph strategy: treat the TSA directives as your legal floor, API 1164 as your program blueprint, IEC 62443 as your vendor yardstick, and NIST as your reference library. Build once against API 1164 and you satisfy all four audiences - TSA, auditors, customers, and insurers - with the same evidence. And when a vendor claims compliance, ask for the mapping, not the logo.
No. API 1164 is a voluntary industry standard published by the American Petroleum Institute, not a regulation. However, it is the reference the US pipeline industry uses to define good SCADA and control-system security practice, TSA's directives push operators toward exactly the kind of program it describes, and customers, partners, and insurers increasingly expect conformance. Treat it as effectively required for any serious pipeline operation, even though no law compels it.
For designated critical pipeline operators, the TSA security directives require a named cybersecurity coordinator available around the clock, reporting of cybersecurity incidents to CISA within 12 hours, and a TSA-approved Cybersecurity Implementation Plan covering network segmentation between IT and OT, access control including multi-factor authentication, continuous monitoring and detection, and risk-based patching. Operators must also maintain an incident response plan and run an annual assessment program that tests their measures over time.
IEC 62443 is the international standard family for industrial control system security, and API 1164 third edition is built directly on it, adapting its requirements into pipeline-specific security profiles. Oil and gas operators use IEC 62443 to define security levels for zones of their network, to evaluate vendors through parts 4-1 and 4-2, and to structure their own security programs through part 2-1. If your SCADA vendor can show how its controls map to IEC 62443, that evidence transfers across API 1164, TSA expectations, and customer audits.
Timelines vary with fleet size and legacy debt, but common ranges are four to twelve weeks for an initial gap assessment and six to eighteen months to build out a full program - segmentation, access control, monitoring, documented plans, and an assessment cadence. Third-party assessments commonly run from the low tens of thousands of dollars for a focused SCADA review to considerably more for large multi-asset systems. Budget honestly and treat published figures as rough guides, because scope drives cost more than any rate card.
Require outbound-only connectivity from the OT network, multi-factor authentication on every account, role-based control over who can write setpoints, tamper-evident audit records, security event export to your SIEM, documented incident response support, and clear data ownership and export rights. Ask how the vendor's controls map to IEC 62443 and API 1164, and ask for evidence - architecture documentation, assessment results, and a security roadmap - rather than certification logos alone.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Outbound-only gateway, MFA and roles on every account, signed telemetry, and audit records built for the evidence your assessors will ask for.