This is a ready-to-use log for a validation project that depends on a vendor or supplier for delivery, configuration, or supporting test evidence. It combines two things project teams often track separately and lose the connection between: the vendor’s delivery dates against your critical path, and every defect the vendor’s product has, from FAT through go-live. Replace every <<FILL: ...>> placeholder, update it at every vendor sync, and review it at every stage gate. A worked filled specimen follows the template.
Document control header
| Field | Entry |
|---|---|
| Document title | Vendor Deliverable and Defect Tracking Log |
| Document number | <<FILL: reference, e.g. VDL-VPP-031>> |
| Project | <<FILL: SYSTEM / PROJECT NAME>> |
| Vendor | <<FILL: VENDOR NAME>> |
| Quality / technical agreement reference | <<FILL: agreement document number>> |
| Log owner | <<FILL: role, e.g. Validation Lead>> |
1. Purpose
This log gives one place to see whether the vendor is on schedule and whether any open defect threatens the validated state or the go-live date. It exists because vendor slippage and vendor defects are usually tracked in separate emails and separate spreadsheets until a stage gate forces someone to reconcile them under time pressure, by which point the schedule impact is already unavoidable.
2. Vendor deliverable tracker
| Deliverable | Committed date (agreement / plan) | Actual delivery date | On critical path? | Incoming acceptance result | Status |
|---|---|---|---|---|---|
<<FILL: e.g. System build/FAT>> | <<FILL>> | <<FILL>> | Yes/No | Accepted / Rejected / Pending | <<FILL>> |
<<FILL: e.g. Vendor IQ/OQ documentation package>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: e.g. Configuration specification>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: e.g. Training materials>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: e.g. Go-live support plan>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
“Delivered” means the item passed incoming acceptance against your requirements, not that a file or a box arrived. A deliverable with a Pending acceptance result is not yet delivered for schedule purposes.
3. Vendor defect log
| Defect ID | Description | Found during | Severity | Target closure date | Confirmatory re-test result | Status | Blocks release? |
|---|---|---|---|---|---|---|---|
<<FILL: DEF-001>> | <<FILL>> | <<FILL: FAT / IQ / OQ / PQ>> | Critical / Major / Minor | <<FILL>> | <<FILL>> | Open / Closed | Yes/No |
<<FILL: DEF-002>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
4. Severity definitions and release rule
| Severity | Definition | Release rule |
|---|---|---|
| Critical | Prevents intended use, causes data loss or a data integrity failure, or blocks a GxP process | Must be closed and re-tested before release, no exceptions |
| Major | Significant functional gap or workaround required, no data integrity or safety impact | Must be closed before release unless QA formally risk-accepts a documented workaround |
| Minor | Cosmetic, low-impact, does not affect fitness for intended use | May be deferred to a post-go-live backlog item with an owner and a target date, documented in the validation summary report as a residual item |
State your own severity thresholds if they differ from this default; the point is that the rule is written down before the first defect is triaged, not decided defect by defect under deadline pressure.
5. How to use this log
- Update the deliverable tracker at every vendor sync (weekly is typical); do not wait for the stage gate meeting to learn a date slipped.
- Log every vendor-reported and internally found defect the same day it is identified, regardless of severity.
- Bring this log to every stage gate and review it explicitly against the readiness or release criteria for that gate.
- Tie the release decision to the severity rule in section 4; do not release with an open Critical defect under any circumstance, and document any accepted Major defect workaround in the validation summary report.
- Any vendor configuration change made during the project, whether it originated as a defect fix or a vendor-initiated update, is brought into your own change control immediately; it is not sufficient to note it only in this log.
6. References
EU GMP Annex 11 clause 3.2, on supplier and service provider competence and reliability as a factor in selection and ongoing management. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (ISPE), for supplier assessment and evidence reuse. ICH Q9, Quality Risk Management, for the risk basis of the severity and release rules.
Confirm the current version of each reference before issue.
7. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
The following shows the log completed midway through an example LIMS implementation, so you can see the level of detail expected. The vendor, system, and numbers are illustrative; replace them with your own.
Deliverable tracker (excerpt)
| Deliverable | Committed date | Actual date | Critical path? | Acceptance | Status |
|---|---|---|---|---|---|
| System build / FAT | 2026-06-15 | 2026-06-15 | Yes | Accepted | Closed |
| Vendor IQ/OQ documentation package | 2026-06-22 | 2026-07-06 | Yes | Accepted | Closed, 2 weeks late; absorbed by buffer, no date impact |
| Configuration specification | 2026-06-08 | 2026-06-08 | Yes | Accepted | Closed |
| Training materials | 2026-08-01 | Pending | No | Pending | Open, not yet blocking |
Defect log (excerpt)
| Defect ID | Description | Found during | Severity | Target closure | Re-test result | Status | Blocks release? |
|---|---|---|---|---|---|---|---|
| DEF-011 | Audit trail entry missing user ID on failed login attempts | OQ | Critical | 2026-07-20 | Pass, re-tested 2026-07-22 | Closed | No, resolved |
| DEF-014 | Report footer shows wrong site logo | PQ | Minor | Deferred | N/A | Open | No, deferred to backlog item BL-2026-004, owner IT, target 2026-09-30 |
In this example the vendor documentation slipped two weeks but the critical path absorbed it through pre-built buffer, so no date impact was recorded, and the Critical audit-trail defect was held, fixed, and confirmatory re-tested before OQ was declared passed, exactly the sequence a reviewer expects for a defect of that severity.
Common inspection findings this log prevents
- A defect fixed and deployed with no confirmatory re-test on record, so the fix was never actually verified.
- A Critical or Major defect open at release with no documented risk acceptance by QA.
- Vendor configuration changes made mid-project outside the sponsor’s own change control, discovered only when the validated configuration does not match what was tested.
- A vendor delivery slip that was never assessed for critical-path impact until the go-live date was already missed.
How to adapt this log
- Set the project, vendor, and agreement reference in the header.
- Replace the deliverable rows with your actual deliverable list from the quality or technical agreement.
- Set your own severity thresholds and release rule in section 4 if they differ from the default, and get QA to agree them before the first defect is triaged.
- Keep this log as the single source vendor status is reported from at every gate meeting; do not let a parallel, unofficial tracker develop.