Validation Test Evidence: What Screenshots Are Actually For Under a Risk-Based Approach

Why Screenshots Became the Default

Ask a validation lead why their test scripts call for a screenshot at every step and the answer is usually some version of “because the auditor will ask.” That answer is worth taking seriously, because it explains both why the habit formed and why it has outlived its purpose.

Evidence Was Designed for a Reviewer Who Was Not There

Test evidence has one job: to let someone who did not watch the test decide whether it passed. FDA’s General Principles of Software Validation, the long-standing FDA device guidance that many pharma validation teams also use as a reference, puts it plainly. Test procedures, test data and test results “should be documented in a manner permitting objective pass/fail decisions to be reached,” and they should be suitable for review and objective decision making after the test has run³. The same guidance says that for user site testing, documented evidence of all testing procedures, test input data and test results should be retained³.

Nothing in that language requires a picture of the screen. But when validation was executed on paper, a printed screen capture was one of the few ways to carry what the system displayed into a signed paper record. The tester ran the step, printed the screen, initialed and dated the printout, and attached it to the protocol. A quality reviewer weeks later could look at the printout and compare it to the expected result. For systems that kept few records of their own, this was a sensible way to create evidence that did not otherwise exist.

The Habit Outlived the Reason

Two things changed. First, the systems changed. Modern GxP applications keep detailed audit trails, event logs, configuration histories and exportable reports. The result of most test steps is already recorded, with a user ID and a timestamp, inside the system under test. Second, the test tools changed. Many teams now execute tests in electronic test management tools or automated test frameworks that record each step, the tester, the time and the outcome.

The screenshot requirement stayed anyway. In many companies it became a blanket rule in the validation procedure: every step, every time. The result is familiar to anyone who has reviewed a large validation package. Hundreds of images of login screens, menus and confirmation dialogs, each one annotated, each one checked by a reviewer, most of them proving nothing that the system’s own records did not already prove.

ISPE’s GAMP Good Practice Guide on enabling innovation describes the wider pattern. It notes that the Case for Quality program run by FDA’s device center identified a problem: when companies focus on compliance over quality, time and management attention go to meeting regulatory requirements instead of to better quality practice¹⁴. Blanket screenshot rules are a small, concrete example of that problem.

Why This Matters to Senior Leaders

Screenshot volume is not just a tester’s annoyance. It drives the length of test execution, the length of quality review, the time between build and release, and the size of the package you need to defend during an inspection. When a SaaS vendor releases updates several times a year, every one of those releases runs through the same evidence rules. A procedure that demands a screenshot per step turns each release into a large manual effort, and that effort is one reason teams delay updates that would otherwise improve their systems.

The opposite mistake is also real. Teams that hear “FDA says fewer screenshots” and remove them everywhere can end up with test records that a reviewer cannot use, because the system record they were counting on was never checked, was not retained, or does not show what the requirement was about. The goal is not fewer screenshots. The goal is evidence that proves the requirement was met, in the form that proves it best.

What the February 2026 CSA Guidance Says About Evidence

FDA’s guidance “Computer Software Assurance for Production and Quality Management System Software” was issued on February 3, 2026. It supersedes the version issued on September 24, 2025, which itself followed a draft first announced in September 2022^1,2. The 2026 title now refers to the quality management system, in line with the device Quality Management System Regulation that took effect on February 2, 2026¹.

Scope: A Device Guidance That Pharma Reads Closely

Be precise about scope before applying it. The guidance was prepared by CDRH and CBER in consultation with CDER, the Office of Combination Products and the Office of Inspections and Investigations¹. It is written for software used as part of medical device production or the device quality management system. It is not a drug CGMP guidance, and like all FDA guidance it is nonbinding. For pharma and biotech companies, it is best read as a clear statement of how FDA thinks about proportionate evidence for production and quality software, not as a rule that replaces your drug CGMP obligations.

Its footnotes also point to industry practice that pharma already uses. For more on current software testing methods and validation approaches, the guidance refers readers to GAMP 5, Second Edition, among other standards and industry guidance¹. That matters, because GAMP is the framework most pharma validation programs are built on.

What the Record Should Contain

Section V.A(6), “Establishing the Appropriate Record,” lists what FDA generally recommends the assurance record include¹:

• the intended use of the software feature, function or operation
• the result of the risk-based analysis
• documentation of the assurance activities, including a description of the testing, issues found (deviations, defects or failures), and a conclusion statement declaring the software acceptable for its intended use
• a record of who performed the testing or assessment and the date
• review and approval when appropriate

Notice what is on the list and what is not. The record has to show what was tested, why that level of testing fits the risk, what went wrong, what the conclusion is, and who did it when. There is no line item for a picture of each step.

The second sentence is the one most often summarized as “FDA says no screenshots.” That summary is wrong. The guidance does not prohibit screenshots. It recommends a preference order: use the data the software already generates and keeps, rather than paper, screenshots, or copies of results the software already holds. The target is duplication. A screenshot of a result that is already in the audit trail is a second copy of the same fact, and a less reliable one.

The Conditions FDA Attaches to Digital Records

The very next sentence adds a condition that teams often skip. When using digital records, FDA recommends that manufacturers consider the intended use and the need for accuracy, reliability, integrity, availability and authenticity of the record as part of the risk-based approach¹. In plain terms: you can rely on the system log instead of a screenshot only if you have reason to trust the log and you can still produce it when someone asks.

The guidance also says the record should keep enough detail of the assurance activity to serve as a baseline for improvements or as a reference point if issues occur¹. That is a useful test for any evidence decision. If a defect shows up in production six months from now, will your validation record let an investigator see what was tested, how, and what the system did? If the answer depends on a log that has since been purged, the evidence has failed.

Evidence Scales With the Type of Testing

Table 1 of the guidance gives examples of the record for different assurance activities¹. The pattern is clear even in summary form.

Even for the most detailed category, what FDA lists is a “result record obtained for each test case,” not a capture of each step. The level of evidence rises with risk, but it rises in the form of more structure and more detail in the result record, not in the number of images.

The guidance also leaves room to automate. For software features that are not high process risk, it says a manufacturer may find it more effective and efficient to develop scripted testing and automate it¹. Automated tests produce their own run logs, which brings the evidence question back to the same point: trust and retain the machine record, and you do not need a picture of it.

The European View: Screen Dumps Where Relevant

Pharma and biotech companies that supply the EU market work under EU GMP, and the European text reads differently. It is worth looking at both the version in force today and the draft revision.

Annex 11 as It Stands Today

As of this writing, the EudraLex Volume 4 page still lists Annex 11, Computerised Systems, as the January 2011 revision⁶. On testing, that version says evidence of appropriate test methods and test scenarios should be demonstrated, and that system parameter limits, data limits and error handling should be considered. It also says automated testing tools and test environments should have documented assessments for their adequacy⁴. It does not mention screenshots at all.

That last point about automated tools is easy to overlook and directly relevant here. If you plan to rely on an automated test tool’s execution log in place of screenshots, the 2011 Annex 11 already expects you to have assessed that tool as adequate for the job.

The Draft Revision Names Screen Dumps

The draft revision of Annex 11 was published for consultation on July 7, 2025, together with a revised Chapter 4 on documentation and a new Annex 22 on artificial intelligence. Comments closed on October 7, 2025⁷. The draft grew from 5 pages to 19⁷, and its section on qualification and validation is far more specific than the 2011 text.

Clause 9.4 reads: “System qualification and validation should provide evidence in the form of executed test scripts, and where relevant, screen dumps, that requirements, and where applicable, derived functional specifications, are met by the system.”⁵ Clause 9.7 adds that test scripts should be described in sufficient detail to ensure a correct and repeatable conduct of test steps and prerequisites⁵. Clause 9.6 lists where testing focus should increase, including access privileges, release of products and results, calculations, audit trails, error handling, alarms and warnings, boundary and negative testing, reports and interfaces, and restore from backup⁵.

Reading “Where Relevant” Correctly

Two phrases in clause 9.4 matter most. “Executed test scripts” is the primary evidence. “Where relevant, screen dumps” is a qualifier, not a blanket rule. The draft does not say every step needs a screen capture. It says screen dumps belong where they are relevant to showing that a requirement is met.

Commentators have read the clause in that direction. Writing in Technology Networks, Mahboubeh Lotfinia and Bob McDowall argued that the new 9.4 should follow GAMP 5 Second Edition by distinguishing primary from secondary test evidence: use the audit trail to document testing, and use screen dumps only when necessary, for example to trace actions back to requirements⁹. The same authors noted that the draft’s demand for detailed, repeatable test scripts conflicts with the unscripted testing that the FDA CSA guidance allows, and they described it as a rejection of CSA-style unscripted testing⁹. Whether the final text keeps that position is an open question.

The Draft Chapter 4 Adds a Data Integrity Angle

The draft revised Chapter 4 on documentation matters to this discussion too, because it describes what a complete electronic record is. Its principles state that a complete record of data generated electronically includes relevant metadata, and that information originally captured in a dynamic state should remain available in that state⁸. It defines a true copy as an exact copy of original documentation that preserves the same content, meaning and attributes of the original⁸.

A screenshot of an electronic record does not meet that definition. It keeps the displayed content but loses the metadata and the dynamic nature of the record. That does not make screenshots invalid as test evidence, since test evidence is a record of what the tester observed, not a copy of the GxP record itself. But it is a reminder that the system’s own record is the stronger form of proof whenever it exists.

One Approach That Satisfies Both

You do not need two validation procedures, one for FDA and one for the EU. A single rule works for both: executed test scripts or test records are the primary evidence; system-generated records are the preferred proof of results; screenshots are captured where they are relevant to the requirement or where no reliable system record exists. That reads as “where relevant” to an EU inspector and as “least burdensome” to FDA.

Sambit Mohapatra, writing on ISPE’s iSpeak blog in January 2026, compared the final CSA guidance with the draft Annex 11 and concluded that both documents give weight to the same ideas, including digital tool-based documentation, risk-based assurance, right-sized test scripting and automated, pragmatic test execution¹². He noted that the draft Annex 11 encourages the use of effective tools to capture and hold requirements and support traceability^12,5. The two regulators differ on how much scripting to require, but they are close on the idea that evidence should come from well-controlled records rather than large sets of manual captures.

What a Screenshot Can and Cannot Prove

Before deciding when to take screenshots, it helps to be clear about what one is. A screenshot is an image of what the display showed at one moment, on one workstation, to one user. That is useful for some questions and useless for others.

The Weaknesses Reviewers Tend to Miss

A screenshot is not tamper-evident. An image file can be edited without leaving a trace in the file itself. Attached to a paper protocol and initialed, it was reasonably protected. Dropped into a shared folder or pasted into a document, it is not. A system audit trail that is enabled and locked, as the draft Annex 11 expects⁵, is much harder to alter without a trace.

A screenshot rarely proves which environment it came from. Test evidence is only useful if it came from the validated configuration and the right version. Many screenshots show a page with no environment banner, no version string and no URL. A system log or a test tool record tied to a specific build and environment answers that question on its own.

A screenshot shows the front end, not the back end. Many important requirements are about what the system does, not what it displays: a calculation stored with the right precision, a status change written to the audit trail, a record locked after approval. A screenshot of the confirmation message proves the message appeared. It does not prove the underlying action happened.

A screenshot duplicates work when the result is already recorded. If the system logs the login, the role check, the status change and the signature, a screenshot of each one creates a second record that someone must capture, name, attach, and review. That is the duplication FDA’s 2026 text names directly¹.

What GAMP 5 Second Edition Says, as Quoted by ISPE Authors

The GAMP 5 Second Edition text is not freely available, but ISPE’s own journal has quoted the relevant lines. In a March 2024 Pharmaceutical Engineering article, Sambit Mohapatra wrote that legacy testing has focused heavily on print screen attachments as the basis for objective evidence, and quoted GAMP 5 Second Edition as saying that “prolific screen shots do not add value and are unnecessary” and that “test evidence is only collected for proving steps that are not inherently covered by evidence from another step”¹¹.

The same article describes GAMP’s more pragmatic approach to recording results: a simple “pass” can be recorded when the system response matches the expected result, with detailed statements reserved for failed steps¹¹. It also argues against treating “contemporaneous” as meaning the observed result must be written in the same minute the screenshot was taken, and suggests a tester who missed a capture could add it later the same day without re-running the whole test¹¹. That last point is the author’s recommendation, not a regulatory statement, and your procedure should say how late captures are handled rather than leaving it to individual judgment.

When a Screenshot Earns Its Place

The useful question is not “screenshot or no screenshot.” It is “what is the best available evidence that this requirement was met?” For most steps, the answer is the system’s own record or the test tool’s record. For some, it is a screenshot. The decision table below is a practical starting point.

Risk Sets the Depth, Not the Default

Risk decides how much evidence you need. It does not decide that the evidence must be a picture. For a high process risk function, the CSA guidance points toward more rigorous testing, such as scripted testing or a mix of scripted and unscripted methods¹. More rigor means more detailed expected results, more precise acceptance criteria and a more complete result record. For many high-risk steps, the most rigorous evidence available is an export of the stored data compared to an independently calculated expected value. A screenshot of the same number on screen would be weaker.

For a function that is not high process risk, the guidance points toward unscripted approaches such as scenario testing, error guessing or exploratory testing, recorded as a summary of what was tested, issues found and a conclusion¹. Requiring a screenshot per step for exploratory testing would defeat its purpose, since the tester is not following fixed steps in the first place.

The Requirement Tells You What to Capture

A practical habit: read the requirement and ask what noun it is about. If the requirement is about a screen, a message, a printout or a label, the evidence should show that screen, message, printout or label. If the requirement is about a record, a value, a status or a permission, the evidence should come from where that record, value, status or permission is stored or enforced.

Failures Deserve More Evidence, Not Less

One area where teams should capture more, not fewer, images is when something goes wrong. FDA’s recommended record includes the issues found during testing and how they were resolved¹. A screenshot of the error state at the moment of failure, alongside the relevant log extract, helps whoever investigates the defect and helps the reviewer judge whether the fix addressed the right problem. The GAMP approach quoted above reflects the same logic: record a simple pass when the result matches, and write more detail when it does not¹¹.

Better Sources of Objective Evidence

If screenshots are the fallback, what is the first choice? The CSA guidance names system logs, audit trails and other data generated and maintained by the software¹. In practice, a GxP validation team usually has these options.

Audit Trail Extracts

For any step that creates, changes or deletes GxP data, the audit trail should already record who did it, when, the old and new values and, where required, the reason. An extract of the relevant audit trail entries, filtered to the test period and the test user, is stronger evidence than a screenshot of the confirmation message. There is a condition: the audit trail itself has to have been verified. If audit trail functionality has not been tested in the same validation effort, you cannot use it as proof for other tests. Test the audit trail first, then rely on it.

System and Event Logs

Many systems keep event logs for logins, failed access attempts, interface transfers, job runs and errors. These are often the only record of things the user never sees, such as a background interface that moved a result from an instrument to a LIMS. For interface and integration testing, logs and message records usually beat any screen capture.

Reports and Data Exports

For calculations, stored values and data transfers, an export or controlled report from the system gives the stored result, not just the displayed one. Compare it to an expected value calculated independently, and record both. This is also the natural evidence for the calculation and reporting functions that draft Annex 11 clause 9.6 singles out for increased focus⁵.

Test Management and Automation Tool Records

Electronic test management tools record each executed step, the tester, the timestamp and the pass or fail result. Automated test frameworks record the build, environment, input data and outcome of every run. The CSA guidance describes digital retention of results, automated traceability, automated testing and electronic capture of work performed as ways to reduce manual or paper-based documentation¹. The 2011 Annex 11 adds the condition: automated testing tools and test environments should have documented assessments for their adequacy⁴. Assess the tool once, then rely on its records across releases.

Configuration Exports

Where a system allows its configuration to be exported or reported, that export is better evidence of the validated configuration than a series of screenshots of settings pages. It is also easier to compare at the next release to see what changed.

Vendor Evidence

The CSA guidance lets manufacturers use a software vendor’s development practices, validation work and electronic information as a starting point, and says that for some lower-risk functions this may be all the assurance needed¹. The draft Annex 11 takes a similar position in clause 9.9: validation documentation may come from a vendor or service provider, but the regulated user remains fully accountable and should review it and consider whether it covers the implemented version⁵. ISPE workshop authors add a caution: vendor testing that relies on undocumented unscripted testing, or uses unscripted testing as a blanket replacement for scripted testing, would not be suitable for the regulated company to rely on¹³.

A Record Chosen as Evidence Becomes a Record to Protect

The CSA guidance includes a useful pair of examples on Part 11. Documentation showing that a system correctly automates checking materials before use would generally be needed as evidence of a validated state, so Part 11 would generally apply to it in electronic form. By contrast, routine activity logs that a commercial product saves on startup, and that are not needed as evidence, would not fall under Part 11¹. The examples are written for the device regulation, but the logic carries over to pharma practice: once you decide a log is your validation evidence, you have made it a record, and it needs the same retention and protection as any other validation record. A log that rotates out after 90 days, for example, is no help at an inspection two years later. Settle retention before you settle evidence.

Writing the Evidence Rules Into Your Procedures

None of this helps if each tester and reviewer applies their own judgment. The point of changing the evidence rules is to make them consistent, explainable and defensible. That means writing them down in the validation procedure and the validation plan, and training testers and reviewers on them.

Start With an Evidence Matrix in the Validation Plan

For each system, the validation plan should state the default evidence source for each type of test: audit trail extracts for data changes, logs for interfaces, exports for calculations, test tool records for executed steps, screenshots for visual requirements and failures. The plan should name which system functions (audit trail, logging, reporting) must be verified first so that later tests can rely on them. This turns a per-step debate into a per-system decision made once, with quality approval.

Test Script Conventions

Three conventions make the biggest difference in daily work. First, expected results should be specific enough that a pass or fail decision can be made objectively, which is the long-standing test from FDA’s General Principles of Software Validation³. Second, a matching result can be recorded as a pass without a narrative, with detail reserved for failures, which follows the GAMP approach described by ISPE authors¹¹. Third, a step that requires a screenshot should say so and say why, so capturing an image is a deliberate choice rather than a reflex.

Rules for the Screenshots You Keep

When a screenshot is the right evidence, make it good evidence. Capture the full window, not a crop. Make sure the user, the environment and the date and time are visible where the system shows them. Name the file to match the test case and step. Store it in the controlled test record, not a shared drive. Do not annotate the image itself in a way that hides content; add notes in the test record instead. And say in the procedure how a missed or late capture is handled, so a tester who forgets one does not have to guess.

Handling the Transition From the Old Rules

Most companies will run both approaches for a while: older systems validated under a screenshot-heavy procedure, newer projects under the revised one. ISPE workshop authors recommend recording the justification for the change in approach and showing that there is no decrease in control during the transition, and they note that an inspection may review projects done either way¹³. A short rationale document, approved by quality, that explains the evidence rules and the regulatory basis for them is worth writing once and attaching to the procedure.

Preparing for the Inspection Question

An inspector who opens a package with few screenshots will ask how you know each step passed. The answer should be quick and consistent: here is the evidence matrix, here is the verification of the audit trail and logs, here is the extract for this test case, here is the retention setting. If a reviewer can follow the path from requirement to test step to system record without help, the evidence is sufficient. If they cannot, adding screenshots will not fix it. Clearer test records and better links to the system data will.

For EU-facing systems, keep an eye on the final Annex 11 text. If the final version keeps “where relevant, screen dumps,” the evidence matrix already answers it. If it becomes stricter, you will know exactly which test types to change, because the rules are written down per type rather than scattered through individual scripts.

Measure What Changes

Changing evidence rules should reduce execution and review effort without reducing defect detection. Track a few things before and after the change: tester hours per test case, review hours per package, the number of review comments about evidence, and defects found in production after release. ISPE’s third edition GAMP Good Practice Guide on testing GxP systems, published in July 2026, frames this shift directly, describing a move from testing primarily to provide audit or inspection evidence toward testing as a means of improving system and product quality, and offering guidance on right-sizing test planning, test coverage and test evidence¹⁰. If your numbers show testers spending less time on captures and more time finding defects before go-live, the change is working.

Conclusion

Screenshots are not good or bad evidence. They are one kind of evidence with a narrow, useful purpose: showing what a person saw when the requirement is about what a person sees, or when the system keeps no better record. FDA’s February 2026 CSA guidance asks companies to prefer the records their software already keeps and to stop duplicating them. The draft revision of Annex 11 still expects screen dumps where relevant. A single evidence rule that treats executed test records as primary, trusted system records as the preferred proof, and screenshots as the targeted exception answers both, and it holds up better at inspection than a binder of images no one can trace to a stored result.

Sakara Digital works with pharma and biotech organizations to build validation approaches that are proportionate to risk and easy to defend, including evidence rules for SaaS releases and automated testing. If you are rethinking how your team captures test evidence and want an independent view on where to start, we are happy to have that conversation.

For Further Reading