Validating a Cloud Regulatory Platform: Part 11, Annex 11 and CSA
Validating a cloud regulatory platform
A risk-based approach to validating SaaS regulatory software: who is responsible for what, what evidence to expect from a vendor, and how to stay validated through continuous releases.
What the regulations ask for
Electronic records and signatures: validation, audit trails, access control, signature manifestation and linking, record copies.
Risk management, supplier assessment, validation, data integrity, change control, periodic review, business continuity. A revised draft was published for consultation in 2025.
FDA’s risk-based approach: concentrate assurance on functions that affect quality and safety; less scripted testing where risk is low.
Industry practice for risk-based, supplier-leveraged validation, and the data integrity expectation behind it.
Four principles that hold up in an inspection
Validate for intended use
Requirements describe how you use the system, not the vendor’s feature list.
Leverage, do not repeat
Use good vendor evidence. Spend your testing on high-risk functions and your own configuration.
Focus on records that matter
Publishing output, lifecycle, approved versions, audit trail, signatures, access.
Plan for change
Release notes, vendor impact assessment, targeted regression, periodic review.
Part 11 and Annex 11 controls to verify yourself
- Unique user identities; no shared accounts.
- Authentication tied to your identity provider, with multi-factor authentication.
- Role-based access, reviewed periodically, with removal on leaving.
- A computer-generated, time-stamped audit trail of create, modify and delete actions — who, what, when, and the previous value.
- Audit trail entries cannot be altered or deleted by users, and are retained as long as the record.
- Electronic signatures show the signer’s name, the date and time, and the meaning of the signature (for example review, approval).
- Signatures are linked to their records so they cannot be copied or transferred.
- Accurate, complete copies of records — including audit trail — can be produced in human-readable form for inspection.
The full validation guide
For IT, quality and computer system validation teams.
- The regulatory basis: Part 11, Annex 11, CSA, GAMP 5, ALCOA+
- Shared responsibility: cloud provider, vendor, regulated company
- A nine-step risk-based approach for SaaS, with deliverables
- Part 11 and Annex 11 controls to verify
- Staying validated through continuous releases, and planning an exit
- Questions for the vendor
Frequently asked
Do we still need IQ, OQ and PQ for SaaS?
You need the assurance those stages provide, scaled to risk. For SaaS, installation evidence is largely the vendor’s; operational evidence combines vendor testing with your own testing of high-risk functions and configuration; acceptance testing of your processes remains yours.
Does every release need re-validation?
No. Assess each release against your requirements and risks using the vendor’s release notes and evidence, and test what changed and matters. Periodic review confirms the overall validated state.
Is the cloud provider’s SOC 2 report enough?
It covers the provider’s infrastructure controls. It says nothing about the application, the vendor’s development practices or your configuration, which need their own evidence.
Validation support built into DnXT
Hosted on SOC 2 Type II certified Microsoft Azure infrastructure, with a Part 11 audit trail and electronic signatures with meaning.
