Are you ready to deal with the business risks arising from robotic process automation? Alex Hunt outlines what to consider with the adoption and assurance of RPA.
Robotic process automation is also commonly referred to as RPA or bots. It can range from simple process automations, such as invoice processing and data entry, to more complex and detailed processing, such as segregation of duty checks, supplier risk profiling or even advanced bots that use artificial intelligence to automate business decision-making.
RPA software is in widespread use across organisations of different sizes and industries. Due to the technical nature and involvement of third-party tools or service providers, however, management must deal with an increasingly complex set of risks and also design appropriate controls for their use.
The main benefit of automation is often financial but automation can also support other areas, such as customer experience, operation of key controls and regulatory reporting.
We've often seen RPA coordinated through a single team or centre (automation centres of excellence or RPA enablement centres) that manages the development and deployment of RPA projects across the whole organisation. Organisations are also partnering with specialist third-party providers to help deliver their RPA programmes. This is because it's difficult to have the resources and knowledge internally to deliver an RPA programme by itself, or be able to recruit externally to fill all the required roles and skillsets.
Service delivery models therefore vary greatly depending on the appetite to outsource technical or maintenance responsibilities. Arrangements can range from having a third party in a supervisory capacity to partnering with multiple service providers to acquiring an in-house team.
Whatever model is adopted, a clear methodology and roadmap is necessary to support the RPA programme, alongside a clearly defined shared responsibility model with any third-party provider. This will help reduce dependency on any third parties and minimise the risk of key-person dependency within the in-house team.
The most viable areas for automation – and fruitful in terms of benefits realisation – can be seen in the finance and compliance functions of an organisation. Within these domains, we see mature, well structured and documented processes with a large of number of manual steps, and significant volumes of data or records being processed. These processes – applied in areas such as invoice processing, cash receipt allocation, KPI reporting, anti-money laundering and more – are often the candidates that generate the highest benefits from automation and are easier to execute in terms of complexity.
Watch our webinar to understand how to get started with automation for controls
RPA can benefit many departments or divisions across a business. Assurance on the RPA process and governance arrangements is needed as organisations rely on bots to perform critical processing. In our experience, the key areas for seeking assurance include:
Once a bot is created, it will need access to systems and data in the same way that a human user would. As such, it makes sense to treat bots as users from a risk and controls perspective, and give them no more than the required level of access and privileges as a human user performing the same process.
Any user with access to the bot (developers or monitoring personnel) will then have access to all the data and systems that the bot has access to, effectively creating a backdoor into those systems. Access to bot applications should be locked down and logged so that these backdoors can’t be abused.
Bots will undergo a standard development and deployment process, and as such should be treated similar to any other IT application or technology solution. For RPA implementations with significant information security, data protection, regulatory and control impacts, there should be appropriate levels of critical evaluation of the RPA project. Relevant teams and subject matter experts (eg, IT, compliance, audit, risk) need to evaluate the bot in advance of deployment where possible to manage risks appropriately.
Once a bot has been deployed, it should be treated as an ongoing technology service provided to business users, with an appropriate service delivery model in place. As part of this, you will need to define service level agreements and key metrics to keep the automation team accountable in its delivery, and regularly review performance with business owners. Any third-party support for service delivery should be explicitly defined, documented as part of a shared responsibility model, and reviewed in line with contracts and service level agreements.
