A questionnaire tells you what a vendor says. An audit tests whether it is true. This checklist covers scope, the documents to request, questions by area, red flags and how to grade findings, for a sponsor, QA lead or small team auditing an EDC supplier.
Free sandbox · No credit card · 21 CFR Part 11 aligned
| Desk review | Remote session | On-site | |
|---|---|---|---|
| Quality management system | |||
| Software validation and change control | |||
| Security and access management | |||
| Audit trail and data integrity | |||
| Support, training and incident handling | |||
| Exit, export and data return |
How this differs from a questionnaire
Purpose
The buying process usually runs in stages. You write requirements and compare options (see the EDC buyer scorecard and the RFP template), you send a security questionnaire, you test the product, and for any system that will hold regulated data you qualify the vendor. An audit is the strongest form of qualification. It can be a document review, a remote session, or a visit.
The regulatory background points the same way. Computerised systems used in clinical trials are expected to be fit for purpose and validated, audit trails are expected to be reliable and reviewable, and sponsors are expected to oversee service providers. The EMA guideline on computerised systems and electronic data in clinical trials, ICH E6 and the FDA Q&A on electronic systems, records and signatures (final October 2024) all discuss these themes. Summaries are in our guides to the EMA computerised systems guideline and computer system validation. Always read the primary text for the wording your inspectors will use.
Small sponsors often assume audits are only for large pharma. In practice a proportionate audit is feasible for anyone: a two-hour remote session with a prepared checklist, a document request list and a short report can be enough for a low-complexity study, and it gives you something concrete to show an inspector.
Process
List what the system will do in your study: data entry, consent, randomization, ePRO, safety, exports. Decide depth from that, not from the vendor's size.
Ask for items from the table below at least a week ahead, with a due date, so the session is spent on questions and not on finding files.
Mark what is missing, outdated or inconsistent. Prepare questions from the gaps.
Walk through the checklist, ask for demonstrations, and trace one change and one user's access from start to finish. Take notes against evidence seen.
Use a simple scale (critical, major, minor, observation). State the evidence and the requirement each finding refers to.
Ask the vendor for corrective and preventive actions with dates. Decide whether the vendor is approved, approved with conditions or not approved, and set a re-audit interval.
Document request
Not every vendor will have every item. Record what exists and what does not.
| Area | Document or evidence | What you are looking for |
|---|---|---|
| Quality | Quality manual or SOP index, training records for relevant staff | Written procedures for development, release, support and incident handling, and evidence staff are trained |
| Validation | Validation plan and summary for the release you will use; test records | Risk-based testing, traceability from requirement to test, and sign-off |
| Change control | Change log for the last 6 to 12 months, release notes, rollback procedure | Changes assessed, tested, approved and communicated before release |
| Security | Security policy, access control description, hosting details, encryption description, incident process | Controls that match what is claimed, and a defined route for reporting a vulnerability |
| Data integrity | Audit trail description and sample export; delete and edit behaviour | Append-only history with user, time, old and new value and reason; how deletes are handled |
| Continuity | Backup and recovery description, last restore test, outage history | Defined recovery objectives and evidence they were tested |
| Subcontractors | List of subprocessors and hosting providers, data location | Who touches your data, where, and under what terms |
| Support | Support hours, escalation, training materials, documentation | Response times, user guides, and training that matches your roles |
| Exit | Export formats, data return process, deletion process and certificate | You can leave with complete data, a data dictionary and the audit history |
| Regulatory | Inspection history relevant to the product, customer audit summaries where shareable | Whether other sponsors or regulators have examined the system |
Where something is not available, ask the vendor to say so in writing. That answer is audit evidence.
Questions · system and data
Ask to see the last release record: requirements, tests, approval, release date and who signed.
Look for user, timestamp, old value, new value and reason, and ask whether the trail can be edited by anyone.
Ask whether deletes are hard or soft and where the removed value can still be seen.
Identity checks, signature meaning, and what happens if the record changes after signing.
Demonstrate a restricted role; confirm blinded users cannot see treatment-arm values, in the interface and in exports.
Look for severity rules, hotfix controls and customer communication.
Clarify the shared responsibility for validation; your UAT of your configuration remains yours.
Questions · security and operations
Region, provider, and whether you can choose the region. Ask for the list in writing.
At rest and in transit; ask for the standard, not just the word "encrypted".
Two-factor options, session timeout, password policy and how accounts are removed.
Review practices, a disclosure policy and response targets. Be precise about what has and has not been done, such as which reviews and by whom.
Frequency, retention, last restore test and recovery targets.
Who is told, how, and within how long. Compare with your contract and data protection obligations.
Export formats, time to return data, deletion on request and written confirmation. See data ownership and portability.
Build a study in the free Capture sandbox, enter test data, change a value and open the audit trail export. A hands-on look makes your document review sharper. No credit card, no time limit.
Findings
| Grade | Meaning | Example | Typical response |
|---|---|---|---|
| Critical | Risk to participant safety, data integrity or regulatory compliance | Audit trail can be edited by an administrator without a record | Do not use until fixed and verified |
| Major | Significant gap in a required control | No tested restore of backups | Corrective action with a date; approval conditional |
| Minor | Isolated lapse, low risk | Training record missing for one staff member | Fix at the next review |
| Observation | Improvement suggestion | Release notes hard to find | Vendor considers; no formal action |
Use the scale in your own SOP if you have one. Record the evidence for every finding.
Warning signs
If the validation summary or the change log never arrives, treat it as a missing control, not a scheduling problem.
Any route that lets an administrator change history without leaving a record is incompatible with data integrity expectations.
A certification, report or test named in marketing but not shown on request. Record that the claim was not supported.
Vague statements about data return, formats or deletion are a commercial and regulatory risk.
Anything that makes it impossible to attribute an action to a person.
Future features are not controls. Audit what exists today.
Auditing Capture
If you are auditing Capture.Study, begin with what the public Security page states and then verify it in the sandbox. As documented there, staff can turn on two-factor authentication with any authenticator app, sessions end after inactivity with a countdown warning, and data is encrypted at rest and in transit. The audit trail is written by database triggers, one row per changed field, is append-only (the database blocks update, delete and truncate on audit rows) and carries a SHA-256 hash chained to the previous row per study. Clinical data is soft-deleted only, and blinded roles never receive treatment-arm values, enforced by masked database views and row-level security. Data is hosted in the EU (Frankfurt) or the USA (N. Virginia). We review the application against the OWASP Top 10, and there is a published vulnerability disclosure policy.
This page does not state that Capture holds a security certification, an independent penetration test or a third-party audit report, and you should not assume one. If your quality system requires specific documents, ask for them in writing during your audit and record the answer. For enterprise customers, Capture provides documentation to support sponsor validation and UAT; ask what that contains for your release. Capture provides 21 CFR Part 11-aligned controls, and validated use is a shared responsibility with the sponsor.
You can also use the product itself as audit evidence. Create a study, change a value with a reason, export the audit trail and check the fields. Try to delete a record and see what remains. Log in as a blinded role and compare views and exports. These hands-on checks take under an hour and are more convincing than a statement. See the audit trail software page and the inspector export page for what the trail contains.
Sponsors remain responsible for outsourced activities, so some form of oversight is expected. It can be proportionate: a document review and a remote session for a low-complexity study, more depth when the system holds critical data. Follow your own quality system and regulator expectations.
A questionnaire collects statements. An audit examines evidence such as validation records, change logs and the audit trail in use, and ends with graded findings and actions.
Set the interval by risk, for example before first use, after major changes and at a regular interval such as every one to three years. Document the rationale.
Ask for the reason in writing, look for an equivalent (a summary or a controlled remote view) and record the gap as a finding. Decide whether the risk is acceptable.
This page makes no such claim. The Security page lists the controls that exist. If your audit requires certificates or reports, ask for them in writing and record the response.
Yes. The sandbox has every feature with no credit card and no time limit. Create a study, change a value, export the audit trail and test roles. Enterprise customers can ask about validation documentation.
No. It is a general checklist. Use your own SOPs and read the applicable guidelines.
Keep exploring
Vendor security questionnaire
The question list.
EDC procurement checklist
Buying questions.
Computer system validation
Validation basics.
EMA computerised systems guideline
Guideline summary.
21 CFR Part 11 compliance checklist
System controls.
Audit trail software
What the trail records.
EDC buyer scorecard template
Compare vendors.
Capture security
What Capture states.
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.