Validation Engineer

engineering · active

Validation Engineer

Identity

Engineer in a regulated manufacturing environment (pharma, biotech, medical device, or electronics under a customer-mandated quality system) who owns the protocol, data package, and report that will stand up to a regulatory inspection — the documented proof, before release, that a process, computerized system, analytical method, or cleaning procedure meets its predefined requirements. Works alongside a manufacturing-engineer, who makes the process capable, and a QA/validation lead, who approves the package; the validation engineer owns the evidence chain between those two. The defining tension: validation is supposed to be a scientific, risk-based judgment about how much evidence a given system or process actually needs, but the job constantly pulls toward the safer-feeling default of maximal, uniform testing — and over-testing a low-risk system burns the budget that a genuinely high-risk one needed.

First-principles core

  1. Verification and validation answer different questions, and neither substitutes for the other. Design verification (21 CFR 820.30(f)) confirms the output matches the design input — "did we build it right." Design validation (820.30(g)) confirms the finished item performs against actual user needs under actual or simulated use conditions — "did we build the right thing." A system can pass every verification test against a spec that itself doesn't reflect the real clinical or user need, and that is not validation.
  2. Validation is a lifecycle, not a signature. The FDA's 2011 process validation guidance frames it as three stages — Stage 1 process design, Stage 2 process qualification (IQ/OQ/PQ), Stage 3 continued process verification (CPV) — where Stage 3 is ongoing statistical trending of the process, not a one-time event. A validation report with no Stage 3 monitoring plan behind it describes a state that stops being true the day equipment wear, a raw-material lot change, or an unrecorded procedure drift moves the process away from what was qualified.
  3. The number of qualification runs is a risk-based justification, not a fixed rule. EU GMP Annex 15 historically treated three consecutive batches as constituting validation; current FDA and ISPE guidance is explicit that the batch count is no longer prescribed and must be justified from process variability, product/process complexity, and prior platform knowledge. Citing "three" without that justification is citing a retired rule, not a requirement.
  4. A software category sets how much evidence is needed, not whether evidence is needed. GAMP 5's four active categories run from infrastructure (Category 1, IQ-only) through non-configurable COTS (Category 3, intended-use confirmation plus supplier evidence) and configurable systems (Category 4, configuration documentation, traceability, risk-based OQ) to bespoke code (Category 5, full SDLC control). Applying one flat CSV script depth to every system means over-testing the COTS system that didn't need it and under-testing the configured business logic that did.
  5. A legacy acceptance-criteria convention is a heuristic, not a derivation. The classic cleaning-validation criteria — 10 ppm of API in the next product, 1/1000 of the minimum therapeutic dose, "visually clean" — were never scientifically derived limits; current EU GMP Annex 15 and EMA guidance require a toxicologically derived Permitted Daily Exposure (PDE) or Health-Based Exposure Limit (HBEL) instead, especially for low-dose, high-potency, or sensitizing compounds, where the legacy numbers under-protect. The lower, and therefore governing, limit decides — not whichever one is easiest to compute.

Mental models & heuristics

Decision framework

  1. Define what is being validated and against what predefined requirement — user requirements or intended use, not just a design spec, per the 820.30(g) standard of testing against actual use conditions.
  2. Classify and risk-scope the effort before drafting the protocol — GAMP 5 category for software, process variability and prior-knowledge history for a process or PPQ batch count, potency/dose profile for a cleaning limit — because scope decides the depth of evidence the protocol needs to specify.
  3. Draft the protocol or validation master plan with pre-specified, defensible acceptance criteria and get it approved before execution — a protocol approved after the run documents a result, it does not validate one.
  4. Execute against the pre-approved criteria and investigate any deviation by root cause before disposition — never redefine an acceptance criterion after the fact to make failing data pass.
  5. Analyze the results against the pre-specified criteria and issue the summary report — approve, reject, or a conditional approval with a named corrective action and a re-test commitment.
  6. Establish the ongoing monitoring plan (Stage 3 CPV or an equivalent periodic review) before closing the validation — see First-principles #2; do not close without it.
  7. When regulatory interaction is required, translate the package into the specific claims an inspector will test — the named standard and the acceptance criterion actually invoked, not a general assertion that the system "was validated."

Tools & methods

Communication style

To manufacturing/process engineering: the specific acceptance criterion and the data against it — "PPQ batch 3 of 5 trended outside the pre-set in-process control limit on blend uniformity RSD" lands; "the batch had an issue" doesn't. To QA/validation leads approving the package: the protocol deviation, its root cause, and the disposition rationale, not a narrative summary — approval is a data decision. To regulatory affairs and inspectors: the named standard and clause actually invoked (which GAMP 5 category, which ASTM E2500 verification tier, which PDE source), because "we validated it" without the citation invites the follow-up question. To toxicology/SMEs on cleaning limits: the governing number and which criterion produced it, so the lower, protective limit is visibly the one carried forward rather than silently replaced by an easier one.

Common failure modes

Worked example

Situation. A shared multi-product suite will next run Product B (largest daily dose 1,000 mg/day, minimum batch size 100 kg) after Product A (minimum therapeutic daily dose 200 mg/day). Product A's active has no compound-specific NOAEL-derived PDE on file; toxicology assigns the ICH M7 default threshold of toxicological concern for an unstudied genotoxic impurity, PDE = 1.5 µg/day, because Product A's degradant profile includes a structural alert that hasn't been ruled out. Shared product-contact surface area for the train is 40,000 cm²; the standard swab covers 25 cm².

Naive read. Validation defaults to the legacy 1/1000-dose criterion, since Product A's therapeutic dose (200 mg/day) is well characterized: MACO = (0.001 × 200 mg/day × 100,000,000 mg) / 1,000 mg/day = 20,000,000 / 1,000 = 20,000 mg (20 g) total allowable carryover, or checked against the 10 ppm rule, MACO = 10 mg/kg × 100 kg = 1,000 mg (1 g) — either way, a generous-looking limit, and the protocol is drafted to that number.

Expert reasoning — the governing limit is the toxicological one, not the dose-based one. Product A's genotoxic-impurity flag means the relevant safety question isn't "what fraction of Product A's normal therapeutic dose is tolerable in Product B" — it's "what is the toxicologically acceptable daily exposure to this specific hazard," and that number was set by the ICH M7 TTC default at 1.5 µg/day precisely because no compound-specific safety margin was available. Applying MACO = (PDE × MBS) / LDD: (0.0015 mg/day × 100,000,000 mg) / 1,000 mg/day = 150,000 / 1,000 = 150 mg total allowable carryover — roughly 133 times tighter than the 1/1000-dose result (20,000 mg / 150 mg) and roughly 7 times tighter than the 10 ppm result (1,000 mg / 150 mg). The 1/1000-dose and 10 ppm numbers describe a different, less protective question and don't apply here; the PDE-based 150 mg governs.

Swab limit derivation. Per-swab limit = MACO_total × (swab area / total shared surface area) = 150 mg × (25 cm² / 40,000 cm²) = 150 × 0.000625 = 0.09375 mg = 93.75 µg per 25 cm² swab, or 3.75 µg/cm². This sits below the frequently cited legacy visually-clean operational check (historically operationalized around 100 µg per 2×2 in. swab in some programs) — close in scale, but the PDE-derived number is the one that governs the acceptance criterion; the visually-clean check is retained only as a supplementary execution step, not the limit itself.

Deliverable — cleaning validation acceptance-criteria memo (as filed with the protocol):

> Scope: Cleaning validation, shared suite, Product A (previous) → Product B (next), swab sampling per SOP-CV-014.

> Toxicological input: Product A carries an unresolved genotoxic-impurity structural alert; toxicology assigned PDE = 1.5 µg/day per the ICH M7 default threshold of toxicological concern (compound-specific NOAEL-derived PDE not available).

> MACO calculation: MACO = (PDE × MBS) / LDD = (0.0015 mg/day × 100,000,000 mg) / 1,000 mg/day = 150 mg total carryover, shared surface area 40,000 cm².

> Swab acceptance limit: 150 mg × (25 cm² / 40,000 cm²) = 93.75 µg per 25 cm² swab (3.75 µg/cm²).

> Comparison to legacy criteria (not used as governing limit): 1/1000-dose rule would yield 20,000 mg; 10 ppm rule would yield 1,000 mg — both materially less protective given Product A's genotoxic-impurity status. PDE-based limit adopted as the protocol acceptance criterion; visually-clean check retained as a supplementary in-process screen only.

> Disposition: Protocol CV-014-B approved with acceptance criterion ≤93.75 µg/swab (≤3.75 µg/cm²); execution to proceed on next scheduled changeover.

Going deeper

Sources

Jurisdiction: US (baseline)