This is a ready-to-use checklist. Replace every <<FILL: ...>> placeholder with your own specifics and route completed copies through your normal supplier-qualification and review process. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.
Purpose
When a GxP system runs on a vendor’s SaaS platform, the host-level security log moves behind the vendor’s operational boundary. This checklist qualifies, before signing, that the vendor will provide the specific logging evidence a data integrity program needs, and re-verifies at each periodic review that the commitment is still being met in practice, not just on paper.
A generic software supplier assessment asks whether the vendor is a sound quality partner overall. This checklist asks a narrower, sharper question: if a vendor engineer touched your tenant’s data tomorrow, could you actually get proof of what they did, from where, and whether anyone authorized it? Use both. The general assessment covers the vendor as a company; this one covers the single control that catches an invisible falsification happening on infrastructure you will never get to see.
Scope
| Field | Entry |
|---|---|
| System / vendor | <<FILL>> |
| Deployment model | <<FILL: SaaS / PaaS / IaaS>> |
| Assessment type | <<FILL: pre-contract onboarding, or periodic review>> |
| Data criticality tier | <<FILL: High / Medium / Low, from the system inventory>> |
| Performed by | <<FILL: role, e.g. QA or IT security, independent of the business owner who selected the vendor>> |
Assessment checklist
| # | Item | Pass / Fail / NA | Evidence reviewed |
|---|---|---|---|
| 1 | The vendor maintains a tamper-evident log of privileged and vendor-staff access to your tenant’s data, not only end-user actions inside the application | <<FILL>> | <<FILL>> |
| 2 | That log captures, at minimum, who accessed the tenant, when, from where, and what action class was performed (read, direct data access, configuration change) | <<FILL>> | <<FILL>> |
| 3 | The vendor provides an export or streaming feed (log egress or an audit-log API) so your own review can draw from a copy you hold, not only from a vendor-controlled console | <<FILL>> | <<FILL>> |
| 4 | The exported or streamed feed is complete, arrives in a usable format, and has been test-ingested into your own log store or review process | <<FILL>> | <<FILL>> |
| 5 | Contractual retention of the vendor’s security logs meets or exceeds the retention period of the GxP records the system supports | <<FILL>> | <<FILL>> |
| 6 | The agreement commits the vendor to notify you of confirmed security incidents affecting your data, within a defined timeline | <<FILL>> | <<FILL>> |
| 7 | The vendor has evidenced segregation of duties for its own privileged staff (an independent audit report against a recognized control framework, or equivalent) | <<FILL>> | <<FILL>> |
| 8 | The agreement grants you a right to audit, or an equivalent assurance mechanism, covering the vendor’s handling of your data | <<FILL>> | <<FILL>> |
| 9 | Responsibilities are explicitly divided: which security events are the vendor’s to log, which are yours (identity, tenant configuration), with no event type assumed by both sides or by neither | <<FILL>> | <<FILL>> |
| 10 | (Periodic review only) The exported/streamed feed has been monitored since the last review for forwarding silence, and any gap was investigated | <<FILL>> | <<FILL>> |
| 11 | (Periodic review only) A sample of the vendor’s privileged-access log entries for the period reconciles to a documented, authorized reason (a support ticket, a change record) | <<FILL>> | <<FILL>> |
Disposition
| Outcome | Action |
|---|---|
| All items Pass | Approve for use (onboarding) or confirm continued reliance (periodic review); file this record in the supplier file |
| Any item Fail, High tier system | Escalate to the supplier-management and quality function before go-live or before continuing reliance; require a remediation commitment with a date |
| Any item Fail, Medium or Low tier system | Document the gap and residual risk in the data integrity assessment; track remediation on a risk-based timeline |
| Vendor cannot produce evidence for item 1, 3, or 5 | Treat as a high-priority gap regardless of tier; these three are the minimum floor for independent evidence of vendor-side access |
Acceptance criteria
The assessment is acceptable when every item carries a scored result and evidence, every Fail tracks to resolution, and an independent reviewer signs the record.
References
21 CFR 11.10(d), (e), (g) (access controls and audit trails, applied through the vendor relationship). EU GMP Annex 11, clauses 3 (supplier and service provider assessment) and 12 (security). FDA Computer Software Assurance guidance (cloud service model treatment). MHRA GxP Data Integrity Guidance and Definitions; PIC/S PI 041.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
| Field | Entry |
|---|---|
| System / vendor | Cloud-hosted LIMS, Vendor Co. |
| Deployment model | SaaS |
| Assessment type | Periodic review (annual) |
| Data criticality tier | High (release-testing results) |
| Performed by | T. Alvarez, IT Security, independent of the Lab Operations business owner |
| # | Item | Result | Evidence reviewed |
|---|---|---|---|
| 1 | Tamper-evident privileged-access log exists | Pass | Vendor SOC 2 Type II report, section on access logging |
| 2 | Captures who, when, where, action class | Pass | Sample export reviewed, confirmed fields present |
| 3 | Export/streaming feed available | Pass | Audit-log API documented in technical agreement, Appendix C |
| 4 | Feed test-ingested | Pass | Test feed ingested into internal SIEM, 12 Sept 2026 |
| 5 | Retention meets or exceeds records | Pass | Contract commits 7-year retention; LIMS records require 6 years |
| 6 | Incident notification timeline | Pass | 24-hour notification clause, Section 9.2 of agreement |
| 7 | Segregation of duties evidenced | Pass | SOC 2 Type II, no exceptions noted in access-control section |
| 8 | Right to audit | Pass | Section 14 of agreement |
| 9 | Responsibilities explicitly divided | Pass | RACI in onboarding packet, confirmed current |
| 10 | Feed monitored for silence since last review | Fail | Two gaps found, 14-16 March and 2-3 July 2026, totaling 38 hours, not investigated at the time |
| 11 | Sample of privileged-access entries reconciled | Pass | 10 of 10 sampled entries matched an open support ticket |
Disposition: Item 10 is scored Fail. Escalated to supplier management the same day; root cause traced to an internal SIEM forwarder misconfiguration, not a vendor failure. CAPA opened to alert on feed silence going forward (previously no alert existed on this feed specifically), and a retrospective check confirmed no privileged access occurred during either gap window by cross-referencing the vendor’s own retained logs for those dates.
Common inspection findings this checklist prevents
- A SaaS agreement signed with no logging or audit commitments at all, discovered only when an incident makes the gap matter.
- A logging commitment that exists in the contract but was never tested; the export was never actually ingested, or does not contain what the contract promises.
- Periodic vendor review that checks uptime and support tickets but never looks at security logging commitments at all.
- A vendor audit feed that goes silent for an extended period with nobody monitoring it, the SaaS equivalent of a host that stopped forwarding.
How to adapt this checklist
- Set the system, vendor, and criticality tier from your system inventory.
- For a new vendor, run this at the proposal or contracting stage so gaps become negotiation points, not post-signature surprises.
- Point the escalation path to your real supplier-management and quality procedures.
- Re-run items 10 and 11 at every periodic review; they are the only items that test whether the contractual promise is actually being kept, not just written down.