This is a ready-to-use audit plan for a remote or postal (documentary) audit of a software supplier. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control. A worked filled specimen follows the template. This is general guidance to adapt, not regulatory advice. Verify each cited regulation against the current source before you rely on it.
1. Objective and scope
State why this audit is being run and what it covers.
3. Document request list (send 2 to 4 weeks ahead)
4. Live agenda (remote audit)
5. Sampling strategy (defeat the curated demo)
- Name the records yourself in the live session; do not accept the records offered.
- Trace at least one requirement end to end: requirement to design reference to code reference to test result.
- Ask to see a failed test and how it was investigated and closed.
- Sample across at least two recent releases, not one.
- For a hosted product, ask the supplier to show real access-control and audit-trail configuration, not slides.
6. Postal (documentary) audit specifics
When the audit is postal rather than live:
- Request objective evidence (redacted real records), not statements.
- Specify the exact version so the evidence matches what you will run.
- Require a signed attestation from the supplier’s quality function that the evidence is true and current.
- Score the package against a checklist and issue a formal report just as for a live audit.
- Escalate to a remote or on-site audit if the package raises a question you cannot resolve on paper.
7. Finding classification
8. Acceptance criteria for the audit
- The agenda areas were covered and the requested documents were received or their absence noted.
- At least one requirement was traced end to end and a failed test was examined.
- Records were sampled across two or more releases (live) or objective evidence with attestation was provided (postal).
- A developer and a tester were interviewed (live).
- Findings are classified and an audit report is issued with the reliance recommendation.
9. Report structure
Supplier and product; scope and method; team and dates; evidence examined (named records); findings by severity with CAPA and due dates; the reliance recommendation feeding the assessment report; conclusion; auditor signatures.
10. References
FDA Computer Software Assurance final guidance (current version issued 3 February 2026); EU GMP Annex 11 sections 3.1 and 3.2; PIC/S PI 011; GAMP 5 Second Edition (described in original wording). Confirm current versions before issue.
11. Approvals
Filled specimen
A remote audit plan executed for an example configured EBR platform (illustrative).
The audit found a real gap (missing regression evidence) precisely because the auditor named the records and sampled two releases instead of accepting the demo.
Common inspection findings this plan prevents
- An audit that reviewed the quality manual but never examined software engineering evidence.
- A “sales demo” audit where the supplier showed only polished records.
- A postal audit that was a glorified questionnaire with no objective evidence or attestation.
- Reliance on a point release whose regression testing was never confirmed.
How to adapt this plan
- Set the document number and link the governing SOP.
- Tune the document request list and agenda to the product type.
- Keep the sampling strategy intact; it is the part that finds real gaps.
- Feed the reliance recommendation into the supplier assessment report.
- Confirm the references against current published versions before issue.
