Third-Party Assurances and the "Cloud Certified" Question

A carve-out means the report gives no assurance over the layer that holds the data. The application controls may be excellent and the database host entirely unexamined - and the database is in another jurisdiction, which adds a transfer and legal-access question on top of the control question.

Reasonable courses of action:

• Obtain the subservice organisation's own report (SOC 2 or ISO 27001) plus a bridge letter covering the gap between the audit period end and today. Absent that, the carve-out is unmitigated.
• Read the complementary user entity controls in the report carefully - they define what the firm itself must do for the provider's assertions to hold. Onboarding without implementing them invalidates the assurance you paid for.
• Require the provider to bring the subprocessor into scope at the next audit, or at minimum to flow down equivalent obligations contractually.
• Perform your own assessment of the hosting layer if the report is genuinely unavailable.

The judgement: a SOC 2 Type II is evidence about a defined boundary. For regulated health data, relying on it while the boundary excludes the data store is not a defensible position to take to a regulator or the audit committee.

The clocks are not the same clock, and the difference is worse than it looks. The firm's 24 hours start when the firm becomes aware - and awareness usually arrives through the provider's notification. So a provider that takes 72 hours uses three times the firm's entire budget before the firm even starts, guaranteeing a missed regulatory deadline.

The contract must change; this is not a risk to accept quietly. Requirements to negotiate:

• Notification without undue delay and in any event within 12 hours of the provider confirming or reasonably suspecting an incident affecting the firm's data - suspicion, not confirmation, because confirmation may be exactly what takes days.
• Notification content sufficient to start triage: affected systems, data categories, time window, containment status.
• A named contact path and an obligation to update, not just a single notice.
• Flow-down of the same obligation to the subservice organisation, otherwise the carve-out reintroduces the delay.

If the provider will not move, record the residual risk with an owner accept and pre-draft the regulator notification template so the 24-hour window is spent on facts, not drafting.

They are the reason the question cannot be answered as asked. There is no "cloud certified." Certification attaches to a provider's control environment for a defined scope; the firm remains accountable for how it configures and uses the service. What the committee should be asking is whether the firm can evidence its side of the shared responsibility split - and without consistent tagging and an inventory, it cannot, because it cannot enumerate what it is responsible for.

Practical path:

• Use the provider's resource inventory export as an interim CMDB, then reconcile against billing data to find untagged or unmanaged resources - the billing account is the one place every resource must appear.
• Enforce tagging at deploy time with policy-as-code (deny on create without owner, data classification, and environment), rather than chasing retroactive tagging.
• Map tags to the control framework so audit evidence can be generated by query rather than by interview.

Give the committee a maturity statement - scope of assurance obtained, gaps, remediation dates - instead of a certificate. A certification claim would be both inaccurate and, in front of a regulator, damaging.