What a QA Audit of an SI Actually Is
There are two types of QA audit an SI might face on a pharma project. The first is the supplier audit — conducted by the client's QA team before project award, as part of the supplier assessment process. This is an assessment of your quality management system: your document control procedures, training records, version control practices, and prior pharma experience. The second is the project-level audit — conducted during or after the project, typically triggered by a regulatory inspection or an internal QA review. This is an assessment of whether your project documentation meets GMP standards.
Both types of audit follow similar logic: the auditor is looking for evidence that your work is controlled, traceable, and honest. They are not trying to find failures to report — they are trying to determine whether, in the event of a product quality issue, they could reconstruct exactly what was built, when, by whom, and whether it was tested and approved. If the documentation supports that reconstruction, the audit goes well. If it does not, findings are raised regardless of how well the system actually works.
An experienced QA auditor approaches an SI's documentation package with one central question: if something went wrong with a batch that this system produced data for, could I trace from the batch record back through the SCADA history, through the audit trail, through the calibration records, to confirm that the measurement was valid? Every document in the validation package either supports or undermines that reconstruction. The audit is testing the reconstruction, not the engineering.
What Auditors Look At First
Experienced QA auditors do not start with the detailed test cases. They start with the document approval dates and the traceability structure, because these tell them whether the project was managed correctly before they have read a single page of content. There are five documents that auditors typically pull first on an SI project audit.
The Approval Date Trap
The single most common finding raised against SIs on project audits is document approval sequence. The Validation Plan must be approved before the URS is written. The URS must be approved before the FDS is written. The FAT protocol must be approved before the FAT is executed. The IQ protocol must be approved before IQ begins. If the approval dates on these documents do not support this sequence, the project did not follow GMP lifecycle methodology regardless of how good the documents are.
An auditor who picks up the VP and sees it was approved three weeks after the FAT protocol — meaning the scope, GAMP category, and acceptance criteria were formally decided after the testing strategy was already written — has a finding. This is not a minor administrative gap. It calls into question whether the validation was genuinely planned or retrospectively documented to look planned.
The mitigation is straightforward: write and approve documents in sequence. If commercial pressure pushes engineering to start before the VP is approved — which happens — the VP approval must be backdated to before engineering starts if the actual approval occurred before engineering started, or a change control must be raised if the sequence was genuinely violated with documented justification. What cannot happen is presenting documents with approval dates that contradict the actual project timeline.
How Auditors Use the Deviation Ledger
The Master Deviation Ledger is the document that most reveals the character of a project. A project with zero deviations is suspicious — it suggests either that testing was not rigorous, or that deviations were resolved informally without being recorded. A project with many well-documented deviations, all with clear root causes and closed corrective actions, tells an auditor that the team was rigorous, problems were found and managed, and the system that was eventually validated was genuinely tested.
What auditors look for in the MDL specifically is the root cause quality and the corrective action credibility. A deviation whose root cause is "human error" with no further analysis is a weak record. The same deviation with a root cause of "test case step 3.2 did not specify the required pre-condition for the alarm to be in cleared state — procedure gap in protocol authoring" and a corrective action of "protocol section updated, step re-executed with clear pre-condition, PASS confirmed" is a strong record. It shows a team that understood what went wrong and fixed it properly.
Auditors also check whether Category A deviations were genuinely closed before phase gates were passed. If the IQ report is dated after all Category A IQ deviations are shown as closed in the MDL — good. If the OQ report shows an approval date that precedes the MDL closure date for a Category A OQ deviation — that is a phase gate violation, and it is a significant finding.
The Traceability Matrix as Audit Evidence
The Traceability Matrix is the document that makes or breaks the completeness argument. It shows, in one place, that every URS requirement has a design reference, a test case, and a test result. An auditor reviewing a TM that is 95% complete with 5% of URS requirements showing no test case will raise a finding on those gaps. An auditor reviewing a TM that shows every requirement as PASS — but where the test case references don't match the executed protocol — will raise a more serious finding about document consistency.
The TM must be maintained throughout the project, not assembled retrospectively. An SI who populates the TM at the end of the project, working backwards from the executed test cases, risks introducing inconsistencies between the requirement IDs in the URS, the test case IDs in the OQ, and the TM cross-references. These inconsistencies are visible to auditors and are treated as evidence of retrospective documentation.
Responding to Audit Findings Professionally
When a QA auditor raises a finding, the correct response is to understand it clearly, confirm whether you agree it is accurate, and — if it is — acknowledge it without defensiveness. The instinct to argue against findings, explain away the gap, or suggest the auditor is misinterpreting the regulation is usually counterproductive. Auditors note how SIs respond to findings as an indicator of the organisation's quality culture. An SI who responds to a calibration certificate gap with "we can get that document for you" performs better than one who argues about whether the certificate was technically required.
Findings that you believe are inaccurate — where the auditor has misapplied the regulation or misread the document — should be challenged professionally, with evidence. Bring the relevant document to the audit, show the auditor the specific section that addresses their concern, and ask if that resolves the finding. Most auditors will close a finding if the evidence clearly addresses it. What auditors will not accept is a verbal assurance that a document exists but cannot be produced during the audit.
When a genuine finding is raised, the CAPA (Corrective and Preventive Action) is the appropriate response — not a verbal commitment to fix it. A CAPA describes what was found, what root cause led to it, what corrective action will be taken (with a completion date), and what preventive action will prevent recurrence. Findings without formal CAPAs stay open. An auditor who returns six months later to verify closure and finds no CAPA record will re-raise the finding with a higher severity.
Preparing Before the Audit Without Cosmetic Fixes
Pre-audit preparation is legitimate and expected. Organising documents, verifying that all protocols are approved, confirming calibration certificates are on file, and checking the MDL for any inadvertently unclosed deviations are all appropriate preparation activities. What is not appropriate — and what auditors are trained to detect — is creating, backdating, or modifying documents in preparation for the audit.
Legitimate pre-audit activities include: conducting an internal documentation review against the same checklist an auditor would use; confirming that the document register matches the actual document set; verifying that all signatures are present and dated; and confirming that the traceability matrix is complete and consistent with the executed protocols. Any genuine gaps identified during pre-audit review should be addressed via formal change control, not silently corrected.
The most effective long-term audit preparation is running the project correctly from the start — approved documents in sequence, complete deviation records, a maintained traceability matrix, and calibration certificates in place before IQ. Projects managed to these standards survive audits because there is nothing to hide. Projects managed to lower standards and then cleaned up before audits are fragile — they survive specific audits but accumulate risk over the system's operational lifetime.
The VSR template (VSR-SYS-001) includes a systematic review of all validation phases, open deviations status, and lessons learned — structured as the document an auditor expects to see as validation closure evidence. The Master Deviation Ledger (MDLSYS001) provides the sequential deviation record with root cause, corrective action, and closure date fields. The Traceability Matrix (TMSYS001) provides the URS-to-test-case cross-reference that auditors verify for completeness. These three documents, well-maintained, are the audit package that demonstrates a controlled project — not a retrospectively assembled one.