Log: Vendor Support and SLA Oversight for GxP Computerized Systems

This is a ready-to-use log for the ongoing management of vendor support relationships behind GxP computerized systems. It exists to close a specific gap: a supplier assessment or audit confirms a vendor was acceptable at one point in time, but the support commitment, the version support window, and the defect notification channel all keep moving after that, quietly, and nobody owns watching them move. Replace every <<FILL: ...>> placeholder, update this log at the review cadence you set per vendor, and review the whole set at periodic review. A worked filled specimen follows the template.

This log does not replace two related documents it is easy to confuse it with. The SOP: Software Supplier Assessment and Reliance under CSA governs the initial and periodic qualification decision, whether the vendor is acceptable at all. The Log: SaaS Vendor Release Notes Review and Regression Trigger governs the release-by-release triage of what a SaaS vendor actually shipped. This log sits between the two: it is the standing record of whether the support relationship itself, the response commitments, the supportability horizon, and the notification channels, is still what you were promised and is still adequate for the system’s criticality.

Document control header

1. Purpose

Every GxP-critical commercial or hosted system depends on a vendor relationship that has to keep working, not just have worked at qualification. This log gives one place to confirm, on a recurring basis, that the vendor’s stated response commitment for critical issues still matches the system’s operational risk, that the qualified software version has not silently drifted toward end of support, that defect and security notifications are actually being received and reviewed by a named owner, and that hosted or SaaS vendors are honoring their change-notice terms. A supplier assessment that was accurate two years ago and has not been checked since is not evidence of a current, adequate support relationship.

2. Field table (one row per vendor / system pair, reviewed each cadence)

3. How to run the review

1. Pull the row for each vendor/system pair due this period, based on the review cadence set when the row was opened.
2. Confirm the response commitment against the current agreement, not from memory. Compare it against the system’s criticality tier: a system that supports batch disposition should not be running on a “next business day” commitment without a documented, accepted risk rationale.
3. Check the vendor’s published product lifecycle page or account notice for the current version’s end-of-support date. Where the qualified version is within the trigger window of end of support, confirm an upgrade plan exists and is on the validation or CSV project schedule; a plan that exists only as an intention with no target date is treated as not existing.
4. Confirm the defect and patch notification subscription is active by checking that notifications were actually received in the period, not only that the subscription was set up once. A named owner reviewing zero notifications in a period where the vendor is known to have published something is itself a finding.
5. For hosted or SaaS vendors, confirm the change-notice term in the agreement was honored this period; a vendor who pushed a release with less notice than the agreement specifies is a contract compliance issue, not only a technical one, and is raised as an action regardless of whether the release itself caused a problem.
6. Set the overall status per row using the same three-outcome model used elsewhere in operational review: adequate, adequate with action, or not adequate. Not adequate escalates to the system owner and QA the same way an incident or periodic review non-conformance would.
7. Roll the summary into the next periodic review evidence set so the reviewer is not re-deriving vendor status from scratch.

4. Acceptance criteria

• Every GxP-critical system with a commercial or hosted vendor has a row in this log, reviewed at the stated cadence.
• The response commitment is checked against the current agreement and against the system’s criticality tier, not assumed unchanged since qualification.
• End-of-support tracking is based on the vendor’s current published position, and any system within the trigger window of end of support has a named upgrade plan with a target date.
• Defect and patch notifications are confirmed as actually received and reviewed, not merely subscribed to.
• Hosted and SaaS change-notice terms are checked against what actually happened in the period, not assumed honored.
• Any “not adequate” status is escalated and tracked to closure with the same rigor as a periodic review non-conformance.

5. References

EU GMP Annex 11, Computerised Systems, clause 3 (supplier and service provider agreement) and clause 4.3 (system description), for the expectation that reliance on a supplier is defined and current, not a one-time assumption. A substantially expanded draft revision addressing supplier and service management in far greater depth was published for consultation in July 2025 and had not been finalized as of this writing; confirm the current in-force version before citing clause numbers. ISPE GAMP 5, Second Edition (2022), for supplier assessment and reliance as an operational-phase, not only a pre-purchase, activity. FDA guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026, for the principle of relying on supplier activity in a documented, risk-based way that this log makes auditable over time.

Confirm the current version and clause numbers of each reference before issue.

6. Records generated

7. Revision history

Filled specimen

The following shows one quarter’s entry for an example commercial LIMS vendor. The company, system, and numbers are illustrative; replace them with your own.

This is what “adequate with action” looks like in practice: nothing is wrong today, the response commitment matches the criticality, the notification channel is demonstrably working because it produced something to assess, and the one real risk on the horizon, end of support ten months out, already has a named plan and a project number rather than a vague intention.

Common inspection findings this log prevents

• A vendor’s stated support commitment for critical issues has quietly moved to a lower tier at the last contract renewal, and nobody on the operational side noticed because the original commitment was only checked at initial qualification.
• A system is found running a software version that reached vendor end of support over a year earlier, discovered only when a security patch was needed and none was available.
• A defect notification subscription was set up once, years ago, and nobody can produce evidence that any notification was ever actually reviewed.
• A hosted vendor pushed a change with far less notice than the agreement specifies, and the shortfall was never logged as anything other than an inconvenience.
• Supplier oversight is documented as a one-time audit with no mechanism for catching drift in the years between audits.

How to adapt this log

1. Set your log-numbering scheme and decide the review cadence per vendor, driven by the system’s criticality tier from the inventory.
2. Populate one row per vendor/system pair currently in your GxP inventory with a commercial or hosted relationship.
3. Point the response-commitment adequacy check to your own risk tolerance by tier, and set your own end-of-support trigger window in section 3.
4. Tie the “not adequate” escalation path to your real deviation or CAPA procedure.
5. Confirm every regulation in section 5 against the current published version before issue.