This is a ready-to-use quality and technical agreement, written specifically for a cloud or SaaS vendor rather than a contract manufacturer. It can stand alone as a schedule attached to the master service agreement, or sit alongside a generic quality agreement where a generic one already exists. Replace every <<FILL: ...>> placeholder, negotiate the specifics with the vendor, and route it through both organizations’ approval before the system goes live. A worked filled specimen follows the template. Get this reviewed and signed by quality before procurement signs the master service agreement; once the master agreement is executed, the bargaining position to add these terms is largely gone. This content is educational and general; adapt it to your own contracts and have it reviewed by qualified counsel and quality before use.
Document control header
| Field | Entry |
|---|---|
| Document title | Quality and Technical Agreement for <<FILL: SYSTEM / PRODUCT NAME>> between <<FILL: CUSTOMER NAME>> and <<FILL: VENDOR NAME>> |
| Agreement number | <<FILL: QTA-ID, e.g. QTA-CLOUD-2026-004>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Expiry / review date | <<FILL: review date, e.g. effective date + 1 year, or tied to master service agreement renewal>> |
| Linked master service agreement | <<FILL: contract reference>> |
| Linked supplier assessment / cloud qualification record | <<FILL: assessment or qualification record ID>> |
| Service model | <<FILL: SaaS / PaaS / IaaS>> |
1. Parties, product, and scope
| Term | Definition |
|---|---|
| Customer | <<FILL: CUSTOMER NAME>>, the regulated company using the system for a GxP purpose. Referred to below as “the Customer.” |
| Vendor | <<FILL: VENDOR NAME>>, the party that builds, operates, and hosts the system, or contracts with a separate cloud infrastructure provider to do so. Referred to below as “the Vendor.” |
| Cloud infrastructure provider (if separate from the Vendor) | <<FILL: provider name, or "same as Vendor">> |
| System / product | <<FILL: application name and version or release channel>> |
| GxP processes supported | <<FILL: e.g. deviation and CAPA management, LIMS result capture, training records>> |
| Data hosted | <<FILL: GxP record types held, including audit trail and metadata>> |
This agreement defines the Vendor’s commitments for the data integrity, change management, access control, availability, audit, and data portability aspects of the system named above. It does not replace the master service agreement’s commercial and legal terms; where the two conflict on a quality or GxP matter, this agreement prevails. The Customer remains the regulated party accountable for the system’s fitness for GxP use regardless of what the Vendor operates.
2. Purpose
Hosting a GxP system does not transfer the Customer’s compliance responsibility to the Vendor. This agreement exists to state, in writing and with measurable terms, exactly what the Vendor commits to provide so the Customer can evidence that commitment at inspection. A quality agreement with no measurable parameters, only “commercially reasonable efforts” or “promptly,” is not a control; it is a hope.
3. Data integrity commitments
| # | Commitment | Vendor undertakes to | Parameter |
|---|---|---|---|
| 3.1 | Audit trail retention and scope | Maintain an audit trail covering all creation, modification, and deletion of GxP records in the Customer’s tenant, aligned to the Customer’s record retention obligations | Retention no shorter than <<FILL: e.g. the longer of contract term plus 1 year, or the Customer's stated retention period>> |
| 3.2 | Audit trail integrity | Ensure the audit trail cannot be disabled or edited by any role, including Vendor administrative roles, without the action itself being logged | <<FILL: attestation reference or design documentation>> |
| 3.3 | No unauthorized modification of Customer data | Not modify, delete, or access Customer GxP data except as needed to operate the service or as directed by the Customer, or as required by law | <<FILL: exceptions listed explicitly, e.g. support access under section 5>> |
| 3.4 | Data loss, corruption, or breach notification | Notify the Customer of any event affecting the confidentiality, integrity, or availability of Customer data | Within <<FILL: e.g. 24 to 72 hours>> of the Vendor becoming aware, in writing, to the named quality contact in section 10 |
| 3.5 | Data accuracy of platform-generated values | Where the platform itself calculates or generates a value used in a GxP decision (a rounding function, a derived field), maintain and provide evidence of the calculation’s correctness | <<FILL: evidence type, e.g. algorithm documentation, test evidence>> |
4. Change management
| # | Commitment | Vendor undertakes to | Parameter |
|---|---|---|---|
| 4.1 | Advance notice of planned updates | Notify the Customer before deploying a software update to the Customer’s production tenant | Minor updates: <<FILL: e.g. 5 business days>>. Major updates (new features, workflow changes, changes to GxP-relevant functions): <<FILL: e.g. 30 to 90 days>> |
| 4.2 | Release notes | Provide release notes sufficient for the Customer to assess GxP impact, identifying at minimum any change to audit trail behavior, e-signature behavior, access control, calculations, or data structure | Provided with every notice under 4.1 |
| 4.3 | Sandbox / test environment access | Provide the Customer access to a sandbox or staging environment reflecting the upcoming release, before it reaches production | At least <<FILL: e.g. 10 business days>> before major-update production deployment |
| 4.4 | Validated-state continuity | Either maintain the Customer’s configured validated state through an update, or explicitly flag in the release notes when a change could affect it | Every release, without exception |
| 4.5 | Emergency and security patches | May deploy an emergency security patch without the standard notice period where a delay would leave a known vulnerability exploitable | Notify the Customer within <<FILL: e.g. 24 hours>> after deployment, with a description of what changed |
| 4.6 | Version pinning (API-delivered or model-based features, where applicable) | State whether and for how long a specific version can be pinned rather than auto-updated | <<FILL: pinning terms, or "not applicable">> |
5. Access controls
| # | Commitment | Vendor undertakes to | Parameter |
|---|---|---|---|
| 5.1 | Vendor administrative access | Limit Vendor staff access to Customer production data to role-limited personnel, log every such access, and notify the Customer of access taken for support or troubleshooting | Access log available on request; notification within <<FILL: e.g. 5 business days>> of a support access event touching GxP data |
| 5.2 | Tenant isolation | In a multi-tenant deployment, logically segregate the Customer’s data from other tenants’ data, with no shared identifier or query path that could surface another tenant’s records | Confirmed by <<FILL: penetration test summary, architecture attestation>>, refreshed <<FILL: annually>> |
| 5.3 | Customer-side access controls provided | Provide the Customer the capability to configure role-based access, unique user accounts, password or SSO/MFA policy, and periodic access review reporting | Available from go-live |
| 5.4 | Identity federation support | Support the Customer’s identity provider (SSO) and document the failure modes if the identity provider grants a stale role or fails to revoke a leaver | <<FILL: documentation reference>> |
6. Availability and business continuity
| # | Commitment | Vendor undertakes to | Parameter |
|---|---|---|---|
| 6.1 | Uptime | Maintain a stated uptime commitment for the production service, measured and reported | <<FILL: e.g. 99.5% monthly, measurement method stated>> |
| 6.2 | Backup frequency and RPO | Perform application-consistent backups on a defined schedule and commit to a recovery point objective | <<FILL: e.g. nightly full plus continuous transaction log, RPO 1 hour>> |
| 6.3 | Recovery time objective | Commit to a technical recovery time for the service following an outage | <<FILL: e.g. RTO 8 hours>> |
| 6.4 | Disaster recovery testing | Test the disaster recovery plan on a defined cadence and make evidence of the test available to the Customer | <<FILL: e.g. annually, summary report on request>> |
| 6.5 | Restore verification | Provide, or support the Customer in performing, at least one documented restore of Customer tenant data confirming completeness and audit trail survival | <<FILL: frequency, e.g. at go-live and annually thereafter>> |
7. Audit rights
| # | Commitment | Vendor undertakes to | Parameter |
|---|---|---|---|
| 7.1 | Right to audit | Grant the Customer, or a mutually acceptable third party, the right to audit the Vendor’s GxP-relevant facilities, systems, and processes | <<FILL: on-site or remote, frequency, e.g. every 2 years or for cause>> |
| 7.2 | Reports in lieu of audit | Where an on-site audit of shared infrastructure is not offered to individual customers, provide independent third-party reports covering the same scope | <<FILL: SOC 2 Type II / ISO 27001, current within the last 12 months>> |
| 7.3 | Sub-processor disclosure | Disclose every sub-processor material to the service, including the underlying cloud infrastructure provider, and notify the Customer before adding or materially changing one | List provided at signature; notice <<FILL: e.g. 30 days>> before a material change |
| 7.4 | Regulatory inspection notice | Notify the Customer of any regulatory inspection or enforcement action covering the service that could affect the Customer’s product or data | Within <<FILL: e.g. 5 business days>> |
8. Data portability and exit
| # | Commitment | Vendor undertakes to | Parameter |
|---|---|---|---|
| 8.1 | Export capability | Provide a mechanism for the Customer to export all Customer data, including metadata and the complete audit trail, in a documented, non-proprietary, human-readable format | Available on demand during the contract term, not only at termination |
| 8.2 | Export at termination | Provide a complete export of Customer data within a defined period following contract termination, in the format described in 8.1 | Within <<FILL: e.g. 30 days>> of termination |
| 8.3 | Data retention after termination | Retain Customer data for a defined period after termination before destruction, to allow the Customer to confirm the export was complete | <<FILL: e.g. 90 days>> |
| 8.4 | Destruction confirmation | Provide written confirmation that Customer data was destroyed after the retention period in 8.3, across the Vendor’s systems and any sub-processor’s systems | Confirmation within <<FILL: e.g. 30 days>> of destruction |
9. Acceptance criteria for this agreement
Apply these tests before accepting the agreement as complete. If any fails, the agreement is not done, no matter how many sections are filled in.
| # | Test | Met? |
|---|---|---|
| 1 | Every commitment above has a measurable parameter (a number of days, a percentage, an RPO/RTO in hours), not “promptly” or “best efforts” | <<FILL: Y/N>> |
| 2 | The data-breach notification window (3.4) is short enough that the Customer can meet its own regulatory reporting deadlines | <<FILL: Y/N>> |
| 3 | Every control that a broader shared-responsibility matrix marks “shared” maps to a named owner and a clause in this agreement; no orphaned control | <<FILL: Y/N>> |
| 4 | Audit rights (section 7) survive even where the Vendor offers reports in lieu of visits, preserving a route to escalate if a report raises questions | <<FILL: Y/N>> |
| 5 | The exit clause (section 8) is testable: the Customer could run an export today and read the result without the Vendor’s software | <<FILL: Y/N>> |
| 6 | Sub-processor disclosure (7.3) names the underlying cloud infrastructure provider specifically, not just “our hosting partners” | <<FILL: Y/N>> |
10. Quality contacts and notice
| Role | Customer | Vendor |
|---|---|---|
| Primary quality contact (name, title, email, phone) | <<FILL>> | <<FILL>> |
| Security incident contact | <<FILL>> | <<FILL>> |
| Escalation contact | <<FILL>> | <<FILL>> |
11. Term, amendment, and termination
This agreement is effective on the date in the header and remains in force for the period stated, after which both parties review and re-approve it or let it lapse with the master service agreement. Either party may propose an amendment in writing; amendments are version-controlled and signed by both quality units. Termination of the master service agreement terminates this agreement, subject to the data retention and destruction commitments in section 8 surviving termination.
12. References
EU GMP Annex 11, “Computerised Systems” (in force since 2011), clause 3 on suppliers and service providers. 21 CFR Part 11, “Electronic Records; Electronic Signatures” (effective 1997). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). Regulation (EU) 2016/679 (General Data Protection Regulation), where personal data is processed, for sub-processor disclosure norms this agreement borrows from. GAMP 5 (Second Edition, ISPE, 2022), supplier reliance and evidence-reuse principles. ISO/IEC 27001 (information security management) and SOC 2 Type II, where relied on as third-party evidence under section 7.
Confirm the current version and clause numbers of each reference before issue.
13. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
14. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Customer, Quality Assurance | <<FILL>> | ||
| Customer, System Owner | <<FILL>> | ||
| Vendor, Quality / Compliance representative | <<FILL>> | ||
| Vendor, authorized signatory | <<FILL>> |
Filled specimen
The following shows selected commitments completed for an example cloud-native QMS vendor, so you can see the level of detail an inspector expects. The company, vendor, and numbers are illustrative; negotiate your own with the other party.
Customer: Helix Therapeutics. Vendor: Northline QMS Inc., a SaaS quality management platform, multi-tenant, hosted on a major public cloud provider disclosed as a sub-processor.
| # | Commitment | Entry |
|---|---|---|
| 3.1 | Audit trail retention | Retained for contract term plus 2 years, meeting Helix’s 10-year record retention through the section 8.1 export routine, since in-application retention alone is shorter than the obligation |
| 3.4 | Breach notification | 48 hours from Vendor awareness, in writing, to Helix’s named Data Integrity Lead |
| 4.1 | Update notice | Minor updates: 5 business days. Major updates (new workflow features, changes to audit trail behavior): 45 days |
| 4.3 | Sandbox access | Staging tenant reflecting the upcoming release available 15 business days before major-update production deployment |
| 6.1 | Uptime | 99.5% monthly, measured via the Vendor’s published status page with historical data retained 12 months |
| 6.2 / 6.3 | Backup / RPO / RTO | Nightly full plus 15-minute transaction log shipping, RPO 1 hour; RTO 8 hours for full service restoration |
| 7.2 | Third-party report | SOC 2 Type II covering the application and the disclosed sub-processor’s infrastructure layer, current within 12 months, provided under NDA |
| 7.3 | Sub-processor disclosure | Names the public cloud provider and region; 30 days’ advance notice before adding or changing a material sub-processor |
| 8.1 / 8.2 | Export | Self-service JSON export with attachments and full audit trail, available on demand; full export within 30 days of termination |
| 8.3 / 8.4 | Retention / destruction | 90-day retention post-termination; written destruction confirmation within 30 days after that window, covering the disclosed sub-processor |
Applying the acceptance test in section 9: every commitment above carries a number, the 48-hour breach window is short enough for Helix to meet its own reporting clock, the SOC 2 report’s scope was checked to actually name the sub-processor’s infrastructure layer rather than assuming it was covered, audit rights survive through the report-in-lieu-of-visit clause, and Helix ran a real test export before signing, confirming the JSON format was readable without Northline’s software. That is what turns this from a filed document into a working control.
Common inspection findings this template prevents
- A master service agreement signed with uptime and pricing terms but no GxP-specific commitments on audit trail retention, breach notification, or data exit.
- Notification clauses written as “promptly” or “commercially reasonable efforts,” with no number a Customer can hold the Vendor to.
- Sub-processor use undisclosed, discovered only when a security incident or an audit reveals a fourth party the Customer never assessed.
- Audit rights that evaporate entirely once the Vendor offers a report in lieu of a visit, with no route to escalate if the report raises questions.
- Data export promised in the contract but never tested, so at exit the format proves unreadable or incomplete.
- Sandbox or staging access to review a major update promised informally but not written down, so the Customer first sees the change in production.
- Quality never reviewed the master service agreement before procurement signed it, so GxP terms were negotiated from a position with no bargaining strength left.
How to adapt this template
- Set the parties, system, service model, and effective date in the header, and link the supplier assessment or cloud qualification record this agreement supports.
- Negotiate every parameter in sections 3 through 8 with the Vendor; do not accept a blank left as “TBD” past the point the system goes live.
- If a generic quality agreement already exists between the parties (for example a contract-manufacturing-style agreement), use this document as a cloud-specific schedule attached to it rather than duplicating the whole structure; keep the responsibility-matrix and data-integrity sections aligned between the two.
- Run the acceptance test in section 9 before signature, not after a finding surfaces the gap.
- Confirm every regulation in section 12 against the current published version, and have both quality units and authorized signatories sign before the system carries GxP data in production.