Third-party risk management: what regulated customers expect from your tech firm

The bank's supplier onboarding pack has arrived. It wants audit rights, your consent process for subcontractors, an incident notice period, a tested continuity plan and an exit plan. The deal is waiting, and nobody on your side has seen a schedule like it before.

Third party risk management is how a firm identifies, tiers, assesses, contracts with, monitors and exits the outside providers it relies on. For a tech firm selling into regulated customers, it applies twice. You are the third party in your customers' programmes, and you need your own proportionate programme over the suppliers you depend on, because customers ask about both.

This guide is for founders, CTOs and security or compliance leads at UK B2B tech firms of 25 to 150 people selling into financial services, insurance or the public sector. It explains what a regulated customer's programme checks at each stage and the rule behind each check. It then shows what to have ready, and how to check your own suppliers without building a department.

What is third party risk management, and why does it apply to you twice?

Third party risk management (TPRM) is how a firm controls the risk that outside providers bring to its services, its data and its standing with regulators. A regulated customer runs it over you. You run a smaller version over your cloud host, sub-processors and other critical suppliers. The customer checks both, because your suppliers are its fourth parties.

The customer's side is not optional. The FCA's outsourcing rules say a firm that outsources critical or important functions remains fully responsible for its obligations. The PRA's supervisory statement on outsourcing and third party risk management (SS2/21) is blunter: boards and senior management "cannot outsource their responsibilities". Your platform sits inside that duty, so the customer has to look inside your platform.

For how risk management fits together more widely, start with our risk management hub. This page stays on the supplier relationship.

How do regulated customers tier their suppliers?

Regulated customers tier suppliers by what a failure would do to them, not by contract value. The FCA says "critical or important" and the PRA says "material outsourcing". From March 2027, both also use "material third-party arrangement". For you, each label means the same thing: more scrutiny, tighter contract terms and a regulator who may hear about you.

The FCA treats a function as critical or important if a defect or failure in it would materially impair the firm's continuing compliance, its financial performance, or the soundness or continuity of its regulated services. The PRA defines material outsourcing as services whose weakness or failure "would cast serious doubt upon the firm's continuing satisfaction of the threshold conditions", and SS2/21 tells firms to determine the materiality of every outsourcing and third party arrangement.

Being classed in the top tier changes your sales cycle in three ways:

• Deeper due diligence. SS2/21 expects due diligence on all potential providers, proportionate to the risk, so the top tier gets the longest pack.
• Fuller contracts. The FCA and PRA contract expectations are written for critical, important or material arrangements.
• Regulator visibility. From 18 March 2027, the FCA's PS26/2 and the PRA's PS7/26 require firms in scope to notify them when they enter into or significantly change a material third-party arrangement. Both use one platform, FCA Connect.

You rarely choose your tier. Ask early which of the customer's services your product supports, and plan the deal around the answer.

What does a customer's third party risk management lifecycle ask of you at each stage?

A regulated customer's lifecycle runs through five stages: tiering, due diligence, contract, ongoing monitoring and exit. Each stage traces to a rule the customer must meet, and each asks the supplier for something specific. Having that material ready before the pack arrives turns a long review into a short one.

The table maps each stage to the customer's rule and to what you should have ready. DORA applies only where the customer is an EU financial entity.

Our guide to operational risk management for tech suppliers pairs each of these asks with the evidence that answers it, clause by clause. This page stays on the lifecycle and the contract. For the mechanics of answering the questionnaire itself, see how to build a security questionnaire answer library.

Which contract terms flow down to you, and how do you pre-agree them?

Six terms recur in regulated customers' contracts with critical suppliers: audit and access rights, subcontracting notice and consent, notification of incidents and material changes, continuity testing, data location, and termination with exit assistance. They come from the customer's own rules, so the customer can't simply drop them. Agree standard positions once, with legal advice, and each deal stops reopening them.

At principle level, here is what each term asks of you:

1. Audit and access rights. The FCA expects the firm, its auditors and the regulator to have effective access to data and, where necessary, premises. SS2/21 lets firms use certificates and independent reports, or pooled audits, as audit methods. A current certificate or assurance report is your first offer.
2. Subcontracting. The FCA's written-agreement rule says outsourcing by the provider "only takes place with the firm's consent in writing". SS2/21 asks contracts to state whether sub-outsourcing is permitted and on what conditions.
3. Notification. You must disclose any development that may materially affect your ability to deliver the service. Customers will also ask for incident notice periods.
4. Continuity testing. Both parties are expected to maintain a contingency plan for disaster recovery and test backup facilities where the service calls for it.
5. Data location. SS2/21 asks contracts to name where data is kept and processed, with reasonable notice before a location changes.
6. Termination and exit. The customer must be able to terminate without harming its service, and to transfer the service elsewhere or bring it in house.

Pre-agreeing means writing a short regulated-customer schedule: your standard position on each term, your fallback, and who can approve anything beyond it. Have your solicitor review it once. Then sales can say yes to the reasonable version on day one.

A clause you can't operate is a breach you've signed in advance.

If a customer asks for an audit right or a notice period your own cloud host won't give you, say so before signing. SS2/21 expects firms to tell the PRA when a provider in a material arrangement is unable or unwilling to support their compliance. Raising it early leaves time to agree an alternative before anyone signs.

How do regulated customers monitor you after the contract is signed?

After signing, regulated customers review suppliers on a cycle set by tier, ask for refreshed attestations, and rely on you to tell them about material changes. The FCA requires firms to review the provider's service on an ongoing basis. For a top-tier supplier, expect a periodic reassessment, service reporting and questions whenever your certificates or sub-processors change.

Run this as a calendar, not a scramble:

• Attestations. Track your certificate and assurance report renewal dates, and send updated copies before customers ask.
• Material change notices. Agree internally what counts as material: a new sub-processor, a hosting region move, a change of ownership, a serious incident. Each one triggers a customer notice.
• Service reporting. Report against the service levels in the contract, on the schedule the contract sets.
• Reassessment. Keep your evidence pack current so each periodic review is a refresh, not a rebuild. A trust centre can carry the public and gated parts of that pack.

For the buyer's view of what this monitoring is for, Harry's piece on supply chain cyber security and the moving perimeter sets it out from the customer's seat.

How should a 25 to 150-person firm run its own third party risk management?

Run your own third party risk management in proportion: an inventory of suppliers, a tier for each, due diligence on the critical few, contract terms that match what you promise customers, a review cadence by tier, and a published sub-processor list. Regulated customers check your cloud host and sub-processors through you, so this work protects your own deals.

We recommend six steps:

1. Build the inventory. List every supplier that touches customer data or keeps your service running: hosting, identity, email, payments, support tooling, monitoring.
2. Tier by what each could break. A critical supplier is one whose failure would stop your service or expose customer data. Spend is a poor guide.
3. Do due diligence on the critical tier. Collect each critical supplier's certificates or assurance reports, and read the scope and exceptions, not just the cover page.
4. Match terms back-to-back. Your contract with a critical supplier should support what you promise customers: notice periods, audit routes, data location and exit.
5. Set a review cadence by tier. Critical suppliers get a scheduled review and a check on every material change; low-risk suppliers get a lighter touch.
6. Publish a sub-processor list. Keep it current and tell customers before you add or replace one.

Your customers' due diligence doesn't stop at your boundary. It follows their data to your suppliers.

If you hold or are working towards ISO 27001, the supplier controls already cover this ground: see Annex A 5.19 on supplier relationships and Annex A 5.21 on the ICT supply chain. For SOC 2, deciding how each supplier is treated is a scoping item in our SOC 2 compliance checklist. A written supplier security policy ties the steps together, and the NCSC's supply chain security principles give a free baseline.

What do UK GDPR processor rules add when you handle customer data?

If you process personal data for a customer, you are its processor, and UK GDPR adds its own supplier rules. The ICO's guidance says you need the customer's prior specific or general written authorisation before engaging a sub-processor, must flow the same data protection obligations down, and stay liable to the customer for your sub-processors' compliance.

The ICO's guidance on contracts between controllers and processors sets out the rest. Under a general authorisation, you should tell the controller about intended changes and give it a chance to object. The contract must also require you to help the controller meet its breach notification duties, and to allow for and contribute to audits and inspections.

These duties overlap with the customer's outsourcing terms. One process for changing sub-processors, with one notice, can meet both. The ICO notes this guidance is under review following the Data (Use and Access) Act, so check it before you rely on the detail.

Does the critical third parties regime remove the need to assess your hosting?

No. HM Treasury can designate a provider as a critical third party under section 312L of FSMA 2000 if its failure could threaten the stability of, or confidence in, the UK financial system. Four providers were designated with effect from 13 July 2026. Regulator oversight of those providers leaves your customer's duties unchanged.

The Bank of England, PRA and FCA say so directly in their policy statement on critical third parties: designation "does not mean that it is inherently more resilient or better suited" than a provider that is not designated, and firms "will remain accountable and responsible" for managing the risk. Your customer will still ask which provider and region you use, how you would recover, and how you would leave.

What are the common third party risk management mistakes for tech suppliers?

The common mistakes are treating each due diligence request as a one-off, agreeing audit or notice terms you can't operate, having no supplier register, having no exit plan, and promising customers more than your own suppliers promise you. Each one turns a routine review into a delay, or a signed contract into a liability.

• Answering every pack from scratch. Each request is treated as a one-off project, so the same evidence is rebuilt by different people each time.
• Agreeing terms you can't run. An audit right with no process behind it, or a notice period your incident process can't meet, fails at the first test.
• No supplier register. When the customer asks for your sub-processors and where they host, nobody can answer in one place.
• No exit plan. The customer is required to plan for your failure. If you can't describe data export and transition support, it has to assume the worst.
• A gap between promises. You commit to a notice period or audit route that your own cloud host doesn't give you.

A supplier with a ready pack and pre-agreed positions doesn't just pass review faster. It becomes the easy choice.

Frequently asked questions