RPA Audit: Auditing Robotic Process Automation
A bot is a user ID that runs code. Audit it like one.
Robotic process automation (RPA) is software that copies what a person does at a screen: logs in, reads a field, keys it into another system, clicks submit. ICAI's material defines its target as tasks that are manual, rule-based and repetitive, such as raising invoices from approved timesheets or updating KYC records.
For an auditor, the useful way to see a bot is as a user ID that runs code. It needs access rights, those rights need segregation, its logic needs change control, and its actions need a log. A bot that posts vendor invoices in a mid-size company's ERP is subject to the same questions as the clerk it replaced, plus a few new ones.
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
Risks and the Controls That Answer Them
Excess access
Example
A bot ID with both vendor-master and payment rights
Control to test
Least-privilege role design; bot IDs included in periodic access reviews and SoD analysis
Shared or exposed credentials
Example
Bot password stored in a script or spreadsheet
Control to test
Credentials held in a vault, rotated, not known to developers
Unapproved logic change
Example
A developer edits a posting rule directly in production
Control to test
Same change management as any application: request, test, approve, separate deployment
Silent failure
Example
A screen layout changes after an ERP upgrade; the bot keys data into the wrong field
Control to test
Exception handling, input and output reconciliations, alerts to a named owner
No audit trail
Example
Postings show the bot ID with no link to the triggering request
Control to test
Bot run logs retained and linked to source documents and approvals
Continuity
Example
Bots stop and no one remembers the manual process
Control to test
Documented fallback procedure and people able to run it
| Risk | Example | Control to test |
|---|---|---|
| Excess access | A bot ID with both vendor-master and payment rights | Least-privilege role design; bot IDs included in periodic access reviews and SoD analysis |
| Shared or exposed credentials | Bot password stored in a script or spreadsheet | Credentials held in a vault, rotated, not known to developers |
| Unapproved logic change | A developer edits a posting rule directly in production | Same change management as any application: request, test, approve, separate deployment |
| Silent failure | A screen layout changes after an ERP upgrade; the bot keys data into the wrong field | Exception handling, input and output reconciliations, alerts to a named owner |
| No audit trail | Postings show the bot ID with no link to the triggering request | Bot run logs retained and linked to source documents and approvals |
| Continuity | Bots stop and no one remembers the manual process | Documented fallback procedure and people able to run it |
An RPA Audit in Five Steps
- 1
Get the bot inventory
Every bot, its process, owner, systems touched, user IDs and schedule. Bots built by business teams outside IT are the usual gap.
- 2
Walk through one process end to end
Confirm what the bot does against its design document, including which decisions it makes and which it hands to a person.
- 3
Test access
Bot IDs against role design and SoD rules; who can start, stop or change each bot; how credentials are stored.
- 4
Test change management
Sample bot changes: approval, testing evidence, separation between the developer and the person deploying to production.
- 5
Test operation
Exception queues, reconciliations of bot output to source, run logs, and how failures were handled during the period.
What ICAI's Material Stresses
- check_circleGovernance: process owners and subject-matter experts, legal, risk and IT all involved; a centre of excellence for scaling.
- check_circleDeployment framework: aligned development and production environments, IT aware of every RPA-enabled process, and change management in place.
- check_circleTool selection risk: some products are little more than screen-scraping, which breaks when screens change and drives high maintenance.
- check_circleOperational risk: bots deployed without a clear operating model leave people unsure of their roles when a bot fails.
- check_circleBusiness continuity: the expectation that deployed bots need no maintenance is wrong; unhandled scenarios surface in production.
Quick practice on audit concepts. No signup.
Automated Does Not Mean Reliable
RPA follows rules exactly, which removes keying errors but also repeats a wrong rule on every transaction. Testing one instance of a correctly designed automated control can support reliance across the period only if change management and access over the bot are effective. That is why the general controls matter more here, not less.
How the DISA Assessment Test Tests This
No ICAI question bank is public; these patterns follow from the material.
- check_circleSuitability: which process suits RPA. Manual, rule-based, repetitive, standardised. A process needing judgement on each case is the wrong answer.
- check_circleRisk classification: ICAI groups RPA risks as strategy, tool selection, launch/project and operational/execution. Expect a scenario to classify.
- check_circleControl choice: a bot ID with conflicting rights calls for SoD review, not more bot monitoring.
- check_circleAudit impact: the material lists a need for new testing approaches and possible changes to the internal audit staffing model.
FAQs
What is RPA in auditing?expand_more
Robotic process automation is software that mimics a person's keystrokes and clicks to perform rule-based, repetitive tasks. Auditors both audit bots the client runs and sometimes use bots for routine audit steps.
What are the risks of robotic process automation?expand_more
Excess bot access, exposed credentials, unapproved logic changes, silent failures after system changes, weak audit trails and loss of the manual fallback. ICAI also lists strategy, tool selection and launch risks.
How do you audit an RPA bot?expand_more
Inventory the bots, walk through each process, then test bot access and SoD, credential storage, change management over bot logic, exception handling and run logs.
Is a bot an IT general control or an application control?expand_more
The bot performs application-level processing, so its rules act like application controls. Reliance on them depends on IT general controls over the bot: access and change management.
Next steps
- Change Managementarrow_forward
- ITGC vs Applicationarrow_forward
- Logical Accessarrow_forward
- AI & ML Auditarrow_forward
Assessment Test format, timed and scored.