Buying enterprise SaaS through an implementation partner: the contracting risks to address early

For many UK organisations, the legal and commercial risk in a SaaS project does not sit in the software subscription alone. It sits in the space between the platform provider’s terms and the implementation partner’s statement of work. In large, business-critical programmes, that gap can become the source of delay, cost overruns and disputes, particularly in regulated procurements (e.g. public / energy sectors and financial services). 

Why this model creates a different contracting challenge

Enterprise SaaS procurements are often sold as a combined transformation: the customer signs for access to the platform, while a separate implementation partner is responsible for design, configuration, migration, integration, testing and, in some cases, ongoing support and other managed services. That might be because of the value of the contract, the structural delivery model of the SaaS provider, or the geographic market.

In practice, this means the customer is contracting with two suppliers under two different models: 

• The software vendor, operating on standardised, heavily risk-managed vendor-friendly subscription terms (one-to-many cloud contract).
• The implementation partner, working under a (usually) more negotiable set of contract terms. 

The result is a familiar problem in large programmes: each supplier is responsible for its own scope, but no one supplier accepts responsibility for the end-to-end outcome. This creates gap risks, and drives a greater need at the outset to understand interdependencies between the suppliers and the contracts.

This issue is not confined to one platform or sector. It commonly arises in programmes involving enterprise platform providers such as SAP, Oracle, Salesforce and Workday, where successful delivery depends heavily on implementation and support partners. 

In practice, well-run SaaS procurements need clear scope, service descriptions, service levels, data terms, termination protections and exit arrangements. Those themes become even more important where the customer operates in a regulated environment, because outsourcing, resilience, audit and change control obligations do not disappear simply because the solution is delivered through a cloud model or a multi-party supply chain.

Particularly (but not exclusively) in regulated environments, it will be important at the procurement planning stage to anticipate likely vendor bidding structures. Will there be single supplier bids from SaaS / platform providers themselves providing the end to end service, or will there be bidding consortia involving partners, or a combination of both.

The days of the customer attaching its chunky standard (very customer friendly) agreement to procure software solutions, and asking vendors to bid to that, are generally gone. It might now look more like pre-defined key contractual principles / requirements reflecting customer red lines (which should generally few, and achievable for vendors versus their playbook deviations from their standard cloud terms). However, if there are bidding consortia involving partners, that can complicate matters e.g. Are both suppliers expected to meet all the KCRs or just between them?  Is there scope to attain negotiated compromise positions on specific KCRs against the implementation partner where that is not possible against the platform provider? What happens if the implementation partner becomes insolvent or materially breaches such that the customer wants to terminate them but not the platform provider? And so on.

The contract gaps customers should test before signing

Against this backdrop, key risks typically arise in a number of recurring areas.

Scope may be complete on paper but incomplete in practice

Customers should assume that the subscription agreement, implementation statement of work, and support arrangements will not naturally align unless they are made to do so. Key functionality may be described at a high level in sales materials but only partially reflected in the signed documents. Integration dependencies, customer responsibilities, third-party tools, data migration assumptions and post go-live support boundaries can all be left unclear. 

If those points are not pinned down before signature, they often reappear later as change requests, delays or disputed defects.

Liability is often divided in a way that leaves the customer exposed

The software vendor may accept responsibility for availability of the core service, but not for implementation quality, data migration, integrations or project delay. The implementation partner may accept responsibility for its professional services, but not for platform defects, roadmap changes or vendor-imposed constraints. 

From the customer’s perspective, this can leave a practical recovery gap if the programme fails due to a combination of issues rather than a single breach by one party. Customers should therefore test whether the liability model reflects the delivery reality, including who is accountable for failed integrations, defective configuration, missed milestones caused by platform constraints, and security and compliance failures that sit across both contracts.

Service levels and acceptance mechanisms may not cover the real delivery risk

SaaS service levels usually focus on platform availability, response times and platform level support processes in a general top level way. They rarely address whether the configured solution is fit for the customer’s intended business use. 

That issue is often pushed into implementation acceptance testing, but acceptance criteria can be weak, overly technical or dependent on supplier-controlled assumptions. Customers should ensure that acceptance, milestone sign-off, defect treatment, warranties, and post go-live support all work together, and that change control mechanisms and triggers do not blur responsibility for delay or underperformance.

Data, audit and regulatory obligations need to work across the whole supply chain

For regulated customers (financial services firms, energy providers, public sector bodies), the analysis cannot stop at standard SaaS terms. Customers may need specific rights on audit, information access, security assurance, business continuity, data location, subcontracting controls and exit support. Larger enterprise platform providers will sometimes have modular contracts which recognise specific regulated sectors (e.g. a FS addendum to the platform contract), but this is not universal.

UK and EU regulatory guidance on cloud and third-party outsourcing has long emphasised that regulated firms remain accountable for outsourced functions, including where services are delivered through layered technology arrangements. However, these obligations are often fragmented across the supply chain if they are not intentionally aligned.

In regulated procurement contexts, customers also need to think carefully about evaluation assumptions, contract modification risk, transparency requirements and whether the chosen delivery model can be documented and governed clearly enough through the procurement process. 

For example, in the UK, under the Procurement Act 2023 and Cabinet Office guidance, utilities and other contracting authorities need to be particularly alert to how the contracted solution is defined at the outset, actively managed during delivery and where necessary, modified after award. All of that can be trickier where there is more than one supplier responsible for implementing and delivering the end to end platform solution.

Practical steps customers can take

1. Map responsibilities end-to-end – cover design, configuration, integration, data migration, testing, cutover, support and regulatory cooperation, and consider reflecting in targeted key contractual requirements.
2. Review the subscription agreement, implementation contract and governance documents side by side, and ensure they fully cover the requirements. Seek to understand any inter-dependencies early.
3. Negotiate practical remedies - including implementation warranties, milestone holdbacks, remediation obligations and exit support. Leverage competitive tension through the procurement process where possible. Consider whether concessions can be obtained from partners where platform providers are unwilling.
4. Engage legal, procurement, security and operational stakeholders early, particularly for regulated customers. Run scenario / stress testing against contract and governance models.

A governing law point, not just a delivery challenge

Although many of these issues are universal and commercial rather than jurisdiction-specific, the governing law, remedies and procurement framework still matter. Customers contracting under English law or Scots law should ensure that the contract structure, remedies, dispute provisions and change mechanisms are drafted with that governing law in mind. 

The key point, however, is broader: in major platform and enterprise SaaS programmes, legal risk often sits in the interfaces between documents, suppliers and responsibilities. That is where early considered advice at the procurement and contracting stages can materially reduce risk and greatly improve delivery outcomes. It can be the difference between a successful platform roll out and total project failure.

How we can help 

Burness Paull’s technology & commercial team advises customers on complex technology procurements, cloud contracting, outsourcing and digital transformation projects, often in regulated sectors. If you are considering or reviewing a major platform / SaaS procurement, or reshaping your contract approach for a strategic technology programme, we would be happy to support you from the outset so please get in touch.

Related News, Insights & Events