This is a ready-to-use assurance plan for a single RPA bot or configurable workflow automation that touches GxP records. It scopes the effort by risk in line with FDA’s Computer Software Assurance thinking. Replace every <<FILL: ...>> placeholder and route it through your normal review and approval. A filled specimen follows. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source.
Document control
| Field | Entry |
|---|---|
| Title | RPA / Workflow Automation Validation (Assurance) Plan |
| Document number | <<FILL: PLAN-ID, e.g. VAL-RPA-012>> |
| Automation name | <<FILL: bot / workflow name>> |
| Platform | <<FILL: e.g. UiPath / Automation Anywhere / Power Automate / Blue Prism>> |
| Version | <<FILL: version>> |
| Prepared by | <<FILL: name, date>> |
| Approved by (QA) | <<FILL: name, date>> |
1. GxP determination
| Field | Entry |
|---|---|
| Records the automation creates/modifies/deletes/moves | <<FILL>> |
| Do those records feed a GxP decision (release, stability, deviation closure, submission, complaint trending)? | <<FILL: Y/N>> |
| GxP determination | <<FILL: in scope / not in scope>> |
| Rationale (record even if not in scope) | <<FILL>> |
If not in scope, record the rationale and stop; the rest of this plan does not apply.
2. Intended use statement
State exactly what the automation does and the boundary of its action, precisely enough to test. Name what it reads, whether it transforms anything, what it writes and where, and any human control relied on.
<<FILL: precise intended-use statement, e.g. "The bot reads the final reportable assay result and its status from the LIMS sample record and writes both values unchanged into the corresponding row of the stability register. It performs no calculation. A qualified analyst reviews every written row against the LIMS source before the register is used.">>
3. Risk assessment
| Factor | Score (Low/Med/High) | Basis |
|---|---|---|
| Record criticality | <<FILL>> | <<FILL>> |
| Bot action (read / move unchanged / calculate-decide-delete) | <<FILL>> | <<FILL>> |
| Human review of output | <<FILL>> | <<FILL>> |
| Detectability if wrong | <<FILL>> | <<FILL>> |
| Overall risk level | <<FILL: Low / Medium / High>> | <<FILL>> |
The overall risk level sets the assurance effort (section 5). Document the GAMP software category of the configured parts and any custom selectors or code, since custom logic carries more of the rigor.
4. Deliverables
| Deliverable | Included? | Notes |
|---|---|---|
| This assurance plan | yes | |
| Intended use / process description | yes | The single most important document |
| Risk assessment | yes | The CSA assurance-needs decision |
| User requirements (URS) incl. negative and exception requirements | <<FILL: Y/N>> | |
| Configuration / design specification (selectors, logic, exceptions) | <<FILL>> | The as-built |
| Traceability matrix | <<FILL>> | Requirements to tests |
| Test protocol(s) and results | yes | Scripted + unscripted per risk |
| Supplier assessment (platform) | reuse | One-time, reused across bots |
| Summary report | yes | States residual risk and conditions of use |
| Procedures: change control, periodic review, incident handling | reference |
5. Test strategy (scaled by CSA)
| Risk level | Approach |
|---|---|
| Low | Unscripted/exploratory evidence for the happy path; light documentation; human review recorded as a bound control |
| Medium | Scripted happy-path core; unscripted elsewhere; all RPA-specific tests (below) mandatory |
| High | Fully scripted verification of logic, calculations, and decision branches; boundary, exception, read-back, concurrency, attributability, and negative tests |
RPA-specific tests that are mandatory regardless of risk band (they target the failure modes RPA is prone to): boundary/format, exception handling (bot must stop, not guess), read-back verification proven to fire on a deliberate mismatch, attributability (target audit trail attributes the bot identity), and negative/must-not.
6. Acceptance criteria
- 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 read-back / built-in verification control was demonstrated to detect a deliberate mismatch.
- Every defined exception path was tested and the bot stopped and routed to a human.
- The target-system audit trail attributes the bot’s actions correctly and completely.
- No test failures remain open; deviations are investigated and closed with rationale.
- Residual risk 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”).
7. Access, credentials, and attributability
| Control | Commitment |
|---|---|
| Service account | <<FILL: named non-human account, never a person's login>> |
| Credential storage | <<FILL: platform credential vault; restricted access>> |
| Least privilege | <<FILL: bot has only the permissions its task needs; no delete/admin on source>> |
| Segregation of duties | Builder is not the sole approver; QA approves independently |
8. Keeping it validated
| Activity | Commitment |
|---|---|
| Change control | Changes to bot logic and to any underlying system the bot drives trigger an impact assessment and re-test before the changed environment goes live |
| Periodic review | Review exception/error rates, accuracy drift, open changes, and whether intended use still matches practice, at <<FILL: cadence>> |
| Incident handling | A wrong record is a deviation: assess every transaction since the last known-good state, correct, and fix the design and change wiring |
| Inventory | The bot is entered in the RPA bot register with the systems it drives |
9. Roles
| Role | Responsibility |
|---|---|
| Process / business owner | Owns intended use; approves requirements |
| RPA developer | Builds the bot, writes the configuration spec, executes initial testing |
| Quality Assurance | Approves determination, risk assessment, plan, and report; independent of the build |
| Validation / CSV lead | Designs the risk-proportionate test strategy; reviews traceability and evidence |
| System/application owners | Notify on system changes; confirm bot service accounts and audit-trail capture |
| IT / security | Manage credentials and least privilege |
10. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Validation / CSV lead | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
11. References
21 CFR Part 11 (electronic records and signatures), in particular 11.10(a), (b), (d), (e). EU GMP Annex 11, in particular clause 5 (data transfer checks), clause 4 (validation), clause 12 (security). FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026). ISPE GAMP 5 (Second Edition). MHRA GXP Data Integrity Guidance and Definitions; FDA Data Integrity and Compliance With Drug CGMP.
Confirm the current version of each reference before issue.
Filled specimen
Illustrative assurance plan summary for a medium-risk stability-register transcription bot.
| Field | Entry |
|---|---|
| Automation | LIMS-to-stability-register transcription bot |
| Platform | UiPath (illustrative) |
| GxP determination | In scope: the register feeds stability conclusions |
| Intended use | Reads reportable result + status from LIMS; writes both unchanged to the register row; no calculation; analyst reviews every row against LIMS before use |
| Risk factors | Criticality Medium; action Move-unchanged; review Every-transaction; detectability Medium |
| Overall risk | Medium |
| Test strategy | Scripted happy-path core; mandatory boundary, exception, read-back, attributability, negative tests |
| Key acceptance criterion | 100 percent happy-path accuracy; read-back proven to fire on a seeded mismatch |
| Condition of use | Valid only while the analyst 100 percent-verifies written rows before the register is used |
| Service account | RPA-STAB-01, vaulted credential, read-only on LIMS, write-only on the register |
The condition of use is not optional prose: because the risk was scored Medium partly on the human review, that review is now a required, procedure-bound control. Drop it and the risk basis no longer holds.
Common inspection findings this plan prevents
- A GxP bot running with no documented determination or risk assessment.
- “We validated the platform” standing in for validating the specific automation.
- No read-back verification on a transcription transfer (the Annex 11 clause 5 miss).
- The bot running under a person’s login, breaking attributability.
- No link between a LIMS/ERP upgrade and re-testing the bots that touch it.
How to adapt this plan
- Write the intended-use statement first and precisely; nearly every later decision flows from it.
- Set the risk level honestly; if you claim Low because a human reviews every output, bind that review as a required control in section 6.
- Reuse the one-time platform supplier assessment; do not re-audit the vendor per bot.
- Point the change-control and periodic-review commitments at your real procedures.
- Enter the bot in the RPA bot register so a system-change ticket surfaces it.