Compliance Audits for IoT Operations: SOC 2, ISO 27001, IEC 62443

Compliance audits are the operational reality that sits behind most enterprise IoT contracts. SOC 2 has become table-stakes for B2B SaaS — including IoT — and ISO 27001 is increasingly required by international customers. IEC 62443 is the operational technology equivalent for industrial IoT.

The audit experience is much smoother when the documentation lives where the engineering happens. Here is what auditors actually look for and what to have ready.

What each audit is for

SOC 2 Type II

• Operated by AICPA, performed by CPA firms
• Type I = “policies are designed adequately” (point in time)
• Type II = “policies have been operating effectively” (over a period, typically 6-12 months)
• Five Trust Service Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, Privacy
• Buyer audience: US enterprise customers, SaaS buyers, anyone procuring B2B services

For most IoT products: SOC 2 Type II covering Security + Availability is the practical scope. Confidentiality and Privacy if you handle sensitive data.

ISO/IEC 27001:2022

• International information security management system (ISMS) standard
• Certifies your management system, not your product
• Covers governance, risk, controls, continuous improvement
• Buyer audience: international enterprise customers, EU procurement, regulated sectors

ISO 27001 and SOC 2 overlap significantly. Most companies that hold both produce one set of evidence that satisfies both.

IEC 62443

• Industrial automation and control systems (IACS) cybersecurity
• Multiple parts (4-1, 4-2, 3-3, etc.) — different parts for different stakeholders
• Mandatory for some industrial customers; increasingly required for OT-touching products
• Buyer audience: industrial buyers, critical infrastructure, manufacturers

IEC 62443-4-1 (product development) and 4-2 (component requirements) are the parts most relevant to IoT product teams.

Sector-specific

• HIPAA (US healthcare)
• HITRUST (US healthcare, broader than HIPAA)
• FedRAMP (US federal)
• IRAP (Australian government)
• C5 (Germany)

These are generally additional to the broader ISO/SOC frameworks for IoT companies serving those sectors.

What auditors actually ask

The audit experience varies by framework, but the questions cluster around common themes:

Access control

• Who has access to production? Why?
• How is access granted, reviewed, revoked?
• MFA enforced everywhere?
• Service accounts inventoried, rotated?

Evidence: identity provider audit logs, access review records, off-boarding tickets.

Change management

• How does code reach production?
• Who reviews? What’s the approval path?
• What’s the rollback procedure?
• How are emergency changes handled?

Evidence: pull request history, deployment logs, runbook for emergency procedures.

Incident response

• What’s the incident response plan?
• Who gets notified for what?
• How quickly are incidents detected, contained, resolved?
• Where are postmortems documented?

Evidence: incident logs, postmortem documents, on-call schedules. See our incident response post.

Device security

• Per-device authentication?
• OTA signing and verification?
• Decommissioning procedure?
• Vulnerability management?

Evidence: device PKI documentation, OTA pipeline configuration, decommissioning runbook.

Data protection

• Where does customer data live?
• How is it encrypted at rest and in transit?
• Retention and deletion policies?
• Access logging on sensitive operations?

Evidence: encryption configuration, retention policy, audit logs.

Vendor / sub-processor management

• Who has access to your customers’ data via your vendors?
• Vendor security assessments?
• Data processing agreements (DPAs)?

Evidence: vendor inventory with assessment status, signed DPAs, sub-processor list.

Where IoT-specific scrutiny applies

Beyond the standard SaaS questions, IoT products face additional audit areas:

Device identity and provisioning

• How is each device uniquely identified?
• Can you prove a device is yours and not a rogue?
• What happens when a credential is compromised?

Evidence: certificate-issuance logs, revocation procedures, zero-touch provisioning architecture. See our provisioning post.

OTA pipeline integrity

• How are firmware images signed?
• Where do signing keys live?
• What’s the staged rollout procedure?
• Rollback tested?

Evidence: HSM configuration, OTA campaign records, rollback test logs.

Physical security of devices

• What if a device is physically compromised?
• Secure boot and flash encryption enabled?
• Debug interfaces disabled in production?

Evidence: hardware security configuration documentation, factory-test fixture confirming secure-fuse blowing.

Fleet observability

• How quickly can you detect a misbehaving device?
• Per-device anomaly detection?
• Customer notification path for security events?

Evidence: monitoring dashboards, alerting rules, runbooks.

What good evidence looks like

Three properties:

1. Generated, not curated — audit logs from real systems, not slides describing them. Auditors ask for the logs.

2. Time-stamped over the audit period — for SOC 2 Type II, evidence covers the 6-12 month observation period continuously.

3. Tied to written policies — every control has a policy document; the policy is dated and version-controlled; the evidence demonstrates the policy was followed.

A common preparation trap: writing 60 policy documents the week before the audit. Auditors recognise this and ask for evidence of policy adherence over the past months — which doesn’t exist.

The defensible approach: write minimum-viable policies early, generate evidence continuously, refine over time.

Tooling that helps

In 2026 the compliance tooling category is mature:

• Vanta, Drata, Secureframe — automated control monitoring across cloud infrastructure, with workflow for evidence collection
• OneTrust — privacy and broader compliance management
• Tugboat Logic, Sprinto — similar category, different sizing

For early-stage companies these tools accelerate first-time SOC 2 / ISO certification by 3-6 months. For mature companies they reduce the audit prep effort each year.

For IoT-specific elements (device PKI, OTA pipelines), automation is less mature — typically custom scripts feeding evidence into the broader tool.

What we typically deliver

For an IoT compliance audit engagement:

• Gap analysis — current state vs the target framework’s controls
• Control implementation roadmap — prioritised by what’s missing vs at-risk
• Documentation templates — policies, procedures, runbooks aligned to the framework
• Evidence collection automation — scripts and dashboards generating the artifacts auditors will request
• Audit preparation — mock audit before the real one, document review, evidence rehearsal
• Continuous compliance program — quarterly reviews so the next year’s audit is preparation, not panic

Compliance is most painful when treated as an annual event. As an ongoing operational discipline embedded in engineering practice, it’s less work overall and significantly less stressful.

If you are preparing for SOC 2, ISO 27001, or IEC 62443 — particularly with the IoT-specific scrutiny — we have shipped this combination across multiple products.