IT Knowledge Topic

Robotics Process Automation (RPA)

September 2020

For Internal Use Only

Disclaimer
This document is for reference information only. The use of this material is optional. It does not modify the
audit methodology or guidance set out in the relevant manual.

If there is a mandatory/specified approach (or document) for your local member firm, please use that. If
you are unsure of your member firm’s policy for use of this document, then it is recommended you contact
your relevant Risk or Methodology team, including Department of Professional Practice resources.

This document may not cover all risks or considerations related to the specified topic. These materials are
provided for consideration and should be assessed for use, if appropriate, on an engagement-specific basis.

Wherever possible, audit work is documented directly in eAudit/KPMG Clara workflow. This document
should not be put on file.

This document is a resource for engagement teams to use to gain knowledge on Robotics Process Automation
(RPA) and general risk considerations related to RPA. This document should not be retained in the audit
workpapers.

Overview
This document provides a high-level overview of RPA and is split into three sections:
1. Overview of RPA,
2. General risk considerations when obtaining an understanding of RPA, and
3. Example Scenarios.

© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
Overview of RPA
As per KPMG Audit Methodology (KAM),1 RPA, often (IT) systems to extract structured data from documents,
referred to as “robotics” or “bots,” is an emerging make calculations, copy/paste, open or read emails and
technology used to automate manual tasks within a attachments, log into web applications, fill in forms,
workflow. These tasks are generally repetitive, low- move files and folders, and collect statistics to enable
judgment, and high-volume in nature and are often transaction processing.
associated with processes that follow explicit or
Examples include invoice processing, new customer
predictable rules and prescriptive steps. Bots generally
setup, employee onboarding/offboarding, payroll, fixed
rely on end users to trigger the activity (i.e., attended bots)
assets reporting, journal entry posting, and month-end
or run independently, enabling work to be scheduled or
reporting.
completed continuously (i.e., unattended bots).
Internal control over financial reporting
Many entities are using bots to automate transaction
processing and to perform certain control activities. Bots may be used in internal control over financial
Additionally, some internal audit (IA) departments are reporting in two ways:
using bots in an effort to enhance the effectiveness and
1. Programmed to perform a control activity from
efficiency of their activities.
beginning to end (i.e., with no human involvement
RPA may include: or interaction) or
— Class 1 – Basic process automation type 2. To form a part of a control activity or replace part of
(automation of entry-level, transactional, rule-based, a human element in a control activity. –
and repeatable processes);
For example, a bot can help verify that all journal
— Class 2 – Enhanced process automation (technology entries were approved by an independent reviewer
that enables use of structured and some before posting (in accordance with company policy).
unstructured data to support elements of self- Using a query, the bot identifies all journal entry activity
learning, e.g., Chat BOTS); and for a specified date range and places the list into Excel.
The bot then identifies if there are any conflicts (e.g.,
— Class 3 – Cognitive automation (decision support
a journal entry that includes the same poster/reviewer)
and advanced algorithms to allow automation of
by summarizing the information using pivot tables.
processes that are more cognitive in nature, e.g.,
IBM Watson). IA function
Based on the current usage and implementation of 1. Use of bots to automate control testing (e.g., three-
RPA at most audit entities, this document only covers way match, reconciliations).
considerations relevant to Class 1 RPA. Even though a
2. U
se of bots for project management and workpaper
lot of the considerations noted in this document may
documentation (e.g., creation of audit programs,
apply to Class 2 and Class 3 RPA, there may be other
lead sheets).
considerations that are not covered in this document.
Below are a few illustrative examples of how entities
are using RPA:
Transaction processing
The processing of certain transactions may require
information to be obtained from different sources, both
internally and externally. Bots can be programmed to
obtain information from various information technology

1
KAM 42, “Appendix 3 – Robotics process automation,” par. 9026.

© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
General risk considerations when obtaining an understanding of RPA
As part of our risk assessment procedures, we obtain
an understanding of financial reporting processes,
including the overall IT environment and information
systems, and the flow of transactions. While the
identification of risks and controls within IT is not a
separate evaluation, IT considerations in planning are
generally consistent for both traditional IT applications
and RPA tools. In many cases, bots perform the same
tasks as humans, and thinking through how a bot
replaces the human element in a process or control
may help us frame our response to the identified risks.
Obtaining a thorough understanding of management’s
RPA program is fundamental to gaining a complete and
accurate understanding of the risks introduced by the
RPA program. An effective way to understand where
risks are introduced by the broader RPA program is for
the audit team, including information risk management
(IRM) and other IT and technology resources, where
applicable, to conduct a meeting with key stakeholders
to discuss each component of the entity’s RPA
operating model. Key stakeholders may include:
— The Chief Financial Officer (or finance-level contact),
— Relevant IT personnel,
— IA, and
— Others, as necessary.
The following are the general categories of risks that
may apply to an entity implementing RPA:
Governance and strategy
Management, with board of director oversight, plays a
key role in establishing the right control environment
for engagement with new technologies. The COSO
framework can provide a structured approach to
identifying relevant risk, determining appropriate
control activities, and generating relevant, quality
information to be used in evaluating operational
objectives association with automated technologies.
As part of assessing the risk associated with
management of the RPA program, it may be
necessary to obtain management’s operational plan
and implementation protocols and to understand the
project management and oversight responsibilities.
Additionally, we consider:
1. Robustness of management oversight, including
risk identification, evaluation and mitigation;
© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
2. Standardization of automation policies and
procedures;
3. Level of business and IT involvement throughout
the automation lifecycle;
4. A
ppropriateness of management’s risk assessment
activities designed to identify the new process-level
risks introduced or altered by the introduction of
RPA technologies; and
5. Key performance indicators or key risk indicators
used to monitor and assess ongoing operation of
the RPA program.
Use of third-party vendors
Third-party vendor risks may arise when an entity
enters into a business processing outsourcing
organization arrangement. Understanding the
contractual arrangement (e.g., governance, user
acceptance protocols, and approvals), whether a SOC
report or other attestation report is provided over
the automation services delivered by the third party,
and how the entity satisfies itself that the third-party
service provider follows appropriate controls and
governance protocols can help to identify relevant
risks. Risks can also relate to data confidentiality,
compliance with the contractual arrangement, and data
ownership and access.
Program development
Program development risks may arise from program
design, configuration, and system capabilities.
These risks may include inappropriate access to the
development platform or the RPA solution, insufficient
underlying configuration, incomplete data migration
when data is moved and stored in a separate data
warehouse and lack of segregation of duties between
developers and the production environment.
Due to the nature of RPA tools (i.e., rapid
development), some entities allow automations
to be built by developers directly in the production
environment. When this is the case, understanding
who has access to develop and migrate bots into
production and how the entity addresses these risks
would be relevant. We gain an understanding of the
approval, testing, and post implementation review
process the entity understands to validate that the bot
is operating as intended.
General risk considerations when obtaining an understanding of RPA
Change management knowledge of the bot’s operating process (e.g.,
how data is entered, stored, manipulated, extracted,
Change management risks may arise when entities
and exchanged) is also relevant. For instance, if a
do not develop and follow a consistent change
bot posts journal entries using data from an Excel
management workflow and approval process.
spreadsheet that is housed in a shared internal
Understanding an entity’s process to implement
folder or on SharePoint, do the business users know
changes is important as the types of changes
where the data is pulled from? If so, this could pose
associated with RPA may not always follow an existing
a risk if users modify the Excel spreadsheet to cause
change control process. Understanding who has
fraudulent or inaccurate journal entries to be posted.
access and authority to make changes and migrate
In these instances, consider the nature and source of
the changes into production, the frequency at which
information used and who has access to change or edit
changes are made (e.g., periodic on a schedule or ad
that information.
hoc), and whether certain types of changes fall outside
the process (e.g., debugging) is important. Change Common controls used by entities to address access
control risks may be greater where an agile change risks include, but are not limited to:
management methodology (e.g., iterative approach to
— Access granted to privileged-level shared, generic,
design and development) is adopted over a traditional
service, and/or vendor accounts is appropriately
approach. In addition, considerations around changes
secured, and passwords to such accounts are
to other aspects of the core application may affect the
modified on a periodic basis (such as when
bot transaction flow.
employees with knowledge of the password leave
Common controls used by entities to address change the entity);
management risks include, but are not limited to:
— Management approves the nature and extent
— Application, server–level, and bot script changes of user-access privileges, including privileged
are appropriately approved and tested before being access, for new and modified user access to the
moved into the production environment; automation platform, including standard application
profiles/roles and critical financial reporting
— Access to implement changes into the application
transactions;
production environment is appropriately
restricted and segregated from the development — Access for terminated and/or transferred users to
environment; and the automation platform is removed or modified in a
timely manner in accordance with the documented
— Postimplementation reviews are performed after
policy;
the bot is implemented in production to verify that
the bot is operating as intended. — User access is periodically reviewed in accordance
with the established requirements in the
Access to programs and data
documented policy;
Access risks may also arise from inappropriate access
— Segregation of duties between developer and
to the configuration and output of bots, creating risks
administrators; and
related to accountability, segregation of duties, and
potential for unauthorized transactions. In addition — Access controls around the input configuration files
to traditional access risks, including access to and file output locations.
bot passwords, understanding of business users’

© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
General risk considerations when obtaining an understanding of RPA
Computer operations
Computer operations risks may arise from bots not
functioning consistently or as planned. Understanding
how bot activity is logged, tracked, and reviewed to
determine if the bot is functioning as intended helps
identify risks requiring an audit response. For instance,
some third-party tools have audit log functionality (e.g.,
tracks bot log-ins and changes to code and passwords).
Risk can be mitigated if this functionality is available,
and logs are retained and reviewed.
In addition, bots generally extract data from various
systems, making the effective operation of the bot
dependent on each system. Understanding system
dependencies, the entity’s business continuity
plan, including whether the entity can perform
tasks manually to address system scheduling or
performance, is necessary for properly identifying
risks. For example, if the entity does not have effective
computer operations controls, then a risk exists that a
bot could fail to process transactions appropriately.
Common controls used by entities to address
computer operation risks include, but are not limited to:
— All system application jobs (including, but not
limited to interfaces, batch processes, automation
processing, and data loads) are monitored for
exceptions and stakeholders are alerted if jobs
are not run to completion; unsuccessful jobs are
documented and followed up to resolution;
— Logging is enabled within the system, and logs are
monitored or audited on a regular basis to detect
unauthorized or inappropriate activity;
— Backup of critical information, including bot logic,
is performed regularly and stored off-site or on-
site in a fireproof safe or room; testing of backup
restoration is performed periodically;
— Business continuity plans are in place and
documented for business critical automations.
End-user consideration risks
Understanding end-user interaction with a bot, or data
used by a bot, is important to understanding end-user
risk. If a bot relies on a report that can be manipulated
subsequent to extraction, management needs to
identify process risk points and controls related to
end-user computing of the information. There may be
additional risks to address if the bot is housed on an end
user’s desktop, as the environments may not be subject
to the same level of rigor and structure as applications
processed in a more centrally controlled environment.
Considerations when IA uses bots
IA may use RPA to execute their work (e.g., in control
test work) and/or IA performs testing of an entity’s
process that relies on RPA for transaction processing.
Up-front planning and communication with IA is
integral to obtaining an understanding of how they use
RPA and how that might alter the nature, timing, and
extent of our reliance on internal audit’s test work.
The following are considerations when using the work
of IA to obtain audit evidence or in a direct assistance
capacity:
Using the work of IA (risk assessment or reliance)
When IA uses bots in the performance of its own test
work and we plan on using that work, determine how
IA satisfied itself that the bot’s configuration and related
output is reliable. This can be accomplished by obtaining
an understanding of the RPA program policies and
implementation protocols, including how IA satisfies itself
that the bot is operating as intended, and determining if
the bot was subject to such procedures. In some cases,
this understanding arises if IA utilizes the same RPA
governance structure as the rest of the organization.
When IA uses bots for its purposes, we understand
how the automation is designed and whether there are
appropriate validation procedures to confirm the data
used by the bot and the related output is accurate and
complete. Often, IA is using a bot to replace manual
activities and IA subsequently verifies or reviews
the bot’s work. Therefore, obtaining a thorough
understanding of how the bot impacts IA’s procedures
is necessary when evaluating the effect of the internal
auditor’s use of bots on our audit strategy.
When reperforming the work of the IA function, we
validate the conclusions reached by IA, including
examining original source documentation, regardless
of whether the source documentation was pulled by a
human or a bot, and consider the nature and extent of
procedures necessary to validate the bot is configured
appropriately to perform its intended function.
.

© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
General risk considerations when obtaining an understanding of RPA
Reperformance is a matter of professional judgment:
— If a RPA tool was recently implemented, consider
the increased risks that accompany new IT
applications, and the impact to the nature and
extent of our audit procedures, which may include
increasing the level of reperformance when a
control or substantive procedure uses automation
— Documentation of our reperformance
considerations includes our consideration of RPA.
Our documentation addresses how IA’s work was
properly planned, performed, and documented,
including any RPA-related considerations.
Using IA in a direct assist capacity (if permitted by
local member firm policy)
A thorough understanding of how RPA is integrated
into the process is critical to helping to identify, assess,
and respond to risks. Therefore, we exercise caution
when using IA to assist in testing processes that
involve RPA at an entity. The steps generally require
direct engagement team involvement:
— Understanding the flow of transactions in processes
that use RPA, including how the transactions are
initiated, authorized, processed, and recorded;
2
KAM 42, “Appendix 3 – Robotics process automation,” par. 9067.
3
KAM 15, “Computer assisted audit techniques.”
© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
— Determining RPA process risk points; and
— Identifying and obtaining an understanding of the
controls management implemented to address risks
the automation program presents.
In some instances, we may work collaboratively with
IA to identify testing areas when IA developed bots
that can be used to support our direct assist request.
If we determine the bot will meet the intended audit
objective and we plan to use the output as audit
evidence, we gain an understanding of how the tool
is governed and used, perform procedures to test the
design and consistent operation of the tool, and include
evidence within the audit file.
As per KAM,2 it may be helpful to think about RPA
tools similar to Software Audit Tools as they establish
the relevance and reliability of the information to be
used as audit evidence when IA uses a RPA tool. Refer
to KAM topic, “Computer assisted audit techniques”3
and the “Direct assistance: RPA tools used by internal
audit” document in KAM, which provides items to
consider when performing procedures to evaluate the
design and consistent operation of RPA tools.
General risk considerations when obtaining an understanding of RPA
Example questions for understanding RPA and 3) Control activities:
associated controls:
a. Is the platform subject to standard IT processes
This below list identifies risk considerations that may and policies or have separate/unique processes
be relevant when obtaining an understanding of the and policies been developed to support the
entity’s RPA operating model: automation program?
1) Control environment – defines the overall b. Does management have a formal SDLC process
automation vision and strategy: for creation of new bots?

a. Who is in charge of overall governance? Are c. Are leading practices for developing and testing
they integrated into the delivery model, including bots established?
providing risk oversight and direction on risk d. Automation impact to internal control over
identification, evaluation, and mitigation? financial reporting:
b. Has an overall automation vision and strategy i. Does scoping of key financial systems
been defined? Are policies, procedures, and include tools/transformation/middleware
guidelines in place to identify, prioritize, and technologies?
develop RPA tools? ii. How are underlying general IT controls
c. How is ownership and accountability of bots changing to address new technology
assigned? platforms?
d. Is IA involved in the integration of governance, iii. How is automation affecting business
risk, and control considerations throughout the process controls and reports relied on by
automation lifecycle? management?
e. What use cases are planned and what iv. If new automated controls are identified,
is management’s strategic roadmap to has the entity identified the appropriate
implementation? procedures to address and understand the
f. Training, tools, and enablement: system complexity and logic?

i. Does the entity’s automation program e. Segregation of duties (SOD):

contemplate whether the employees possess i. How has segregation been contemplated in
necessary competency and capabilities to the design of the access at the applications,
execute the RPA program? If no, how does operating system, and infrastructure layers?
the entity plan on acquiring this skill set? ii. Are traditional SOD conflicts affected by the
ii. What training offerings are available to upskill use of bots?
employees? iii. Do system IDs used by bots provide bot
2) Risk assessment: owners with additional access levels that
exceed the access the bot owners would
a. Has management evaluated the impact on its
otherwise possess?
processes as a result of introducing automation?
iv. Has management evaluated at the bot level,
b. What is the process management undertakes to
whether the level of access that the bots have
analyze new or altered process risk points and
on target systems present any SOD conflicts?
control activities?
f. Platform details:
c. Has management developed an integrated risk
and control framework that aligns with the RPA i. Does management have a list of the
operating model? infrastructure, operating system(s),
and application versions supporting the
d. Does management have a process to update
automation program?
control listings, process flow diagrams,
narratives, etc.? ii. Does management have a means to track
changes to the applications/platforms the
e. Are there new fraud risks that arise as a result of
automations support?
introducing automation?
f. How does RPA affect statutory, regulatory, or
contractual compliance?
© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
General risk considerations when obtaining an understanding of RPA
g. Automation design and development: whether the components of internal control are
i. What is the process the entity undertakes present and functioning?
to verify secure development and testing? e. Are control deficiencies evaluated and
Does testing verify that controls are designed communicated in a timely manner to those
effectively and operate as intended? charged with overall program governance?
ii. Who is responsible for evaluating automations 6) Third-party vendor-developed RPA tools:
and approving those automations prior to go-live?
a. If the company uses a third-party vendor, has the
h. Automation continuity: company performed a vendor assessment?
i. If implementation issues are encountered, b. Did the entity make any modifications to the tool
what is management’s process to resolve and delivered by the vendor?
minimize the impact on operations?
c. Does management or IA have the ability to
ii. In the event that the automation platform edit the source code of the third-party tool, and
suffers a shutdown, does the business have a therefore, manipulate the system configuration of
manual continuity plan in place? the tool and the relevant outputs? Consider using
iii. Is a process in place to back up bot logic? Is IRM to help verify whether the company has
recovery from backups tested periodically? modified or has the ability to modify source code.
i. Ownership: d. How often does the vendor release updates to
i. Does management use a third party or BPO the RPA tool? How will users of the application
as part of the delivery model? be notified of updates and how will the
application owner confirm all users are using the
1. Are SOC reports or other attestation
most current approved version?
reports provided over automation services
by the third party? e. Who is responsible for monitoring that all users
are on the current approved version?
2. How does management get comfortable
that third-party services follow controls and f. What is the client’s process to verify that third-
are appropriately governed? party vendor RPA tools do not get implemented
into their IT environment before the tool is
3. If the RPA uses data from external
validated?
sources, how does the entity determine
the reliability and data integrity of these g. Does the vendor provide a SOC report or other
external sources? attestation report? If so, has the engagement
4) Information and communication: team obtained and reviewed the report?
7) IA using RPA tools:
a. How is management tracking effectiveness and
return on investment? a. How does IA use the RPA tool?
b. How do learnings from previous implementations b. Does IA have the necessary skills and
optimize future program performance? competence to operate the RPA tool for its
5) Monitoring activities: intended function? What type of training is
provided to the end user(s)?
a. How does management verify that RPA tools are
c. How is the RPA tool accessed (i.e., installed on a
operating as intended?
laptop or web-based)?
b. Have key performance indicators (KPIs) or key
d. What type of population is the RPA tool applied to?
risk indicators (KRIs) been defined to assess
ongoing operation of the RPA program? How are e. What tasks is the RPA tool performing?
KPIs and KRIs being monitored? f. Is IA using preprogrammed tool functionality? If
c. How are KPIs and KRIs reported to key not, are they evaluating the design of the routine
stakeholders? each time it is being used?
d. Is management using appropriate combinations g. How does the engagement team plan on relying
of ongoing and separate evaluations to ascertain on the tools’ output?

© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
Example scenarios
The following examples illustrate the importance of
obtaining a thorough understanding of how bot activity
affects the entire process to evaluate the bot’s impact
on the audit.
Scenario #1: A bot initiates a bank reconciliation,
which is completed by a control operator. The bot
extracts bank statement information from the bank
website, enters the bank statement information
into Excel, and reads the ending balance. The bot
then extracts the book balance from the general
ledger and the outstanding checks from the treasury
system, compares the balance to the bank balance,
and calculates a difference. The control operator
then completes the reconciliation by validating that
the balances agree to supporting documentation,
and investigates the difference. In this case, the bot
replaced manual tasks; however, the bot activity was
likely not relevant to the audit because the control
operator manually reperformed the bot’s activities.
© 2020 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative
(“KPMG International”), a Swiss entity. All rights reserved. NDP111567A-1H
Scenario #2: A bot completes the same steps as
in scenario #1, but if the account can be reconciled
within a predetermined threshold, then no further
review is completed. If the cash account cannot be
reconciled within a predetermined threshold, then
the bot is configured to route the reconciliation to
a cash manager for review. In this case, the bot
activity replaces a manual control and is relevant to
the audit. We would need to test two controls: an
automated configuration control and/or other manual
control activity over cash reconciliations within the
predetermined threshold and the cash manager
review for those cash reconciliations outside the
predetermined threshold, including evaluating if the
supervisory controls were performed at the appropriate
level and how the cash manager determined the bot
pulled accurate and complete information.