Compliance · Guide
Compliance programme: how a B2B tech firm builds one its regulated customers trust compliance programme
Compliance programme: how a B2B tech firm builds one its regulated customers trust
Key takeaways
A compliance programme is the owners, obligations, controls, evidence and reporting that show a firm keeps its commitments and can prove it. For a B2B tech supplier, most obligations arrive through customer contracts and certifications, so start with a contract-fed obligations register and one control set mapped to every framework, then automate evidence where systems produce it.
- DORA flow-down
- DORA Article 30 sets the minimum terms an EU financial entity's ICT contracts must contain; most suppliers meet them through the customer's contract, not as regulated firms.
- Critical ICT providers
- Under DORA Article 31, the European Supervisory Authorities designate the ICT third-party providers that are critical for financial entities, and only those are overseen directly.
- FCA outsourcing agreements
- FCA SYSC 8.1.9R requires a common platform firm outsourcing a critical or important function to keep instruction, termination, information, inspection and access rights in a written agreement.
- 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.
A bank's supplier onboarding team sends a 300-question security questionnaire, a draft contract with DORA clauses and a request for your SOC 2 report. Your ISO 27001 certificate helps, but nobody can say which of last year's contract promises are still being met. A compliance programme is how a tech supplier answers with evidence instead of effort. It rests on one obligations register fed by contracts, one control set mapped to every framework, and evidence collected from the systems that produce it.
This guide is for founders, COOs, CTOs and first security or compliance leads at UK B2B tech firms with 25 to 150 staff. Their customers are in financial services, insurance or the public sector. It shows where a supplier's obligations really come from and the nine building blocks of a compliance programme, in the order to build them. It then covers what to automate at each size and the mistakes that turn compliance into an annual scramble.
What is a compliance programme?
A compliance programme is the owners, obligations, controls, evidence and reporting that show a firm keeps its commitments and can prove it. For a B2B tech supplier, most obligations arrive through customer contracts and certifications. So start with a contract-fed obligations register and one control set, then automate the evidence wherever systems already produce it.
The term is used loosely, so it helps to place it:
- The compliance programme is the operating work: who owns what, how controls run, how evidence is gathered and how status is reported. This page covers it.
- The compliance management system is the structure the programme runs on, centred on the obligations register.
- A GRC programme is wider still, joining governance and risk management to compliance in one operating cycle.
Most US guides build a compliance programme for the firm that is regulated, a bank or a broker. A tech supplier sits on the other side of that relationship, and its programme looks different.
Where do a tech supplier's compliance obligations come from?
A tech supplier's compliance obligations come from five places: customer contracts and security schedules, UK GDPR processor terms, terms that regulated customers must flow down to their suppliers, certifications such as ISO 27001 and SOC 2, and the firm's own legal duties. For most suppliers, contracts create more obligations than any regulator does.
- Customer contracts and security schedules. Service levels, incident notification windows, penetration testing, data location, named contacts and audit rights, negotiated one customer at a time.
- UK GDPR processor terms. UK GDPR Article 28 requires a processor's contract to cover, among other things, acting on documented instructions, security, sub-processor conditions, assistance to the controller and audits.
- Flow-down terms from regulated customers. For EU financial entities, DORA (Regulation (EU) 2022/2554) Article 30 lists the provisions their ICT contracts must contain. In the UK, the FCA's SYSC 8.1 sets the outsourcing rules. A common platform firm that outsources a critical or important function must set out its instruction, termination, information, inspection and access rights in a written agreement (SYSC 8.1.9R). Other FCA firms that outsource critical or important functions remain fully responsible for their regulatory obligations (SYSC 8.1.6R). The PRA's SS2/21 sets outsourcing expectations for banks, building societies, PRA-designated investment firms and insurers.
- Certifications and attestations. ISO 27001 requirements and controls, and the SOC 2 Trust Services Criteria plus the commitments in your system description.
- Your own legal duties. UK GDPR applies to you directly as a controller for your own staff and customer data, alongside sector or contract-specific law.
The flow-down rules mostly do not apply to you directly. DORA binds the financial entity, and SYSC 8 binds the FCA firm; each reaches you through the contract your customer must put in front of you. Under DORA Article 31, only ICT providers designated as critical by the European Supervisory Authorities are overseen directly.
A promise in a security schedule is a control you haven't built yet.
How do you build a compliance programme, step by step?
Build a compliance programme in nine steps, in order, because each step uses the one before. Name an accountable owner, build the obligations register and map one control set to every framework and contract. Then write the policies, set up evidence collection, monitor controls, define incident and breach notification to customers, report to customers and the board, and review.
Step 1: Name an accountable owner
One senior person answers for the programme. At 25 to 75 staff that is usually the COO or CTO; nearer 150, a dedicated security and compliance lead. The owner needs authority to change how engineering and operations work, because most controls live there.
Step 2: Build the obligations register
List every obligation from the five sources above, with an owner, the controls that meet it and the evidence that proves it. Feed it from contract signature and renewal, so new promises enter the register on the day they are made. The register is the foundation of the compliance management system and deserves its own design work.
Step 3: Map one control set to every framework and contract
Define each control once and link it to every obligation it serves. An access review can satisfy ISO 27001, SOC 2 and several customers' audit clauses at the same time. When a new contract arrives, map its terms to existing controls first and create new controls only for genuine gaps.
Step 4: Write the policies
Write a short policy set that states the rules your controls implement: information security, acceptable use, access, incident response, supplier management and a compliance policy. Keep them short enough that staff read them, and link each policy to the controls that put it into practice.
Step 5: Collect evidence, automatically where systems produce it
Collect the records each control produces. Some systems already hold the evidence, such as an identity provider for access reviews or a code repository for change approvals. Pull it from them on a schedule. Reserve manual evidence for judgement calls, such as risk acceptance decisions.
Step 6: Monitor controls
Check that controls still operate between audits. Automated checks catch configuration drift and missed reviews as they happen; scheduled checks cover the rest. Route failures to the control owner, so a failing control becomes a fix this week rather than a finding next quarter.
Step 7: Define incident and breach notification to customers
Map every notification duty you have accepted. Start with the contractual windows in each customer's security schedule. Add the UK GDPR Article 33(2) duty: a processor must notify the controller without undue delay. Then add any DORA terms requiring assistance when an ICT incident hits the service. Build them into the incident response procedure so the clock starts automatically.
Step 8: Report to customers, the board and investors
Report compliance status in the form each audience needs. Customers want evidence against their own terms; the board wants obligations at risk, incidents and decisions; investors want to know certifications are current. One register, filtered three ways, serves all three.
Step 9: Review and improve
Review the programme on a set cadence and when a trigger fires: a new regulated customer, a new framework, a significant incident or an audit finding. Record the decisions, update the register and controls, and carry actions into the next cycle. If you run ISO 27001, use the same management review.
What should you engineer and what stays manual as you grow?
What to engineer in a compliance programme depends on size. At about 25 staff, automate evidence from your main cloud and identity systems and keep the rest simple. By 75, automate monitoring and connect the register to the control set. By 150, most evidence and monitoring should run without people, who then focus on judgement.
The table is a planning aid, not a prescription. It assumes a cloud-native SaaS firm holding or pursuing ISO 27001 or SOC 2.
| Building block | About 25 staff | About 75 staff | About 150 staff |
|---|---|---|---|
| Owner | Founder, COO or CTO, part of the role | Named lead, part of the role | Dedicated security and compliance lead |
| Obligations register | Spreadsheet fed at contract signature | Structured register linked to controls | Register integrated with contract and control records |
| Control set | One set mapped to ISO 27001 or SOC 2 | Mapped to both, plus key contract terms | Mapped to every framework and contract |
| Policies | Short core set | Full set with annual attestation | Versioned, attested, mapped to controls |
| Evidence | Automated from cloud and identity systems; rest manual | Most technical evidence automated | Automated by default; manual only for judgement |
| Monitoring | Scheduled manual checks | Automated checks on key controls | Continuous checks routed to owners |
| Customer notification | Procedure with contract windows listed | Windows built into incident tooling | Windows tracked per customer automatically |
| Reporting | Quarterly note to the board | Dashboard from the register | Self-serve evidence for customers |
| Review | Annual, plus triggers | Quarterly, plus triggers | Quarterly, plus triggers |
Evidence gathered the week before an audit proves only that the week before an audit happened.
How does a compliance programme answer customer due diligence and security questionnaires?
A compliance programme answers customer due diligence by reusing one body of evidence. When every questionnaire item maps to a control, and every control has current evidence, answering becomes retrieval: find the control, attach the evidence, note the owner. The same record serves the next questionnaire, the next contract review and the next audit.
Three habits make this work:
- Keep a library of approved answers linked to controls, so an answer changes when the control changes.
- Answer from evidence, not memory. Each answer should point to a record a customer could ask to see.
- Feed new questions back. A question you cannot answer is either a gap in your controls or a new obligation for the register.
Regulated customers can test what they were told. Under DORA Article 30(3), contracts for services that support critical or important functions must let the financial entity monitor the provider's performance. That includes rights of access, inspection and audit. A programme that runs continuously passes that test without preparation.
How do you build a compliance programme on an ISO 27001 ISMS?
Build a compliance programme on an ISO 27001 ISMS by extending what it already does rather than starting a separate effort. The ISMS gives you an owner, risk assessment, policies, internal audit and management review. The compliance programme widens those routines to cover every obligation, including contract terms that have nothing to do with security.
ISO 27001 already asks you to identify your legal, statutory, regulatory and contractual requirements, and its implementation builds the routines the programme reuses. Extend them in four ways:
- Scope the requirements list up. Move from security requirements to every obligation, including service levels, data location and notification windows.
- Reuse the control set. Add contract and SOC 2 mappings to your Annex A controls rather than creating parallel controls.
- Reuse the audit cycle. Include obligations in internal audit and management review.
- Reuse the corrective action process for missed obligations, so a broken promise is handled like any other nonconformity.
What are the most common compliance programme mistakes?
The most common compliance programme mistakes are running a separate programme for each framework, leaving contract promises untracked, gathering evidence only before audits, and buying a platform before owners and obligations are set. Each makes the programme look busy while leaving the firm unable to prove what it has promised.
- One programme per framework. Separate ISO 27001, SOC 2 and customer workstreams send the same engineers the same evidence requests three times.
- Contract promises nobody tracks. Terms negotiated by sales and signed by the founder sit in a contract folder until a customer audits them.
- Evidence only before audits. A burst of evidence collection before each audit leaves gaps across the rest of the period. A SOC 2 Type 2 report tests the whole period.
- A platform before owners. A tool cannot assign accountability. Set owners and obligations first, then choose tooling that fits them.
- Notification windows nobody knows. If the on-call engineer cannot see which customers must be told within 24 hours, the deadline can pass before anyone checks.
Frequently asked questions
Yes, but much of it already exists. ISO 27001 covers security requirements, risk, policies and audit. A compliance programme extends those routines to every obligation, including customer contract terms, processor duties and flow-down clauses that fall outside the certified scope.
A senior person with authority over engineering and operations, usually the COO or CTO. As the firm grows, a security or compliance lead takes on the day-to-day work. Each obligation and control then has its own owner in the teams that run it.
Usually not directly: they reach you through your customer's contract. How much that contract asks for depends on how the customer classifies your service. DORA Article 30(3) adds terms such as performance monitoring, audit rights and exit strategies only where the service supports a critical or important function. Ask how your service has been classified, and take legal advice on specific terms.
It depends on what already exists. A firm with ISO 27001 or SOC 2 in place can usually extend its existing routines. A firm starting from nothing needs to build the ISMS foundations first. Plan in stages, starting with the owner, the register and the control set.
No. Evidence collection and control monitoring can be largely automated where systems produce the records. Deciding which obligations to accept, who owns them, whether a risk is acceptable and how to respond to an incident still needs people. Automation removes the scramble; it does not remove judgement.
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.