What Auditors Actually Look for in Validation Documentation

An auditor reading a validation package is not reading every page. They are sampling five things in a predictable order: the approval chain, traceability from requirements to evidence, execution integrity, deviation handling, and change-control impact since qualification. If any of those threads breaks, the rest of the package gets a much closer reading.

Most teams assume that if the protocol covers the right tests, they are fine. Auditors evaluate whether the documentation proves you had the process under control the entire time. There is a significant gap between "we did the work" and "we can prove we did the work correctly." That gap is where findings come from.

This article breaks down what auditors actually focus on when they review validation documentation, why those things matter, and how to keep your protocols from becoming a target.

They check the approval chain first

Before an auditor reads a single test result, they look at the approval page. They want to see that the protocol was written, reviewed, and approved by people with appropriate authority, and that those approvals happened before any testing started.

If your approval dates are after your test execution dates, you have a problem. If your approval page is missing signatures, you have a bigger problem. If the same person wrote, reviewed, and approved the protocol, expect questions about your separation of duties.

The approval chain tells the auditor whether your organization treats validation as a controlled activity or as paperwork that gets filled in after the fact. It sets the tone for everything that follows.

What they are specifically looking for:

• Author, reviewer, and approver are clearly identified with printed names and signatures
• Approval dates precede execution dates
• The reviewer and approver are not the same person who wrote the protocol
• Quality Assurance involvement in the approval chain matches site procedure (typically as a reviewer or approver per your QMS)
• Any revision history matches the current document version

They compare your acceptance criteria to your specifications

One of the fastest ways to get flagged is to have acceptance criteria that do not trace directly back to your equipment specifications. If your User Requirements Specification says the machine operates between 20 and 40 RPM, and your OQ protocol tests at 25 and 35 RPM, an auditor will ask why you did not test at the boundaries.

Auditors are trained to look for acceptance criteria that are vague, overly generous, or disconnected from the documented requirements. They compare what you tested against what you said the equipment was supposed to do. If those two things do not line up, it raises questions about whether your qualification actually proved anything.

Common flags:

• Acceptance criteria listed as "per manufacturer specifications" without stating the actual values
• Ranges that are wider than what the URS or FS specifies
• No reference to the source document for each criterion
• Pass/fail criteria that rely on subjective judgment rather than measurable values

If you are not sure how IQ, OQ, and PQ acceptance criteria differ, our breakdown of what goes in each protocol covers this in detail.

They look for gaps in your test execution records

Auditors pay close attention to whether every test step has a recorded result, who performed it, and when. A blank field in your execution record is not just an oversight. It is a documentation gap that can trigger a formal finding.

They also look at the sequence and timing of your test records. If you ran 47 test steps and every single one has an identical timestamp that the system cannot explain, they will question whether the tests were actually executed or whether someone filled in the paperwork at a desk after the fact. Real testing takes time, and the timestamps should reflect that, or the system behavior that produced identical timestamps (such as section-level commits or batch saves) should be documented.

What they scrutinize:

• Every test step has an actual recorded result, not just pass or fail
• The person who performed each test is identified
• Dates and times are consistent and realistic
• Any test that was not performed has a documented justification
• Raw data is attached or referenced, not just summarized
• Contemporaneous corrections are made per Good Documentation Practice (single line through the original entry, reason, date, and initials for paper records; documented audit-trail review for electronic records)

They verify your deviation handling

No validation runs perfectly the first time. Auditors know this. What concerns them is not that deviations occurred, but how your team handled them. Zero deviations are not inherently a problem (a low-complexity scope or a mature process can legitimately produce a clean run), but auditors may scrutinize whether exceptions were captured and handled when the package looks unusually clean.

When a test fails or produces an unexpected result, auditors expect to see a formal record of the event. That record needs to describe what happened, investigate the root cause, assess the impact on product quality, and document the corrective action taken. Simply re-running the test and recording a passing result without documenting the original failure is a serious red flag.

What auditors expect to find:

• A deviation report (or equivalent nonconformance record per site terminology) for every result outside acceptance criteria
• Root cause investigation with supporting evidence
• Impact assessment on the overall qualification
• Corrective actions with completion dates, with CAPA opened where the investigation identifies a systemic or risk-significant cause
• Re-test results linked back to the original deviation
• Final disposition approved per the site QMS

They examine your traceability

Traceability is the thread that connects your User Requirements Specification to your functional tests and back to your results. Auditors trace individual requirements through the entire qualification package to confirm that every requirement was tested, every test has a result, and every result has supporting data.

If your traceability matrix is an afterthought that was assembled the day before the audit, it will show. The references will not match. The test step numbers will be off. Requirements will be listed as "tested" without a corresponding protocol section.

A strong traceability matrix is one of the most effective defenses against audit findings. It shows the auditor, at a glance, that your validation package is complete and coherent.

What they check:

• Every URS requirement maps to at least one test
• Every test maps back to a specific requirement
• Test results are traceable to raw data or supporting evidence
• No orphan tests exist without a corresponding requirement
• No requirements exist without a corresponding test

A worked example of what a single traceable thread looks like end to end:

> URS-017 (chamber temperature uniformity within plus or minus 2 degrees Celsius across all mapped points) -> FS-04.2 (control loop tolerance, sensor placement) -> OQ-05 step 3 (24-hour empty-chamber mapping at 2, 5, and 8 degrees Celsius) -> Raw data file MAP-2024-017.csv -> Deviation DEV-22 (one sensor exceeded tolerance, root cause: sensor calibration drift, disposition: re-cal and re-test passed) -> Summary report Section 7.2 (release statement)

Every requirement in the URS should be able to produce a thread like that on demand. If you cannot, the traceability matrix is incomplete.

They assess your change control records

Equipment rarely stays in its validated state forever. Auditors look at whether changes made after initial qualification were properly controlled and whether revalidation was performed when required.

If your equipment received a software update six months ago and there is no impact assessment or revalidation record, the auditor will question whether the equipment is still in a validated state. The same applies to hardware modifications, relocated equipment, or changes to operating procedures that affect qualified parameters.

What they look for:

• Change control records for any modification after initial qualification
• Impact assessments that reference the original validation
• Revalidation protocols and results when changes affect qualified parameters
• Updated traceability matrices that reflect the current configuration
• Changes approved per site change-control procedure before implementation, with documented quality oversight

They review your summary report

The validation summary report is often the first document an auditor reads after the table of contents. It gives them a high-level view of the entire qualification: what was tested, what passed, what deviated, and whether the equipment was released for use.

A weak summary report forces the auditor to dig through every page of the protocol to understand the outcome. A strong summary report tells the complete story and points the auditor to exactly where they can find supporting evidence.

What they expect in a summary report:

• Clear statement of the qualification objective
• List of all tests performed with pass/fail status
• Summary of all deviations and their dispositions
• Reference to the final approved traceability matrix
• Conclusion statement with release recommendation
• Signatures matching the site approval procedure (typically the validation owner and a quality oversight signatory)

The pattern behind every finding

If you look at the common themes across all of these areas, they come down to three things: completeness, consistency, and traceability. Did you document everything? Does the documentation tell a consistent story? Can every claim be traced back to evidence?

Auditors are not trying to catch you making mistakes. They are trying to determine whether your validation process is robust enough that you would catch your own mistakes. Your documentation either demonstrates that capability or it does not.

The difference between a validation package that passes cleanly and one that generates findings is rarely about the testing itself. It is about the discipline of the documentation. The tests might be identical. The documentation is what separates a clean audit from a corrective action.

---

Valiqa is an AI-powered validation lifecycle platform for regulated manufacturing. Learn more at valiqa.io

If you are evaluating validation software with auditor review in mind, our guide on choosing validation software for equipment qualification walks through the seven dimensions that show up in audit findings.

When auditors find a change that was not properly evaluated for its impact on the validated state, that becomes a finding. Our post on revalidation: when do you actually need to redo IQ/OQ/PQ walks through the documentation that makes a revalidation scope decision defensible.

If documentation quality has surfaced in your last audit, the self-scoring evaluation can help you scope whether tooling would move the needle for your team.

Auditors often request the Validation Master Plan early in an inspection to orient on the program. We covered what a defensible VMP contains in What is a Validation Master Plan and who owns it.