You cannot inherit qualification from your provider

The conversation goes the same way each time. The provider is a major cloud platform or a well-run SaaS vendor. They supply certifications, an audit report, sometimes a substantial compliance portal. The project concludes that infrastructure qualification is covered, and moves on.

It is not covered. What has been established is that the supplier is competent — which is necessary, and is not the same thing.

What a certificate actually asserts

An ISO/IEC 27001 certificate asserts that an organisation operates an information security management system meeting the standard, within a defined scope. A SOC 2 report describes controls relevant to security, availability, confidentiality and related criteria, and — in a Type II report — that they operated over a period.

Both are statements about the provider's organisation and controls. Neither is a statement about your instance, your configuration, your data, or your intended use. Three specific gaps follow.

Scope

Certification scope is defined by the provider, not by you. It frequently covers the platform and not every service on it, and rarely covers the region or the specific service tier your system runs in. Reading the scope statement — the actual annex, not the badge — takes ten minutes and changes the conversation more often than not.

Configuration

The provider's controls do not extend to how you configured the service. Retention settings, access model, audit logging, encryption key ownership, backup schedule and region pinning are almost always yours. A perfectly certified platform will happily let you configure a GxP system with audit logging disabled.

Intended use

Qualification is meaningful only against a stated intended use. The provider does not know yours, has not tested against it, and explicitly disclaims responsibility for it in the contract. This is the gap no certificate can close, because closing it requires knowing what the system is for.

What actually has to exist

The deliverable set is not large, but each item exists for a reason an inspector will recognise.

• Supplier assessment — a documented evaluation of the provider against your criteria, referencing their certifications as evidence rather than as conclusion. This is where the certificate belongs: as an input.
• Shared responsibility matrix — line by line, which control is the provider's, which is yours, and which is split. Split controls are where findings originate, because both parties assume the other holds them.
• Intended use and requirements — what this system does in your process, written as requirements you can test.
• Risk assessment — functional risk against your configuration and your process, not against generic cloud risk.
• Qualification testing — of your instance as configured: access model, audit trail behaviour, retention, restore, and the integrations either side of it.
• Periodic review and change awareness — the hard part, below.

The part most packages miss

On-premise systems change when you change them. Cloud services change when the provider changes them, on the provider's schedule, sometimes without a version number you can point at.

This breaks the assumption underneath classical change control. A validation package that qualified a configuration eighteen months ago may be describing software that no longer behaves that way, and nothing in your quality system will have noticed.

What works in practice:

• Subscribe to the provider's change and release notifications as a documented process with a named owner — not as an inbox someone occasionally reads.
• Define in advance which categories of provider change trigger assessment, and which are noted and closed. Without that filter, the volume makes the process collapse within two months.
• Re-verify a small, fixed set of critical behaviours on a schedule — audit trail generation, access enforcement, restore — rather than attempting to re-test everything.
• Write the contractual notification requirement into the agreement while you still have negotiating leverage, which is before signature and never after.

The strongest position is not a thicker validation package. It is being able to show that you know what your provider changed last quarter, and what you did about it.

A note on proportion

None of this argues for treating every cloud service as a critical GxP system. Most are not. The determination of what is in scope should happen first and should be documented, because the effort saved by correctly scoping a service out is far larger than the effort saved by qualifying it thinly.

The failure mode we see is not organisations doing too little cloud validation. It is organisations doing a moderate amount of it on the wrong systems, while the one service holding the records nobody classified sits entirely outside the quality system.

---

Written from cloud and SaaS qualification work under GAMP 5 Category 3 and 4. The deliverable set described above is available as a fixed-fee package, adapted to your provider and configuration.