The Shared Responsibility Model in Cloud SCADA

Part of the SCADA Security Hub - 60+ guides on SCADA security, compliance & certifications.

Where the Model Comes From - and Why OT Needs Its Own Version

The shared responsibility model was popularized by the big cloud infrastructure providers to answer a recurring confusion: customers assumed "it's in the cloud" meant "it's secured," while providers meant only "the parts we run are secured." The canonical phrasing became security OF the cloud (provider) versus security IN the cloud (customer) - a split federal guidance formalizes in CISA's Cloud Security Technical Reference Architecture and, a decade earlier, in NIST SP 800-144 on public cloud security. Cloud breach post-mortems show a recurring pattern: incidents commonly trace not to provider failures but to customer-side misconfiguration - open storage buckets, over-privileged accounts, leaked keys. The infrastructure was secure; the usage wasn't.

Cloud SCADA needs its own version of the model because the stack is longer than SaaS. A CRM vendor's model ends at the browser. A SCADA platform's stack extends past the browser, through a gateway on your plant network, down to PLCs, instruments, and physical valves - layers no cloud vendor can reach, patch, or watch for you. That means the operator's half of the model is bigger in OT than in IT, not smaller, and pretending otherwise is how the seam-gaps form. If you're still weighing deployment models, our cloud vs on-premise comparison is the companion read; this article assumes cloud is on the table and asks who does what.

The Layer-by-Layer Responsibility Matrix

Here is the model we recommend buyers adapt, whatever vendor they choose. Print it, put names in the last column, and attach it to the contract:

Two readings of this table repay attention. First, rows 1–2 are delegation, not abdication: you don't operate those controls, but you choose the vendor, so due diligence is your control. Second, rows 3 and 7 are traps for optimists: the vendor supplies the mechanism, but the mechanism does nothing until you operate it. MFA that exists but isn't enforced, and alerts that fire into an unwatched inbox, are the two most common ways "shared" responsibility becomes "nobody's."

What a Serious Vendor Owns - and Can Prove

On its side of the line, the vendor's obligations are absolute: you cannot patch their application or configure their database isolation, so the standard must be documentation, not trust. Concretely, a serious cloud SCADA vendor should be able to show:

• Tenant isolation with teeth - application-level authorization plus database-level enforcement such as row-level security, with cross-tenant access attempts denied, logged, and alerted on. Our treats this as a first-class evaluation criterion.
• Authenticated, verifiable telemetry - unique per-device credentials, transport encryption, and ideally device-side signing with replay detection, so the data driving your decisions can't be silently forged.
• Disciplined releases - tested, reviewed deployments with visibility into exactly what version is running.
• Operated data protection - encryption at rest for sensitive data, validated backup archives, controlled restore tooling.
• An honest assurance story - named frameworks and current status. As an example of honest framing: Merobix runs a SOC 2 readiness program, maps its controls to ISA/IEC 62443, and treats independent penetration testing as part of an ongoing validation program - stated exactly that way, rather than waving a certification it doesn't hold. Whatever vendor you evaluate, that precision is the tell; vague "bank-grade security" language is the anti-tell.

What You Always Own - No Matter the Vendor

No platform, however good, can reach these; budget real recurring hours for them:

• The user lifecycle. Accounts, roles, MFA enforcement, contractor scoping, and offboarding the day someone leaves. The platform can make revocation instant; only you know it's needed.
• Field reality. Everything behind the gateway - PLC passwords, network segmentation, the padlock on the panel, the legacy modem someone forgot. The vendor's outbound-only architecture removes inbound exposure, but it cannot see the port forward a contractor adds beside it.
• Control decisions. Which tags are writable, what setpoint bounds apply, who is competent to command what. Good platforms enforce these as configuration - writable-tag allowlists, bounds checking, role and competency gates - but the values in them are operational judgments only you can make.
• Response. An alarm delivered in seconds is worthless without a rostered human who acts on it, and an incident plan that has been walked through at least once - the preparation discipline at the heart of NIST SP 800-61 Rev. 3 on incident response. Our small-operator guide shows how thin this layer can be and still work.

The Gray Zones Where Incidents Actually Happen

Post-incident reviews in cloud-connected operations keep finding the same five seams - each one a control both parties plausibly believed the other owned:

1. Gateway custody. Vendor ships it, operator hosts it. Who confirms updates were applied? Resolve it in writing: managed by the vendor via signed automatic updates, or operator-applied on a schedule with the vendor reporting version drift.
2. Alert response. The vendor proves delivery; nobody rostered receipt. Fix: a written escalation chain with an on-call name, tested quarterly.
3. Offboarding. The platform supports instant revocation; HR never told operations the technician left. Fix: departure checklist that includes SCADA access, verified in the quarterly access review.
4. Configuration backups. The vendor backs up the platform; who archives your tag maps, screens, and alarm setpoints for offboarding or dispute scenarios? Fix: scheduled exports through the platform's export workflow, stored on your side.
5. Incident declaration. Each side sees half the anomaly and waits for the other. Fix: contractual notification duties in both directions, with named contacts and timeframes.

Putting It in the Contract

The matrix earns its keep when it's contractual. Minimum set of terms to demand - reasonable vendors accept these without drama:

• The responsibility matrix as an exhibit, referenced by the agreement, not a slide from the sales deck.
• Uptime SLA with defined measurement, exclusions, and remedies.
• Security incident notification - a concrete timeframe, a named contact path, and tenant-isolation breach listed explicitly as a reportable event.
• Data ownership and exit - the telemetry is yours; export rights in standard formats during the term and at offboarding; defined retention and deletion timelines. (This matters enough that we cover it separately in our data residency and export guide.)
• Assurance evidence flow - how you receive the vendor's validation results, and notification of material security-posture changes.
• Vendor personnel access - under what circumstances vendor staff can access your tenant, and whether that access is logged and visible to you.

Five questions that reveal in one meeting whether a vendor understands its half: Where exactly does your responsibility end and mine begin - show me the document? How would you detect and tell me about a cross-tenant incident? What happens to my data and configuration if we part ways? Who patches the gateway and how do I verify it? What evidence of your security program do I get without asking? Merobix publishes its answers on the security page, and a demo is a fine place to ask all five out loud - of us or anyone else.

Frequently Asked Questions

Sources & Further Reading

• Cloud Security Technical Reference Architecture - CISA
• NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing - NIST
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations - NIST
• ISA/IEC 62443 Series of Standards - International Society of Automation