What SOC 2 is (and is not)
SOC 2 is an AICPA attestation over controls relevant to security, availability, processing integrity, confidentiality, and/or privacy of a service organization’s systems. An independent CPA firm examines your description of the system and related controls, then issues a Type I or Type II report.
SOC 2 is not a product certification, not an OT safety standard, and not a replacement for pipeline integrity, process safety, or data-center physical design codes. It addresses how you protect and operate the information systems and services customers (or internal stakeholders) rely on. Plant actuation and safety interlocks stay in OT — see LDUX and SCADA.
Levels of requirement: Type I vs Type II
People often say “SOC 2 level” when they mean report type and which criteria are in scope. Those are the two real depth switches:
| Level | What it examines | Typical use |
|---|---|---|
| Type I | Design of controls described in the system — at a point in time. | Early readiness, new service boundaries, first customer ask. |
| Type II | Design and operating effectiveness over a period (commonly 3–12 months). | Customer and procurement expectation for ongoing SaaS, hosting, or managed data services. |
Type II is the stricter commercial bar: evidence must show controls ran as designed across the period (access reviews, change tickets, monitoring, incident handling), not only that policies exist on paper.
Trust Services Criteria (what must be covered)
Every SOC 2 examination includes Security (the common criteria). Optional categories are added when your service commitments require them — that is the second “level” of requirements:
| Category | Required? | Focus |
|---|---|---|
| Security | Always in scope | Protect against unauthorized access, disclosure, and damage — logical access, change management, risk, monitoring, incident response. |
| Availability | Optional — often expected | System available for operation and use as committed — capacity, backup, recovery, environmental (esp. facilities). |
| Processing Integrity | Optional | Processing is complete, valid, accurate, timely, authorized — critical when you process measurement, tickets, or billing-related data. |
| Confidentiality | Optional — often expected | Information designated confidential is protected — encryption, classification, NDAs, restricted data paths. |
| Privacy | Optional | Personal information collected, used, retained, disclosed, and disposed per commitments and criteria — when PII is in the system boundary. |
Requirement depth: Security is baseline → add Availability / Confidentiality for facilities and hosted platforms → add Processing Integrity when measurement or commercial data accuracy is part of the service → add Privacy when personal data is in scope → prove it with Type II when customers need operating evidence.
Oil & gas: how requirements typically land
For operators and vendors serving upstream, midstream, and land/office systems, SOC 2 usually bounds the IT and information path — portals, APIs, cloud stages, attested views — not the PLC or ESD. Common pressure points:
- Security — identity for field apps and office users; segmentation between OT and IT; vendor remote access; secrets for gateways and APIs.
- Processing Integrity — when you commit that readings, tickets, or allocations are complete and accurate (who · what · where · when · how measured). See field measurement and pipeline data.
- Confidentiality — well, land, commercial, and integrity data that must not leak across shippers, partners, or public channels.
- Availability — when you offer continuous telemetry portals or scheduling views with uptime commitments.
- Change & provenance — who published which office view or config; signed releases align with audit evidence — see field to verifiable view.
Data centers: how requirements typically land
Colocation, wholesale, and facility operators are often asked for SOC 2 (and sometimes companion reports) covering the customer-facing facility and management systems:
- Security — physical access, badging, visitor control, logical access to BMS/DCIM and customer portals, camera retention policy.
- Availability — power, cooling, and monitoring commitments; incident and maintenance communication; backup of critical facility data.
- Confidentiality — customer cage/hall layouts, capacity plans, and telemetry that must stay tenant-isolated.
- Processing Integrity — when tickets, capacity records, or metered usage feed billing or SLA credits.
- Privacy — visitor logs, badge photos, and staff PII when those systems sit inside the examined boundary.
Shared control themes (both industries)
| Theme | What examiners and customers look for |
|---|---|
| System description | Clear boundary: what services, locations, and data flows are in (and out) of the report. |
| Access control | Joiners/movers/leavers, MFA, least privilege, periodic access reviews. |
| Change management | Authorized changes to production systems and published views; separation of duties where claimed. |
| Monitoring & incidents | Logging, alerting, response playbooks, post-incident records. |
| Vendor / subprocessors | Cloud, connectivity, and integrator risk assessment and oversight. |
| Evidence over time | Type II samples across the period — not a single screenshot week. |
How this relates to Discovery and data work
Choosing criteria and Type I vs Type II is a business engagement decision: which commitments you make to customers, which systems sit in the boundary, and what evidence you can sustain. That fits the Discovery process — clarify requirements and scope before build. Open standards and attested views support Processing Integrity and change evidence; they do not replace a CPA examination.
Data Field Services helps map oil & gas and data-center data requirements to control-ready designs (identity, audit trails, office views). Formal SOC 2 opinions are issued only by licensed practitioners; we do not substitute for that attestation.