Validating RPA and Workflow Automation in Quality Operations

Robotic process automation (RPA) shows up in quality operations the moment someone gets tired of copying data between two systems that will never have a real interface. A bot logs into a LIMS, reads a result, types it into a stability tracker, attaches a PDF to a document management system, and emails a reviewer. None of that is hard to build. All of it can break data integrity if you treat the bot the way you would treat a desktop macro nobody validated.

This page covers how to validate RPA and configurable workflow automation that touches GxP records: what the regulatory basis actually is, what deliverables you produce, how to scope effort by risk, what good acceptance criteria look like, and the inspection findings that show up when teams skip steps. The mental model that works is this: the bot is not the system of record. It is an automated user. You validate what it does to records, not the bot as a sealed black box.

What RPA is, and why it needs a different validation lens

RPA is software that mimics a human operator at the user-interface layer. Instead of integrating two systems through an API or a database link, an RPA bot drives the same screens a person would: it clicks buttons, reads fields, copies values, and moves data between applications. Common platforms in this category include UiPath, Automation Anywhere, Microsoft Power Automate, and Blue Prism. Workflow automation tools (form-driven routing, approvals, conditional logic builders) sit next to RPA and raise the same questions, so this page treats them together.

Three properties make RPA different from a traditional validated application and force a different validation approach.

It operates at the UI layer, so it is brittle. A field that moves, a pop-up that appears, a screen resolution change, or a vendor patch to the underlying application can silently break the bot or, worse, make it act on the wrong field. Traditional CSV assumes a relatively stable application. RPA assumes the opposite: the surfaces it touches change underneath it.

It usually spans multiple systems. A single bot may read from a chromatography data system, transform a value, and write to a spreadsheet and an ERP. That means the validation boundary is not one application. It is a transaction that crosses several validated and sometimes unvalidated systems.

It runs unattended. A human transcriber makes errors but also notices when something looks wrong. An unattended bot will happily transcribe a result into the wrong batch a thousand times before anyone catches it. The control you lose is human judgment in the loop; the control you must add is detection and exception handling.

Because of these properties, the question is never “is the RPA tool validated.” The platform is infrastructure. The question is “is this specific automation, doing this specific task, on these specific records, fit for its intended use, and can we detect when it fails.”

Attended bots, unattended bots, and why governance differs

RPA vendors split bots into two operating modes, and the split matters for validation because it changes where the human control actually sits.

An attended bot runs on a person’s own workstation, usually triggered by that person and often working alongside them inside an application they are actively using. Picture an analyst who clicks a trigger inside the LIMS and watches a bot populate a form while reviewing the source record on the same screen. An unattended bot runs on a server or in an orchestrator’s queue with no one watching in real time. It starts on a schedule or a trigger, a new file dropped in a folder, a status change in a queue, and it finishes before anyone looks at the result.

The instinct is to assume attended bots are automatically lower risk because a person is sitting there. That instinct is only half right, and it creates a failure mode of its own.

An unattended bot is honest about its risk. Nobody is there, so testing has to prove the bot catches its own failures. An attended bot can quietly become just as risky when the “human review” the risk assessment relied on degrades into a person clicking past a screen they have seen a hundred times. If a risk assessment credits human review for an attended bot, write down what that review actually requires the person to check, then test whether the review step as designed can catch a wrong value. A reviewer who only confirms the bot finished, not that the written value is correct, is not the control the risk assessment assumed.

The regulatory basis

There is no regulation titled “RPA validation.” You assemble the obligation from existing GxP computerized-system and data-integrity expectations. Know these and be able to map each to a concrete control.

21 CFR Part 11 (Electronic Records; Electronic Signatures). If the bot creates, modifies, deletes, or transfers electronic records that are GxP records, Part 11 applies to those records. The relevant clauses for RPA: §11.10(a) validation of systems to ensure accuracy, reliability, and consistent intended performance; §11.10(b) the ability to generate accurate and complete copies; §11.10(d) limiting system access to authorized individuals; §11.10(e) secure, computer-generated, time-stamped audit trails; and §11.10(g)/(h) authority and device checks. A bot is an authorized individual in the sense that it acts under credentials. That has consequences for access control and audit trails covered below.

EU GMP Annex 11 (Computerised Systems). Annex 11 is the European counterpart and is in some respects more explicit for RPA. Clause 5 (Data) is where a system handing data to another system has to prove the handoff itself is trustworthy: some form of automated verification, not a human glancing at the result, has to confirm what arrived on the far side matches what left the source, so nothing gets silently mangled or dropped in transit. That clause is the direct hook for the verification controls every RPA transcription bot needs. Clause 1 requires risk management across the lifecycle, clause 4 covers validation, clause 6 covers accuracy checks for critical data entered manually, clause 7 covers data storage, and clause 12 covers security and access.

FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026). This is the guidance that makes a risk-based, least-burden approach to RPA defensible. CSA tells you to spend effort proportional to the risk the software poses to product quality and patient safety, to favor unscripted and exploratory testing where appropriate, and to record evidence in proportion to risk rather than generating documentation for its own sake. RPA is a textbook CSA candidate because much of it is low-to-medium risk plumbing where heavy scripted protocols add cost without adding assurance.

GAMP 5 Second Edition (ISPE, 2022). GAMP 5 gives you the software category model and the critical-thinking framing. Most RPA automations are configured or, where you write custom selectors and code, custom logic on top of a configurable platform (think GAMP categories 4 and 5). GAMP 5 Second Edition explicitly endorses critical thinking, reliance on supplier activities, and scaling rigor to risk, which aligns with CSA.

ALCOA+ and the data-integrity guidances. MHRA’s “GXP Data Integrity Guidance and Definitions” (March 2018) and FDA’s “Data Integrity and Compliance With Drug CGMP” (December 2018) frame what the records the bot touches must remain: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring, and available. The bot must not break any of these. The two that RPA threatens most are attributable (who really did this, the bot or a person) and accurate (did the value survive the hop intact).

Put plainly: Part 11 and Annex 11 say the records must stay controlled, CSA and GAMP 5 tell you how much effort to spend proving it, and ALCOA+ is the yardstick for the records themselves.

Decide whether the automation is in scope, and at what risk level

Not every bot is a GxP system. The first deliverable is a documented determination. Do this before you write a single test.

Step 1: GxP determination

Ask whether the records the automation creates, modifies, deletes, or moves are used to make a GxP decision (release, stability conclusion, deviation closure, submission content, complaint trending). If yes, it is in scope. If the bot only moves non-GxP administrative data (booking a meeting room, generating a non-quality metrics chart for an internal dashboard with no GxP use), document the rationale and stop. Write the determination down; “we decided it was not GxP” with no record is itself a finding waiting to happen.

A common point of confusion: touching a validated system is not the same as being GxP

Teams often assume a bot inherits GxP status, or exemption from it, from the system it touches. Neither follows automatically.

The target system’s validation covers what the target system does with data once it has it: the calculations it performs, how it stores the record, its own audit trail. It says nothing about whether the bot delivered the right value to the right field in the first place. A bot that reads a validated LIMS and writes into a validated stability tracker is still the unvalidated link in the chain unless the transcription itself is validated, independent of either system’s own qualification.

The opposite error shows up just as often. A bot that only reads from a validated system for a non-GxP purpose, say a staffing dashboard that counts open deviations by owner with no bearing on any quality decision, is not automatically in scope merely because its source system is GxP. Scope follows what the bot’s output is used for, not which systems it happens to pass through along the way.

Step 2: Intended use statement

Write one or two sentences that state exactly what the automation does and the boundary of its action. Vague intended-use statements produce vague validation. Compare:

• Weak: “The bot helps with stability data.”
• Strong: “The bot reads the final reportable assay result and its result status from the LIMS sample record, and writes both values, unchanged, into the corresponding row of the stability summary register. It performs no calculation, rounding, or interpretation. A qualified analyst reviews every written row against the LIMS source before the register is used for any decision.”

The strong version tells you precisely what to test and what risk you carry.

Step 3: Risk assessment

Score the automation on impact and detectability. A simple, defensible matrix:

The combination drives rigor. A read-only bot that populates a screen a human then fully verifies is low risk and gets light testing. An unattended bot that calculates a value and writes it to a record nobody re-checks before release is high risk and gets full scripted verification, boundary testing, and strong exception handling. Document the score and the resulting test strategy. This risk assessment is your CSA “assurance needs” decision and it is the document an inspector will read first.

Those first three steps chain into one determination path. Run it before any test design:

Cross-reference the dedicated method here: see CSV risk assessment methodology and data criticality and data risk.

GAMP software category for an RPA automation

Risk sets how much assurance you need; the GAMP software category helps you decide where that assurance comes from (how much you can rely on the platform vendor versus how much you must test yourself). RPA rarely sits in one clean category, because you are almost always writing configuration and often custom selectors or scripting on top of a configurable platform. Map each automation so the split of supplier reliance and your own testing is explicit.

The practical lesson is that “we are on UiPath, so it is Category 4” is too glib. The selectors and the decision logic are frequently the Category 5 part, and that is exactly where a fragile selector or an untested branch turns into a wrong GxP record. Categorize the parts, not just the platform.

ISPE’s own trade literature backs that split. Pharmaceutical Engineering magazine ran “A GAMP Approach to Robotic Process Automation” in its May/June 2020 issue (Wyn and Canterbury), which places the RPA platform itself, and each deployed bot considered as a piece of ready-to-run infrastructure, in Category 1, while treating the automation logic that tells the bot what to do as Category 5 regardless of how it was assembled. That framing matches GAMP 5 Second Edition’s broader category model: a bot built in a low-code designer is still custom logic where it matters, and it earns a Category 5 lifecycle for that logic even though the platform underneath it is off the shelf. See GAMP Category 5 custom system validation for how to run that lifecycle for the custom pieces.

Orchestration platform validation: the layer above the individual bot

Most production RPA runs under an orchestrator (UiPath Orchestrator, Automation Anywhere Control Room, the Power Automate admin center, or an equivalent). The orchestrator schedules runs, holds the credential vault, queues work items, licenses bots, and centralizes execution logs across the whole fleet. That is a different validation question from whether any one bot moves the right value into the right field, and treating the two as the same thing leaves a real gap.

Qualify the orchestrator once, as infrastructure, much as you would qualify a server or a database platform: installation and configuration verification, access control and credential vault configuration, backup and recovery of the scheduling and logging data, and confirmation that its own audit log cannot be altered by an ordinary user. See infrastructure qualification and spreadsheet validation for the pattern this follows.

A highly qualified platform does not make an individual bot’s transcription correct, and a well-tested bot does not protect you if the orchestrator’s credential vault is misconfigured and every bot in the fleet can read every other bot’s service account. Both layers need their own evidence, and the orchestrator’s periodic review (vault access, scheduling integrity, license and capacity headroom) belongs on the same cadence discipline as any other qualified infrastructure, kept separate from the periodic review of each bot’s accuracy and exception rate.

What goes in the validation package

For an in-scope RPA automation, the deliverable set mirrors a small CSV package but is sized to the risk. A medium-risk bot typically needs the following. Lower risk drops items; higher risk expands them.

Two of these deserve extra attention because RPA gets them wrong most often: the configuration specification and the supplier assessment.

The configuration specification must capture how the bot finds each field it touches. RPA tools identify UI elements through selectors (attribute paths, image matching, coordinates, or accessibility identifiers). A bot built on screen coordinates or fragile image matching is a future false-result generator. Document the selector strategy so a reviewer can judge how stable it is and so the next person can maintain it.

The supplier assessment is done once for the platform vendor (their development lifecycle, their patch and security practices, their support). You do not re-audit UiPath for every bot. You assess the platform once and reuse it, which is exactly the supplier-reliance principle GAMP 5 endorses. See software supplier assessment (CSA) and supplier and vendor qualification.

For the broader deliverable map, see validation deliverables guide and GAMP 5 CSV framework.

Requirements: write the negatives, not just the positives

The URS for a bot is short but has a feature most URS documents lack: explicit negative requirements and exception behavior. Inspectors and good reviewers look for these because they reveal whether you thought about failure.

A usable RPA requirement set has four blocks.

Functional requirements. What the bot reads, transforms (if anything), and writes, and where. Each must be testable. Example: “The bot shall write the reportable result exactly as displayed in the LIMS source field, with no rounding or reformatting.”

Negative requirements. What the bot must not do. Example: “The bot shall not modify any LIMS source record.” “The bot shall not proceed if the source field is blank, but shall instead halt and raise an exception.”

Exception and error handling. What happens when the bot meets a state it cannot handle: a missing record, a login failure, an unexpected pop-up, a value that fails a format check, a target system that is down. The required behavior is almost always “stop, do not guess, log the exception, and route it to a human.” A bot that swallows errors silently is the single biggest data-integrity risk in RPA.

Data verification requirements. This is the Annex 11 clause 5 hook. For any data transfer, require a built-in check that the written value equals the source value. Read-back verification (write, then read the target field and compare to source, fail if mismatch) is the standard control and turns a transcription bot from “trust me” into “self-checking.”

Trace every requirement to a test in the matrix. See user requirements and traceability.

Testing: scale it with CSA, but never skip the data-integrity checks

CSA lets you choose the lightest method that gives genuine assurance. For RPA, the practical split is:

• Unscripted / exploratory testing for lower-risk, lower-impact behavior and for the happy path on a medium-risk bot. Run the bot on representative inputs, observe, and record evidence (screenshots, output files, a short test note). You do not need a 40-step scripted protocol to confirm a low-risk bot moved three fields correctly.
• Scripted testing for high-risk logic, calculations, decision branches, and anything that directly determines a GxP decision. Here you want pre-approved steps, defined expected results, and recorded actual results.
• Limited / stress testing that is specific to RPA and must not be skipped regardless of risk band, because it targets the failure modes RPA is prone to.

The RPA-specific tests that earn their keep:

A worked example of a single test case in the format an auditor expects to see:

Test ID: RPA-TC-007 Boundary, blank source result Requirement traced: REQ-014 (bot shall halt on blank source), REQ-009 (bot shall not write a guessed value) Pre-condition: A LIMS sample record exists with the reportable result field empty. Steps: 1) Trigger the bot against the sample. 2) Observe bot behavior. 3) Inspect the stability register row. 4) Inspect the exception queue. Expected result: Bot halts; no row written or row written with no result value; exception logged with sample ID, timestamp, and reason “source result blank”; item routed to analyst queue. Actual result: [recorded at execution] Pass/Fail: [recorded] Evidence: screenshot of exception queue entry; export of register showing no fabricated value.

For protocol mechanics and how to handle a test that fails during execution, see writing validation protocols and reports and validation test failure management.

Acceptance criteria: what “done correctly” looks like

State acceptance criteria up front, in the plan, so the conclusion is not a judgment call after the fact. For an RPA automation, “good” means all of the following hold.

• Every requirement traces to at least one executed test with a recorded result.
• Happy-path accuracy is 100 percent on the executed representative dataset. A transcription bot that is “98 percent accurate” is not acceptable; the 2 percent is a wrong GxP record. Accuracy here is binary by design, which is why read-back verification exists.
• The read-back / built-in verification control was demonstrated to detect a deliberate mismatch (you proved the check works by making it fire).
• Every defined exception path was tested and the bot stopped and routed to a human rather than proceeding.
• The target-system audit trail attributes the bot’s actions correctly and completely.
• No test failures remain open; any deviation during testing is investigated and closed with documented rationale.
• The residual risk stated in the summary report is accepted by QA in writing, including any conditions of use (for example, “valid only while a qualified reviewer verifies 100 percent of written rows before the register is used”).

That last point matters: validation does not remove the human control if your risk assessment relied on it. If you claimed low risk because a human reviews every output, that human review is now a required, procedure-bound control, not an optional nicety.

Access control, credentials, and attributability

This is where RPA most often collides with Part 11 and Annex 11, and it is a favorite inspection topic.

A bot acts under credentials. If it logs into the LIMS as “Service Account RPA01,” then the LIMS audit trail attributes the writes to RPA01, which is correct and attributable. The mistakes that generate findings:

The bot uses a real person’s named account. Now the audit trail says the analyst performed actions the analyst never performed. That destroys attributability and is a direct ALCOA+ failure. Bots get their own clearly named, non-human service accounts.

The service account is shared or its password is in plain text in a config file or script. Part 11 §11.10(d) and §11.300 expect controls over identity. A shared bot credential that any developer can read and use breaks the link between an action and an accountable identity. Use a credential vault (the RPA platforms provide one), restrict who can see and change it, and document it.

The bot has more access than its task needs. Least privilege applies to bots. A bot that only reads a result and writes one register should not have admin rights or delete permissions on the source system. Map the bot’s permissions to its intended use and remove the rest.

No segregation between who builds the bot and who approves it for GxP use. The developer who writes the automation should not be the sole approver of its validation. QA approves; an independent reviewer checks. See CSV cybersecurity and access control and electronic signatures implementation.

If the bot’s action constitutes a signing or approval step in a GxP record, that crosses into electronic signature territory and needs deliberate design; most teams correctly keep approval decisions with humans and let the bot only prepare and route.

Audit trails: two layers you must think about

RPA creates an audit-trail question with two layers, and reviewers conflate them.

Layer one: the records the bot touches. When the bot writes to the LIMS or the register, the target system’s own audit trail must capture the change (who/bot, what, old value if applicable, new value, timestamp). This is the GxP-relevant audit trail and it must be reviewed as part of normal audit-trail review. The bot does not get to bypass the target system’s controls. If a bot writes through a back door that the application audit trail does not capture, that is a serious finding.

Layer two: the bot’s own execution log. The RPA platform logs what the bot did, when, on which items, and which exceptions occurred. This log is your evidence of consistent intended performance and your exception record. It is operationally vital (it is how you catch a bot that started misbehaving after an application update) but it is the execution evidence, not a substitute for the target system’s record audit trail.

Define who reviews each, how often, and what triggers action. For a high-risk unattended bot, periodic review of the execution log (exception rates, run completeness) is a real control, not paperwork. See audit trail design and review and operationalizing audit trail review.

Keeping it validated: change control and periodic review

RPA breaks the “validate once, leave alone” assumption harder than any other system class, because the applications underneath it change constantly and a vendor patch can silently shift a field. Your validated state has more moving parts than the bot itself.

Change control. Changes to the bot logic obviously trigger assessment, but the RPA-specific addition is that changes to the underlying applications can invalidate the bot without anyone touching the bot. Wire your change-control process so that an upgrade to the LIMS, the ERP, the browser, or the operating system triggers an impact assessment on every bot that touches those surfaces. Maintain a register that maps each bot to the systems it drives, so when a system change comes in you can immediately see which bots are exposed. Re-test the affected paths before the changed environment goes live. See change control for validated systems and IT change and configuration management in GxP.

Periodic review. On a defined cadence, review each bot: exception and error rates from the execution log, any drift in accuracy, open changes, incidents, and whether the intended use still matches what the business actually does with the bot. A bot whose exception rate is climbing is telling you a surface is drifting underneath it. See validation master plan and periodic review and requalification and periodic review of equipment for the cadence pattern.

Incident handling. When a bot does produce a wrong record (it will, eventually), that is a deviation. Investigate it, assess the impact on records already produced (how many transactions since the last known-good state, what decisions relied on them), correct, and feed the lessons back into the bot design and the change-control wiring. See deviation management and CAPA effectiveness verification.

Citizen-developer governance: make room for it without losing control

Low-code RPA platforms exist precisely so people outside IT can build automations, and that is also where most of the ungoverned bots at a given site come from. The fix is not a blanket ban; that mostly pushes citizen development underground, where visibility disappears entirely. The fix is a short, enforced intake path that catches a bot before it reaches a GxP record, not after.

A workable model has three moving parts. A business user who wants to automate a task touching a regulated system follows a published intake process rather than an informal “let’s see if it works.” The GxP determination happens before logic gets built against production data, not after a working prototype already exists and momentum makes it hard to kill. And a bot determined to be in scope moves onto the validated track regardless of who built it; a bot determined to be out of scope still gets entered in the bot register with its rationale on file, so the person who built it is not the only one who knows it exists.

Training is the piece teams skip. A citizen developer does not need a validation certification, but needs to know what a negative requirement is, why an exception has to stop the bot rather than let it guess, and that “it works on my test case” is a different claim from “it is validated.” See training program for GxP roles for scoping that kind of role-specific training, and GxP roles and responsibilities for how the citizen-developer track fits the wider accountability model.

Roles and responsibilities

Clear ownership prevents the most common RPA failure mode, which is a bot built by an enthusiastic citizen developer that nobody validated, owns, or maintains.

The non-negotiable separation: the person who builds the bot is not the only person who approves it for GxP use. See GxP roles and responsibilities.

Common mistakes and inspection-finding patterns

These are the patterns that turn up in computerized-system and data-integrity observations. None require naming a company; they are generic and recurring.

Citizen-developer bots in production with no validation. A team buys a low-code RPA license, a non-validation person automates a GxP transcription task, and it runs unvalidated for months. The fix is governance: any bot touching GxP records goes through the determination and risk process before it runs. See validating scripts and low-code analytics.

Treating the platform as the validated object. “We validated UiPath” tells you nothing about whether a specific bot moves your specific data correctly. The platform is qualified infrastructure; each automation is validated for its intended use.

No data-transfer verification (the Annex 11 clause 5 miss). A transcription bot with no read-back check is trusted blind. When it eventually writes a wrong value, there is no detection until a human stumbles on it. Build and test the verification.

Silent exception handling. The bot meets an unexpected state and guesses, retries, or skips without logging. This is the worst case because it produces wrong records with no trail. Exceptions must stop the bot and route to a human.

Bots running under human credentials. The audit trail attributes bot actions to a named person, which is a false record and an attributability failure under ALCOA+ and Part 11.

No impact assessment when underlying systems change. A LIMS upgrade moves a field; the bot now reads the wrong field and transcribes wrong results for weeks. The change-control wiring that links system changes to bot re-testing was never built.

Validation evidence that is all happy path. Every test shows the bot working when everything is perfect. No boundary tests, no forced exceptions, no proof the verification check can fire. Inspectors read this as “you never tested failure,” which is where data integrity actually lives.

Lost or undocumented bot inventory. Nobody can produce a list of which bots exist, what they touch, and which are GxP. You cannot defend a fleet you cannot enumerate. Maintain a bot register tied to the systems each one drives.

Automation complacency on an attended bot. A human is technically present when the bot runs, but the “review” has worn down to a reflexive click past a screen the person has seen hundreds of times. The risk assessment credited a human control that no longer exists in practice. Test what the review step actually requires the reviewer to look at, not whether a human happens to be in the room.

The orchestrator treated as someone else’s infrastructure. Bots are validated one by one, but the credential vault, scheduling engine, and platform-wide access controls that every bot depends on were never qualified or reviewed as their own layer. A misconfigured vault can expose every bot’s credentials at once, a failure mode that no amount of individual bot testing would catch.

A citizen-developer bot discovered in production after the fact. Someone outside the RPA group builds a working automation, it proves useful, and it quietly becomes part of how a team works before anyone runs the GxP determination. The finding is not that a non-specialist built something; it is that no intake process existed to catch it before it touched a regulated record.

Interview-ready: questions you should be able to answer

“How is validating an RPA bot different from validating an application?” The bot is not the system of record; it is an automated user acting at the UI layer across multiple systems, unattended and brittle. You validate what it does to records, not the bot as a sealed black box. The validation boundary is the cross-system transaction, the dominant risks are silent transcription errors and broken attributability, and the bot needs continuous protection against changes in the applications underneath it.

“What regulation requires a data-transfer verification check?” EU GMP Annex 11 clause 5: when one system hands data to another, the exchange itself has to carry an automated way of confirming the value arrived intact rather than trusting that it did. In practice that is read-back verification on every transfer, and FDA Part 11 §11.10(a) and (b) back the same intent through accuracy and accurate-copy requirements.

“How does CSA change how you test an RPA bot?” CSA (FDA’s Computer Software Assurance guidance, current version issued 3 February 2026) lets you scale effort to risk. Low-risk, read-only or fully human-reviewed bots get unscripted testing and lighter evidence; high-risk unattended bots that calculate or decide get scripted testing, boundary testing, and full exception verification. You spend assurance where wrong records would hurt product quality or patient safety, not uniformly.

“A bot logs into the LIMS as an analyst’s account. What is wrong with that?” It breaks attributability. The LIMS audit trail will attribute the bot’s actions to a person who never performed them, which is a false record and an ALCOA+ and Part 11 access-control failure. Bots need their own named service accounts with vaulted credentials and least privilege.

“Your transcription bot writes a wrong result into a register. How do you know, and how should it have been prevented?” Prevention is a built-in read-back check that compares the written value to the source and fails on mismatch, tested to confirm it actually fires. Detection in life is that check plus periodic review of the execution log’s exception rate and the human review you committed to in the risk assessment. When it happens, it is a deviation: assess every transaction since the last known-good state, correct the records, and fix the design and the change wiring.

“What triggers re-validation of a bot that you have not changed?” A change to any system the bot drives: LIMS, ERP, browser, or operating system upgrades, screen or field changes, or security configuration changes. Your change-control process must link those system changes to an impact assessment and re-test of the affected bots before the changed environment goes live.

“How do you handle exceptions in a GxP bot?” Fail safe: on any unexpected state the bot stops, does not guess or skip silently, logs the exception with enough context (record ID, timestamp, reason), and routes the item to a human queue. Then you test that this actually happens by forcing the failure conditions.

“What is the difference between an attended and an unattended bot, from a validation standpoint?” An attended bot runs on a person’s own workstation while they watch; an unattended bot runs on a schedule or a trigger with no one present. Attended does not mean low risk by default. The real question is what the human review actually requires the person to check, and whether that review still happens in practice rather than having worn down into a reflexive click-through. Unattended bots have no such fallback, so the bot’s own exception handling and read-back verification have to carry the full weight.

“Does a bot become a GxP system just because it logs into your validated LIMS?” No. Scope follows what the bot’s output is used for, not which systems it passes through. A bot that reads a validated system for a non-GxP purpose, like a staffing dashboard, is not in scope on that basis alone. Conversely, the target system’s own validation does not cover the bot’s transcription; that link in the chain needs its own validation regardless of how well qualified the systems on either end are.

“Your RPA fleet runs under an orchestrator. Does qualifying the orchestrator validate the bots?” No, and treating it that way is a common gap. The orchestrator is infrastructure: it schedules runs, holds the credential vault, and centralizes logs, and you qualify it once, much as you would qualify a server. Each bot still needs its own validation for what it reads, transforms, and writes. A well-qualified orchestrator running an unvalidated bot still produces a wrong record, and a validated bot running on a misconfigured orchestrator can still have its credentials exposed across the whole fleet.

Go-live checklist

Run this before any RPA automation that touches a GxP record moves into production. It does not replace the validation package; it confirms the package is actually complete.

• GxP determination documented, including the rationale if the automation was judged out of scope
• Intended-use statement states exactly what is read, what is transformed (if anything), what is written, and where
• Risk assessment completed and the resulting test strategy matches the risk level
• GAMP category assigned separately for the platform, the configured workflow, and any custom selectors or code
• Attended or unattended mode identified, and if attended, the human review step is defined precisely enough to test
• URS includes negative requirements and exception behavior, not only the happy path
• Configuration specification documents the selector strategy
• Mandatory RPA-specific tests executed: boundary/format, exception handling, read-back verification proven to fire, concurrency/volume, attributability, negative/must-not
• Service account is named, non-human, and vaulted; access is least privilege
• Target-system audit trail confirmed to attribute the bot’s actions correctly
• Bot entered in the bot inventory and system-dependency register
• Change control wired so a change to any system the bot drives triggers an impact assessment
• Orchestrator-layer controls (credential vault, scheduling, platform audit log) already qualified and on their own periodic review cycle
• Summary report approved by QA, with residual risk and any conditions of use stated in writing

Practical tips

• Write the intended-use statement first and make it precise. Nearly every later argument (risk level, what to test, residual risk) flows from it.
• Default the bot to “stop and ask a human” for anything it was not explicitly built to handle. Optimistic bots produce confident wrong records.
• Build read-back verification into every transfer and then deliberately break it once in testing to prove the check fires.
• Give every bot its own named service account and put the credential in the platform vault. Never a human’s login, never a plain-text password.
• Keep a living register that maps each bot to the systems it drives, so a system upgrade ticket immediately surfaces which bots need reassessment.
• Prefer stable selectors (attribute or accessibility identifiers) over screen coordinates or image matching. Document the selector strategy so maintainability is reviewable.
• Lean on the platform supplier assessment once and reuse it; do not re-audit the vendor per bot.
• Govern citizen development. The risk is not the tool; it is an unvalidated GxP bot nobody owns.

Related reading

• Computer Software Assurance (FDA)
• GAMP 5 CSV framework
• GAMP Category 5 custom system validation
• Infrastructure qualification and spreadsheet validation
• Training program for GxP roles
• Validating scripts and low-code analytics
• Validating AI GxP systems
• CSV risk assessment methodology
• 21 CFR Part 11 and EU Annex 11
• Audit trail design and review
• Change control for validated systems
• Data criticality and data risk