Technology risks in sourcing
August 2017 | SPECIAL REPORT: TECHNOLOGY RISK MANAGEMENT
Financier Worldwide Magazine
August 2017 Issue
The risk landscape of sourcing contracts has shifted in recent years, with a fundamental change to the factors that are driving businesses to outsource and an awareness of the implications of getting it wrong from a regulatory perspective. An increased use of technology is also playing a large part in the change in profile. Robotic process automation (RPA) contributes greatly to cost efficiencies, accuracy and speed in an outsourced environment. However, the use of RPA can also create some complexities for organisations.
The current environment and future developments
In 2015, Lloyd’s estimated that cyber attacks cost businesses as much as $400bn a year. That amount included direct damage in addition to the post-attack disruption to the usual course of business. However, analysts are predicting multiples of such losses over the coming years, as the frequency and impact of cyber crime is increasing. And with the adoption of different technologies such as RPA, new attack surfaces are created or existing attack surfaces expanded.
This technology risk must also be viewed against the legislative backdrop, which is particularly onerous for certain industries and sectors. For example, regulatory compliance is one of the larger risks for financial institutions when outsourcing business functions. The regulated entity remains ultimately responsible for compliance with regulation and cannot relinquish its regulatory compliance obligations by attempting to pass on such obligations to a third-party supplier. In late 2016, the Financial Conduct Authority (FCA) fined Aviva £8.2m for failing to provide adequate oversight of the third parties to whom it outsourced the protection of its customer assets. Mark Steward, director of enforcement and market oversight at the FCA, said: “Other firms with similar outsourcing arrangements should take this as a warning that there is no excuse for not having robust controls and oversight systems in place.”
A more general example of legislation that businesses must consider in this context is data protection legislation. When it applies in the UK from 25 May 2018, the General Data Protection Regulation (GDPR) will place new obligations directly on data processors. The law will move away from data controllers (i.e., those determining the purpose of processing the data) being responsible for non-compliance with the current data protection legislation, and instead there will be a move to data processors sharing the responsibility and the risk of non-compliance with the data controller. The GDPR sets out two sets of maximum thresholds for fines that may be imposed for certain infringements of the GDPR and these thresholds are significantly higher than those under the Data Protection Act 1998. Ensuring compliance with the GDPR is, quite simply, a must.
Bearing these risks in mind when negotiating a sourcing contract
There are numerous procurement options when considering RPA in the context of a sourcing arrangement. Essentially, the customer may licence RPA through a service provider, including as part of a wider provision of services, or alternatively, the customer may licence RPA directly from the creator of RPA. Even though many of the larger outsourced service providers have already developed their own RPA, some service providers will licence RPA themselves from a third party. As such, there is a good chance that a third-party RPA licensor will be involved in the supply chain at some point, with customers ending up in a multi-sourced environment.
While there are clear benefits in a multi-sourced environment, there are also challenges including potentially having no single point of responsibility, the risk of service gaps, ensuring alignment to the wider business and IT strategies of the customer and the difficulty of managing the transition to, and subsequent management of, a multi-sourcing model.
So what does this mean for outsourcing contracts? And what should the parties pay particular attention to when considering the use of RPA and managing the associated technology risks?
An increased number of providers within a customer’s ecosystem means more technologies, with some proprietary and requiring interactions between the various systems and software. ‘Lift and shift’ is no longer as easy as it may have been where one provider controlled the entire outsourced operation and may have been the owner of most (if not all) of the IP.
It is therefore crucial for a customer to understand how intellectual property is handled in any deal. A customer will need to ensure that the licence for RPA accurately captures its requirements. The basics of any IP licence should be considered. What is being licensed? How are updates handled? If there is any bespoke customisation of RPA for a customer, who owns the IP in the customisation? Who can use it? Are there any restrictions as to use by affiliates, third-party providers, or even other robots, that would cause concern or other user limits that need to be understood? When can it be used? Is it simply during the term of a sourcing agreement or does it extend beyond termination? How can it be used? Is the intended use and implementation within the customer’s information systems permitted? Where can it be installed and where can it be used?
When assessing compliance, it is useful to think about both legislative compliance and contractual compliance.
For example, in terms of legislative compliance, a customer will need to ensure that the use of RPA is in line with data protection legislation. This is particularly the case where RPA is used to process sensitive personal data. Customers should consider if there are any changes in the way in which any data is captured or processed when using technology compared to the manual process it replaces, which would need to be reviewed in the context of legislation.
In relation to contractual compliance, a customer must ensure that the software can be installed on the relevant IT systems without affecting other IT components. For instance, where RPA feeds into or pulls data from other software, a customer will need to consider whether that is permissible pursuant to the licence terms of the other software. In some instances, the use of RPA in conjunction with third-party software might be expressly prohibited. Conversely, software licences may not have been drafted with a robot in mind (e.g., definitions of ‘users’ might be quite narrow) and the use restrictions might not allow the types of user privileges that RPA might require.
Multi-sourcing creates additional risks for information security, as data flows between more providers than in a typical one-provider outsourcing model. Regardless of the number of suppliers in the mix, the onus is always on the customer to assess its suppliers’ controls over the availability, confidentiality and integrity of its data processed by third parties. This includes both physical security (facility access and security measures) and logical security (the adequacy of their systems and applications). Given that RPA may change the way data is processed or stored, customers should review the use of such technology in light of their data security policies and procedures, and update their data mapping and data process flows accordingly.
From an operational point of view, does the customer have any concerns relating to the use of RPA in the customer’s IT environment, such as in relation to security, resilience, performance and the impact on underlying systems?
A customer should also assess the plans in place for updates and new releases of the RPA further down the line. Release management is invariably addressed in IT arrangements, but might not be on a customer’s radar in the context of a standard business process operation (BPO).
Multi-sourcing heightens the risks associated with business continuity and disaster recovery (BCDR) for customers. A customer needs a deep understanding of how each provider operates with all other providers to be able to put in place and invoke a BCDR plan for its end to end business operations. The RPA licence should be reviewed in this context also as to its permitted use in the BCDR environment.
With advances in technology, audit rights are extending beyond paper-based audits and are more often than not incorporating IT security and compliance checks. Suppliers will naturally be cautious as to the access it grants to its own networks and systems for audit purposes for legitimate security concerns, so checks and balances as to such access will need to be agreed and stated clearly in the contract.
Insurance and escrow
The increased risk of a data breach or cyber attack means that the demand for cyber insurance has grown and will continue to grow in the years to come. Cyber is not a standard product, and a customer will need to review its (and its providers’) options and coverage carefully.
For any software that is core to the services being provided, the practicalities of an escrow arrangement as an appropriate mechanism to allow access to the software on the occurrence of any agreed trigger events should be explored.
Managing a termination is difficult if the relationship breaks down, but is made even tougher with a complicated supply chain incorporating complex technological solutions. How this might be managed depends on the technology itself (for example, any restrictions around IP). What rights does the customer have to use the solutions following termination or will these solutions have to be replaced? In any event, moving from one supplier to another in a tangled web of technology solutions requires involvement from the incumbent supplier and the successor supplier, achievedthrough a well-documented exit plan, and transformation plan, to cater for the transfer from one operating model to another.
It is increasingly important for customers to manage and mitigate the risk in outsourcing contracts. Regulatory compliance is becoming tougher and failure to comply is becoming more costly. The use of RPA should not be seen as the riskier option when contemplating a sourcing strategy, but nor should the added complexities be ignored. Provided customers take into account the contractual impact of RPA appropriately, it offers the chance to complete tasks more quickly and accurately, in a cost-competitive and scalable manner.
Tania Williams is the commercial technology partner and Chris Benn is an associate at Kemp Little LLP. Ms Williams can be contacted on +44 (0)20 7710 8001 or by email: email@example.com. Mr Benn can be contacted on +44 (0)20 7710 8011 or by email: firstname.lastname@example.org.
© Financier Worldwide
Tania Williams and Chris Benn
Kemp Little LLP