FAT/SAT Punch List
& Open-Item Log FAQ

A punch list item is a minor, non-GxP-critical issue identified during FAT or SAT that doesn't affect equipment function or the validity of test results and can be tracked to closure without invoking the formal deviation process; a full deviation is raised when an issue affects a GxP-critical function, safety, or the accuracy of test results already obtained.

The classification decision itself should be documented, not just the item — an inspector reviewing a punch list wants to see the rationale for why something was treated as minor, not just the closed item.

A punch list should be a separate, structured, trackable document rather than informal notes embedded in the protocol, because open items typically need to be tracked and closed after the protocol itself has already been executed and signed — informal notes within the protocol are easy to lose track of once the protocol is filed.

Each punch list entry should capture enough detail that anyone reviewing it later — including an inspector — can understand exactly what the issue was, why it was classified as minor, who's responsible for resolving it, and what evidence confirms it was actually closed.

• Item description and where or how it was identified.
• Classification rationale: why it was treated as a punch list item, not a deviation.
• Assigned owner and target closure date.
• Current status: open, in progress, or closed.
• Closure evidence and the person who verified closure.

QA, in consultation with the engineering lead who identified the issue, should make the classification decision, since it directly affects how rigorously the issue needs to be tracked and resolved — leaving this decision solely to the person executing the test creates an incentive to under-classify issues to keep testing moving.

Yes — a punch list item can be added after protocol sign-off if a minor issue is identified later, such as during final walkdown or subsequent use, but it should be formally logged against the relevant protocol reference with the date it was identified, rather than silently added without a record of when and how it surfaced.

A simple, commonly used approach classifies items by whether they affect function, safety, or GxP compliance at all — true punch list items are typically split into categories such as cosmetic or documentation, minor functional with a workaround available, and minor functional requiring resolution before the next qualification phase, with priority and target dates set accordingly.

Yes — every punch list item should have a target closure date, even a generous one for low-priority cosmetic issues, because an item with no target date has no way to be flagged as overdue, and open-ended items are exactly what tend to get forgotten and surface as unresolved findings during an inspection years later.

No — equipment should not ship or go live with an open item affecting a GxP-critical function unresolved; if timeline pressure makes this seem necessary, the correct path is a documented, QA-approved risk acceptance with a firm resolution commitment, not simply carrying the item forward on the punch list as though it were minor.

The item should be immediately reclassified and escalated to a formal deviation, and the reclassification itself should be documented along with an assessment of whether the original misclassification affected any decisions made or data generated in the interim, such as an equipment release decision based on the item being considered minor.

The item should still be logged and tracked with a realistic target date tied to the external dependency, with the dependency itself documented, and the site should assess whether the equipment can be safely and compliantly used in the interim while that external item remains open, rather than leaving the item's status ambiguous.

The person responsible for the corrective action typically completes the fix, but closure should be independently verified and signed off by someone else — often QA or the original reviewer — with objective evidence, such as a photo, a retest result, or an updated document, rather than a simple statement that the item was resolved.

Yes — closing a punch list item should have its own documented sign-off and date, separate from the original protocol approval, since the protocol approval reflected the state of testing at that time, and closure evidence for items that remained open afterward needs its own independent record.

A risk assessment should confirm the open item doesn't affect the objectives of the next qualification phase before that phase proceeds — if the open item could influence IQ or OQ results, the next phase should be delayed until the item is closed, or the item's potential impact should be explicitly addressed within the next phase's own protocol.

Any punch list item still open at final commissioning or system release should be explicitly listed and risk-assessed within the release decision — commonly documented in the release certificate or validation summary report as a known open item with an accepted risk rationale and a firm closure commitment, rather than silently omitted from the release documentation.

Punch list items themselves can be tracked in a lighter-weight, project-specific log rather than the full deviation system, but any item that gets reclassified as GxP-critical should immediately move into the formal deviation and CAPA system — keeping the two systems clearly connected, rather than entirely separate and unaware of each other, prevents a reclassified item from falling through the gap between them.

Yes — the final FAT or SAT summary report should reference the punch list, including how many items remained open at the time of the report and their status, so the report gives a complete and honest picture of the equipment's state rather than implying everything was fully resolved.

The punch list or open-item log should be retained for at least as long as the FAT or SAT records it supports, since it's part of the evidence trail showing how the equipment reached its final qualified state — commonly the equipment's operational lifetime plus the site's standard retention period after decommissioning.

Inspectors typically check that items were classified appropriately and not used to quietly downgrade issues that should have been deviations, that every item has clear closure evidence and an independent sign-off, and that no item was left open indefinitely without a documented risk rationale.

A frequent finding is a punch list with several items marked "closed" but no supporting evidence attached — this reads as an assertion rather than demonstrated closure, and an inspector will typically ask to see the underlying proof.

An acceptable justification documents why the delay hasn't changed the original risk classification — for example, confirming the equipment has continued to operate without incident related to that item — combined with a revised, realistic closure date and periodic reconfirmation of the risk assessment, rather than an undated, indefinite carry-forward with no reassessment.

The most common mistake is letting the punch list become a place where borderline issues get quietly downgraded to avoid triggering the formal deviation process, combined with weak tracking that lets items go overdue without anyone noticing — both patterns turn the punch list from a legitimate minor-issue tracker into an undocumented risk that surfaces all at once during an inspection.