Most regulated companies now run at least one GxP-critical process on software they do not host, cannot inspect directly, and cannot stop from updating. That is not a reason to avoid the cloud. It is a reason to be precise about who is responsible for what — because the regulatory accountability does not move to the supplier, no matter what the contract says.
The principle regulators start from
Outsourcing an activity never outsources responsibility for it. A marketing authorisation holder or manufacturer remains accountable for the integrity of GxP data held in a third-party system, for the validated state of that system, and for its availability over the full retention period. The supplier is a party you must oversee, not a party you can defer to.
The ISPE GAMP 5 Guide, second edition, expanded its treatment of cloud and IT service providers precisely because this model had become the default. The draft revision of EU GMP Annex 11 published for consultation on 7 July 2025 goes further, giving supplier oversight, access management and cybersecurity far more prominence than the current text.
Mapping the shared responsibility boundary
Before validating anything, write down where the line falls. The allocation differs sharply between infrastructure, platform and software services, and the differences matter:
- Infrastructure and physical security — almost always the provider
- Platform patching and underlying components — usually the provider, but confirm the notification and testing arrangements
- Application configuration — almost always you, and almost always the highest-risk area
- User provisioning, roles and privilege review — you, even when the provider supplies the tooling
- Data content, retention and deletion — you
- Backup and, critically, restoration testing — contracted to the provider, verified by you
Anything unassigned in this table is, in practice, unassigned in reality. That is where findings originate.
Supplier assessment that is worth doing
A returned questionnaire is not an assessment. Proportionate oversight of a GxP-critical cloud supplier should establish what development and testing evidence exists and whether you may see it; how the provider manages change, including the notice you receive before an update and whether you can defer it; what certifications are held and what their scope actually covers; what the incident and breach notification path is; and what happens to your data at the end of the contract, in what format, and over what period.
On-site or remote audit rights should be written into the quality agreement, alongside the obligation to notify you of subcontracting. Multi-tenant environments where every customer receives the same update on the same day require a validation strategy built around regression testing of your critical functions, not around approving each release in advance.
Continuous release and the periodic review problem
Traditional validation assumes a stable configuration punctuated by controlled changes. SaaS inverts that assumption. The workable response is to identify a defined set of critical functions, automate or streamline their regression testing, run that set on each significant release, and record the outcome. Periodic review then becomes a genuine control: it confirms that the accumulated small changes have not drifted the system away from its validated state.
How PQRA helps
PQRA supports companies moving GxP processes to cloud and SaaS platforms: responsibility mapping, supplier assessment and audit, quality and technical agreements, validation strategies suited to continuous release, data retention and exit planning, and readiness for the stricter supplier oversight expectations coming with the revised Annex 11.
If you are selecting, implementing or already running a GxP system in the cloud, contact PQRA to discuss how your oversight would stand up to inspection.
No responses yet