Because Robotic Process Automation (RPA) technology directly targets business processes, there exists some tension between traditional Information Technology (IT) functions and those of the business. In short, the business often finds RPA to be a disruptive tool at their disposal. It is. At the same time, IT might consider RPA in the hands of the business to be a runaround of what would normally be well-governed data processing services. It can be. This dialogue plays out on many fronts. End-User Security is one of those fronts.
Consider These Common Robotic Process Automation Use Cases
- Suppliers request changes to their address records via a form.
- Supplier Invoices are matched to the correct Supplier Purchase order and Receipt and processed for payment.
ERP systems implement solutions for both these use cases. Yet, these use cases often require manual intervention. Perhaps the ERP footprint excludes from its scope the features meant to solve these. Alternately, perhaps the firm’s ERP is a hybrid, and the disparate applications comprising their ERP do not integrate well enough to implement these features without some amount of manual exception-management.
In either of those cases, RPA solves these problems measurably and quickly. A platform-agnostic bot can easily read structured data from an enterprise form, log in to the Supplier Master Data system of record, and update an address. Bots are also well-positioned to identify the matching Purchase Order and Receipt for a Supplier’s Invoice that has been recorded in the Accounts Payable (AP) system because the task uses structured data (an AP voucher) along with rules (Levenstein Distance or some such algorithm) to do so.
So where lies the tension? Often, security is the breaking point. It is a good thing that RPA technology allows bots to easily perform these functions, but don’t such bots then violate Separation of Duties (SoD)?
The Argument
The argument proceeds from the guiding principle that no individual should be able to authorize, record, and maintain physical custody of a company’s assets. Rather, these duties should be separated. In the aforementioned use cases, an individual with permission to perform all such functions would be able to update a supplier’s address to one of their own choosing and then stage an AP payment to that address. They would possess a license to print money. Extending this principle to RPA, one could argue that no bot should be able to perform both these functions either. Taken to its conclusion, this implies that bots themselves should be subject to the same SoD matrix as human employees.
The Counter Argument
The counter argument runs like this. Automation has been around decades prior to the technologies that make RPA attractive and successful. In fact, those very features the ERP vendors offer to solve the above use cases represent automation of a sort. In some set of code, they automate what a human would otherwise have to do. Do we apply SoD to the batch programs running in Oracle Cloud ERP or SAP? Considering that the ERP instances themselves operate via high-privilege service accounts, the proposition makes little sense. Nor should it. Malfeasance is the purview of humans, not computer programs. Ipso facto, do not impose SoD on bots, the counter argument concludes.
A dialectic resolution follows. The latter argument carries weight. Because bots lack human motivations, they should no more be subject to SoD than would the equivalent features (code) of an ERP package. Having said that, due diligence requires some respect for this new technology and the needs to implement proper internal controls around it.
Here are Some Such Controls
- On machines configured for attended automation, ensure that the user(s) of that machine do not have administrative rights.
- Limit robot permissions to the minimum required to execute the particular automation(s).
- Disable robot creation for those users with administrator or other high-privilege roles in Orchestrator.
- Align on the processes and technologies for Privileged Access Management
SoD represents only one facet of security considerations when implementing any enterprise technology, RPA included. As your automation initiatives grow, it is imperative that the Chief Information Security Officer as well as the Corporate Controller maintains a presence in your automation Center of Excellence. This best practice mitigates some of the novel tension that RPA might otherwise introduce.
Interested in learning more about Robotic Process Automation? Send us an email to get started today!
