Add a bookmark to get started

Website_Hero_Abstact_Architectural_Ceiling_P_0089_Mono
1 June 202233 minute read

Negotiating InsurTech agreements: checklist

The original version of the following checklist of the main issues to consider when drafting and negotiating technology agreements for the insurance sector was produced by Anthony Day, Partner and Nichola Donovan, Legal Director of DLA Piper for Practical Law and can also be found here.

Scope of this checklist

This checklist highlights the key legal and commercial issues to consider when negotiating and drafting a technology contract for a business in the insurance sector. "InsurTech" refers to the use of technology innovation within the insurance sector to drive savings and increase profitability, simplify processes, improve the customer journey and, more generally, to solve specific problems and shortcomings faced by participants in the sector. Examples of InsurTech products include digital insurance platforms, claims automation and optimisation, fraud detection and prevention solutions, and artificial intelligence (AI) based offerings.

Insurance is a highly regulated sector. This is complicated by the global nature of today’s insurance market, which necessitates compliance with multiple regulatory regimes across jurisdictions for those carrying on cross-border activities.

The issues raised in this checklist are not intended to be exhaustive. Additional issues may need to be considered, depending on the particular arrangements being contemplated.

Regulatory environment

If the services are within the scope of insurance or financial services regulations, this will be a prominent factor in the customer’s risk profile and will drive requirements for higher contractual standards and rights for the customer. As the customer (an insurer, reinsurer or insurance intermediary) will itself be regulated under the Financial Services and Markets Act 2000 (FSMA), a range of regulatory issues must be addressed in the agreement. If the services being provided are themselves regulated or relate to the regulated aspects of the customer’s business, then further regulatory requirements will apply.

The customer should consider if there are any regulatory requirements triggering consents to, or notification or approval of, the contract, and the rights of co-operation, audit and approval that the regulators may require.

For information on the key financial services regulatory requirements that apply to insurers, reinsurers and insurance intermediaries in the UK, mainly set out in the Prudential Regulation Authority (PRA) Rulebook and the Financial Conduct Authority (FCA) Handbook, see Sector note, Insurers and reinsurers: regulatory overview. The regulatory requirements include provisions on outsourcing and other third-party arrangements (see Toolkit, Outsourcing in the insurance industry).

Nature of the relationship

InsurTech agreements are often styled more as "collaboration" agreements and have a mutuality in terms of approach, so they tend to be balanced and adopt reciprocal provisions where appropriate. Understanding the nature of the collaboration goes to the heart of framing the contractual relationship:

  • Is it a collaboration to drive sales of insurance products with digital distribution elements?
  • Is it a collaboration arrangement to access better technology to, for example, improve the experience of end customers?
  • Is it about opening up access to a InsurTech’s customers and contacts (a referral arrangement)?

Understanding the nature of the relationship is also critical for determining whether the activities that are envisaged are regulated. If they are, the arrangement will need to be structured so that it complies with applicable insurance and financial services regulations (see Regulatory environment).

Investment

InsurTech collaboration deals often go hand in hand with a linked investment in the relevant supplier, whether a minority or majority equity stake, convertible loan note or similar injection of financing. A key aspect to understand here is the linkage with the collaboration agreement/InsurTech agreement, particularly from a cross-termination perspective. For example, if the collaboration agreement is terminated, what rights will the customer have to relinquish or exit from the investment and vice versa?

Ideally, facilitating an ability for a clean break for both aspects is important, but there may be commercial drivers that mean they need to be treated separately. Again, if one party already has rights, such as a board director or board observer of the other, there may be less need for formal reporting and measures to control and influence the activities of the InsurTech business as some of this may be achieved through the board director or board observer rights.

Understanding the risk profile

Both parties need to understand the risk profile of the transaction so the contract can be drafted to reflect that profile. Drafted appropriately, any clause in the contract could be used to allocate or control risk.

Having identified the risks, each party should ask:

  • Can that risk be allocated to the other party?
  • If the risk cannot be allocated to the other party, what contractual provisions could be included in the contract to control or reduce its exposure to that risk?

Parties should have a clear understanding of their risk exposure before negotiations start, and throughout the negotiation process, as this will drive their stance on key issues in the contract.

Key risks for the customer

Some of the key risks for the customer are:

  • Regulatory compliance, in particular regarding privacy, data security and operational resilience, and the avoidance of regulatory breach and related investigation, enforcement and fines.
  • Ownership of data, how this is maintained and protected, and the purposes for which it can be used.
  • Personal data, including any sensitive personal data which will be subject to more stringent regulatory requirements.
  • The supplier’s failure to deliver the services:

- on time or at all;

- to the required standard; or

- according to the agreed scope or specification.

How would this affect the operation of the customer’s business? And its ability to service its customers?

  • The supplier becoming insolvent and no longer being able to deliver the services at all.
  • The supplier terminating the contract, leaving the customer without a replacement supplier.
  • The extent to which the supplier or the services can be replaced by an alternative, and how quickly and easily this can be put into place?
  • Protecting the interests of its customers and avoiding related complaints, compensation claims, loss of business and reputational damage.
Key risks for the supplier

Some of the key risks for the supplier are:

  • The customer’s failure to pay the fees, either on time or at all.
  • The customer terminating the contract, which may affect the supplier’s cash flow.
  • The customer’s failure to carry out its responsibilities (sometimes referred to as "customer dependencies"), which may affect the supplier’s ability to deliver the services.
  • Protection of its proprietary intellectual property (IP) and ensuring that it retains ownership and control of this.
  • Maintaining data security and integrity.
  • Managing its exposure to liability, particularly in relation to "software as a service" (SaaS) solutions that are provided to customers on a one-to-many basis. For more information on SaaS solutions, see Practice note, Main issues in software licensing and maintenance contracts: Software as a service.
Preliminary considerations for the customer

Scope, purpose and stage

  • Scope. What services will the supplier provide? To which business units and locations?
  • Purpose and approvals. What is the reason for procuring the services? Is the primary motive to decrease cost, improve service or both? Has the customer established a business case to procure the services and are all internal approvals in place? Customers should note that establishing the business need and use cases for an InsurTech solution is critically important when choosing an InsurTech partner and maximising the chances of that partnership succeeding.
  • Stage. Is this the first time that those services have been provided to such business units and locations? Or is an incumbent supplier already providing those services?

Sourcing model and procurement process

  • Model. What sourcing model is the customer intending to adopt (single supplier, multiple suppliers, or some sort of joint venture or partnering arrangement with the supplier)?
  • Supplier selection. How will the customer select the supplier? Will it directly approach the prospective supplier and start negotiating the contract, or will it use a competitive procurement exercise? The customer should ensure that sufficient due diligence is completed, to assess the suitability of the supplier from a financial, capability and regulatory compliance perspective. The geographic locations of the supplier and the services will need to be carefully understood to ensure compliance with relevant regulatory requirements and standards.

Parent company guarantee and buy options

  • Guarantee. Does the customer have concerns over the supplier’s financial standing or its ability to deliver the services throughout the term of the contract? If yes, will it require some sort of financial and performance guarantee, or a parent company guarantee from the supplier?
  • Appropriateness. What value does the guarantee actually add? For example, would a parent company have the requisite technical ability to deliver the services if the guarantee is called on?
  • Buy options. Linked to the above, the customer may wish to consider having a contractual ability to offer to buy the InsurTech business to give more assurance and interventionist remedies and, if so, the process for how this will work. What is permitted or practically enforceable will need to be considered in the light of relevant insolvency legislation.
Key contract terms

Length of contract

  • Term. What is the term of the contract? There are likely to be a number of different considerations at play in agreeing an appropriate term. For example: how established is the supplier and its services, is the pricing discounted, what volume and spend commitments are required by the customer, what rights will each party have to exit the arrangement, will termination payments apply? In agreeing the term, the customer should also consider the exit arrangements and its ability to move to a replacement supplier or provide the same functionality or service in-house (see Suspension, termination and survival and Exit management).
  • Extension. Are there extension rights? Would this trigger a re-negotiation of the terms?

Exclusivity and minimum volume

  • Exclusivity. Does the supplier require some degree of exclusivity in providing the services, or some element of the services, to the customer? Exclusivity can often be a requirement of discounted pricing, to ensure that the supplier nevertheless generates meaningful revenues. The period of exclusivity could be linked to an initial term or alternatively apply for the duration of the agreement.
  • Lock-in. Does the nature of the services and deliverables allow them to be provided, on a temporary or permanent basis, by the customer or other third party? Or are they unique to the supplier?
  • Minimum volume/spend. Will the supplier require a minimum volume of services to be purchased by the customer or a minimum overall spend commitment?
  • Benefit to customer. What financial or other benefit will the customer gain in return for agreeing to any of the requirements outlined above?

Non-compete and non-solicitation

  • Non-compete. Does the customer require commitments from the supplier that it will not compete with the customer’s business? The customer will want to ensure that strict controls are placed on its confidential information and data, to ensure that the supplier cannot use this to compete with the customer or benefit from any competitive advantage.
  • Lock-in. It may be appropriate to agree a lock-in period (for example, for an initial 12 to 24 months) where neither party will directly compete or enter into a similar deal with a competitor, subject to applicable competition and anti-trust requirements.
  • Non-solicitation. Consider the inclusion of non-solicitation clauses restricting the solicitation of employees and customers, which may apply during the term of the agreement and for a period of time thereafter (see Suspension, termination and survival).

Services and deliverables

  • Type. What types of services will be delivered? These may comprise technology build; configuration; third-party products; infrastructure and hosting; helpdesk; application support; and maintenance and development services. Where cloud services are used, are the services multi-tenanted or will they be dedicated to the customer?
  • Scope. Is the scope and specification of the services and deliverables clear? Has the customer specified its functional and non-functional requirements?
  • Responsibilities. Have the responsibilities of the customer, the supplier and relevant third parties been clearly defined? What key roles and teams are required for both the customer and the supplier?
  • Delivery method. For services that involve technology build (for example, the development of an insurance placing platform), will the parties adopt a waterfall or agile delivery methodology? If agile, is there a minimum viable product, to ensure the customer has some certainty that its requirements will be met, and the costs and timescales associated with this? For more information on agile and waterfall delivery methods, see Practice note, Agile software development methods.
  • Changes. What is the process for changing the scope or other details relating to the services and deliverables? Will this be subject to the general change control mechanism in the contract? If using an agile delivery methodology, will there be a separate process for agile changes?
  • Service escalation. Which service escalation procedures are most appropriate? For example, service augmentation, increased monitoring or step-in?
  • Local requirements. If the services are to be provided across multiple locations, are there local service and commercial requirements that need to be reflected? Are there any mandatory local laws which needs to be catered for? Are there different regulatory regimes that will apply and, if so, how do these differ from the "home" location?
  • External verification. Will the value for money offered by the services be subject to external verification from time-to-time? Is this acceptable? For example, by a formal benchmarking process, or an informal process of obtaining tenders from third parties. This is long established in more traditional outsourcing arrangements, so customers often want to explore similar means of ensuring longer term value. What is the effect of such comparison being unfavourable to the supplier? Will the supplier be prepared to open its books for inspection?

Milestones, acceptance and testing

  • Timetable and milestones. What is the timetable for delivery of the services and the deliverables? What milestones apply and what is the process for determining whether those milestones have been met? What remedies will apply if the timetable and milestones are not met? For example, delay payments, step-in or termination rights (see Suspension, termination and survival).
  • Acceptance. What acceptance criteria will apply to the services and the deliverables? When and how will this be agreed?
  • Testing. What acceptance testing will apply, who will perform this and has a testing strategy been agreed? Will there be broader acceptance testing across market participants and, if so, how and when will this be managed?

Migration

  • Data. Who is responsible for data migration from heritage systems? Will there be a single go live or will this migration be phased?
  • Heritage environment, applications and services. How and when will these be retired? Who is responsible for this?

Transformation

  • Transformation. Do the services involve a transformational element of an existing service or offering that the customer already has in place? What are the customer’s key drivers? For example, does the customer wish to simplify, enhance or digitise existing processes?
  • Measurement. How will transformation be achieved and measured?
  • Fees. Are there any fees linked to transformation? If so, what payment triggers apply? (See Price and payment.)

Service levels

  • Performance levels. Is there a service level regime? When will this take effect (this could be on commencement or after an initial baselining period)? Consider the importance of setting, tracking and reporting against the right metrics and recognising that these may need to change as the nature of the relationship evolves, so a flexible approach here is useful.
  • Service credits. What happens if the service levels are not met, will there be a service credit regime? What is the overall amount at risk, and over what period?
  • Changes. How will changes to service levels be made? Will these always require agreement or will either party have rights to make unilateral changes? What are the parameters for changes and how frequently can they be made? Is there any commitment to continuously improve the service levels (and increase the required level accordingly)?
  • Earnback and bonus. Is the supplier entitled to any earnback or bonus for over-achieving against the service levels? These regimes often arise in InsurTech agreements as they align to the entrepreneurial spirit of these agreements.
Employees

Transfer of employees pursuant to the Transfer of Undertakings (Protection of Employment) Regulations 2006

  • On entry.

- Will any of the customer’s (or an incumbent supplier’s) employees transfer to the supplier by virtue of the Transfer of Undertakings (Protection of Employment) Regulations 2006 (SI 2006/246) (TUPE)?

- What contractual protection does the supplier seek to cover those transfers and is the customer able to provide those?

  • On exit.

- Will any of the supplier’s employees transfer to a replacement supplier (or to the customer if services are taken back in-house) by virtue of TUPE?

- What contractual protections should the customer try to include in the contract to cover those transfers? Is it possible to prescribe in advance what will happen to those employees on exit? How about the possible interface with the replacement supplier? (See Exit management.)

  • Pensions. What is the pension position for those affected by TUPE?

Key personnel

  • Designated individuals. Does the customer require the supplier to put in place a key personnel team for the services? Does the delivery of the services require specialist knowledge that can only be provided by certain highly trained, skilled and experienced individuals? This can be particularly relevant for complex technology solutions. Where relevant, this should be considered by the customer upfront, as part of the due diligence process, with appropriate commitments made in the contract.
  • Replacement. What is the process for replacing key personnel? How much say does the customer want over this?

Intellectual property rights (IPRs)

  • Custom code. Will the services include the creation of custom code (used to connect the customer’s and the supplier’s systems together)?
  • Third party IPRs. What IPRs will each party need from the other party’s existing licensors to provide and receive the services? Should existing licences be assigned or novated, or should the usage rights simply be extended to cover the other party? Which party will be responsible for obtaining the necessary consents and paying any resulting fee?
  • Existing IPRs. Will the parties need to license their existing IPRs (as in, materials owned by each party that were developed independently of the services before the contract) to each other as necessary for the provision or receipt of the services?
  • New IPRs. Where materials (such as deliverables) are created by the supplier for the customer in the provision of services, who will own these? Consider whether this new IPR is custom software code, or simply custom configurations. Is it possible to "segregate" new IPRs from any existing IPRs within a service or deliverable? Consider also improvements to existing IPR, which may result in new IPR.
  • AI learnings. Consider who will own the IPRs in the "learnings" to the algorithms when deploying AI solutions. Customers should be wary of inadvertently giving away a lot of their key underwriting and risk management know how by allowing AI providers access to all their data sets for a project (where the AI provider owns the learnings to the algorithms and can potentially use with direct competitors without restriction).
  • Exit. Consider how far it is possible to prescribe in advance what will happen to IPRs on termination or expiry of the contract (see Suspension, termination and survival and Exit management).
  • Indemnities. What indemnities would each party require in relation to the use of third party IPRs? (See Indemnities.)
  • Scope of IPR rights. To what extent should rights granted by the supplier to the customer also be exercisable by third parties providing services to the customer? For example, consultants to the customer or successors to the supplier.

Third-party software

  • Type. Will the supplier be using third-party software? Will this be sub-licensed to the customer or will the customer contract for it directly? If direct, is this "commercial-off-the shelf software" (COTS) or bespoke? Consider the extent to which a customer may be "locked in" to a particular supplier.
  • Use. What functionality and purpose does the third-party software provide?
  • Open-source software (OSS). Will the supplier use OSS as part of the services or deliverables? Does the customer have policy requirements regarding the use of OSS, particularly copyleft software. This is particularly important where the supplier is building new technology for the customer, as the customer will want to be certain that its proprietary software is protected and remains confidential. For more information on OSS, see Practice note, Open-source software.

Price and payment

  • Pricing mechanism. What is the optimum method of pricing the services? For example, fixed price, fixed cost per unit of utilised resource or "cost plus" (where a fixed percentage is added to the unit cost).
  • Milestone payments. Are any of the charges dependent on achieving milestones?
  • Retention. Are any of the charges subject to a retention period, for example, pending successful completion of a warranty period or the resolution of identified defects?
  • Indexation. Are the charges subject to indexation or other pricing variation?
  • Payment. What is the payment mechanism? For example, payment in advance against estimated usage with reconciliation in the following month. Will interest apply to late payment?
  • Invoicing. What are the invoicing requirements?
  • Expenses. Are expenses included within the price or payable in addition? Is there a process or policy that governs expenses?
  • Cost reduction. Will there be a cost reduction mechanism? If so, how will it be measured and what remedies will apply if it is not achieved?
  • Profit sharing. If the supplier can use transferred assets to service other customers, should there be a mechanism by which the customer shares the profits which it generates? If not, is the customer confident this has been adequately taken into account in determining the price?

Warranties

  • Service warranty. What warranties will the customer seek as to the quality of the services, compliance with laws and regulations, and other matters? For arrangements involving technology build, it would be reasonable to expect warranties regarding material compliance with functional and non-functional requirements and specifications, and the use of commercially available coding language that is capable of being configured, implemented, added to, modified or enhanced by a skilled and professional provider of services of a similar nature to the services.
  • Deliverables warranty. What warranties will the customer seek as to the quality of the deliverables, compliance with laws and regulations, and other matters? How long is the applicable warranty period and what is the process for resolving defects?
  • Pre-transfer. If assets, employees and third-party contracts will transfer, what warranties would the customer be prepared to give the supplier as regards pre-transfer acts or omissions?

Customer’s responsibilities (dependencies)

  • Dependencies. Does the customer need to meet any obligations to enable the supplier to provide the services?
  • Relief. To what extent is the supply of services by the supplier dependent on acts of the customer or third parties for whom the customer is responsible? Should the supplier be entitled to relief or compensation if those dependencies fail?

Change control

  • Procedure. What is the procedure for dealing with changes to the contract?
  • Scope. Would the procedure apply to all proposed changes? Or would changes to certain elements (for example, the scope of the services) be subject to a different procedure? If the arrangement concerns software development using an agile delivery methodology, will there be a separate process for agile changes?
  • Compulsory changes. Are there any changes that the customer expects the supplier to comply with on a mandatory basis, other than certain exceptions (for example, it being technically unfeasible), such as changes in law or regulation? Typically, InsurTech suppliers will not be willing to accept responsibility for complying with laws and regulations that are specific to the customer (as opposed to applicable to the InsurTech as a provider of technology services). In most cases, the customer will be required to specify its compliance requirements, and be responsible for monitoring (and bearing the costs relating to) subsequent changes to these compliance requirements.
  • Emergency changes. Is there a process to expediate emergency changes?
  • Disagreement. What happens if the parties cannot agree on the change or the details of it? Would this be referred to the dispute resolution procedure? (See Dispute resolution.)

Processing personal data

  • Personal data. Will the services involve the supplier processing "personal data" (pursuant to the retained EU law version of the General Data Protection Regulation ((EU) 2016/679) (UK GDPR)) on the customer’s behalf? For information on how the UK GDPR applies in the context of insurance transactions, see Practice note, Data protection compliance in insurance transactions.
  • Data protection regime. In addition to the UK GDPR, does the EU GDPR (or any other applicable data protection legislation) also apply?
  • Processing requirements. Have the parties correctly identified their respective processing roles (controller, processor or co-controllers) and the corresponding obligations that are imposed on them under applicable data protection legislation? Will the contract accurately reflect the requirements for processing (and subprocessing) personal data to ensure compliance with the relevant legislation?
  • Offshore processing. Will the supplier’s processing activities be done from an offshore location? Would the offshore processing comply with the requirements of applicable data protection legislation?
  • Liability. How will liability for data processing breaches be addressed in the contract? (See Loss of data in Limitation of liability.)

Limitation of liability

  • Risk exposure. Do the liability caps appropriately reflect each party’s risk exposure under the contract?
  • Structuring the cap. Will there be a single cap or multiple caps for different years, or for different matters?
  • Scope. What is included or excluded from the cap? For example, would indemnities be subject to the cap? (See Indemnities.)
  • Loss of data. Consider the extent to which loss of data and loss arising from breaches of the data provisions will be recoverable. Suppliers are unlikely to agree unlimited liability for loss of data, but it may be possible to agree a separate cap (which is higher than the cap for other losses). (See Processing personal data.)
  • Recoverable losses. Will the parties adopt an inclusive approach to liability by listing out heads of losses that are recoverable? Will the supplier take on any responsibility for the customer’s operational losses, which could, for example, include compensation payments to customers?
  • Excluded losses. Consider whether loss of revenue, business and profits will be recoverable (which could be more pertinent if insurance distribution activities are involved), in addition to indirect, special and consequential losses which are commonly excluded.

Indemnities

  • Types of indemnities. What indemnities do the parties seek from each other? It is common to agree indemnities relating to IPRs (see Intellectual property rights (IPRs)).
  • Cap and limitation. Will the indemnities be subject to any financial caps? How do they interface with the limitation of liability clause? (See Limitation of liability.)

Compliance issues

  • Key areas. Are there any compliance-related issues that the customer wants the supplier to comply with? For example, on issues such as:

- Anti-bribery and corruption (ABC) pursuant to the Bribery Act 2010. For more information, see Toolkit, Bribery Act 2010.

- Modern slavery and human trafficking pursuant to the Modern Slavery Act 2015. For more information, see Practice note, Modern slavery: overview.

- Failure to prevent the facilitation of tax evasion pursuant to the Criminal Finances Act 2017.

- The security of network and information services pursuant to the Network and Information Systems Regulations 2018 (SI 2018/506) (NIS Regulations). For more information, see Practice note, UK cybersecurity law: NIS Regulations.

- Environment and climate change. For more information, see Toolkit, Climate change.

- Corporate social responsibility (CSR). For more information, see Toolkit, Environmental, social and governance (ESG): UK.

  • Compliance and flow down. Will the contract include relevant provisions to ensure that the supplier complies with these compliance issues and ensure that these obligations are flowed down to subcontracts?
  • Customer policies. Does the customer require the supplier to agree to specific policies in relation to the services (for example, security, modern slavery, diversity and inclusion (D&I) and sustainability)?

Subcontracting

  • Permitted subcontracting. Will the supplier be allowed to subcontract any or all of the services to a subcontractor? The customer will need to be mindful of applicable regulatory requirements in this respect, to ensure that the contractual commitments and controls are not circumvented by subcontracting.
  • Flow-down terms. Will the customer require any terms from the prime contract to be flowed down to the subcontractors (particularly with respect to services subject to regulatory requirements)? What happens if the subcontractor resists the inclusion of those terms in the subcontract?
  • Sub-processing. If the data processing activities will be subcontracted, the subcontracting arrangements must comply with the requirements of the UK GDPR (see Processing personal data).

Disaster recovery and business continuity

  • Plans. What arrangements are in place to ensure continuity of services where there is a disaster event?
  • Relationship with force majeure clause. Check that the force majeure clause would not relieve or affect the supplier’s specific obligations to provide the disaster recovery services.

Financial distress

  • Due diligence. InsurTech partners are often high growth businesses, so their financial positions may be less robust than long established suppliers. Undertaking thorough due diligence of the supplier, including its financial position, will, therefore, be an important exercise for the customer (including to meet regulatory expectations).
  • Contractual protections. The customer may wish to include financial distress provisions that apply earlier than insolvency. A financial distress event could include, for example:

- the issue of profit warnings;

- public investigation into allegations of improper financial accounting and reporting;

- suspected fraud or financial impropriety that is likely to result in a material adverse change to the supplier’s financial position;

- breaches of banking covenants;

- material non-payment of subcontractors; and

- changes to the supplier’s solvency ratio.

It would be advisable to include a spectrum of rights, such as senior stakeholder escalation, "get well plans" to resolve or avoid a financial distress event, a jointly controlled escrow account for the payment of subcontractors, access to source code if there is software (or SaaS based escrow), as well as the ability to step-in or terminate, or both.

Audit

  • Regulatory requirements. The UK regulatory regime mandates broad audit rights for the regulator and the customer. In some circumstances such audit rights must be flowed down to certain subcontractors. Sophisticated and established InsurTech suppliers often have well defined contractual provisions in this regard. While these will likely meet the minimum regulatory requirements, they can often fall short of a customer’s expectations and normal contracting standards. The ability of the customer to improve on these terms will depend on the relative bargaining strength of the parties and the nature of the services.
  • Scope and frequency. What can be audited? For example, is it just charges that can be audited or the services generally? How frequently can the customer exercise its audit rights?
  • Subcontractors. Do the audit provisions extend to subcontractors? This will be particularly important if the services are subject to regulatory requirements.
  • Outcome. Would the outcome of an audit automatically require the supplier to adjust its obligations or charges?

Governance

  • Structure. Are there management structures in place to reflect the importance of the services agreement to the customer’s business?
  • Reporting lines. Are there clear reporting lines within the governance structure so that accountability is easily established? The customer will want to ensure that it has access to regular information or reports from the supplier to ensure an appropriate level of control and oversight of the arrangements, as well as early notice of any potential issues.
  • Tiers and committees. Are specific committees required to deal with specific issues? For example, is a leadership committee needed to deal with major changes in circumstances, such as mergers or divestments? Or are the services very technical so there should be a technical committee to oversee delivery?

Dispute resolution

  • Mechanism. How will disputes be dealt with? Will there be a multi-tiered dispute resolution procedure?
  • Scope and outcome. Would all disputes be subject to the procedure? What happens if the parties fail to resolve a dispute under the procedure?
  • Expert determination. Would expert determination be an appropriate procedure?

Suspension, termination and survival

  • Suspension. Does the supplier require rights to suspend the services? Commonly this is required in one-to-many SaaS solutions, to prevent or mitigate the impact that wrongful actions by one customer may have on the supplier’s broader customer base. What events or occurrences would trigger suspension? The most common ones include breach of the supplier’s acceptable use policy, non-payment of fees and breach of laws.
  • Termination for cause. What events or occurrences would trigger termination? The most common ones include termination for material breach (potentially subject to a cure period), a change in control or change in financial circumstances. The customer may also require performance related triggers, for example, for failure to meet milestone(s) by the longstop date(s), or for severe or persistent service level failures.
  • Termination for insolvency. Parties should note that the Corporate Insolvency and Governance Act 2020 makes it difficult or impossible for a supplier to terminate most supply contracts on grounds that the customer has entered into a formal corporate insolvency procedure (or even on other, pre-existing grounds).
  • Partial termination. Can the discrete elements of the service be terminated?
  • Termination for convenience. Does the customer require a right of termination for convenience? If yes, is it willing to pay compensation to the supplier?
  • Survival of clauses. Would any provisions survive termination? For example, confidentiality and limitation of liability, insurance, data protection and ownership, non-compete and non-solicitation.

Exit management

  • Exit assistance. What sort of exit assistance will the customer require when the contract terminates or expires? Is the supplier required to prepare an exit plan? The customer will need to be particularly mindful of its regulatory requirements regarding continuity of business-critical services and consider (and mitigate against) the impact of disruption to such services. The supplier’s willingness to provide commitments in this respect will very much depend on the nature of the offering, in particular whether this is bespoke or a more standard solution. In many cases it would not be uncommon for this to be restricted to access to data and minimal technical assistance to support this.
  • Length and fees. How long would the exit assistance last? How will the supplier charge for this? The customer ought to be wary of pushing the supplier to provide specific exit assistance for no additional charge. Typically, suppliers do not bake this into their pricing, as the needs will differ from customer to customer. Requiring the supplier to provide additional resource and assistance on a free of charge basis inevitably increases the risk that the supplier will look to recoup by other means, for example, by winding down the services or moving key personnel onto other accounts, therefore increasing the risk that the customer will face poor quality of service and a disrupted transition.
  • Data. Who is responsible for transferring back? How long will the supplier continue to make data available?
  • Licences and assets. Will the customer take back licences and assets, or transfer them to a third party?
  • Availability of alternatives. The customer will need to consider, at the outset, how easy it will be to replace the supplier. Given the innovative and emerging nature of InsurTech, the availability of alternatives may well be very limited. How will the customer ensure that it continues to meet its business requirements and services its customers?
  • Replacement supplier. Assuming there is an alternative option, will the customer require the supplier to co-operate with a new replacement supplier and, if so, will this be provided for in the contract? What sort of co-operation or assistance does the customer require? Is this acceptable to the supplier, given that it may need to co-operate or assist a competitor?

Governing law and jurisdiction

  • Governing law. Which law will govern the contract?
  • Jurisdiction. Which court will have jurisdiction over disputes?
  • Alternative to court proceedings. Will the parties consider alternatives to court proceedings? For example, mediation, arbitration or expert determination?

Other provisions and boilerplate

  • Confidentiality.
  • Entire agreement.
  • Third-party rights.
  • Transfer of contracts and assignments.
  • Conflict.
  • Costs.
  • Force majeure.
  • Notices.
  • Set-off.
  • Time of the essence.
Signing the contract and post-signature

Contract signing

  • Appropriate approvals. Has each party obtained the requisite internal approval to enter into the contract?
  • Signature process. Are the signatories properly authorised to sign on behalf of each party? Is the signature block correct? Have the parties dated the agreement?

Post-signing

  • Copies of signed contract. Does each party have a full copy of the signed contract? Where will this be kept?
  • Contract management. Do the parties have adequate contract management procedures in place to effectively manage the contract?
Print