Compliance · Guide
Compliance management system: how a B2B tech firm manages every obligation it has taken on compliance management system
Compliance management system: how a B2B tech firm manages every obligation it has taken on
Key takeaways
A compliance management system is the owners, obligations register, policies, controls, evidence and reviews a firm uses to know what it must comply with, meet it and prove it. For a B2B tech supplier, most obligations arrive through customer contracts and certifications as well as law. Build it on your existing ISO 27001 ISMS, centred on an obligations register.
- Processor breach duty
- Under UK GDPR Article 33(2), a processor must notify the controller without undue delay after becoming aware of a personal data breach, whatever the contract says.
- DORA contract terms
- DORA Article 30 lists the terms EU financial entities' ICT contracts must contain: data locations, incident assistance, termination rights and, for critical or important functions, audit rights and exit strategies.
- DORA application date
- DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Most ICT suppliers meet it through their financial-entity customers' contracts; only providers designated as critical are overseen directly.
- Obligations register
- The core record of a compliance management system: each obligation with its source, who it is owed to, an owner, linked controls, evidence and a review date.
A regulated customer's due-diligence questionnaire asks how you manage your compliance obligations. The honest answer is that they live in signed contracts, a shared drive, the ISO 27001 auditor's last report and the heads of two people. A compliance management system turns that into one record you can show.
This guide is for founders, CTOs and first security or compliance leads at UK B2B tech firms with 25 to 150 staff. You already run ISO 27001 or SOC 2, and your obligations grow with every bank, insurer or public-sector contract. It explains what the system is and where a supplier's obligations come from. It then shows how to build the obligations register at its centre and run it on the management system you already have.
What is a compliance management system?
A compliance management system is the owners, obligations register, policies, controls, evidence and reviews a firm uses to know what it must comply with, meet it and prove it. For a B2B tech firm, those obligations include customer contract terms as well as law and standards. Build it on the ISMS you already run; software supports it but isn't it.
Three terms get blurred, so it helps to separate them:
- A compliance management system is the set of decisions, records and routines described above. It exists whether or not you buy anything.
- Compliance software is a tool that can hold the register, collect evidence and send reminders. It supports the system. It does not decide what your obligations are or who owns them.
- A compliance programme is the day-to-day work of running compliance: the owners, the cadence, the reporting. The system is what the programme runs on.
In US banking, "compliance management system" also has a specific supervisory meaning for consumer-protection law. That meaning does not apply to a UK tech supplier and is not covered here.
Where do a B2B tech supplier's compliance obligations come from?
A B2B tech supplier's compliance obligations come from four places: the law that applies to the firm directly, the certifications and attestations it holds, the contracts and security schedules it signs, and the requirements that regulated customers must pass down to their suppliers. A compliance management system that tracks only the first source misses most of what customers will test.
| Source | Examples | How it reaches you |
|---|---|---|
| Law that applies to you | UK GDPR duties as a processor, such as acting only on the controller's documented instructions and telling the controller about a personal data breach without undue delay | Directly, by statute |
| Certifications and attestations | ISO 27001 requirements and Annex A controls; SOC 2 Trust Services Criteria and the service commitments in your system description | By choice, then by audit |
| Customer contracts | Master services agreements, security schedules, data processing agreements, service levels, notification deadlines, audit rights | Signed, one customer at a time |
| Regulated customers' flow-down terms | DORA Article 30 contract terms for EU financial entities; PRA SS2/21 outsourcing expectations for UK banks and insurers | Through the customer's contract, because the customer is the one regulated |
The legal duties are specific. UK GDPR Article 28 sets out what a processor's contract must cover. Among other things, it must require the processor to:
- act only on the controller's documented instructions;
- make sure its staff are bound by confidentiality;
- take appropriate security measures;
- meet set conditions before using a sub-processor;
- help the controller answer data subject requests;
- delete or return the data at the end of the service;
- allow and contribute to audits.
Article 33(2) adds that the processor must notify the controller of a personal data breach without undue delay. The ICO's guidance on controller and processor contracts notes that a processor also has direct responsibilities and liabilities of its own, beyond the contract.
The flow-down terms are where obligations multiply. DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. Its Article 30 sets out the terms an EU financial entity's contract with an ICT provider must contain. They include:
- the locations where data is processed, and advance notice of any change;
- help at no extra cost, or at a cost agreed in advance, when an ICT incident occurs;
- full cooperation with the customer's regulators;
- termination rights and minimum notice periods;
- for services supporting critical or important functions, access, inspection and audit rights and exit strategies.
In the UK, the PRA's supervisory statement SS2/21 on outsourcing and third-party risk management sets expectations for banks, building societies, PRA-designated investment firms and insurers. Those expectations shape what they ask of their suppliers.
The law binds you directly. Most of the rest binds you because you signed something.
What goes in a compliance obligations register?
A compliance obligations register lists every obligation the firm has taken on, with its source, the customer or authority it is owed to, an owner, the controls that meet it, the evidence that proves it and the date it is next reviewed. It sits at the centre of the system: every policy, control and report traces back to an entry.
We recommend one row per obligation, not one row per document. A 40-page security schedule might create a dozen rows: a 24-hour incident notification, an annual penetration test, data hosted in the UK, a named security contact, and so on. Each row needs the same fields:
| Field | What it records | Example |
|---|---|---|
| Obligation | The requirement in plain English | Notify the customer of a security incident affecting their data within 24 hours |
| Source | The law, standard or contract clause, with a reference | Customer A security schedule, clause 7.2 |
| Owed to | The customer, regulator or certification body | Customer A |
| Owner | One named person accountable for meeting it | Head of engineering |
| Linked controls | The controls in your control library that meet it | Incident response procedure; on-call alerting |
| Evidence | The record that proves it was met | Incident log with notification timestamps |
| Review date | When the entry is next checked | At renewal, or annually |
| Status | Met, partly met, not met or accepted risk | Met |
Two fields do most of the work. Owner makes someone answerable. Linked controls stops the register from becoming a list of promises. If an obligation has no control, you have found a gap before a customer does.
A contract clause nobody owns is a promise nobody keeps.
How do contract obligations get into the register?
Contract obligations get into the register at two moments: when a contract is signed and when it is renewed or amended. Make register entry part of the signing process, not something compliance catches up on later. Whoever approves a non-standard security schedule or data processing agreement should also confirm the new rows and their owners.
In practice, that means three small habits:
- Review before signature. The person who reviews the security schedule flags any term that differs from your standard position. That term goes into the register as a draft row.
- Confirm at signature. Once signed, the draft rows go live with owners and linked controls. Any term you cannot meet becomes a recorded gap with a plan, not a surprise.
- Recheck at renewal. Renewals and amendments often tighten notification windows or add audit rights. Compare the new terms against the existing rows rather than assuming nothing changed.
Where a customer flows down regulatory terms, such as DORA Article 30 provisions, record the regulatory source alongside the contract clause. It tells the owner why the term is not negotiable.
How do you watch for new or changed obligations?
Watch for new or changed obligations by naming the triggers that create them and checking the register when one fires. The usual triggers for a tech supplier are a new customer contract, a new framework or certification, a new product or data type, a change in law, and an incident. Each trigger should prompt a short register review.
A light routine is enough at this size. Keep a list of the sources that matter to you, such as the ICO, your largest customers' regulators and the bodies behind your certifications. Check them on a set cadence. When something changes, add or update the affected rows and tell the owners. This is horizon scanning, not a full regulatory change process. For most 25 to 150-person suppliers, it is enough.
What are the components of a compliance management system for a small tech firm?
A lean compliance management system for a 25 to 150-person tech firm has eight components: an accountable owner, the obligations register, a compliance policy, controls mapped to obligations, evidence, monitoring, management review, and change triggers. A firm running ISO 27001 already has most of these in some form. The work is connecting them, not starting again.
- An accountable owner. One senior person who answers for the system as a whole, usually the founder, COO or CTO at this size.
- The obligations register. As above: every obligation, owner, control and evidence source.
- A compliance policy. A short statement, approved by leadership, of how the firm identifies and meets its obligations. It points to the register rather than repeating it.
- Controls mapped to obligations. One control set, with each control linked to every obligation it serves. A single control can then satisfy ISO 27001, SOC 2 and three customer contracts at once.
- Evidence. The records each control produces, kept where an auditor or customer can be shown them.
- Monitoring. Checks that controls still operate and obligations are still met, ideally run from the systems that produce the evidence.
- Management review. A regular look by leadership at status, gaps, incidents and changes, with decisions recorded.
- Change triggers. The events that force a register review, from a new contract to a new framework.
How do you build a compliance management system on an existing ISO 27001 ISMS?
You build a compliance management system on an existing ISO 27001 ISMS by widening its scope rather than running a second system beside it. ISO 27001 and ISO 37301 share the same high-level management system structure, so context, leadership, planning, support, operation, evaluation and improvement already exist. You extend each one to cover every obligation, not only security.
ISO 27001 already asks you to understand the needs and expectations of interested parties and to identify your legal, statutory, regulatory and contractual requirements. Those two requirements are the seed of an obligations register. Most ISMSs record them as a short list scoped to information security. The compliance management system makes that list the full register.
The table shows how each part of the shared structure extends. It is a planning aid in our words, not ISO text.
| Clause group | What your ISMS already has | What the compliance management system adds |
|---|---|---|
| Context (clause 4) | Interested parties and their security requirements | Every legal, certification and contract obligation in one register |
| Leadership (clause 5) | Security policy and roles | A compliance policy and an owner for each obligation |
| Planning (clause 6) | Information security risks and objectives | Obligations whose failure would matter most, and objectives for meeting them |
| Support (clause 7) | Competence, awareness, documented information | Staff who know which customer terms affect their work |
| Operation (clause 8) | Security controls in operation | Controls linked to non-security obligations too, such as service levels and notification duties |
| Performance evaluation (clause 9) | Monitoring, internal audit, management review | Obligation status in the same monitoring and in management review |
| Improvement (clause 10) | Nonconformity and corrective action | Missed obligations handled through the same corrective action process |
The same logic extends to AI. If you are adopting ISO 42001 for AI governance, it uses the same structure. The obligations it brings belong in the same register, including those from customers asking how you govern AI. One integrated management system, one register, one review.
A second management system for compliance doubles the meetings and halves the attention.
How do you run a compliance management system as an engineered system?
You run a compliance management system as an engineered system by keeping one control library that serves every obligation, collecting evidence automatically from the systems that produce it, and monitoring controls continuously instead of checking them before each audit. The register stays the source of truth. Automation keeps it current without a scramble.
Three design choices matter most:
- One control library. Each control is defined once and mapped to every framework and contract it serves. When a customer adds a requirement, you map it to an existing control or record a gap, rather than writing a new control for each contract.
- Evidence from the source. Some systems already record the evidence, such as access reviews in an identity provider or change approvals in a code repository. Collect it from there on a schedule. People supply evidence only where judgement is involved.
- Continuous checks. Controls that can be tested automatically are tested all the time. Failures go straight to the obligation owner. A failing control then shows up as an at-risk obligation in the register, before a customer review or audit finds it.
The result is that customer due diligence, your ISO 27001 audit and your SOC 2 examination all draw on the same record.
Should a tech firm get ISO 37301 certification?
Most B2B tech firms should align with ISO 37301 rather than certify against it. ISO 37301:2021, the international standard for compliance management systems, replaced the guidance-only ISO 19600:2014 and sets requirements a firm can be certified against. Tech firms' customers rarely ask for it. They ask for ISO 27001, SOC 2 and evidence that contract terms are met.
ISO 37301 is useful as a reference. Its structure confirms what a complete compliance management system includes. Because it shares the ISO 27001 structure, aligning with it costs little extra. Certification is a different decision.
Consider certifying when:
- a major customer, tender or regulator names ISO 37301 in its requirements;
- you sell into sectors where buyers are starting to expect a certified compliance management system;
- you already run an integrated management system and the extra audit would add little effort.
Check the certificate route before you commit. In the UK, ISO 37301 had not yet been subject to UKAS-accredited certification when UKAS opened a pilot accreditation project in January 2025. Ask any certification body whether its certificate will be accredited, and by whom.
Stay aligned but uncertified when the request is "show us how you manage compliance". The register, the review records and the evidence answer that more directly than a certificate.
How does a compliance management system answer a customer's due diligence?
A compliance management system answers customer due diligence by showing the record, not describing intentions. When a customer asks how you manage compliance, you can show the register entries for their contract, the owner of each, the controls that meet them, current evidence and the last management review. That is a stronger answer than a policy document alone.
Prepare a short, shareable pack:
- The compliance policy, showing leadership approval and the review date.
- An extract of the register filtered to the customer's own terms, with owners and status.
- Evidence for the terms they care most about, such as incident notification, sub-processor changes or data location.
- Your certifications and reports, such as the ISO 27001 certificate and SOC 2 report.
The same pack, filtered differently, serves the next customer. That reuse is the commercial payoff. Due diligence becomes a quick search, not a project.
What are the most common compliance management system mistakes?
The most common compliance management system mistakes are buying software before knowing the obligations, running a second management system beside the ISMS, leaving contract obligations out of the register, and having no owner for a customer's flow-down terms. Each leaves the firm unable to show what it has promised, to whom, and how it knows the promise is kept.
- Buying software first. A tool configured before the obligations are known encodes guesses. Build the register, then choose a tool that fits it.
- A parallel system. A separate compliance manual, committee and audit cycle beside the ISMS duplicates effort and splits ownership.
- Law and standards only. A register that lists UK GDPR and ISO 27001 but no contract terms is missing the obligations customers will actually test.
- Unowned flow-down terms. DORA or PRA-derived clauses are signed by sales and given no owner in operations. They surface for the first time in the customer's audit.
- No change triggers. A register built once and reviewed annually drifts out of date with every new contract.
Frequently asked questions
No. The system is the owners, register, policies, controls, evidence and reviews; software is one place to hold them. Build the register first, because it tells you which fields, integrations and evidence sources a tool must support. A spreadsheet or the ticketing tool you already use is enough to start.
You need one, but you probably have most of it. ISO 27001 already asks you to identify legal and contractual requirements and interested parties' needs. The usual gap is scope. An ISMS records the obligations that touch information security. Terms such as service levels, insurance cover or reporting duties sit outside it until the register takes them in.
One senior person should own the register as a whole, usually the COO, CTO or a security and compliance lead. Each obligation then has its own owner: the person whose team meets it. The register owner keeps it complete; obligation owners keep it true.
Review the whole register at least once a year, as an input to management review. Check a sample of the evidence each time, not only the status column: a row marked "met" is only as good as its proof. Between reviews, update entries as triggers fire. Entries tied to short notification windows or often-amended contracts may need more frequent checks.
For most suppliers, no. DORA applies to EU financial entities, which must put Article 30 terms into their contracts with ICT providers. A supplier meets those terms through the contract. Only providers designated as critical by the European Supervisory Authorities are overseen directly. Take legal advice on any specific contract.
Domain engine
Compliance reference directory.
Every guide in this domain, grouped by level — fundamentals, intermediate and advanced. Open any entry for its core practices, implementation steps and the evidence it produces.
01Fundamentals2 guides
02Intermediate8 guides
Compliance reporting: what a B2B tech firm reports to customers, the board and investorsAudit readiness: how to be ready for any security or compliance auditCompliance risk assessment: rank the obligations your customers and regulators hold you toCompliance training for tech suppliers: what customers and auditors expect, who needs it, and how to prove itCompliance monitoring: run a programme that keeps customer and audit promisesCyber security audit: what it covers and how to prepareCompliance policy: what a B2B tech supplier's policy must coverCompliance audit: every audit a B2B supplier faces, and how to run them from one evidence base
Compliance Accelerator
Ready to meet every framework with one set of controls?
Work with a Trust Architect to map your obligations, choose the right frameworks in the right order, and build a programme that satisfies auditors and enterprise buyers alike.