Compliance reporting: what a B2B tech firm reports to customers, the board and investors

Your largest customer is a bank. Its contract asks for an annual assurance pack, notice of any incident affecting the service, and answers whenever its auditors call. Your board wants a security update next week. Three people are pulling the same facts into three documents, and the numbers will not quite match.

Compliance reporting fixes that. This guide is for founders, CTOs and security leads at UK B2B tech firms that sell to regulated customers. It shows who is owed which report and why. It covers what goes in a customer assurance pack and a one-page board update, and how to draw every report from one evidence base.

What is compliance reporting for a B2B tech supplier?

Compliance reporting tells customers, the board and investors whether the firm is meeting its obligations, where it is not, and what is being done, backed by evidence. For a B2B tech supplier, the core is a reporting calendar driven by customer contracts and certifications, fed from one live evidence base.

Most pages on compliance reporting sort it by type: financial, regulatory, IT. That sorting suits a regulated firm reporting upwards to a regulator. A supplier's position is different. Most of what you owe is outbound and contractual. Your regulated customers had to write reporting terms into your contract, and now they need you to meet them.

The board and investors want something else again. They want a status opinion on posture and risk, not a list of activity. Both audiences can be served from the same facts, which is the point of the rest of this guide.

Who gets which compliance report, and how often?

A supplier's compliance reporting has five audiences: regulated customers, prospects, the board, investors and auditors. Each one gets a different report, on a different basis and cadence. The cadences in the table below are our recommended defaults unless the basis is a law: replace them with the dates in your own contracts and certification cycle.

Two things stand out. Most rows are owed to customers, not to a regulator. And nearly every row draws on the same core facts: controls, incidents, findings and certification dates.

Why do regulated customers write compliance reporting into your contract?

Regulated customers put reporting terms into supplier contracts because their own rules require them to. EU financial entities must include specific terms under DORA, and UK firms face FCA and PRA outsourcing expectations. The duties sit on the customer, then reach you through the contract you sign.

That distinction matters. DORA applies to financial entities, not to most of their technology suppliers. You meet it as a set of contract clauses, not as a regulation you are directly subject to.

DORA, for EU financial entities. Article 30 of DORA (Regulation (EU) 2022/2554), which has applied since 17 January 2025, lists the minimum terms a financial entity's contracts for ICT services must contain. They include service level descriptions and an obligation on the supplier to assist when an ICT incident related to the service occurs. Where the service supports a critical or important function, the contract must also set notice periods and reporting obligations. It must require notice of any development that might materially affect the supplier's ability to deliver, and grant unrestricted rights of access, inspection and audit.

FCA outsourcing rules, for UK firms. SYSC 8.1 sets the FCA's outsourcing requirements. The strictest conditions apply when a common platform firm outsources a critical or important operational function. The service provider must disclose any development that may materially affect its ability to carry out the outsourced functions. The firm, its auditors and the FCA must also have effective access to related data and to the provider's premises, where effective oversight needs it. Other firms in its scope meet a separate set of conditions and should take account of the general outsourcing rule as guidance.

PRA SS2/21, for banks, building societies and insurers. The PRA's supervisory statement on outsourcing and third party risk management applies to banks, building societies, PRA-designated investment firms and Solvency II insurers. For material outsourcing, it expects written agreements to set out the provider's reporting obligations and incident handling, including escalation and reporting. Firms may rely on certificates and independent reports from the provider, but must assess them rather than treat their existence as enough.

UK GDPR, for any customer whose personal data you process. Under Article 33(2) of the UK GDPR, a processor must notify the controller without undue delay after becoming aware of a personal data breach. Article 28(3) requires the processing contract to oblige you to give the controller the information needed to demonstrate compliance and to allow for audits, including inspections.

Read together, these produce a familiar set of clauses: notify incidents, report material changes, share assurance reports, and let the customer or its regulator audit you. Our guide to ISO 27001 Annex A 5.20, supplier agreements, covers the same terms from the customer's side of the table.

What goes in a customer assurance pack, and when should you refresh it?

A customer assurance pack is the standard set of documents a regulated customer receives each year and a prospect receives during due diligence. It usually holds a SOC 2 report and bridge letter, an ISO 27001 certificate and scope, a penetration test summary and key policies. Refresh it whenever any of those items changes.

Keep one current version of the pack, dated, with a named owner. A customer who receives last year's certificate, or a scope statement that excludes the service they buy, will ask more questions, not fewer.

The pack is a list of what to share. How you publish it, whether by email, portal or trust centre, is a separate decision.

What should a board and investor compliance update contain?

A board and investor compliance update should fit on one page and give a status opinion, not a list of activity. It covers headline status, certification and report dates, open findings, incidents, customer commitments at risk and decisions needed. The reader should know within a minute whether anything needs their attention.

A workable one-page structure:

1. Headline status. One sentence: on track, at risk or off track, and why.
2. Certifications and reports. Current ISO 27001 certificate expiry, next surveillance audit, current SOC 2 period end and the next report date.
3. Open findings. Audit nonconformities, exceptions and penetration test findings, by severity and age, with the oldest named.
4. Incidents. Incidents since the last update, which customers were notified, and whether every notice met its contractual deadline.
5. Customer commitments at risk. Any contractual reporting or control commitment you are likely to miss, with the customer and date.
6. Decisions needed. Budget, risk acceptance or priority calls only the board can make.

Investors usually need a shorter version of the same page: status, certifications, material incidents and anything that could affect revenue or a renewal.

"Completed the annual policy reviews" tells the board what the team did. "On track for recertification in March; one major customer commitment at risk" tells them what they need to know.

How does continuous evidence turn compliance reporting into a generated output?

Compliance reporting becomes a generated output when every report reads from one evidence base that is collected continuously, not assembled before each deadline. Each control's evidence is captured from its source system on a schedule, with a date and an owner. Each report is then a view of the same records.

The method has three parts:

1. An obligations register. Every reporting promise in every customer contract, with the deadline, recipient and clause. This is where notification windows and annual pack dates live.
2. An evidence base. For each control, the evidence, where it comes from, when it was last collected and who owns it. Pull it from systems of record such as identity, ticketing, cloud configuration and vulnerability scans, rather than from screenshots taken the week before an audit. Deciding which controls to monitor, and how often, is the job of a compliance monitoring plan; reporting only reads the result.
3. Report templates that query both. The customer pack, the board page and the investor section each pull the same fields: certification dates, open findings, incidents and notices sent.

Because each figure has one source, the numbers cannot disagree between documents. The question of why a customer's pack says something different from the board page stops arising.

The ISO 27001 management review reuses the same data. Clause 9.3.2 lists the inputs top management must consider, including information security performance, audit results, feedback from interested parties and the status of risk treatment. Our Clause 9.3 management review guide sets out each one. If your quarterly board page already carries those inputs, the management review becomes a longer sitting of the same meeting, not a separate production.

How should a small firm run compliance reporting, step by step?

In a firm of 25 to 150 staff, compliance reporting needs one owner, one calendar and a fixed routine. The security or compliance lead owns the evidence and drafts every report. A named director signs off what goes to the board and investors. The CTO or incident lead owns customer incident notices.

1. List the obligations. Read every customer contract and processing agreement and copy each reporting, notification and audit-right clause into the obligations register.
2. Build the calendar. Plot annual packs, certification and report dates, board meetings and investor updates on one calendar, with an owner per item.
3. Map each report to its evidence. For every field in every report, record which evidence record supplies it.
4. Set the notification route. Agree who decides an event is notifiable, who drafts the notice, and how the contractual deadline is tracked from the moment of awareness.
5. Generate, review, send. Produce each report from the evidence base, have the owner check it, and record what was sent, to whom and when.
6. Feed back. Customer questions, audit findings and missed deadlines go back into the obligations register and the next management review.

This routine is kept small on purpose. Its value is that the same steps run every quarter. Nothing depends on one person remembering a clause in a contract signed two years ago.

What are the most common compliance reporting mistakes?

The most common compliance reporting mistakes are contractual reporting promises nobody tracks, figures that disagree across customer packs, activity lists instead of a status opinion, and missed notification deadlines. Each one damages the customer's trust faster than the control gap itself would, because it shows the supplier cannot see its own position.

Contractual promises nobody tracks. Sales agrees an extra audit right or a quarterly report in a contract redline, and nobody records it. The first time anyone hears of it is when the customer's auditor writes in.

A reporting promise nobody has written down is a breach waiting for a date.

Figures that disagree. One customer's pack shows one count of open findings, another shows a different count, and the board page shows a third. Each was built by hand on a different day. A regulated customer comparing notes with its peers, or with its own auditor, will notice.

Activity instead of opinion. Reports that list work done leave the reader to work out whether the firm is compliant. Lead with the status, then the evidence for it.

Missed notification deadlines. The incident was handled well, but the customer heard about it late. Under a contract with a fixed notice window, a late notice can be its own breach, even when the incident itself caused no harm.

The notice is part of the incident, not an afterthought to it.

Frequently asked questions