---
title: "SaaS compliance for B2B tech firms selling into regulated industries: what your customers' regulators push down to you"
canonical: https://www.grcmana.io/vault/grc/grc-b2b-tech
published: 2026-10-21
updated: 2026-10-23
author: "Harry West"
framework: "GRC"
control: "Guide SaaS compliance for B2B tech firms selling into regulated industries: what your customers' regulators push down to you"
journeyStage: fundamentals
---

# SaaS compliance for B2B tech firms selling into regulated industries: what your customers' regulators push down to you

## Key takeaways

For a B2B tech firm, SaaS compliance is mostly a regulated customer's own rules passed down by contract. FCA SYSC 8, PRA SS2/21 and, for EU financial entities, DORA Article 30 make banks and insurers keep audit, access, data and exit rights over the suppliers they rely on. One GRC programme with a single mapped control set and current evidence answers those asks for every customer.

- **Critical or important function** — Under DORA Article 3(22) and FCA SYSC 8.1.4AR, a function whose failure would materially impair a firm's finances, the continuity of its services or its regulatory compliance.
- **DORA contract terms** — DORA Article 30 lists terms every EU financial entity's ICT contract must contain, including data locations, incident assistance and termination rights, with audit rights and exit plans for critical services.
- **Certificates as evidence** — PRA SS2/21 paragraph 8.9 expects firms in material outsourcing arrangements to assess whether a provider's certificates and reports are adequate, and not assume that their existence is enough.
- **Managed service providers** — The Cyber Security and Resilience Bill, not yet law as of October 2026, would regulate medium and large providers that manage and access customers' IT systems.

The bank liked the demo. Then its procurement team sent a long security questionnaire, a draft contract with audit, exit and sub-outsourcing clauses, and a request for your ISO 27001 certificate or SOC 2 report. The deal now waits on paperwork nobody on your team owns.

For a B2B tech firm, SaaS compliance is mostly your customers' regulation passed down by contract. Regulated buyers must keep audit, access and exit rights over the suppliers they rely on, so they ask you for evidence. A working GRC programme is how you supply that evidence once, instead of rebuilding it for every customer.

This guide is for founders, COOs and CTOs at UK SaaS and B2B tech firms with 25 to 250 staff who sell to banks, insurers, payments firms and other regulated buyers. It reads the rules behind the asks from your side of the table, then sets out the programme and the deal-stage checklist that answer them.

## What does SaaS compliance mean when your customer is regulated?

SaaS compliance, for a firm selling into financial services, means meeting rules that belong to your customer. The bank or insurer is regulated; you are usually not. But its rules make it control its suppliers. So the controls, rights and evidence it needs become terms in your contract and questions in your security review.

That is why the asks feel out of proportion to the size of the deal. The procurement team is not inventing requirements. It is turning its regulator's rulebook into supplier terms. The same rulebook applies whether the supplier has ten staff or ten thousand.

Once you see the rule behind each ask, the work stops looking like a list of demands and starts looking like a design brief.

## Why do banks and insurers ask suppliers for so much?

Banks and insurers ask for so much because they stay fully responsible for anything they outsource. UK and EU rules make them keep the right to audit you, get data back, monitor your performance and leave in an orderly way. They cannot hand that responsibility to you, so they write it into your contract.

Three texts drive most of what a UK supplier sees:

- **FCA SYSC 8.** The FCA's [outsourcing rules in SYSC 8.1](https://www.handbook.fca.org.uk/handbook/SYSC/8/1.html) say a firm that outsources a critical or important function must, among other things, be able to terminate the arrangement, keep a disaster recovery plan and test its backup facilities where the service needs one, and give itself, its auditors and the FCA effective access to data related to the outsourced activities. SYSC 8.1.9R requires a written agreement, and lets the provider sub-outsource only with the firm's written consent.
- **PRA SS2/21.** The PRA's [supervisory statement on outsourcing and third party risk management](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss) applies to banks, building societies, PRA-designated investment firms and insurers. The current version took effect on 31 December 2024. Paragraph 6.4 lists what a written agreement for material outsourcing should set out, and it reads like a contract checklist.
- **DORA.** The EU's [Digital Operational Resilience Act](https://eur-lex.europa.eu/eli/reg/2022/2554/oj), Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 30 lists the terms every contract for ICT services with an EU financial entity must include, with extra terms where the service supports a critical or important function.

DORA binds EU financial entities, not UK suppliers. It reaches you because your EU customers must put its terms into their contracts with you. Only providers designated as critical by the EU supervisory authorities, under Article 31, are overseen directly.

The FCA's [guidance for firms outsourcing to the cloud, FG16/5](https://www.fca.org.uk/publication/finalised-guidance/fg16-5.pdf), adds practical detail. It also states that the FCA sees no fundamental reason why cloud services cannot be used in a way that complies with its rules. Regulators are not against SaaS. They want your customer to stay in control of it.

## What do regulated buyers typically require of a supplier?

Regulated buyers tend to ask a supplier for six things: rights to audit and access, a say over subcontractors, incident notice and help, tested continuity plans and a way out, a stated data location, and proof of security, often a certificate. Each one traces to a rule, and the table below maps them.

| What the buyer asks for | What it looks like in your contract or review | The rule behind it |
| --- | --- | --- |
| Right to audit and access | Audit and inspection clauses for the customer, its auditors and its regulator, plus requests for information | SYSC 8.1.8R; SS2/21 chapter 8; DORA Article 30(3)(e) |
| Sub-outsourcing notice | Consent or notice before you use a new subcontractor for the service, and a list of current subcontractors | SYSC 8.1.9R; SS2/21 paragraph 6.4 and chapter 9; DORA Article 30(2)(a) |
| Incident notification | Duty to report incidents and material developments, and to help when an incident affects the customer | SYSC 8.1.8R; SS2/21 paragraph 6.4; DORA Article 30(2)(f) and 30(3)(b) |
| Business continuity and exit | Tested contingency plans, termination rights, a transition period and return of data | SYSC 8.1.8R; SS2/21 chapter 10; DORA Article 30(2)(d), 30(2)(h), 30(3)(c) and 30(3)(f) |
| Data location | The regions or countries where the service runs and data is stored, with advance notice of changes | SS2/21 paragraph 6.4; DORA Article 30(2)(b) |
| Security certification | A request for ISO 27001, SOC 2 or Cyber Essentials, backed by a security questionnaire | SS2/21 paragraphs 5.20 and 8.9; DORA Article 30(3)(c) |

Two of these are easy to underestimate. The first is that the regulator's access right is real: SS2/21 expects the agreement to oblige the provider to co-operate with the PRA. The second is the subcontractor list. SS2/21 paragraph 9.3 wants firms to see their supply chain, with providers encouraged to keep an up-to-date list of their own sub-outsourced providers, so your cloud host and your support tooling are part of the conversation.

## Are you a critical or important supplier to your customer?

You are a critical or important supplier if a failure in your service would materially impair your customer's finances, the continuity of its services, or its compliance with its licence. That test comes from SYSC 8.1.4AR and DORA Article 3(22). The label is your customer's call, and it changes how much of the contract applies.

The PRA uses the term "material outsourcing". SS2/21 asks firms to weigh a set of tests. They include a direct link to a regulated activity, the effect of an outage on the firm's resilience, data protection duties, and how hard the provider would be to replace or bring in-house.

You can usually tell where you sit from the paperwork. Signs that your customer treats you as critical or important:

1. **Your service sits inside a regulated activity.** Payments, policy administration, lending decisions or client money flows run through your product.
2. **You hold or process customer data at scale.** Personal or transactional data lives in your platform, not just passes through it.
3. **You would be hard to replace.** A switch would take months, or there is no ready alternative.
4. **The contract has a long schedule.** Audit rights, exit plans, testing duties and regulator access appear in full, not as one-line clauses.

The label matters because the asks step up. Under DORA Article 30(3), a service that supports a critical or important function brings unrestricted rights of access, inspection and audit. It adds a duty to take part in the customer's threat-led penetration testing, and an exit plan with a set transition period. Other ICT services get only the Article 30(2) list.

Ask your customer directly how it classifies your service. The answer tells you how much evidence to prepare.

UK rules also have a regime for critical third parties to the whole financial sector. Under the Bank of England, PRA and FCA [policy statement PS16/24](https://www.bankofengland.co.uk/prudential-regulation/publication/2024/november/operational-resilience-critical-third-parties-to-the-uk-financial-sector-policy-statement), HM Treasury designates those providers. That regime targets providers whose failure could threaten financial stability, not a typical scale-up.

## Which assurance should a SaaS firm get first?

We recommend getting assurance in this order for a UK SaaS firm selling into regulated industries: Cyber Essentials first, then ISO 27001, then SOC 2 when US customers or an attestation report are asked for. Each step builds on the controls from the last, and each answers a different buyer. The order matters less than the scope.

- **Cyber Essentials.** The [NCSC describes Cyber Essentials](https://www.ncsc.gov.uk/cyberessentials/overview) as the minimum standard of cyber security the government recommends, built on five technical controls. It notes that a growing number of organisations require suppliers to be certified to bid for work. Our [Cyber Essentials page](https://www.grcmana.io/vault/cyber-essentials) covers the scheme.
- **ISO 27001.** The certificate UK and EU buyers recognise for an information security management system. It gives you the risk register, policies and control set the rest of your programme hangs on. Start with our [ISO 27001 hub](https://www.grcmana.io/vault/iso-27001).
- **SOC 2.** An attestation report issued by a CPA firm under AICPA standards, and the report US buyers tend to ask for. Our [SOC 2 hub](https://www.grcmana.io/vault/soc-2) explains the report types and criteria.

A certificate is evidence, not a pass. SS2/21 paragraph 8.9 says that, in material outsourcing, firms should assess whether a provider's certificates and reports are adequate, and not assume that their existence is enough. The PRA also expects those reports to cover the key systems and controls the firm relies on.

## What does a minimum viable GRC programme look like for a SaaS firm?

A minimum viable GRC programme for a SaaS firm has six parts: named owners, a risk register, one control set mapped once to the frameworks customers ask for, evidence kept current, a trust centre, and a reusable answer library. Together they let you answer any customer from one place, rather than starting again for each deal.

1. **Named owners.** One accountable person for security and compliance, and an owner for each control area. Contract clauses need a name behind them.
2. **A risk register.** The risks to the service you sell, rated and reviewed. Regulated buyers ask how you identify and manage risk, and a register is the answer.
3. **One control set, mapped once.** A single set of controls mapped to ISO 27001, SOC 2 and the contract terms in the table above. When a new customer asks, you show the mapping rather than build a new one.
4. **Evidence kept current.** Access reviews, change records, backup tests and incident logs produced as the work happens, not gathered before an audit. Current evidence is what an audit clause is really testing.
5. **A trust centre.** A controlled place to publish your certificates, policies and sub-processor list to customers under NDA.
6. **A reusable answer library.** Approved answers to the security questions buyers repeat, tied to the controls and evidence that prove them.

The supplier side of this mirrors what your customer runs on its own side. If it holds ISO 27001, its review of you sits under [Annex A 5.19, information security in supplier relationships](https://www.grcmana.io/vault/iso-27001/annex-a-5-19-information-security-in-supplier-relationships). Knowing that control helps you predict what it will ask.

## What should you have ready at each deal stage?

Have different evidence ready at each deal stage: a short security pack before procurement starts, full answers and reports during the security review, and a tested position on audit, exit and incident clauses before contract. Preparing each layer in advance keeps the deal moving at each handover between the buyer's teams.

| Deal stage | What the buyer asks | What to have ready |
| --- | --- | --- |
| Before procurement | Do you hold a certificate or report, and where is your data? | Certificate or report, a one-page security overview, data location statement, subcontractor list |
| Security review | The full questionnaire, policies, penetration test summary, continuity plan | Answer library, current policies, a summary of the latest test and its fixes, a tested continuity plan |
| Contract | Audit and access, sub-outsourcing, incident notification, exit and data return | Pre-agreed positions on each clause, a standard exit plan, and an incident notification process you can meet |
| After signature | Renewal evidence, change notices, periodic reviews | Updated reports, notice of subcontractor or location changes, a [SOC 2 bridge letter](https://www.grcmana.io/vault/soc-2/bridge-letter) where your report period has ended |

Agree your contract positions internally before the first negotiation. For example, decide in advance how you will offer audit rights. SS2/21 paragraph 8.7 accepts certificates and independent reports, and pooled audits run with other customers, as audit methods. Paragraph 8.10 still expects material outsourcing agreements to keep the firm's right to audit on site.

## Will the Cyber Security and Resilience Bill bring SaaS firms into scope?

The Cyber Security and Resilience Bill may bring some SaaS and B2B tech firms into direct regulation, but it is still a Bill. As proposed, it would cover medium and large managed service providers that run and access customers' IT systems. As of October 2026, it is still going through the House of Lords and is not yet law.

The government's [factsheet on relevant managed service providers](https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/relevant-managed-service-providers) describes a managed service as one provided under contract for the ongoing management of a customer's IT systems, where the provider connects to or accesses those systems. Small and micro enterprises would be exempt. In-scope providers would register with the Information Commission, take proportionate security measures and report significant incidents.

Whether your firm falls in depends on what you do, not what you call yourself. A product your customers run themselves is different from a service where your engineers administer their systems. Check the definition against your service once the final text and secondary legislation are published, and track the Bill through the [government's collection page](https://www.gov.uk/government/collections/cyber-security-and-resilience-bill).

## What are the common mistakes in SaaS compliance for regulated customers?

The common mistakes in SaaS compliance for regulated customers are chasing a new certificate for each customer, scoping assurance around the office instead of the product, signing audit and exit clauses you cannot honour, and answering questionnaires from memory. Each one costs you on the next deal as well as this one.

- **A certificate per customer.** Adding frameworks one deal at a time builds overlapping programmes. Map one control set to all of them.
- **Assurance that misses the product.** If the service the customer buys sits outside your certificate's scope, the certificate does not answer its question.
- **Clauses you cannot meet.** Agreeing to incident notice timescales or onsite audits you have no process for turns a contract into a breach waiting to happen.
- **Answers from memory.** Two salespeople giving two answers to the same question is how a security review loses trust.

The NCSC's [supply chain security guidance](https://www.ncsc.gov.uk/collection/supply-chain-security) sets out principles for buyers to establish control and oversight of their supply chain. Reading it shows you the questions before they arrive.

## Frequently asked questions

### Does DORA apply to a UK SaaS company?

Not directly, unless the EU authorities designate you as a critical ICT third-party provider. DORA Article 30(4) also asks financial entities and providers to consider standard contractual clauses developed by public authorities. Expect EU customers to arrive with their own DORA schedule, and review it against what you already do.

### Can we refuse a right-to-audit clause?

A regulated buyer will find an outright refusal hard to accept, because its rules expect it to keep that right. You can negotiate how it is used. DORA Article 30(3)(e)(ii) allows the parties to agree alternative assurance levels where other clients' rights would be affected, and SS2/21 describes pooled audits shared between customers.

### Why does an EU customer ask for so many details about our contract?

Under DORA Article 28(3), EU financial firms must keep a register of information that lists every contract they hold for ICT services. Your customer needs your details to complete its entry. Give the information once in a standard form, and reuse it for every EU customer.

### What does the FCA expect when a firm leaves a cloud provider?

FG16/5 expects firms to have documented and tested exit plans, to know how they would move to another provider, and to know how they would remove their data from the provider's systems. A written, standard exit plan from you answers that before the customer asks.