A cloud supplier cannot validate your use of its software for you. This guide walks through the lifecycle: split the responsibilities, assess the supplier, size the effort by risk, classify the software, control change, and review it on a schedule.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Intended use and risk
What the system does, to which data
Supplier assessment
Quality system, security, hosting
Configure and test
UAT scaled to risk
Release and train
Validation summary signed
Change control
Vendor releases assessed
Periodic review
Still fit for intended use?
The short answer
Who owns what
Typical, not universal. Your contract and quality agreement control the real split.
| Activity | Supplier | You (the regulated user) |
|---|---|---|
| Infrastructure, hosting, backups, disaster recovery | Builds, operates and monitors | Reviews evidence; confirms it meets your retention and recovery needs |
| Software development lifecycle and testing of the product | Owns and documents | Assesses during supplier qualification |
| Security controls and incident response | Operates and reports | Reviews reports; manages your own users and passwords |
| Configuration of your study or workflows | Provides the tools | Owns the specification, build decisions and approval |
| User acceptance testing | May supply scripts and support | Executes and approves for your intended use |
| Release management of the platform | Decides and announces releases | Assesses impact and retests what your risk assessment requires |
| User access and training | Provides roles and controls | Grants, reviews and removes access; trains users |
| Periodic review and retirement | Provides service information | Owns the review decision, data export and archive |
Ask suppliers to describe their side in documents you can file. Ask yourself whether you have the staff to carry your side.
Step 2
A supplier assessment decides whether you can rely on the vendor's quality system for the parts you do not test yourself. Scale it to risk. A system holding primary clinical data warrants more than a tool for scheduling meetings. See also the EDC vendor audit checklist and the vendor security questionnaire.
Quality management documentation and development lifecycle; test approach and release process; security policies, access control and encryption; backup and recovery arrangements; hosting locations; sub-processors; audit and inspection history; support and incident procedures; and exit terms including data return.
A supplier report, a third-party certificate or a past audit tells you about the supplier. None of it tells you that your configuration works. Record what you reviewed, what gaps you found, what risk you accepted and what you will test yourself.
Put in writing: notice of releases and incidents, audit rights, data access during inspections, retention, sub-processor changes and termination support. Missing terms become findings later.
Step 3
Traditional computer system validation produced large document sets whether or not they added assurance. The current direction, which FDA describes as computer software assurance and which the GAMP 5 second edition expresses as critical thinking and risk-based testing, is to focus effort where failure would affect participant safety, data integrity or product quality, and to use the vendor's evidence and unscripted testing where risk is low.
In practice, assess each function by what it does to the record. A function that calculates a derived value or enforces an eligibility rule deserves scripted testing with evidence. A cosmetic setting does not. Document the reasoning, because the reasoning is what an inspector reads. The data validation plan template and the EDC validation checklist give the study-level side.
Functions assessed
9
High risk
3
Step 4
GAMP categories describe how much of the software you configure or write. The category drives how much you must verify yourself.
| Category | Cloud example | What you typically verify |
|---|---|---|
| 1 · Infrastructure software | Operating systems and database engines under the service | Mostly the supplier's responsibility; confirm through supplier assessment. |
| 3 · Non-configured product | A cloud tool used as supplied, such as a scheduling or document viewing tool | Fitness for intended use and supplier evidence; light testing. |
| 4 · Configured product | An EDC, ePRO or eConsent platform where you build forms, rules and roles | Your configuration against the specification, with testing scaled to risk. |
| 5 · Custom application | Bespoke code, custom integrations, scripts you write on top | Full lifecycle for the custom part: design, code review, testing. |
Category 2 (firmware) was removed in the second edition of GAMP 5. Most SaaS clinical tools are category 4 for the product plus category 5 for any bespoke integration.
Build a study in the free Capture sandbox, enter test data, break your own edit checks and read the audit trail. Free, every feature, no credit card. Documentation to support sponsor validation and UAT is available to enterprise customers.
Steps 5 and 6
The cloud difference: you do not control the release calendar, so your process has to absorb releases.
Agree in the quality agreement how you are told about releases, security patches and deprecations, and how far ahead.
Compare the release notes with your intended use list. Classify: no impact, impact on a configured function, or impact on a high-risk function.
For high-risk impact, rerun the relevant scripted tests in a non-production environment if one exists, or against a test study. Record the result.
Protocol amendments and form changes follow your change procedure: request, impact, approval, test, release. Approved forms in production should not change without it.
Check users, roles and removals, and keep the signed record.
At least yearly for critical systems: incidents, changes, deviations, supplier status and fitness for intended use. Decide: continue, remediate, or retire.
Define how data and audit history are exported, verified and archived at close-out. See data archiving and retention.
What Capture contributes
Capture is a self-serve EDC, eCRF, ePRO, eConsent and randomization platform. It does not make you validated; your validated use is yours to show. What it supplies are controls to test and document in your UAT.
Weight changed 68.0 to 68.5 kg
Site coordinator · Reason: Transcription error
Query Q-0014 answered on Weight
Site coordinator · Reason: Source checked
Vital signs form locked
Data manager · Reason: Visit cleaned
Related regimes
The same lifecycle satisfies the common ground of FDA's electronic records rules and EU Annex 11: supplier assessment, validation proportionate to risk, audit trails, access control and periodic evaluation. The differences are covered in Annex 11 vs 21 CFR Part 11 and the FDA electronic systems guidance guide.
If the cloud system includes AI features, treat them as additional functions with their own risk assessment. The AI in clinical data capture GxP checklist covers human review, traceability and change handling for AI-assisted steps.
Yes. Validation is about showing fitness for your intended use, not about owning the servers. You qualify the supplier, test your configuration with user acceptance testing and control changes and access.
Both, for different parts. The vendor builds and operates the service under its quality system. The regulated user remains accountable for intended-use validation, configuration, user management and records. Put the split in the contract.
CSV is the traditional documentation-heavy validation approach. CSA is the risk-based direction that focuses assurance on functions affecting safety, data integrity and quality, uses critical thinking and allows unscripted testing for lower risk. Both aim at the same objective.
Agree release notice terms, triage each release against your intended-use list, retest functions with high-risk impact and record the decision. Do not retest everything each time; do document why you did not.
No. A certificate or audit report tells you about the supplier's processes. Your configuration, rules and roles are yours and need your own testing, scaled to risk.
Most commercial EDC platforms are treated as category 4, configured products. Custom integrations or scripts you add are treated as category 5 for that part.
Frequency should follow risk and your SOP. Many organisations review critical systems at least annually, and after major incidents or significant changes.
No. Capture provides controls such as an audit trail, edit checks and role-based access, and a free sandbox for your UAT. Validation of your use is the sponsor's responsibility, supported by documentation available to enterprise customers.
Keep exploring
GAMP 5 EDC validation
Sponsor and vendor split for an EDC.
Computer system validation for clinical trial software
Whose job CSV is.
AI in clinical data capture: GxP checklist
Controls for AI-assisted steps.
EDC validation checklist
A study-level validation list.
EDC vendor audit checklist
What to ask when you assess a supplier.
Data validation plan template
A starting plan.
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.