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

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 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 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, 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, 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.

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, 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 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 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.
• 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 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. 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.

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 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.

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 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