This is a ready-to-use checklist for confirming that a SaaS GxP system’s data export and exit provisions actually work, not just that the contract says they should. It is not a substitute for the full system decommissioning and retirement plan, which governs the moment you actually leave a system; this checklist is narrower and runs at three points where the generic plan does not reach: before you sign, at defined intervals while the contract is active, and as a final pre-exit confirmation. Replace every <<FILL: ...>> placeholder, run it, and route the completed version through your normal document control and records retention. A worked filled specimen follows. This content is educational reference, not legal or regulatory advice.
How to use this checklist
| Field | Meaning |
|---|---|
| Verify | The specific question being answered, not a topic |
| Evidence to request | What to ask for or test, by name |
| P / F / NA | Pass, Fail, or Not Applicable. Not Applicable requires a written reason in Notes |
| Notes | What was actually examined or tested, with a date and a result, not “confirmed” alone |
Run this checklist at three points, and keep all three runs on file:
- Pre-signature. Before the master service agreement or the quality/technical agreement is signed, so an unacceptable answer is still a negotiating point rather than a discovered gap.
- Periodic, during the active contract. At a defined interval (annually is typical for a high-impact system) to prove the export mechanism still works and the contractual terms have not quietly drifted, rather than trusting a promise made once at signature.
- Pre-exit. Before the contract actually ends, as the final gate feeding into the full decommissioning and retirement plan.
Section 1. Contractual basis
| # | Verify | Evidence to request | P / F / NA | Notes |
|---|---|---|---|---|
| 1.1 | The agreement states a specific data export format, and that format is non-proprietary and readable without the vendor’s software | Quality/technical agreement export clause, or the cloud/SaaS quality and technical agreement section 8 | ||
| 1.2 | The agreement states a timeframe for delivering a complete export after termination is requested | Agreement clause with a stated number of days | ||
| 1.3 | The agreement states a data retention period after termination, before destruction, long enough to confirm the export was complete | Agreement clause with a stated retention period | ||
| 1.4 | The agreement requires written confirmation of data destruction after the retention period | Agreement clause | ||
| 1.5 | The agreement confirms the audit trail is included in the export, in a format that preserves its meaning (who, what, when, why), not flattened to a value-only extract | Agreement clause or vendor documentation describing the export’s audit trail content | ||
| 1.6 | The export commitment extends to any sub-processor holding Customer data, not only the primary vendor | Sub-processor disclosure and the agreement’s flow-down clause |
Section 2. Export mechanism, tested
Do not accept a description of the export mechanism as evidence that it works. Run it.
| # | Verify | Evidence to request | P / F / NA | Notes |
|---|---|---|---|---|
| 2.1 | A full export was actually executed within the last <<FILL: e.g. 12 months>>, not merely offered as a feature | The export test record, with date and executor | ||
| 2.2 | The export includes all GxP record types the system holds, not a subset | Compare the export contents against the system’s known record inventory | ||
| 2.3 | The export includes metadata (creation date, modification history, ownership, linkage between records) | Open the export and confirm metadata fields are present and populated | ||
| 2.4 | The export includes the complete audit trail, with entries readable and attributable | Open the audit trail portion of the export and trace one record’s history end to end | ||
| 2.5 | The export can be opened and read using only commonly available software, with no dependency on the vendor’s application | Open the export on a machine with no vendor software installed | ||
| 2.6 | A sample of exported records was compared against the live system and found accurate and complete | Side-by-side comparison record for a defined sample | ||
| 2.7 | The export includes, or is accompanied by, sufficient documentation to interpret the data structure (a data dictionary or schema description) | The data dictionary or schema documentation provided with the export | ||
| 2.8 | Dynamic data (records that need reprocessing to be meaningful, such as calculated fields with live formulas) either exports in a usable static form or the export includes a documented alternative | Review of any dynamic record type against the export format |
Section 3. Configuration and non-data assets
| # | Verify | Evidence to request | P / F / NA | Notes |
|---|---|---|---|---|
| 3.1 | Tenant configuration (workflow rules, roles, e-signature meanings, field definitions) can be exported or is otherwise documented outside the vendor’s system | Configuration export or an independently maintained configuration baseline document | ||
| 3.2 | User account and role history is included or separately retrievable, since it supports attribution of historical records | User/role export or independently maintained record | ||
| 3.3 | Any custom reports, templates, or integrations built in the platform are documented independently of the vendor’s system | Documentation of custom builds outside the platform |
Section 4. Timing and process readiness
| # | Verify | Evidence to request | P / F / NA | Notes |
|---|---|---|---|---|
| 4.1 | The time actually taken to produce the last test export matches or beats the contractual commitment | Export test record with elapsed time, compared against the agreement’s stated window | ||
| 4.2 | A named internal owner is responsible for initiating and verifying the export at contract end, independent of who initiated the last periodic test | Role assignment in the system’s validation file or this checklist’s completion record | ||
| 4.3 | The destination for exported data (archive system, successor system, or offline store) is identified and itself capable of retaining the data for the full GxP retention period | Destination system’s retention capability, or the archive plan | ||
| 4.4 | Where the destination is not yet built or qualified, a documented interim plan exists (for example, a qualified holding archive) | Interim plan documentation |
Acceptance criteria
This checklist run is acceptable when:
- Every item is marked Pass, Fail, or Not Applicable with a written reason, and no Pass relies on a vendor claim alone; every Pass in Section 2 is backed by an actual test performed by the Customer.
- Any Fail is documented with an owner and a target resolution date, and a Fail in Section 2 (the export does not actually work) blocks acceptance of the system for GxP use if found pre-signature, or triggers an escalation to the vendor and a documented risk position if found during periodic testing.
- The pre-signature run is completed and reviewed by Quality Assurance before the master service agreement is executed.
- The periodic run repeats on the interval set for the system’s criticality, and results are compared run to run to detect drift (a previously passing item that now fails).
- The pre-exit run feeds directly into the system’s decommissioning and retirement plan rather than standing alone.
Filled specimen
The following shows selected items completed for the periodic (annual) run on an example cloud-native QMS, so you can see the level of detail expected. The vendor, system, and dates are illustrative; replace them with your own.
| # | Verify | P / F / NA | Notes |
|---|---|---|---|
| 1.5 | Audit trail included in export, meaning preserved | P | Agreement section 8.1 (Quality and Technical Agreement QTA-CLOUD-2026-004) confirms audit trail export in JSON with who/what/when/why fields named explicitly. Confirmed against the actual export in item 2.4. |
| 2.1 | Full export executed within 12 months | P | Export executed 14 Jul 2026 by A. Reyes (Validation), using the vendor’s self-service export function. Second periodic test since go-live (prior: 09 Aug 2025). |
| 2.4 | Audit trail complete and attributable | P | Traced record DEV-2026-0442 (a closed deviation) through the exported audit trail: 11 entries from creation to closure, each showing user, timestamp, old and new values, and the recorded reason. Matched the live system’s audit trail for the same record, viewed 15 Jul 2026. |
| 2.5 | Readable without vendor software | P | Export opened on a laptop with no vendor application installed, using a standard spreadsheet application and a JSON viewer. All fields legible, no proprietary format encountered. |
| 2.6 | Sample compared against live system | P | 15 records sampled at random plus the 3 most recent closures; all 15 matched the live system exactly on content and metadata. |
| 2.8 | Dynamic data handled | NA | System holds no dynamic/formula-driven record types; all GxP records are static once approved. |
| 4.1 | Export timing vs. contractual commitment | P | Export completed in 6 hours; agreement commits to export availability “on demand,” no fixed SLA for a self-service export, so this item measures against internal expectation of same-business-day, which was met. |
Overall result for this periodic run: Pass, no open items. Next periodic run due 14 Jul 2027, or immediately upon any material change to the vendor’s export mechanism or a sub-processor change per the vendor release review log.
Common inspection findings this checklist prevents
- A data export clause in the contract that was never tested, discovered to be incomplete or unreadable only at the moment the Customer actually needed to leave the vendor.
- An export that includes the data but not the audit trail, or includes the audit trail flattened into a form that no longer shows who changed what and why.
- A pre-signature review that checked the contract language but never ran the export, so an unenforceable or vague clause was accepted without anyone noticing.
- Tenant configuration and workflow rules assumed to travel with a data export, never confirmed, and lost when the system is actually retired.
- A periodic export test performed once at go-live and never repeated, so drift in the vendor’s export mechanism or scope goes undetected for years.
- No named internal owner for initiating the exit export, discovered only when the contract is already ending and everyone assumes someone else has it.
How to adapt this checklist
- Set the system, vendor, and agreement reference, and confirm which of the three run types (pre-signature, periodic, pre-exit) you are performing.
- Adjust the record types and dynamic-data considerations in Sections 2 and 3 to what this specific system actually holds.
- Set your periodic interval by the system’s criticality; a high-impact system supporting release decisions warrants an annual run, a lower-impact system may run less often.
- Where a Fail is found, route it as a finding against the vendor relationship, not a private note; escalate contractually if the export mechanism does not meet the agreement’s own terms.
- Feed the pre-exit run directly into the system decommissioning and retirement plan so the two documents do not duplicate effort or leave a gap between them.