How to Write Testable URS Requirements for Isolators, BIBO, VHP Pass Boxes and EDS

Vague requirements rarely fail a URS review. They fail at the FAT table, when a protocol writer cannot locate an acceptance criterion and the qualification schedule absorbs the delay. A requirement that reads “the isolator shall maintain containment during glove changes” can pass a document review without anyone noticing it never specifies which test agent challenges the barrier, which instrument measures the result, or what record would prove the condition was met. The cost is not just revision time — it is repeated alignment meetings between the supplier, the QA team, and the site validation engineer, often after fabrication decisions have already been made. What resolves this is a drafting discipline applied before the URS leaves the project team: if a tester cannot write a test against a requirement without guessing, the requirement is not ready. The sections below give that discipline a specific form for isolators, BIBO systems, VHP pass boxes, and EDS, and close with a rule for deciding whether any individual requirement earns its place in the document.

Testable wording for isolator barrier functions

Isolator URS documents frequently carry barrier-function requirements that read well during internal review and collapse at FAT. The failure pattern is consistent: requirements written as design intent rather than verifiable outcome. “The system shall maintain negative pressure differential” looks complete until a protocol writer asks what the target value is, what the tolerance is, where the sensor is located, how frequently it samples, and what state the system enters when the reading falls outside range. None of that is implied by the sentence. All of it must be in the test script, which means the protocol writer either invents the answer or reopens the URS.

The practical fix is to treat every isolator barrier requirement as having four components before it is considered complete: an actor (which system or role), an input condition (what state or parameter triggers the requirement), a required output or system state, and a constraint (time limit, accuracy class, instrument type, or recording interval). A requirement covering a pressure exceedance response, for example, should name the differential threshold, the sensor standard, the visual and audible alarm behavior, and whether the system enters a locked state requiring a credentialed override. That level of specificity takes longer to draft. It also means the FAT protocol writer has nothing to invent.

A second common mistake is bundling related conditions into a single requirement using “and/or” constructions. If an item covers both alarm activation and door interlock behavior, those are two separately testable conditions — one may pass and the other may fail. Bundled items create partial compliance states that qualification protocols cannot cleanly score. Each atomic condition should carry its own number and its own acceptance criterion.

ASTM E2500-25 supports the underlying principle that requirements must be expressed in a form that allows objective verification — not as a prescriptive rule about sentence structure, but as a testing-framework expectation that shapes how specification language is assessed. Writing toward verifiability from the start keeps the URS aligned with that expectation without waiting for the verification phase to expose gaps.

BIBO requirements tied to maintenance evidence

Bag-in/bag-out housing requirements have a specific documentation vulnerability that isolator requirements do not always share: maintenance access. The functional performance of a Sistema BIBO depends on filter change procedures that must be executable under containment, and the URS is often where the evidence expectations for those procedures are either defined or silently omitted.

A URS requirement that reads “filter change shall be performed under safe conditions” does not tell a tester what safe means, what procedure is followed, what containment verification is performed during or after the change, or what record confirms the activity was completed correctly. At the IQ or OQ stage, the qualification engineer must reconstruct all of that. If the reconstruction does not match the supplier’s original design intent, the qualification stalls while the gap is negotiated. That negotiation is the direct downstream consequence of not naming the evidence type in the URS.

The more defensible approach is to tie each BIBO maintenance requirement to the specific record that will prove it was met. Not “a maintenance log shall be retained” but “filter exchange activities shall be documented using [Site Preventive Maintenance Form ID] or equivalent, capturing date, technician ID, bag lot number, pre- and post-exchange differential pressure readings, and containment verification test result.” That level of specificity is not over-engineering — it removes the tester’s guesswork entirely, which is the purpose of Annex 15’s qualification documentation expectations applied to this equipment type.

The risk-proportionality dimension matters here as well. Not every BIBO requirement carries equal containment consequence. Requirements governing filter change containment integrity sit at a different risk tier than requirements governing housing external surface finish. When a URS assigns risk levels to requirements, the expected evidence depth — calibration certificate, maintenance record, photographic documentation, witnessed test result — follows from the tier. A URS that lists requirements without risk context forces the protocol writer to judge that depth independently, and different engineers will judge it differently. That inconsistency is auditable.

For teams looking to structure commissioning evidence expectations further, the BIBO commissioning checklist covering FAT, SAT, IQ, and OQ identifies specific points that are frequently omitted at each stage.

VHP pass box cycle assumptions in the URS

The term “cycle assumption” is where VHP pass box URS documents tend to fail regulatory scrutiny. Teams document that a VHP decontamination cycle will be used for transfer without converting that assumption into the measurable parameters that the cycle must achieve. The consequence is that the validation team arrives at OQ with a system that runs a cycle and no URS basis for what the cycle was supposed to demonstrate.

Annex 15 and the FDA Process Validation guidance both support the principle that conditions — including worst-case conditions — must be defined before they can be verified. For a VHP pass box, that means the URS must state the target H₂O₂ concentration range, the exposure phase duration, the temperature tolerance at the measurement location, the pressure differential behavior during cycle phases, and the biological indicator or chemical indicator acceptance criteria for cycle qualification. These are not design specifications — they are performance conditions that the supplier’s cycle development work must satisfy, and the URS is where the buyer establishes what satisfactory means.

The risk of leaving cycle parameters undefined is not theoretical. A supplier may develop a cycle that achieves a 6-log reduction under their factory conditions without documenting the parameter envelope that produces that result. At SAT or PQ, when the site temperature or humidity falls outside the unarticulated assumptions, cycle performance varies and the qualification team has no URS basis for deciding whether the result is acceptable. Reprinting the cycle development data as a retrospective acceptance criterion is a recognized audit vulnerability.

Each parameter should be assigned a verification stage in the URS itself — not left to the protocol writer to determine. A temperature range verified at FAT under controlled factory conditions may need re-verification at SAT and again at OQ under site conditions. Stating that mapping in the URS resolves later scope disputes about which tests are required at each stage.

EDS records and alarm requirements buyers should define

Electronic data and alarm systems within containment equipment sit at the intersection of operational safety and regulatory data integrity, and the URS is where buyers must define the specific behaviors that will be tested — not the supplier. A supplier will configure the system to their defaults. If those defaults do not meet the site’s Part 11 or Annex 11 obligations, the gap is discovered during qualification when configuration changes are expensive and timeline-damaging.

The reason this falls on the buyer is scope clarity. Part 11 and Annex 11 govern the site’s electronic records obligations, not the supplier’s product design. A supplier who ships a system with a shared login, no e-signature prompt, and a deletable alarm log has delivered a functional product. Whether that product meets the buyer’s regulatory environment is a URS problem, not a supplier deficiency — unless the URS stated otherwise.

What that means in practice is that buyers must specify each regulated behavior explicitly before procurement. Audit trail content, unique user identification, e-signature trigger conditions, the displayed meaning of each signature, and record protection mechanisms are not implied by a requirement that says “the system shall comply with applicable regulations.” That sentence is not testable. The five behaviors it gestures at are each individually testable, and each requires its own acceptance criterion.

Part 11 and Annex 11 set the regulatory floor. The URS translates that floor into site-specific, testable language — naming specific fields, behaviors, and record types that a tester can verify against a pass/fail threshold rather than against a regulatory citation that each reviewer might interpret differently.

Consistency across multiple equipment packages

A project managing isolator, BIBO, VHP pass box, and EDS procurements simultaneously faces a documentation risk that does not appear in any single equipment URS: the four documents will diverge. Without an imposed structure, each URS develops its own numbering convention, its own shorthand for risk tiers, and its own vocabulary for evidence types. The divergence is invisible until a cross-package audit or a change control event requires linking a single site-level requirement across all four documents.

The practical consequence is that traceability gaps appear not because individual requirements are poorly written, but because the project never established a shared framework that all four documents could reference. A requirement numbered FR-14 in the isolator URS and SR-003 in the VHP pass box URS may address the same site-level pressure control need. Without a traceability matrix that explicitly links both to the parent requirement, a reviewer cannot confirm that the site need has been addressed across all relevant equipment — and the audit observation writes itself.

The remedy is structural and must be applied before the first equipment-specific URS reaches its first draft. A shared numbering convention — such as FR-## for functional requirements, SR-## for safety requirements — applied consistently across all packages allows requirements to be cross-referenced without reconstruction. A shared risk-tier vocabulary, even a simple three-level classification, ensures that evidence depth expectations are applied consistently. And a project-level traceability matrix that links each URS item to design or configuration objects, test scripts, results, and associated controls gives the qualification team a single auditable artifact rather than four parallel documents with no connecting tissue.

These are planning and project-management criteria, not regulatory obligations. But Annex 15 and ASTM E2500-25 both treat traceability as a condition for defensible qualification — and a cross-package gap in traceability is harder to close after FAT than before the URS is issued.

Evidence rule for keeping or rejecting a URS item

Every URS accumulates requirements that look reasonable during drafting and resist challenge during review. The operational problem is that teams rarely have a clear decision rule for removing or revising an item — so borderline requirements stay in the document and become borderline test scripts. The downstream consequence is a qualification record that includes tests no one can interpret as a clear pass or fail, and a supplier relationship where scope disputes trace back to language that was never resolved.

The operative rule is direct: if a tester cannot write a test against a requirement without guessing, the requirement is not ready to stay in the URS. This applies before the requirement leaves the drafting stage. It is a more useful discipline than any formal checklist because it forces the writer to resolve the ambiguity immediately, rather than allowing the requirement to shape a flawed test script that will need revision at FAT.

Two supporting metrics give that rule a quantitative form for project review cycles. Traceability completeness — the percentage of URS requirements linked to approved test scripts and passing evidence — should target 100%. Any requirement that cannot reach that state after qualification must be removed or revised; a permanently unlinked requirement signals that the acceptance criterion was never defined clearly enough to test. Ambiguity rate — reviewer-flagged items per 100 requirements — should stay below 2. That threshold is a practitioner judgment figure, not a regulatory benchmark, but it provides a useful signal: a document above the threshold needs a systematic revision pass before it is issued, not item-by-item negotiation during FAT.

What happens at the project level when items are kept despite failing these checks is predictable. Protocol writers make assumptions, FAT sessions produce conditional results, and the qualification engineer writes a rationale that attempts to retroactively define what the requirement meant. That rationale is defensible only if an auditor accepts the reconstruction — which is not guaranteed, and which is entirely avoidable if the requirement is rephrased before it leaves the URS.

The discipline that separates a qualification-ready URS from one that generates repeated protocol revisions is not complexity — it is specificity applied at the right level. For containment and decontamination equipment in particular, a requirement that cannot name the challenge method, the measuring instrument, the acceptance threshold, and the record type has not been finished. It has been deferred, and the deferral cost appears later, in qualification timelines that teams consistently underestimate when they treat vague “shall maintain” language as a reasonable drafting shortcut.

Before issuing any equipment-specific URS, confirm that every safety-critical and decontamination requirement has a named verification method, a specific output or record identifier, and a pass/fail threshold that a tester can execute without interpretation. That review takes time at the drafting stage. It reliably costs less than the alternative.

Preguntas frecuentes

Q: What should a team do immediately after the URS is finalized but before FAT begins?
A: Conduct a structured traceability review that maps every URS requirement to a specific test script, an assigned verification stage (FAT, SAT, IQ, OQ, or PQ), and an identified record type before the FAT protocol is issued. This step surfaces acceptance criteria gaps while configuration changes are still low-cost — once fabrication decisions are fixed, renegotiating scope at the FAT table absorbs significantly more time than resolving ambiguity at the document stage.

Q: Does this approach still work if the project only involves one equipment type rather than all four?
A: Yes, but the consistency disciplines — shared numbering conventions, risk-tier vocabulary, and traceability matrix structure — are worth applying even to a single-equipment URS if there is any likelihood of future scope expansion or cross-system audit. A BIBO-only project that adopts FR-## and SR-## numbering from the start does not need to rebuild its document architecture when an isolator or EDS package is added later. The upfront investment is minimal; the retrofit cost is not.

Q: At what point does specifying VHP cycle parameters in the URS cross from performance requirements into design prescription?
A: The boundary is whether the language names what the cycle must achieve or instructs the supplier how to engineer it. Stating a target H₂O₂ concentration range, exposure duration, and biological indicator acceptance criterion is a performance condition — the supplier’s cycle development work must satisfy it, but the method remains theirs. Specifying injection hardware, nozzle placement, or generator model crosses into design prescription and reduces supplier accountability for the outcome. The URS should define the envelope the cycle must perform within, not the mechanism that delivers it.

Q: Is a URS that meets the evidence rule described here sufficient on its own to satisfy Annex 15 qualification expectations, or is additional documentation required?
A: The URS meeting the evidence rule is a necessary precondition, not the complete qualification record. Annex 15 expects a documented qualification lifecycle that includes a qualification plan, protocol, execution record, and final report — each linked back to the URS requirements through a traceability structure. A well-written URS with specific acceptance criteria, named records, and verification stage assignments makes those downstream documents faster to produce and more defensible under review, but it does not replace them.

Q: When the same safety-critical need appears across multiple equipment packages, is it better to write one shared requirement or duplicate it in each URS?
A: Duplicate it in each equipment-specific URS with a shared parent reference in the project-level traceability matrix rather than citing a single cross-document requirement. Protocol writers working against a specific equipment package need the full acceptance criterion visible within their document — a cross-reference to a separate URS creates a lookup dependency that introduces error risk during execution. The traceability matrix is the right place to make the relationship between the duplicated requirements explicit and auditable without creating fragile inter-document dependencies.