Test Evidence for a 21 CFR Part 11 Audit

Part 11 doesn't ask whether you tested

Before anything else, one caveat this whole piece rests on: what follows describes how teams commonly assemble test evidence for a Part 11 context. It is not legal or regulatory advice, and it is not a substitute for a qualified quality or regulatory professional who knows your specific situation. Treat it as a mental model, then confirm the specifics with someone qualified to sign off on them.

With that said. An FDA 21 CFR Part 11 audit does not ask "did you test this?" It assumes you did. What it asks is that you show it — with records that are attributable to a named person, time-stamped, and signed, proving what was tested, when, and that someone accepted the result.

That's a different thing from testing well, and it's where teams get caught. Plenty of teams test thoroughly and still can't produce the evidence, because their test records were built as a working tool to be cleared out each sprint, not as a durable, signed record. The gap shows up in the week the auditor arrives.

What Part 11 actually cares about

At its core, 21 CFR Part 11 is about electronic records and electronic signatures — the conditions under which the FDA will treat them as trustworthy and equivalent to paper and ink. For test evidence, that translates into a few plain expectations about the records themselves.

The records should be attributable (you can tell who did what), legible (readable and permanent), contemporaneous (recorded when the work happened, not backfilled), original (the real record, not a retyped copy), and accurate. Those five are often remembered as ALCOA, and they're a useful lens even outside a regulated context.

On top of the records sit electronic signatures and approvals: a named person accepting something, tied to what they accepted and when. A sign-off that can't say who approved which version, on what date, isn't carrying the weight Part 11 expects. The record has to hold the approval as data, not as a vibe.

The chain it follows

An auditor working test evidence follows the same chain any audit does, with the signatures and dates made load-bearing.

It runs requirement → case → run → defect. Show a requirement. Show the documented case that verifies it, with a record of who approved that case and when. Show the run that executed the case against what shipped — the build, the date, the result. And show the defects it found and how each was resolved or accepted. At every step where a human made a decision, the record should carry that person's approval and its timestamp.

The link teams most often can't produce is the signed, dated approval on the case itself. They have the cases and they have the runs, but not a durable record of who accepted this case, in this state, on this date. A "last modified by" field doesn't answer it — it's overwritten by the next edit. What Part 11 wants is history that survives.

What's in the evidence pack

Made concrete, a test evidence pack for this context is a set of connected records, not a single document:

• The scope — the requirements the release was meant to satisfy.
• The traceability — which case covers which requirement, so coverage is shown, not asserted.
• The run records — which cases ran, when, on which build, and the result.
• The defects — what was found, its severity, and how it was resolved or accepted.
• The approvals — who signed off on the cases and the release, on what dates, against what.

Assembled, those answer the auditor's real question: prove you tested what was required, and show that named people owned the decisions along the way.

Why reconstructing afterward fails here

When the evidence doesn't already exist, teams try to build it after the request lands. In a Part 11 context this fails twice over.

It fails on cost — reconstructing a signed, dated history from tickets, emails, and memory is slow, painful work that pulls your best people off delivery for weeks. And it fails on credibility, which matters more here than almost anywhere.

A record assembled after the fact cannot honestly be contemporaneous, and contemporaneousness is one of the things the record is supposed to demonstrate. An approval dated to the week of the audit, for work done six months earlier, tells its own story.

The conclusion is the one this cluster keeps arriving at: the evidence has to be a by-product of doing the work, captured as it happens, not a project you start when someone asks for it.

This is common practice, not compliance advice

It bears repeating plainly, because the stakes are real. Everything here is a description of how teams commonly think about assembling test evidence. It is not legal advice, not regulatory advice, and not a determination of what your obligations are.

What an auditor requires depends on your specific system, its intended use, and your organisation's own procedures and interpretation of the regulation. Use this as a working picture of the shape of the evidence, and confirm every specific with a qualified quality or regulatory professional. The goal here is to help you keep records that make an audit less painful — not to tell you what compliance requires.

Where a record helps

The honest role for a tool here is upstream of all of it: keeping the records in the right shape as you work, so the pack is something you assemble rather than write. A case record that maintains its requirement links, keeps runs as their own records, and logs who approved what and when is what makes the chain producible on demand — the same record a release rests on, with the approvals attached.

Here the boundary has to be exact. Tesbo keeps the case record and an approval log — who accepted each case, and when. It does not run, schedule, or execute your tests; that stays with your own tools.

And to be completely clear: Tesbo is not certified, validated, or compliant with 21 CFR Part 11 or any standard, and using it does not make you compliant. Good records are a foundation for evidence; they are not a substitute for an assessment by someone qualified to make one.