Key Highlights
- RPA-enabled environments impact different aspects of your compliance requirements, including but not limited to oversight & governance, data security, access management, change & version controls and cloud security requirements.
- Upskilling compliance leaders to understand the key risks associated with the deployment of RPA technologies is key to allow companies to better assess the inherent risk being introduced by this new technology.
- Companies should plan to conduct regular formal risk assessments in conjunction with any RPA changes to determine the likelihood and impact of all possible risks using qualitative and quantitative methods.
Background
RPA-enabled environments are quite different from traditional environments supported by the core application’s manual processes & their normal automated application controls. RPA adds an additional layer of complexity, which is aimed to increase productivity and quality to the end-to-end execution of the business process. That said, the effectiveness of RPA is dependent on the correct design and integration of this new technology within the end-to-end process.
There has been a focus on upskilling the different impacted end-users, including compliance leaders, to better understand the inherent risks introduced in the digital RPA environments. In this post, I will explore the risks introduced in an RPA environment and the top hotspots that should be considered in a typical RPA risk assessment.
This is merely an introduction and in future posts I will continue going a little bit deeper with examples from different technologies, including BluePrism, UiPath and SAP Intelligent RPA technology.
Architecture layers of RPA products (SAP Intelligent RPA)
An RPA solution must assure three main functions, being able to efficiently create, execute, and monitor automations. SAP Intelligent RPA has the following three core layers:
In order to layout the right risk assessment procedures, we need to understand the architecture components of the RPA technology first. Any RPA technology has a set of three main components:
- Development Studio (Client-based - Desktop Studio): This is the developer tool that is used to build out the bot logic. This where developers build the step-by-step code that the digital worker will execute.
- Digital Worker (Desktop Agent): This is the digital account that executes the code developed. It is the bot (i.e. account) that will interact with the different systems to execute the steps as outlined by the developer.
- Automation Operator (Web-based - Cloud Factory): This is the control room where administrators will manage deployment and authentication of the bots. This is a critical application because it is where you can run/stop a bot, troubleshoot errors, manage bot authentications and most importantly deploy new bots in production environments.
Additionally, usually a password vault software is used with the RPA-enabled technologies (e.g. CyberArk) to maintain the credentials of the Bots.
Risk Assessment - Example of Hotspots
Business, Compliance and Internal Audit functions should constantly plan to conduct regular formal risk assessments in conjunction with any RPA changes to determine the likelihood and impact of all identified risks using qualitative and quantitative methods. The likelihood and impact associated with inherent and residual risk should be determined independently, while considering all risk categories (e.g. previous compliance results, threat and vulnerability analysis, and regulatory compliance). Risks should be mitigated to an acceptable level; acceptance levels based on risk criteria should be established and documented in accordance with reasonable resolution time frames and business owners approval.
The heatmap illustrates a typical risk assessments hotspot measured by impact against the business transactions supported by the RPA technologies. Specifically, the heatmap is measuring the hotspot risks according to Control Risk (Impact on Controls Compliance) and Inherent Risk (Significance of the scope area on Compliance). As a quick reminder:
- Inherent risk refers to the susceptibility of a process to a misstatement, due to error or fraud, that could be material, before consideration of any related controls.
- Control risk is the risk a material misstatement due to error or fraud that could occur, in the absence of effective design and operation of internal control.
Hotspots plotted on the diagram were defined based on multiple criteria including proximity to business transactions, controls & process complexity and impact on compliance opinion in case of failure. These plotted risks can (in fact should) be changed per your environment. Below is an example of the heatmap and some illustrative control activity statements for each area.
(A) Governance and Oversight
- RPA Governance Board & Oversight structure: An appropriate level of oversight over the RPA should be developed. This can include a federated, Centralized or Distributed approach. Oversight responsibilities may include validating RPA program effectiveness and ensuring appropriateness of RPA functionality and funding.
- Annual Compliance Reviews: Independent reviews and assessments should be performed to ensure that the organization addresses the established RPA policies, standards, procedures, and compliance obligations for bot usage.
- RPA Controls and Risk Framework: An RPA control framework outlining the standards, regulatory, legal, and statutory requirements relevant for the business needs should be established and well communicated to relevant stakeholders, including developers.
(B) Bot Development and Change Management
- Business and Compliance Functional Requirements: Business and Compliance specifications for each automation project should be reviewed by the RPA committee, including security and controls and business team members, to validate the appropriateness of the RPA-enabled process design. A post-production review of bot logic against business & compliance requirement should also occur for each RPA deployment project.
- Change management and Version Controls Policies: A set of policies and procedures guiding developers to adhere to company’s change management policy should be created and communicated. The set of procedures should also outline any specific tools needed to have a version history of packages developed e.g. GitHub.
- Change management testing and quality assurance: Quality change control and testing process should be established with a focus on system availability, confidentiality, and integrity testing criteria.
- Environment Isolation: Production and non-production environments should be separated to prevent unauthorized access or changes. Development environment (e.g. UiPath Orchestrator Development environment) and bots should not be connected directly to production systems.
(C) Cloud and Cyber Threats management
- Encryption Configuration: Automation projects should encrypt sensitive data to apply confidentiality compliance requirements (e.g. using algorithms such as AES, DES, RC2, Rijndael, and TripleDES to encrypt and decrypt plain text files processed by bots).
- Infrastructure Hardening: Infrastructure environments, including persistence and server layers, should be hardened to provide only necessary ports, protocols, and services to meet business needs and have in place supporting technical controls as part of the baseline build standard or template.
- Service Organization Compliance Reports: Third-party service reports (e.g. SOC 1 or 2 reports) demonstrating compliance with information security and confidentiality, access control, service definitions, and delivery level agreements should be reviewed.
(D) Error and Issue resolution (including Business Continuity)
- Bot Error log messages: Data input and output integrity logs (i.e. bot log messages, reconciliation and edit checks) should be built in the bot’s code to prevent manual or systematic processing errors, corruption of data, or misuse.
- Business Continuity Rollback Plans: Business continuity and security incident response plans should be subject to regular updates to involve impacted RPA-enabled business processes. Manual workaround should be established as well as supporting business processes and technical measures should be implemented, ensuring continuity and availability of operations in case that the RPA process failed.
- Error and issue resolution procedures: Processing errors (e.g. service stops) configurations are identified, tracked and escalated to resolution. Root causes should be identified and resolved timely; a root cause analysis should be performed as well, and resolution should be documented to avoid similar interruption of bot services.
(E) Authentication and Identify Access Management
- Restricted access to RPA technology architecture layers: Access to, and use of, RPA technologies should be appropriately segregated and access restricted to prevent inappropriate disclosure of sensitive data and tampering of key RPA configuration (e.g. access to UiPath Orchestrator)
- User Access Management: Provisioning and de-provisioning of Bots and user access to RPA technologies should be processed timely, completely and accurately.
- Bots credentials and authentication: Bots credentials used to authenticate with different systems in the process should be restricted and not hard coded. Password safe tools should be used to manage authentication.
(F) Data Security and Privacy Requirements
- Bot Data Security policies & procedures: Policies and procedures should be established and maintained in support of developing RPA steps to maintain data security to include confidentiality, integrity, and availability.
- Bot Data Access Approval: Bots processing critical objects or data should be assigned a classification by the data owner based on data type, value, sensitivity, and criticality to the organization. Bot access to the data should be approved and reviewed by data custodians and owners.
- Production Data Usage for Development: Production data should not be replicated or used in non-production environments. Any use of production data in non-production environments requires explicit, documented approval from relevant stakeholders whose data is affected, and must comply with all legal and regulatory requirements for scrubbing of sensitive data elements.
Bringing it all together,
All in all, the above is only the tip of the iceberg. RPA-enabled environment pushes the assurance leaders to upskill their followers to better manage the new risks. There are many competing technologies in the RPA & AI space, but the approach to manage the risk follows the same logic. Leaders should get ahead of the new AI/RPA technologies and appropriately manage the new inherent risks to comply with the law and compliance regulations.
Follow me via Twitter and LinkedIn
The views, information or opinions expressed in this short article are views of my own. All information in this article is provided “as is”, with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information.
- SAP Managed Tags:
