---
title: "Compliance policy: what a B2B tech supplier's policy must cover"
canonical: https://www.grcmana.io/vault/compliance/compliance-policy
published: 2026-10-21
updated: 2026-10-23
author: "Harry West"
framework: "Compliance"
control: "Guide Compliance policy: what a B2B tech supplier's policy must cover"
journeyStage: intermediate
---

# Compliance policy: what a B2B tech supplier's policy must cover

## Key takeaways

A compliance policy states how a firm identifies the laws, standards and customer contract terms it must meet, who owns each one, how compliance is monitored and evidenced, and how breaches are escalated. For a B2B tech supplier it must also cover obligations customers pass down, such as UK GDPR processor duties and DORA contract terms, and be reviewed whenever a new regulated customer signs.

- **Processor contract duties** — UK GDPR Article 28 requires a binding contract under which a processor acts only on documented instructions and provides the information needed to demonstrate compliance, including audits.
- **Processor breach notification** — Under UK GDPR Article 33(2), a processor must notify the controller without undue delay after becoming aware of a personal data breach.
- **DORA contract terms** — DORA Article 30, applying since 17 January 2025, sets the minimum terms EU financial entities must agree with ICT suppliers, including cooperation with their regulators and termination rights.
- **Critical or important functions** — Where an ICT service supports a critical or important function, DORA Article 30(3) adds unrestricted access, inspection and audit rights, participation in threat-led penetration testing and exit strategies.

The bank's supplier onboarding portal has a mandatory upload field: "Compliance policy". Your security policies are in good shape, but nothing in the folder says how the firm keeps track of the laws, standards and contract terms it has signed up to. The deal is waiting on a document nobody has written.

This guide is for founders, CTOs and first compliance leads at UK B2B tech firms with 25 to 150 staff selling into financial services, insurance or the public sector. It explains what a compliance policy is and what each section should say. It also shows how to cover the obligations regulated customers pass down to you, and how to run the policy so it produces its own evidence.

## What is a compliance policy?

A compliance policy states how your firm identifies the laws, standards and customer contract terms it must meet, who owns each one, how compliance is monitored and evidenced, and how breaches are escalated and reported to customers or authorities. It is short, approved by leadership, and backed by an obligations register and procedures.

The compliance policy sits at the top of your policy set. It does not repeat the rules in your other policies. It describes the system that makes sure those rules, and the obligations behind them, are known, owned and met.

Three documents are often confused with it:

- **A device compliance policy.** In endpoint management tools, a "compliance policy" is a technical rule that checks whether a laptop or phone meets a configuration baseline. That is a control setting, not a governance document.
- **The information security policy.** Your [information security policy](https://www.grcmana.io/vault/iso-27001/annex-a-5-1-information-security-policy) sets out how you protect information. The compliance policy covers every obligation, including data protection, contract terms and sector rules, and the security policy is one of the documents it governs.
- **A code of conduct.** A code of conduct tells staff how to behave. A compliance policy tells the business how it meets its external obligations.

## Why do customers and auditors ask for a compliance policy?

Customers and auditors ask for a compliance policy because it is the quickest way to judge whether a supplier knows what it is bound by. A regulated customer passes its own obligations down through the contract, so it needs proof that you track them. SOC 2 and ISO 27001 auditors need the same proof.

The request usually arrives in one of three places:

1. **A security questionnaire.** A typical question asks whether you maintain a documented compliance policy, approved by management and reviewed every year, alongside the usual security questions.
2. **Supplier onboarding.** Banks, insurers and public bodies run third-party risk assessments before contract signature, and a compliance policy is a common item in the evidence pack.
3. **Your own audit.** ISO 27001 includes a control requiring you to identify and document the [legal, statutory, regulatory and contractual requirements](https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements) relevant to information security. You must also document your approach to meeting them and keep both up to date. A related control requires regular review of [compliance with your own security policies, rules and standards](https://www.grcmana.io/vault/iso-27001/annex-a-5-36-compliance-with-policies-rules-and-standards-for-information-security). For SOC 2, the policies and commitments you document form part of the evidence for the control environment; our [SOC 2 documentation guide](https://www.grcmana.io/vault/soc-2/documentation) lists what auditors expect to see.

What the customer is really testing is whether your commitments survive contact with your operations. A policy that names owners, review dates and evidence answers that question. A policy that only restates the law does not.

## What should a compliance policy include, section by section?

A compliance policy for a B2B tech supplier needs about ten sections: purpose and scope, commitments, roles, how obligations are identified, supplier obligations, monitoring and evidence, breach handling, training, exceptions, and review. Each section can be a few sentences long, because the detail lives in the register, procedures and records the policy points to.

| Section | What it says |
| --- | --- |
| 1. Purpose and scope | Which entities, services, staff and contractors the policy covers |
| 2. Policy statement | Leadership's commitment to meet legal, regulatory and contractual obligations, signed and dated |
| 3. Roles and responsibilities | Who owns the policy, who owns each obligation, and who approves exceptions |
| 4. Identifying obligations | How new laws, standards and contract terms are captured in the obligations register, and who checks it |
| 5. Customer and supplier obligations | How duties in customer contracts, data processing agreements and security schedules are tracked and passed to your own suppliers |
| 6. Monitoring and evidence | How compliance is checked, how often, and where the evidence is kept |
| 7. Breaches and incidents | How a suspected breach of an obligation is escalated, assessed and reported to customers or authorities, and within what time |
| 8. Training and awareness | Who must read and confirm the policy, and how often |
| 9. Exceptions | How a deviation is requested, approved, time-limited and recorded |
| 10. Review and approval | The review cycle, the triggers for an early review, and the approval route |

Keep the policy to two or three pages. The information security policy, data protection policy and other topic policies sit beneath it, and the compliance policy simply names them.

## How should a supplier's compliance policy cover customer obligations?

A supplier's compliance policy should state that obligations arriving through customer contracts are treated exactly like laws: captured, owned, monitored and evidenced. For a UK SaaS firm, that means UK GDPR processor duties, customer security schedules and data processing agreements. It also means the terms regulated customers must pass down under their own operational resilience and outsourcing rules.

This section is what separates a supplier's compliance policy from a regulated firm's. Your customer has the regulator. You have the contract, and the contract carries the regulator's expectations to you.

### UK GDPR processor duties

When you process personal data on a customer's behalf, you are usually a processor. [Article 28 of the UK GDPR](https://www.legislation.gov.uk/eur/2016/679/article/28) requires a binding contract with the controller. Under it, the processor acts only on the controller's documented instructions, keeps staff bound by confidentiality and applies the security measures in Article 32. It must also make available all the information needed to show compliance, and allow for and contribute to audits.

[Article 33(2)](https://www.legislation.gov.uk/eur/2016/679/article/33) adds that a processor must notify the controller without undue delay after becoming aware of a personal data breach. The ICO's guidance on [processors' responsibilities in their own right](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/responsibilities-and-liabilities-for-processors-in-their-own-right/) is clear that processors have direct liabilities and can face administrative fines. Your compliance policy should name who owns data processing agreements and how breach notification deadlines are met.

### Customer security schedules and data processing agreements

Enterprise contracts often add a security schedule with commitments of their own: notification windows, penetration testing frequency, data location, subcontractor approval and audit rights. Each commitment is an obligation, so each belongs in the register with an owner.

A signed security schedule nobody has read is a liability, not a control.

### Terms regulated financial customers pass down

If you provide ICT services to financial entities in the EU, the Digital Operational Resilience Act sets the contract terms they must agree with you. [DORA (Regulation (EU) 2022/2554)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) has applied since 17 January 2025. Article 30 requires the contract to cover, among other things, service descriptions, data locations, data protection, incident assistance, cooperation with the customer's regulators and termination rights.

Where your service supports a critical or important function, Article 30(3) goes further. It adds full service levels with precise performance targets, participation in the customer's threat-led penetration testing, and exit strategies with a transition period. Article 30(3)(e) gives the customer, a third party it appoints and its regulator unrestricted rights of access, inspection and audit. That includes the right to take copies of relevant documents on site where they are critical to your operations. The contract must also allow both sides to agree other forms of assurance where those rights would affect your other clients.

UK financial customers bring their own regulators' expectations, and both the FCA and the PRA expect access and audit rights in the contract. The FCA's [guidance on outsourcing to the cloud and other third-party IT services (FG16/5)](https://www.fca.org.uk/publications/finalised-guidance/fg16-5-guidance-firms-outsourcing-cloud-and-other-third-party-it) applies to FCA-authorised firms. Paragraph 2.2 excludes banks, building societies, some investment firms, and the payment and e-money firms covered by the EBA outsourcing guidelines. Its section 3 expects those firms to have effective access to data for themselves, their auditors and the FCA, with no limit on the number of requests. They should also be able to request on-site visits to the provider's relevant business premises.

The PRA's [supervisory statement SS2/21](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss) covers banks, building societies, PRA-designated investment firms and insurers in scope of Solvency II (paragraph 1.2). For material outsourcing, paragraph 8.3 expects the written agreement to give the firm, its auditors and the PRA full access and unrestricted rights of audit and information. Paragraph 8.4 says those rights should reach, where relevant, the supplier's data, systems and networks, its penetration test results, and its external auditors, staff and premises.

You do not need to interpret these regulations yourself, and how a specific clause binds you is a question for your lawyer. Your compliance policy needs one rule: every regulated customer's contract is reviewed when signed. Each term it imposes then lands in the register with an owner and a way to evidence it.

## Who owns a compliance policy, and when should it be reviewed?

A named senior person owns the compliance policy: usually the CEO, COO or CTO in a firm of 25 to 150 people. Day-to-day upkeep is delegated to the compliance or security lead. Leadership approves it. Review it at least once a year, and straight away when a trigger event changes what the firm is bound by.

We recommend writing the triggers into the policy itself, because an annual review alone will always lag the business. Five triggers cover most of what changes a supplier's obligations:

1. **A new framework.** You start a SOC 2 examination, an ISO 27001 certification or Cyber Essentials.
2. **A new regulated customer.** A bank, insurer or public body signs, bringing its own contract schedule.
3. **A significant contract change.** An existing customer adds a security schedule, audit right or data location term.
4. **An incident or a breach of an obligation.** The review checks whether the policy, the register or a procedure failed.
5. **A change in law or regulation.** New UK legislation or guidance affects how you process data or deliver your service.

Record each review: the date, who reviewed it, what changed and who approved it. That record is the evidence an auditor will sample.

## How does the compliance policy link to the obligations register and the policy set?

The compliance policy states the rules; the obligations register lists what the firm is bound by; the policy set and procedures say how each obligation is met; and the evidence proves it was met. The compliance policy should name the register, say who owns it, and point to the policies beneath it.

Think of it as four layers that reference each other:

- **Compliance policy.** Why and who: the commitment, the roles and the review rules.
- **Obligations register.** What: each law, standard and contract term, with its owner and the control that meets it.
- **Topic policies and procedures.** How: the [information security policy](https://www.grcmana.io/vault/templates/information-security-policy), data protection policy, incident response procedure and the rest.
- **Evidence.** Proof: records, logs, attestations and review minutes.

The policy itself should not contain the register. Keep the register as a living table that changes every time a contract is signed, and keep the policy stable enough that leadership approves it once a year.

## How do you run a compliance policy as an engineered system?

Run the compliance policy like code: keep it under version control, collect staff attestations automatically, generate review evidence as a by-product of the workflow, and map each policy statement to the controls and obligations it covers. The policy then proves itself whenever a customer or auditor asks, instead of being rebuilt for each request.

A PDF signed once for an audit is a snapshot, not a policy.

Four practices turn the document into a system:

1. **Version control.** Store the policy in a repository or document system that records every change, who made it and who approved it. The change history becomes your review evidence.
2. **Staff attestation.** Send the policy to every in-scope person when they join and after each material change, and record each confirmation automatically. A completion report replaces a chase by email.
3. **Review evidence by default.** Trigger reviews from events, such as a new customer record or a closed incident, and log the outcome against the policy version. Nothing depends on someone remembering the anniversary.
4. **Policies mapped to controls.** Link each policy statement to the obligations it meets and the controls that enforce it. When a customer asks how you meet a DORA term or an Article 28 duty, you can trace the answer from the contract to the evidence in minutes.

This is how a lean team answers enterprise due diligence at enterprise standard. The work moves from writing documents to maintaining a system that writes its own audit trail.

## What does a compliance policy clause look like?

A good compliance policy clause is short, names an owner, sets a time limit and says where the evidence lives. The example below, written by GRCMANA, covers customer contract obligations. Adapt the roles, timings and system names to your firm; it is an illustration of plain-English drafting, not legal wording.

**Example clause (illustrative, written by GRCMANA): obligations from customer contracts**

"Before any customer contract is signed, the Head of Compliance reviews its security schedule, data processing agreement and any regulatory terms. Each obligation is added to the obligations register within five working days of signature, with a named owner and the control that meets it. Owners confirm their obligations are met at each quarterly review, and the register records the evidence for each confirmation."

The clause works because a third party can test every sentence: was the review done before signature, was the register updated within five days, and do quarterly confirmations exist?

## What are the common mistakes with a compliance policy?

The most common mistakes are copying a large regulated firm's policy wholesale, writing commitments nobody can evidence, and leaving the policy unchanged after a new customer contract adds obligations. Each one creates a gap between what the document says and what the firm does, which is exactly what due diligence and audits test.

**Copying a bank's policy.** A bank's compliance policy describes a compliance function, regulator relationships and reporting lines a 60-person SaaS firm does not have. Auditors and customers notice roles that do not exist. Write for the firm you are.

**Commitments nobody can evidence.** "All staff will comply with all applicable laws" cannot be tested. Every commitment should point to an owner, a frequency and a record.

**Never updated after a new contract.** The policy and register were written for the first audit, then a bank signed with a 40-page schedule and nothing changed. The next questionnaire asks how you meet those terms, and the honest answer is that you did not track them.

## Frequently asked questions

### Do we need a compliance policy if we already have an information security policy?

Usually, yes. ISO 27001 does not require a document with that title, but it does require you to identify and document the legal, regulatory and contractual requirements relevant to information security. Obligations outside security, such as UK GDPR processor duties and customer contract terms, still need an owner and a home. A short compliance policy is the clearest place to show customers they are tracked.

### Does a SOC 2 report or ISO 27001 certificate replace a compliance policy?

No. A report or certificate shows that an independent auditor examined your security controls or management system. It says little about how you track UK GDPR duties or the terms in each customer's contract. Regulated customers are also told not to rely on it alone. For material outsourcing, paragraph 8.9 of the PRA's SS2/21 expects firms to assess a supplier's certificates and reports, not assume their existence is enough.

### Who should approve a compliance policy?

Leadership should approve it: the board or, in a smaller firm, the CEO or the executive team. Keep the approval where an auditor can find it, such as a dated entry in leadership minutes or a signed version in your document system. A policy with no approval record reads as a draft, however good the content.

### Can we use a compliance policy template?

A template is a sound starting point if you rewrite it for your firm. Replace generic roles with real names and job titles, add the obligations your customers actually impose, and delete anything you cannot evidence. A template copied unchanged tends to promise more than the firm delivers.

### Should we share our compliance policy with customers?

Yes, on request, under a non-disclosure agreement or through a trust centre alongside your certificates and reports. A well-written compliance policy contains no secrets: it describes how obligations are managed, not the security details of your systems.