This is a ready-to-use log for a continuously or frequently updated SaaS system. It exists because the most common cloud-era inspection finding in this space is not a bad decision about a vendor release, it is no decision at all on record: release notes that nobody can show were ever opened. This log gives every release, no matter how minor, a dated entry, a named reviewer, and a triage outcome, so “unmanaged vendor updates” stops being possible to say about your program. Replace every <<FILL: ...>> placeholder, update it at every vendor release, and review it at periodic review. A worked filled specimen follows the template.
Document control header
| Field | Entry |
|---|---|
| Document title | SaaS Vendor Release Review Log for <<FILL: SYSTEM NAME>> |
| Document number | <<FILL: reference, e.g. VRL-CLOUD-014>> |
| System / vendor | <<FILL: system name, vendor name>> |
| Quality / technical agreement reference | <<FILL: agreement document number>> |
| Log owner | <<FILL: role, e.g. System Owner / Validation Lead>> |
| Release notification channel | <<FILL: how the vendor notifies, e.g. portal, email distribution, RSS>> |
1. Purpose
Every release a SaaS vendor pushes to the Customer’s production tenant is a change to a validated system, whether the vendor calls it a patch, a minor update, or a major release. This log gives one place to show that release notes were reviewed for every release, that a GxP-relevance triage decision was made and recorded, and that any release warranting deeper analysis was handed off to a full change impact assessment rather than absorbed silently. A validation report describing a software version that no longer exists, with no periodic review linking to what actually shipped since, is the failure mode this log is built to prevent.
2. Field table
| Field | Format | Required | Who | When |
|---|---|---|---|---|
| Release ID / version | text | Yes | Log owner | On notification |
| Release date (vendor) | date | Yes | Log owner | On notification |
| Notification received date | date | Yes | Log owner | On notification |
| Notice period met? (per agreement) | Yes/No | Yes | Log owner | On notification |
| Release type | Minor / Major / Emergency-security | Yes | Log owner | On notification |
| Release notes reviewed by | name/role | Yes | Reviewer | Before deployment |
| GxP-relevant change identified? | Yes/No | Yes | Reviewer | At review |
| Areas potentially affected | text (audit trail / e-signature / access / calculation / data structure / none) | Yes | Reviewer | At review |
| Triage outcome | No action / Confirmatory check / Full change impact assessment | Yes | Reviewer + QA | At review |
| Sandbox / staging test performed? | Yes/No, with result | Conditional (Major releases) | Tester | Before production deployment |
| Linked change control / impact assessment ID | text or N/A | Conditional | Log owner | If triaged to full assessment |
| Production deployment date | date | Yes | Log owner | After deployment |
| Post-deployment confirmation | Pass/Fail with note | Yes | Log owner | After deployment |
3. Triage decision rule
| Triage outcome | When it applies | Action |
|---|---|---|
| No action | Release notes show no change to any GxP-relevant area (audit trail, e-signature, access control, GxP calculations, data structure, workflow the Customer relies on) | Log the review and the “no GxP-relevant change” basis; no further action |
| Confirmatory check | Release notes show a change plausibly touching a GxP-relevant area, but low risk and well within the vendor’s own regression scope (a mature, vendor-tested minor patch) | Perform and record a defined confirmatory check (spot-check the affected function post-deployment); no full protocol required |
| Full change impact assessment | Release notes show a change to a GxP-relevant area with meaningful risk, ambiguity, or a new feature the Customer will rely on | Escalate immediately to the <<FILL: change control SOP-ID>> process and complete a change impact and risk assessment before or promptly after production deployment, per the risk |
A release with no stated basis for its triage outcome is treated as incomplete and returned to the reviewer; “reviewed, no issues” with nothing else recorded does not satisfy this log, for the same reason a bare audit-trail-review tick does not satisfy an audit trail review record.
4. Instructions
- Log every release notification the moment it is received, before it is reviewed, so a missed or unreviewed release is visible as an open row rather than silently absent.
- The reviewer reads the actual release notes, not a marketing summary, and names the specific areas checked (audit trail, e-signature, access control, calculations, data structure, workflow) even when the answer for each is “no change.”
- Apply the triage rule in section 3 and record the basis. QA confirms the triage outcome for any release triaged as GxP-relevant, whether it ends in a confirmatory check or a full assessment.
- For a major release, confirm sandbox or staging testing was performed before production deployment where the quality/technical agreement provides that window; if the vendor does not honor the notice period, record that as a deviation from the agreement, not a silent gap.
- Close the loop after production deployment with a post-deployment confirmation, even for “no action” releases, so a release that behaved differently than the notes described is caught.
- Bring this log to periodic review; the count of releases logged against the count actually deployed (available from the vendor’s version history or portal) is the completeness check.
5. Retention
Retain with the system’s validation file for not less than <<FILL: retention period>>. This log, not the vendor’s own release history, is the record that proves the Customer’s own review discipline.
Filled specimen
The following shows a run of entries for an example cloud QMS over one quarter, so you can see the level of detail expected. The vendor, system, and dates are illustrative; replace them with your own.
| Release ID | Release date | Notice met? | Type | Reviewed by | GxP-relevant? | Areas checked | Triage outcome | Linked assessment | Deployed | Post-check |
|---|---|---|---|---|---|---|---|---|---|---|
| v14.2.0 | 2026-05-04 | Yes (5 bd) | Minor | A. Reyes, Validation | No | Audit trail: no change. E-sig: no change. Access: no change. Calc: no change. Reporting UI text only | No action | N/A | 2026-05-11 | Pass, UI text change confirmed cosmetic |
| v14.3.0 | 2026-05-28 | Yes (5 bd) | Minor | A. Reyes, Validation | Yes | Access control: new “read-only auditor” role added, additive, no change to existing roles | Confirmatory check | N/A | 2026-06-04 | Pass, existing roles unchanged, new role confirmed read-only |
| v15.0.0 | 2026-06-15 | Yes (46 days, agreement requires 45) | Major | A. Reyes, Validation + QA (R. Kessler) | Yes | Workflow engine rewritten (release note item 6.2); audit trail entry structure for workflow steps changed | Full change impact assessment | CC-2026-0311 | 2026-07-30 | Pass, per CC-2026-0311 regression results |
| v15.0.1 | 2026-08-02 | Yes (emergency) | Emergency-security | A. Reyes, Validation | No (security-only, no functional change) | Confirmed via vendor security advisory: authentication library patched, no application logic changed | No action | N/A | 2026-08-02 (same day, per emergency clause) | Pass, login and session behavior spot-checked post-deployment |
In this example, three of four releases needed nothing beyond a logged review, and the one release that touched the audit trail’s own structure was caught at triage, escalated, and closed through a real change impact assessment before the log moved on. The emergency security patch is on the log too, deployed same-day under the agreement’s emergency clause, with the basis for “no action” written down rather than assumed because it was labeled “security.” That is the completeness a periodic reviewer checks: every release accounted for, every triage decision reasoned, nothing silently absorbed.
Common inspection findings this log prevents
- Release notes that nobody can show were ever reviewed, discovered only when a periodic review compares the log to the vendor’s actual version history and finds gaps.
- A “no impact” conclusion for a release with no record of which GxP-relevant areas were actually checked.
- A major release deployed to production with no sandbox or staging test, despite the quality agreement promising one.
- An emergency security patch treated as automatically GxP-irrelevant with no basis recorded, when the patch in fact touched an authentication or access-control path.
- A release that should have triggered a full change impact assessment instead absorbed as a routine “no action” entry, discovered only when its effect surfaces downstream.
- A validated state described in a report from months or years ago, with a long run of undocumented releases in between and no periodic reconciliation.
How to adapt this log
- Set the system, vendor, and quality/technical agreement reference in the header, and point the notification channel field to however this vendor actually communicates releases.
- Adjust the “areas potentially affected” list in section 2 to the GxP-relevant functions specific to this system.
- Set your own triage thresholds in section 3 if they differ, and confirm QA involvement is required for any release triaged above “no action.”
- Link this log’s escalation row directly to your real change control SOP-ID and the change impact and risk assessment template for the deep-dive analysis.
- Bring the log to every periodic review and reconcile its entry count against the vendor’s own version history before signing off that nothing was missed.