This is a ready-to-use register. It answers two questions an inspector asks and a change ticket depends on: which bots exist and touch GxP records, and which systems each bot drives so a system upgrade surfaces the exposed bots. Replace every <<FILL: ...>> placeholder, keep it current, and treat it as a controlled record. Field definitions and a filled specimen follow. This content is educational reference, not legal or regulatory advice.
Register control
| Field | Entry |
|---|---|
| Register title | RPA Bot Inventory and System-Dependency Register |
| Register number | <<FILL: REG-ID, e.g. REG-RPA-001>> |
| Owner | <<FILL: role, e.g. RPA governance lead / QA>> |
| Review cadence | <<FILL: e.g. quarterly>> |
| Location | <<FILL: controlled location / system>> |
Register (one row per bot)
| Bot ID | Bot name | Business process | GxP? | Risk level | Systems driven (dependencies) | Service account | Platform / version | Validation status | Plan / report ref | Last periodic review | Next review | Owner |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
<<FILL: BOT-001>> | <<FILL>> | <<FILL>> | <<FILL: Y/N>> | <<FILL: L/M/H>> | <<FILL: e.g. LIMS v.., ERP v.., browser, OS>> | <<FILL: service account>> | <<FILL>> | <<FILL: Validated / In progress / Retired>> | <<FILL: VAL-RPA-.. >> | <<FILL: date>> | <<FILL: date>> | <<FILL>> |
<<FILL: BOT-002>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Field definitions
| Field | Format / rule | Who maintains | When updated |
|---|---|---|---|
| Bot ID | Unique, stable identifier | Register owner | At bot creation |
| GxP? | Y/N per the documented determination | Register owner / QA | At determination |
| Risk level | L/M/H from the risk assessment | Validation lead | At validation, on change |
| Systems driven | Every application, browser, and OS the bot depends on, with version | Developer / system owners | At build and on any dependency change |
| Service account | The bot’s named non-human account (never a person’s login) | IT / security | At provisioning |
| Validation status | Validated / In progress / Retired | QA | On status change |
| Last / next periodic review | Dates driving the review cadence | Register owner | Each review |
Retention: retain as a controlled record for not less than <<FILL: retention period>>.
How the register earns its keep: the change-impact query
When a change ticket arrives for any system (a LIMS upgrade, an ERP patch, a browser or OS update, a screen redesign), filter the register on the “Systems driven” column for that system. Every matching bot gets an impact assessment and re-test of the affected paths before the changed environment goes live. Without the register, a field move in an upgraded LIMS can send a bot reading the wrong field for weeks before anyone notices.
Acceptance criteria for the register
- Every bot that touches GxP records appears, with its GxP determination recorded.
- Each bot lists all systems it drives, so a system change can surface the exposed bots.
- Each in-scope bot links to its validation plan/report and shows a validation status.
- Service accounts are named and are non-human.
- Periodic review dates are current; overdue reviews are visible.
Filled specimen
| Bot ID | Bot name | Process | GxP? | Risk | Systems driven | Service account | Platform | Status | Ref | Last review | Next review | Owner |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| BOT-004 | Stability register transcription | Stability data entry | Y | M | LIMS v7.2, StabTrack v3, Chrome, Win Server 2022 | RPA-STAB-01 | UiPath 2024.10 | Validated | VAL-RPA-012 | 2026-04-10 | 2026-07-10 | QC Systems |
| BOT-009 | COA PDF filing | Document filing | Y | L | DMS v5, Win Server 2022 | RPA-DMS-02 | UiPath 2024.10 | Validated | VAL-RPA-018 | 2026-05-02 | 2026-08-02 | QA Docs |
| BOT-011 | Meeting-room booking | Facilities | N | n/a | Room-booking SaaS | RPA-FAC-01 | Power Automate | Not GxP (rationale on file) | DET-RPA-011 | n/a | n/a | Facilities |
When a LIMS v7.2 to v7.3 upgrade ticket lands, filtering “Systems driven” on “LIMS” returns BOT-004 immediately, which triggers its impact assessment and re-test before the upgrade goes live. BOT-011 is in the register too, with its not-GxP rationale recorded, so no one has to re-derive why it was excluded.
Common inspection findings this register prevents
- No one can produce a list of which bots exist, what they touch, and which are GxP.
- A bot reading a moved field for weeks because no one linked the LIMS upgrade to the bot.
- Bots running under human logins, invisible until an audit trail is questioned.
- Overdue periodic reviews with no visibility.
- A “not GxP” exclusion with no recorded rationale.
How to adapt this register
- Set your register number, owner, and cadence in the control block.
- Populate “Systems driven” with versions; the version is what makes the change-impact query precise.
- Include non-GxP bots with their not-GxP rationale so exclusions are defensible.
- Wire the change-control process to query this register on every system change ticket.
- Surface overdue “Next review” dates on your quality dashboard so reviews do not slip.