The Multilayered Security RPA-as-a-Service Requires

Security might not be the first thing that comes to mind when thinking about Robotic Process Automation (RPA). Yet, it has long been the cornerstone of leading RPA platforms because the processes RPA automates routinely access numerous business applications, traverse crowds of company devices, and handle vast volumes of data that fuel business workflows. And that’s just on-premise RPA.

Today, as businesses move to the cloud, interest is growing in RPA-as-a-Service, which delivers RPA functionality in the cloud, fully hosted and managed by the RPA provider. This adds cloud security as another important consideration when businesses are evaluating RPA-as-a-Service vendors.

Here are 12 security standards to look for in RPA-as-a-Service or cloud-native automation platforms.

1. ISO 27001 certification

To earn an ISO 27001 certification, an RPA vendor must demonstrate full compliance with the confidentiality, integrity, and availability standards for information assets related to its cloud service. This baseline for IT security practices was created by the International Organization for Standardization (ISO) and is an internationally recognized certification to gauge the safety of information security systems.

To achieve this certification, RPA-as-a-Service vendors must successfully complete a comprehensive and independent audit of their technical controls and IT security policies. Most importantly, the level of security that this credential assures can boost the value businesses get from RPA-as-a-Service by enabling them to automate processes without worrying that their sensitive data will be put at risk.

When evaluating an RPA cloud solution, the ISO 27001 certification should be one of the first things to ask for.

2. SOC 2 Type 1 certification

Created by the American Institute of Certified Public Accountants (AICPA), the System and Organization Controls (SOC) 2 Type 1 certified certification measures IT security controls based on five principles:

• Availability: Attests that an RPA-as-a-Service solution is available to be used as agreed upon in the contract with a customer.
• Confidentiality: If an RPA-as-a-Service service handles sensitive data, such as financial information or intellectual property (IP), it must present how it uses, accesses, and protects that information in the SOC 2 report for the auditor.
• Processing integrity: Used for determining if the RPA-as-a-Service vendor delivers complete, valid, accurate, and authorized data in a timely manner.
• Security: Addresses whether the RPA-as-a-Service product protects customers against unauthorized access through appropriate access controls.
• Privacy: This principle is concerned with how the RPA vendor collects and uses personal information, such as personally identifiable information (PII), both as it pertains to the vendor’s own privacy notice as well as generally accepted privacy principles of the AICPA. PII includes such things as the name, address, phone number, and social security number of an individual.

SOC 2 certification is issued by outside auditors. They assess the extent to which a vendor complies with one or more of these principles based on the systems and processes they have in place. The SOC 2 Type 1 report gives potential customers peace of mind that an RPA-as-a-Service vendor has passed an audit and that their data will be safe. SOC 2 reports are unique to each organization. Each RPA-as-a-Service vendor designs its own controls to comply with one or more of the trust principles.

3. SOC 2 Type 2 certification

While SOC 2 Type 1 describes the systems of an RPA-as-a-Service vendor and addresses whether it meets trust principles as of a specified date, SOC 2 Type 2 reports the results of an audit that has assessed the operational effectiveness of an RPA vendor’s systems over a specific period of time, for example, one year.

These internal reports provide customers and prospects with critical information about how an RPA-as-a-Service vendor manages data.

4. SOC 1 Type 2 certification

The SOC 1 Type 2 audit is a semi-annual certification that tells customers and potential customers that an RPA-as-a-Service vendor has the proper internal controls and processes in place regarding security and availability to ensure that customer data is kept safe.

SOC 1 is most appropriate for companies that must meet financial reporting regulations such as Sarbanes-Oxley (SOX). Other federal regulations, such as Gramm-Leach-Bliley (GLBA) and the Health Insurance Profitability and Accountability Act (HIPAA), require corporations to audit the internal controls of their suppliers, including those that provide technology services such as RPA-as-a-Service. Controls that are audited include but are not limited to:

• Information security
• Physical security
• Logical access
• Network monitoring
• Configuration management
• Vulnerability management
• Backup and restore
• Incident management
• Application development

5. ISO 22301 certification

The stability and resiliency of your RPA vendor should be a consideration, especially when you’re investing in RPA-as-a-Service. Beyond the cloud service that your RPA vendor offers, what happens if a disaster strikes and systems go down? The ISO 22301:2019 “Security and Resilience – Business Continuity Management Systems” certification covers how well a company is ready to respond and recover in the case of an emergency or disaster. RPA is often implemented in business-critical processes, and the RPA-as-a-Service vendor should have a clear business continuity plan so that its customers are not impacted.

6. Validated industry standards

Various industries have standards to ensure that RPA-as-a-Service platforms provide you with security controls that can be used in the most sensitive use cases. For example, the Federal Information Security Management Act (FISMA) requires federal agencies to implement information security plans to protect sensitive data.

Industry standards support controls such as centralized authentication (active directory), centralized log management, analysis and reporting capabilities through security information and event management (SIEM), and network partitioning and network access control through virtual local area networks (VLANs). They also audit to check that firewalls are in place and integrated with the RPA-as-a-Service wherever appropriate.

7. Integration with industry-recognized authentication frameworks

When it comes to authentication and identity management (AIM), organizations have to think about security on two fronts: their human users who access the RPA-as-a-Service platform and the bots that also interact with the platform and with enterprise applications. Because of this, it is imperative that RPA-as-a-Service platforms can seamlessly integrate with enterprise security systems.

As single sign-on (SSO) is a common way for enterprises to enhance security, RPA-as-a-Service platforms should be interoperable with SSOs using security assertion markup language (SAML 2.0). Organizations should also consider whether the RPA-as-a-Service can be securely integrated with Microsoft Active Directory and industry-standard Kerberos support.

8. Accessibility for authorized individuals and devices only

Successful authentication is the first level of enforcing access control. Equally important is access authorization, which adheres to the principle of least privilege. This principle means that users start with the least amount of access they require—and frequently no access at all. The administrator must then explicitly provide access to features and functionality to every role type using role-RBAC to ensure a clear separation of duties.

Many companies have business applications hosted both on premises and in the cloud that the employees and bots must interact with. Automated processes may require logging into enterprise applications such as Salesforce, SAP HANA, or Oracle DB. The use of lockers to store credentials and sensitive data prevents data leaks or exposures because bots only access what they need for a given process. If lockers are used, credential information does not need to be hardcoded within the bot.

Having a credential vault is an important part of an RPA-as-a-Service platform. When it is natively integrated within the system, organizations can immediately set up access to their enterprise applications. Support for the integration of third-party credential vaults, lockers, and keys such as CyberArk and Azure Key Vault should be included to comply with company policies on secure access to applications.

9. Protection of data

Data needs to be protected during transmission between an enterprise’s network and the RPA-as-a-Service provider’s cloud service, including through transport layer encryption (TLS) leveraging at least 2,048-bit RSA server certificates and 128-bit symmetric encryption keys. All data, including customer data that is transmitted between data centers for replication purposes, should be across a dedicated, encrypted link utilizing AES-256 encryption. Data at rest should be across all data storage facilities using asymmetric encryption with AES-256-bit keys. 

Adhering to data privacy standards such as the general data protection regulation (GDPR) is also critical. While regionally the name of the privacy regulation or directive may vary, implementing globally accepted controls to meet privacy requirements should be built into the platform of the RPA-as-a-Service service vendor.

10. Protection of code

As RPA often involves automating business-critical processes, RPA-as-a-Service vendors must adhere to stringent software development lifecycle practices to ensure that not only is the product tested for any weaknesses to threats or malware but is continuously monitored. Industry best practices can be applied to ensure that the product code is protected. As RPA moves increasingly to the cloud, vendors should have a Security Operations (SecOps) team with a proactive security posture and threat defense management protocol. For additional protection and validation, RPA providers can also integrate third-party scanning and testing tools throughout the product development lifecycle such as Veracode Verified Continuous.

11. Granular auditing

All RPA solutions should come with extensive audit capabilities, including advanced logging, monitoring, and reporting. RPA-as-a-Service solutions are no exception to this.

According to Deloitte, there are five stages to an audit:

• Planning: Gain a comprehensive view of the business areas and processes where RPA has been deployed.
• Walkthrough: Understand the relationship between the automated process and IT, and identify risks as well as controls.
• Design evaluation: Evaluate control design, identify the exception-handling process, and identify any gaps in security
• Operating effectiveness: Perform substantive testing of all controls.
• Reporting: Report on gaps between risks and controls, and make recommendations for how to fix them.

Leading RPA-as-a-Service platforms provide embedded tools to do these things quickly and easily.

12. Dedicated CloudOps and SecOps teams

In addition to having security certifications, standards, and capabilities in place, vendors offering RPA-as-a-Service must have cloud and security operational expertise dedicated to ensuring the service is up and running and protected against security threats. As a best practice, this involves two specialized teams, CloudOps and SecOps.

CloudOps (cloud + operations) refers to best practices and procedures that allow cloud platforms—as well as the applications and data that reside on them—to function over extended periods of time.

SecOps (security + operations) involves collaboration between IT security and operations teams, where the technology and processes—to keep systems and data secure—are integrated. The goal is to minimize risk and improve business agility.