Robotic process automation is software that does what a person does at a keyboard: logs into applications, copies data between them, fills forms, runs reports, compares files and sends emails, following rules, without changing the applications it touches. For internal audit it is two subjects. The first is using bots inside the function, where they take over the evidence gathering, reconciliation and monitoring that consume staff hours and produce a repeatable, documented result. The second is auditing the organisation’s own automation program, where hundreds of bots now hold credentials, move money and data, and operate controls that used to be performed by people, with governance that often lags the build. This guide covers both: where bots pay off in the function and where they do not, how to build one properly with the controls that make its output audit evidence, the economics, how RPA now sits beside generative and agentic AI, the control framework for an enterprise automation program, a twelve-test audit of that program, the findings that recur, and a worked engagement at an illustrative bank that did both in the same year.
It replaces the earlier version at this address and sits with the generative AI across the audit lifecycle guide, the auditing agentic AI guide and the AI governance audit guide, which cover the technologies that have grown up around the bots.
In this guide
- What RPA is and is not
- Using bots in the audit function: where they pay off
- Building a bot that produces audit evidence
- The economics
- RPA beside generative and agentic AI
- A first-year roadmap for the function
- Skills the function needs
- The control framework for an enterprise automation program
- Auditing the automation program: twelve tests
- The findings that recur
- Worked example: Thornwick Bank builds six bots and audits 140
- Frequently asked questions
- Related guides
What RPA is and is not
| Technology | What it does | Where it fits | What it is not |
|---|---|---|---|
| Robotic process automation | Rule-based bots that operate applications through their user interfaces or APIs, following a scripted workflow; attended (triggered by a person) or unattended (scheduled) | Repetitive, rule-based, high-volume tasks across systems that do not integrate | Intelligent; it cannot handle what the rules did not anticipate |
| Intelligent document processing | Extraction of data from documents (invoices, statements, contracts) using recognition and machine learning, usually feeding a bot | Unstructured inputs to a structured process | Deterministic; extraction has an error rate that has to be managed |
| Workflow and integration platforms | Orchestration of tasks across systems through connectors and APIs | Processes where the systems have APIs | A replacement for RPA where interfaces do not exist |
| Generative AI assistants | Language models that draft, summarise, classify and answer questions from context | Judgment-adjacent tasks with human review | Reliable for deterministic tasks; the generative AI guide |
| Agentic AI | Models that plan and execute multi-step tasks across tools, deciding the steps | Tasks with variable paths | A bot: it acts on its own interpretation, which is the audit problem the agentic AI guide addresses |
The distinction matters for both subjects. A bot does exactly what it was scripted to do, every time, which is why its output can be audit evidence and why its failures are systematic rather than random. An agent decides what to do, which is why its output needs review and why its failures are unpredictable. Most enterprise automation programs now contain all of the above under one centre of excellence, and the audit program below treats them as one population with different controls by type.
Using bots in the audit function: where they pay off
Bots pay off in the function where the task is repetitive, rule-based, cross-system and needed on a cycle, and they fail where the task needs judgment or changes every time. The table lists the uses that have worked in functions of twenty to two hundred people, in rough order of value.
| Use | What the bot does | Hours it replaces | Watch-out |
|---|---|---|---|
| Evidence collection | Logs into systems on a schedule, runs the standard reports (user lists, change logs, exception reports, reconciliations), saves them with a hash and a timestamp to the audit file | The largest: the request-and-chase cycle for every engagement | Report parameters must be fixed and documented; the bot’s access is read-only and reviewed |
| Continuous monitoring | Runs the function’s analytics (journal entry tests, access reviews, duplicate payments, segregation-of-duties conflicts) monthly and routes exceptions | Analyst hours; it turns an annual test into a monthly one | Exceptions need an owner or the monitoring becomes noise |
| Reconciliation and completeness | Compares populations across systems (ledger to sub-ledger, HR to access, inventory to counts) and lists differences | Fieldwork hours on completeness | Matching rules documented and tested; differences explained by a person |
| Issue follow-up | Sends status requests, collects responses and evidence, updates the tracker, escalates overdue items by rule | Administrator hours; it enforces the issue tracking cadence | The bot updates status; it does not validate |
| Regulatory and committee reporting | Assembles the quarterly pack’s standard tables from the tracker and the plan | Manager hours before each meeting | A person writes the commentary |
| Sampling and workpaper setup | Draws samples with the documented method, creates the workpaper shells with the population and sample recorded | Senior hours; it enforces the sampling memo standard | Sampling parameters are the auditor’s decision |
| Confirmation and survey handling | Sends and tracks confirmations and surveys, chases non-responses, compiles results | Staff hours | Responses still read by a person |
Where bots do not pay off: anything that needs judgment (rating a finding, assessing an explanation), anything that changes each engagement (scoping, interviews), and anything with an unstable interface, because a bot that breaks every time a vendor redesigns a screen costs more than the hours it saved.
Building a bot that produces audit evidence
A bot built for the function has to meet the standard the function applies to anyone else’s automation, because its output goes into the file and a quality assessor or an examiner will ask how the function knows the bot did what it says. The documenting analytics as evidence guide gives the standard for queries and scripts; the table applies it to a bot.
| Stage | What to do | Evidence produced |
|---|---|---|
| Candidate selection | Score tasks on volume, rule stability, interface stability, systems crossed and hours; build the highest-scoring first | Candidate register with scores |
| Specification | Document the process step by step with the rules, exceptions, inputs, outputs and the systems and accounts touched; agree it with the process owner | Process definition document |
| Design | Separate configuration from logic; log every step with inputs, outputs and timestamps; handle exceptions by stopping and routing, never by guessing; use a dedicated bot account with least privilege | Design document; access request |
| Build and test | Unit tests per step; a test run on a known dataset with expected results; a parallel run against the manual process for at least one cycle | Test plan and results; parallel-run comparison |
| Approval | The function’s methodology owner approves the bot for use as evidence; the specification and tests are filed | Approval record |
| Operation | Scheduled runs with logs retained; exceptions routed to a named person; output hashed and stored in the audit file with the run log | Run logs; evidence files with hashes |
| Change control | Any change to the bot or to the underlying applications triggers re-test; versions retained | Change log; re-test evidence |
| Periodic review | Quarterly review of runs, exceptions and output accuracy against a manual re-performance sample | Review record |
Two design rules protect the evidence value of every bot in the table. The bot never has write access to the system it collects from, so its existence cannot be the cause of what it reports; and the bot’s output goes into the file with the run log and a hash, so a reviewer can tie the evidence to the run that produced it and see that it has not been altered. A function that cannot show both to a quality assessor has a labour-saving tool, not an evidence source, and should say so in its methodology.
The economics
A bot costs licence, build time, infrastructure and maintenance, and saves hours. The arithmetic most functions find: a bot that takes 80 to 150 hours to specify, build and test, costs a licence that most organisations already hold for enterprise use, and needs 10 to 20 per cent of its build effort a year in maintenance, pays back within the first year if it replaces more than 300 hours of recurring work, and does not if it replaces fewer than 100 or if the interfaces it depends on change more than twice a year. The hidden cost is maintenance: every application upgrade can break a user-interface bot, which is why API-based automation is preferred where an API exists and why the candidate score weights interface stability. The function’s budget case to the audit committee should show the hours replaced, the maintenance assumed, and the evidence-quality benefit, which the committee values more than the hours.
The licence question deserves one sentence: most functions use the organisation’s enterprise platform rather than buying their own, which keeps the bots under the centre of excellence’s controls and makes the function subject to the same inventory, identity and change standards it audits, which is as it should be.
RPA beside generative and agentic AI
Since 2023 the automation vendors have added language-model capabilities to their platforms, and the combination has changed what a bot can do and what it can be trusted to do. A rule-based bot can now call a model to classify a document, summarise an exception or draft an email; an agent can decide which bots to run. For the function the practical rule is a boundary: the deterministic part (collect, compare, compute, route) is bot work and produces evidence; the judgment-adjacent part (classify, summarise, draft) is model work and produces a draft for review under the function’s AI usage policy; and nothing an agent decides on its own enters a file as evidence. The same boundary is the audit criterion for the organisation’s program, where the risk is an agent given the credentials of a bot.
A first-year roadmap for the function
Functions that succeed with automation start small, prove the evidence standard on one bot and grow from there; the ones that fail buy a platform and look for uses. The table is a first-year plan for a function of twenty to fifty people with access to the organisation’s automation platform.
| Quarter | Actions | Deliverable | Decision at the end |
|---|---|---|---|
| Q1 | Score the recurring tasks; choose two candidates with stable interfaces and high hours; agree the evidence standard with the methodology owner; set up a dedicated bot identity and vault access | Candidate register; evidence standard; identity | Proceed with the two builds |
| Q2 | Specify, build and test the two bots; parallel-run for one cycle; file the specifications and test results | Two bots in parallel run | Approve for evidence use or rework |
| Q3 | Operate the two; build the next two from the register; add a quarterly review of runs and exceptions; report hours replaced | Four bots; first review | Continue or pause based on maintenance load |
| Q4 | Add continuous monitoring on one analytic; present the economics and the evidence-quality case to the audit committee; plan year two | Committee paper; year-two plan | Budget and scope for year two |
Skills the function needs
Automation in the function needs three skills that most functions have in part: process analysis (writing the specification a developer can build from, which is the auditor’s walkthrough discipline applied to the function’s own work), low-code development (most platforms are learnable by an auditor with analytics skills in a few weeks, and the organisation’s centre of excellence will usually train the function), and evidence discipline (the analytics evidence standard applied to the bots). Functions without the second skill borrow it from the centre of excellence or a co-sourcing provider for the first builds and learn by maintaining them; the skills guide places the capability in the competency matrix and the courses guide lists where the platform training comes from.
The control framework for an enterprise automation program
An enterprise program with hundreds of bots is an application portfolio with unusual properties: the bots hold human-grade credentials, act across systems at machine speed, and were often built by business staff outside the technology change process. The framework below is what examiners, external auditors and the SOX program expect to find, and the end-user computing guide covers the uncontrolled tail that preceded it.
| Domain | Controls expected | Why it matters | Where it is weak |
|---|---|---|---|
| Governance and inventory | A centre of excellence or equivalent; a complete inventory of bots with owner, purpose, systems, credentials, criticality and whether it performs a control | You cannot audit what is not listed; bots built by the business are often absent | Inventories maintained by the platform licence count, not by business ownership |
| Identity and access | Dedicated bot identities with least privilege; credentials in a vault, rotated, never embedded; privileged bots treated as privileged users; access reviews including bot accounts | Bots are the ideal credential theft target: always on, broad access, no suspicion | Bots running under a developer’s account; passwords in scripts |
| Development and change | Bots under the change management process: requirements, design, testing on representative data, approval, deployment by someone other than the developer, versioning | A change to a bot is a change to a control | Business-built bots changed in production by their builders |
| Exception handling and monitoring | Every bot stops and routes on unexpected conditions; run logs retained; failures alerted to a named owner; reconciliation of expected to actual runs | A bot that keeps going past an unexpected screen processes garbage at speed | Exceptions suppressed to keep the bot running |
| Bots that perform controls | Identified in the inventory and the control framework; the bot’s logic tested as the control’s design; its operation evidenced by logs; a human review where the control requires judgment | The SOX program and the regulators test the bot as the control | Controls assigned to a person who no longer performs them because the bot does, with no one testing the bot |
| Data and privacy | Data the bot touches classified; logs that do not store sensitive fields; retention rules | Bots copy data between systems and logs | Logs full of personal data |
| Resilience | Critical bots identified; failure impact assessed; manual fallback documented; disaster recovery for the platform | A bot that runs the daily funding file is critical infrastructure | No one knows what happens if the platform is down |
| Decommissioning | Bots retired with credentials removed and inventory updated | Orphan bots with live credentials | Retired bots still running on a schedule |
| AI components | Model components inventoried with the bot; accuracy monitored; human review where required; the AI governance controls | The boundary between bot and agent | A language model given the bot’s credentials to decide the steps |
The framework applies with different weight by bot type. Attended bots that a person triggers and watches carry less identity and exception risk and more risk of inconsistent use; unattended bots on schedules carry the full set; bots that move money or post to ledgers are treated as payment and journal controls with the approvals those require; and bots with AI components add the model controls. A program that applies one standard to all of them either over-controls the attended tail or under-controls the critical few, and the inventory’s criticality field is where the weighting is recorded.
Auditing the automation program: twelve tests
| # | Test | Method | Typical finding |
|---|---|---|---|
| 1 | Inventory completeness | Reconcile the inventory to platform licences, service accounts, scheduler entries and a survey of business units | Bots in production not on the inventory |
| 2 | Governance | Charter, roles, approval process, reporting to a risk forum | No forum sees the portfolio |
| 3 | Bot identities and credentials | Sample bots for dedicated accounts, vault storage, rotation, least privilege; search scripts for embedded credentials | Credentials embedded; bots on human accounts |
| 4 | Privileged bots | Identify bots with privileged access; test their controls against the privileged access standard | Privileged bots outside the privileged access program |
| 5 | Access reviews | Confirm bot accounts are in the periodic access review with a human owner certifying | Bot accounts excluded from reviews |
| 6 | Change management | Sample bot changes for requirements, test evidence, approval, segregation of deployment | Business developers change production bots |
| 7 | Testing quality | Review test plans and data for a sample; check negative and exception cases | Happy-path testing only |
| 8 | Exception handling and logging | Review bot designs for stop-and-route; test logs for retention and for a sample of failures and their resolution | Exceptions suppressed; logs overwritten |
| 9 | Bots as controls | Map bots to the control framework; for a sample, test the logic as control design and the logs as operation; confirm the human review where required | Controls performed by bots with no owner testing them |
| 10 | Data handling | Classify data touched by a sample of bots; inspect logs for sensitive fields; check retention | Personal data in logs |
| 11 | Resilience | Critical bot list; fallback procedures; platform recovery test | No fallback for critical bots |
| 12 | AI components | Inventory of model components; accuracy monitoring; human review points; agent credentials | An agent with unrestricted bot credentials |
The work program guide covers documentation. The most informative tests are the inventory reconciliation (the gap between the inventory and reality is the program’s maturity in one number), the credential search, and the bots-as-controls mapping, because each finds something the program’s own reporting does not show.
Scoping the program audit depends on the program’s size. Under fifty bots, the whole population can be inventoried and the critical bots tested individually in a few hundred hours; above that, the audit tests the program’s controls with samples and reserves individual testing for the bots that move money, post to ledgers or perform controls in the regulatory and financial reporting frameworks. Either way the engagement starts with the reconciliation, because every later test depends on knowing the population.
The findings that recur
| Finding | Root cause | Fix that holds |
|---|---|---|
| Inventory incomplete | Business-built bots; no registration requirement | Registration enforced through platform access; periodic reconciliation |
| Credentials embedded or shared | Speed of build; no vault integration | Vault integration mandatory; scanning of scripts |
| Bots on human accounts | Easiest way to get access | Dedicated identities; human-account bots blocked |
| Bots changed in production by builders | Citizen-developer model without change control | Promotion through environments; separation of build and deploy |
| Exceptions suppressed | Bots measured on completion | Stop-and-route standard; failure metrics reported |
| Controls performed by bots nobody tests | Control ownership not updated when the bot was built | Control framework updated; bot logic tested annually |
| Orphan bots | Owners leave; bots keep running | Owner confirmation quarterly; decommissioning process |
| Agents given bot credentials | AI features enabled on the platform without a decision | Agent use approved separately; scoped credentials; human checkpoints |
Worked example: Thornwick Bank builds six bots and audits 140
Thornwick Bank is the illustrative sixty-two-billion-dollar bank used across this site, with a twenty-four person internal audit function and a capital markets business. In FY27 the function did both halves of this guide: it built six bots for its own work, and it audited the bank’s automation program, which had grown to 140 bots under a centre of excellence in three years.
| Part | What was done | Result |
|---|---|---|
| Function bots: candidate selection | Thirty-one recurring tasks scored; six selected: evidence collection for the quarterly access reviews, monthly journal entry analytics, HR-to-access reconciliation, issue follow-up, committee pack tables, and confirmation tracking | An estimated 1,900 recurring hours a year in scope |
| Function bots: build | Specifications agreed with system owners; dedicated read-only bot identity; vault credentials; step logging; stop-and-route exceptions; parallel runs for one cycle each; approval by the methodology owner; evidence stored with hashes | Five of six approved for evidence use; the confirmation bot withdrawn after the vendor portal changed twice in a quarter |
| Function bots: first-year economics | Build 610 hours; maintenance 90 hours; hours replaced 1,650 | Payback in the first year; the monthly journal entry test replaced an annual one |
| Program audit: inventory | Inventory of 140 reconciled to 172 service accounts and 158 scheduler entries; 23 bots found in production unregistered, 11 of them in operations | High |
| Program audit: credentials | Script scan found embedded credentials in 17 bots; 9 bots ran on former employees’ accounts; bot accounts excluded from the quarterly access review | High |
| Program audit: change | Citizen developers changed production bots directly; no test evidence for 31 of 40 sampled changes | High |
| Program audit: bots as controls | 28 bots performed controls in the SOX and regulatory reporting frameworks; 19 still had a human named as the control performer; none had its logic tested | High |
| Program audit: exceptions and AI | Twelve bots configured to continue on error; a document-processing model fed three payment bots with no accuracy monitoring; the platform’s agent feature enabled for two teams with the bots’ credentials | Medium to High |
Management’s actions: registration enforced through platform access and the 23 bots registered or retired; vault integration made mandatory with a script scan at deployment; dedicated identities for every bot and bot accounts added to the access review; a promotion path through environments with deployment separated from build; the control framework updated with bots as performers and annual logic testing added to the SOX program; a stop-and-route standard with failure metrics; accuracy monitoring for the document model; and agent use suspended pending a separate approval process with scoped credentials and human checkpoints. Internal audit validated the actions over two quarters under the issue validation standard and added the inventory reconciliation to its continuous monitoring, run by one of its own bots.
Frequently asked questions
What is RPA in internal audit?
Two things. Using software bots inside the audit function to collect evidence, run analytics and reconciliations, follow up issues and assemble reports, on a schedule, with logs that make the output audit evidence. And auditing the organisation’s own automation program: the inventory, identities and credentials, change management, exception handling, the bots that perform controls, data handling, resilience, decommissioning and the AI components now attached to the bots.
Where does RPA pay off in an audit function?
In repetitive, rule-based, cross-system tasks needed on a cycle: evidence collection from standard reports, continuous monitoring analytics, population reconciliations, issue follow-up, committee pack tables, sampling and workpaper setup, and confirmation tracking. It does not pay off for judgment (ratings, assessments), for work that changes every engagement (scoping, interviews), or where the interfaces it depends on change often.
How can a bot’s output be used as audit evidence?
When the bot is built to the standard the function applies to any automation: a documented specification agreed with the process owner, a design that logs every step and stops on exceptions, tests on known data and a parallel run against the manual process, approval by the methodology owner, operation under a dedicated least-privilege identity with retained logs, hashed output stored with the run log, change control with re-testing, and periodic review against manual re-performance.
What are the biggest risks in an enterprise RPA program?
Bots that are not on the inventory; credentials embedded in scripts or bots running on human accounts; privileged bots outside the privileged access program; bots changed in production by their builders without testing; exceptions suppressed so the bot keeps running; bots that perform controls nobody tests; orphan bots with live credentials after their owners leave; personal data in logs; no fallback for critical bots; and AI agents given the bots’ credentials.
How does internal audit audit RPA?
With twelve tests: inventory completeness by reconciliation to licences, service accounts and schedulers; governance; bot identities and credentials including a script scan; privileged bots; access reviews including bot accounts; change management; testing quality; exception handling and logging; bots mapped to the control framework and tested as controls; data handling; resilience; and AI components. The inventory reconciliation, the credential scan and the bots-as-controls mapping find what the program’s own reporting does not.
What is the difference between RPA and agentic AI?
A bot follows a script exactly, so its output is predictable and can be evidence, and its failures are systematic. An agent plans and executes steps from its own interpretation, so its output needs review and its failures are unpredictable. The boundary matters for both subjects: in the function, nothing an agent decides enters a file as evidence; in the organisation, an agent given a bot’s credentials is the finding.
Does a bot that performs a control change the SOX program?
Yes. The bot’s logic is the control’s design and must be tested as such; its logs are the evidence of operation; the control framework must name the bot as the performer and a person as the owner; changes to the bot are changes to the control under change management; and where the control requires judgment, the human review step must remain and be evidenced. Controls still assigned to a person who no longer performs them because the bot does are the common finding.
What should the budget case for audit bots say?
The recurring hours replaced, the build and maintenance hours assumed (with maintenance at 10 to 20 per cent of build a year and higher for user-interface bots), the licence position, the payback period, and the evidence-quality benefit: tests run monthly instead of annually, populations instead of samples, and output a quality assessor can verify. Audit committees fund the last point more readily than the hours.
Related guides
- Generative AI Across the Audit Lifecycle — the model side of automation in the function
- Auditing Agentic AI — when the system acts rather than answers
- Auditing AI Governance — the framework for the AI components
- AI Usage Policy for Internal Audit — the rules for model-assisted work
- Documenting Analytics as Audit Evidence — the evidence standard bots must meet
- SQL for Auditors — the queries bots run
- How to Audit End-User Computing — the uncontrolled automation that preceded RPA
- SOX 404 Explained — bots as controls in the ICFR program
- Audit Issue Tracking — the follow-up cadence a bot can enforce
- The Sampling Memo — the standard a sampling bot enforces
- Internal Audit Work Program — documenting the twelve tests
- Data Analytics and Continuous Auditing category — every automation and analytics guide in one archive
Leave a Reply