Policy: Citizen-Developer RPA Governance

This is a ready-to-use policy. A policy states what the organization requires and who owns it; the procedures underneath it state how to do the work. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This policy sets the requirement that anyone who builds a robotic process automation (RPA) bot or configurable workflow automation at <<FILL: COMPANY NAME>>, inside or outside the RPA center of excellence, follows a defined intake and determination path before that automation touches a regulated record. The objective is to make citizen development (automation built by people outside a dedicated RPA team) safe to allow rather than something to suppress, by catching an automation before it reaches production, not after it has already become how a team works.

2. Policy statement

<<FILL: COMPANY NAME>> permits citizen development of RPA and workflow automation, because low-code platforms put real productivity gains in the hands of the people who understand the process best. That permission carries one condition: no automation that creates, modifies, deletes, or moves a GxP record goes into production without the same GxP determination, risk assessment, and validation that applies to any RPA bot, regardless of who built it or which platform hosts it. The condition exists because an unvalidated transcription bot fails silently: it does not announce a wrong value, it simply writes one, and by the time anyone notices, the record has already been used to support a conclusion.

An automation built outside the RPA center of excellence is not exempt because it started life as a personal productivity tool. The moment its output is used to support a GxP decision, it falls under this policy and under <<FILL: SOP-ID for RPA / automation validation>>.

3. Scope

This policy applies to all RPA bots and configurable workflow automations built by anyone at <<FILL: COMPANY NAME>>, including business users, process owners, and quality personnel who are not members of the RPA center of excellence, on any licensed low-code or RPA platform. It does not change the validation requirements themselves, which are set in <<FILL: SOP-ID for RPA / automation validation>>; it sets the governance path that gets an automation to that requirement before it ever reaches production.

4. Definitions

• Citizen developer: a person who builds an automation on a low-code or RPA platform as part of their job, without being a member of the RPA center of excellence or a professional software developer.
• RPA center of excellence (CoE): the group accountable for the RPA platform, its standards, and the validation of higher-complexity automations.
• Intake: the point at which a proposed automation is declared before any logic is built against production data.
• Build track: the determination, made at intake, of whether an automation may be built by its citizen developer under supervision or must be handed to the CoE.

5. Roles

6. Policy statements (mandatory rules)

1. No automation touching a potential GxP record is built against production data before the intake request is filed and the GxP determination is run.
2. The GxP determination and the resulting risk assessment are not optional for a citizen-built automation; “it is just a small script” is not a basis for skipping them.
3. An automation assessed as low complexity (standard platform activities only, no custom selectors, code, or calculation) may be built by its citizen developer under the supervised track, provided the developer has completed the training in section 7 and a named QA approver signs off before go-live.
4. An automation assessed as higher complexity (custom selectors, scripted logic, calculation, decision branches, or deletion), or assessed high risk on any factor, is handed to the RPA center of excellence for the full validated lifecycle regardless of who proposed it.
5. Every automation, regardless of track or GxP determination outcome, is entered in the RPA bot inventory and system-dependency register, including a not-GxP automation with its rationale on file.
6. No citizen-built automation uses a person’s own login as its service account; credential provisioning follows the same vaulted, least-privilege standard as any CoE-built bot.
7. An automation discovered operating in production without having gone through intake is treated as a governance gap, not a technical bug: it is brought under control (determination run retroactively, register entry created, risk assessed) and the gap itself is logged for trend review.
8. Citizen developers do not bypass intake by labeling a regulated-record automation a “personal productivity tool” or a “pilot.”

7. Training

A citizen developer completes role-specific training before building any automation against a regulated system, covering at minimum: how to write a negative requirement, why an exception has to stop the automation rather than let it guess or retry silently, the difference between “it worked on my test case” and “it is validated,” and how to file an intake request. See training program for GxP roles for scoping that kind of role-specific curriculum. Training completion is a precondition for the supervised build track, not a recommendation.

8. Compliance and exceptions

Any exception to this policy (for example, an urgent automation needed before the full intake cycle can complete) requires written QA approval, a documented interim risk control, and a committed date to complete the determination and, if in scope, the validation. An exception is never silent and never open-ended.

9. References

21 CFR Part 11 and EU GMP Annex 11: the basis for validating any automation that creates, modifies, or moves GxP records, regardless of who built it. ISPE GAMP 5 (Second Edition, 2022): the risk-based, critical-thinking framework behind this policy’s build-track decision. FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026): the basis for scaling validation effort to risk rather than treating every automation identically. ISPE Pharmaceutical Engineering, “A GAMP Approach to Robotic Process Automation” (Wyn and Canterbury, May/June 2020): industry guidance on categorizing RPA platforms, bots, and automation logic.

Confirm the current version of each reference before issue.

10. Revision history

11. Approvals

Filled specimen

Illustrative intake decision recorded under this policy.

A second proposal from the same analyst six months later, a bot that writes the reportable result directly into the stability register used for the stability conclusion, produces a different outcome: in scope, risk assessed Medium, handed to the RPA center of excellence for the full validated lifecycle under <<FILL: SOP-ID>>, because writing to a record that supports a GxP decision is a different proposition from scheduling work.

Common inspection findings this policy prevents

• A citizen-built bot found running in production with no intake record and no GxP determination.
• A citizen developer who built a regulated-record automation with no training on negative requirements or exception handling.
• An automation labeled a “pilot” indefinitely to avoid the validation requirement.
• A bot register with gaps that line up exactly with the automations citizen developers built, because only CoE-built bots were ever entered.
• An exception to this policy that was never documented or never closed out.

How to adapt this policy

1. Set your document number, owner, and effective date in the header.
2. Define your own complexity thresholds for the supervised track versus the CoE track, consistent with your risk assessment method.
3. Point the training reference and the SOP-ID cross-references at your real procedures.
4. Decide where intake requests are filed (a ticketing system, a form, an intake meeting) and publish that path so it is genuinely easier to follow than to bypass.
5. Review the register periodically specifically for automations with no intake record, since that is the gap this policy exists to close.