Compliance risk assessment: rank the obligations your customers and regulators hold you to

Your largest customer's annual supplier audit lands, and the first request is evidence that you met the incident notification window in your contract. Nobody on your team knew the window existed. It was agreed in a security schedule two years ago, alongside sixty other clauses that live in a folder, not in anyone's working week.

A compliance risk assessment fixes that by ranking every obligation you have taken on, from UK GDPR to certifications to customer contract terms, by the chance of missing it and what a miss would cost. This guide is for founders, COOs, CTOs and security leads at UK B2B tech firms with 25 to 150 staff that have signed their first financial services, insurance or public sector customers. It covers where your obligations come from, a six-step method, impact and likelihood criteria written for a supplier, a worked example, and how to keep the ranking current.

What is a compliance risk assessment?

A compliance risk assessment scores each obligation your firm holds, from laws and certifications to contract terms, by how likely a breach is and what it would cost: a failed customer audit, a lost renewal, a contractual claim or a regulator notification. Start from the obligations register, score inherent risk, credit controls and evidence, then monitor the top residual risks.

Compliance risk is the risk of failing to meet an obligation. Security risk is the risk of harm to information or systems. The two overlap but are not the same: you can suffer no breach of data at all and still be in breach of a contract that required you to report a suspected incident within a fixed window.

This page scores the entries in an obligations register; it does not cover building the register itself. For the general risk method, scales and treatment options in ISO terms, see our page on ISO 27001 clause 6.1, actions to address risks and opportunities.

Where do a tech supplier's compliance requirements come from?

A tech supplier's compliance requirements come from five places: data protection law, customer security schedules and data processing agreements, terms that regulated customers must impose on their suppliers, the outsourcing expectations UK regulators set for banks and insurers, and the certifications you have promised to keep. Most reach you through a contract rather than a regulator.

That last point shapes the whole assessment. Your financial services customer carries the regulatory duty, and it passes the duty to you as a clause. You may never deal with the regulator directly, but you will deal with the customer's auditor, its renewal team and its legal department.

Check each row against your own contracts and your customers' regulatory status, because the details vary by firm. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025 and binds EU financial entities, so for most UK suppliers it arrives through EU customers' contracts rather than directly. Only ICT providers designated as critical are overseen under DORA itself. For how ISO 27001 frames the same duty to identify these requirements, see Annex A 5.31 on legal, statutory, regulatory and contractual requirements.

For the processor duties in context, see our GDPR overview. Your customer sees the same clauses from the other side: Annex A 5.20 on information security within supplier agreements explains what a buyer is expected to write into them, which is a useful guide to what the next contract will ask of you.

How do you run a compliance risk assessment, step by step?

Run a compliance risk assessment in six steps: start from the obligations register, group obligations that share a control, score inherent impact, score inherent likelihood, credit the controls and evidence you already have, then rank the residual risks and set monitoring. Each step uses the previous one, so a weak register produces a weak ranking however careful the scoring.

1. Start from the obligations register. List every obligation with its source, the contract or law it comes from, and an owner. Include customer-specific terms, not only the frameworks you hold. If a clause exists in one contract only, it still gets its own line.
2. Group obligations that share a control. Ten customers may each require incident notification, with windows that differ. Group them under one control, but record the strictest window, because that is the one the control has to meet.
3. Score inherent impact. Ask what a miss would cost if no control existed, using the supplier impact criteria below. Score the worst realistic case, not the worst imaginable one.
4. Score inherent likelihood. Ask how likely a miss is, again before controls, using the likelihood drivers below. Use the same scale and matrix you use for other risks so the results sit on one board report.
5. Credit controls and evidence. Lower the score only where a control exists and leaves a record. A policy that says "we notify customers promptly" earns little credit; a ticketed incident process with timestamps earns more.
6. Rank residual risk and set monitoring. Sort by residual score. The top entries get an owner, a monitoring method and a review date; the rest get a periodic check.

The output is a short ranked list, not a long spreadsheet. If the top ten is not obvious after step 6, the impact criteria are probably too generous.

How do you score the impact of a missed obligation for a supplier?

Score the impact of a missed obligation by what it would do to revenue, to your contractual position, to your notification duties, to your certifications and to your customer's standing with its regulator. A supplier's impact criteria are commercial first. The regulator usually arrives through the customer, as an audit finding or a question about how the customer oversees you.

We recommend four levels with plain definitions, so two people scoring the same obligation reach the same answer. The levels below are our illustrative guidance, not taken from any law or standard. Set your thresholds against your own revenue and contracts.

The PRA's supervisory statement on outsourcing, SS2/21, shows why level 4 is realistic. It expects a bank or insurer to tell the PRA if a provider in a material outsourcing arrangement is unable or unwilling to support the firm's compliance through the contract.

What makes a compliance breach more likely?

A compliance breach is more likely when evidence is gathered by hand, when one customer's terms differ from everyone else's, when the obligation or the system behind it changes often, when it has been missed before, and when no automated control checks it. Score likelihood on these drivers rather than on how confident the owner feels.

• Manual evidence. An obligation met by someone remembering to export a report each month is more likely to slip than one met by a system log.
• Customer-specific terms. A bespoke term is the one most likely to be missed. Take a 24-hour incident notice in one contract when the others agreed 72 hours. Neither figure comes from the law. Under UK GDPR Article 33, a processor must tell the controller without undue delay. The 72 hours is the controller's own deadline to report to the regulator, so a customer has reason to set your window shorter.
• Rate of change. Obligations tied to fast-moving parts of the stack, such as sub-processors and hosting locations, drift as the product changes.
• Past misses. An obligation missed once, even without consequence, has shown the control can fail.
• Automation. Score down when a control is checked by a tool that alerts on failure; score up when nobody would notice a failure until the customer asked.

A clause nobody can find is a clause nobody is meeting.

What does a compliance risk assessment look like in practice?

A worked compliance risk assessment shows each obligation with its source, inherent score, the controls and evidence credited, the residual score and the monitoring that follows. The excerpt below is illustrative, for a SaaS supplier with UK banking and EU insurance customers; its notification windows and scores are examples, not legal requirements.

Scores use a 1 to 4 scale for impact and likelihood, multiplied.

The top line is the lesson. A strong general incident process did not lower the residual score, because the control does not meet the strictest term. The assessment is what found that, before the customer's auditor did.

Who owns the compliance risk assessment, and when should you review it?

The compliance risk assessment needs one owner who maintains the ranking, usually the security or compliance lead, and an owner for each obligation who answers for its control. Review the whole ranking at least once a year, and re-score affected entries whenever a new regulated customer signs, a contract renews, a framework is added or an incident occurs.

These events change the ranking more than the calendar does:

• A new regulated customer. Its contract may add terms you have never carried, such as audit rights for its regulator.
• A contract renewal. Renewals are where customers tighten terms, often after their own regulator has asked questions.
• A new framework or certification. Adding SOC 2 or ISO 27001 adds commitments to keep, and may change which controls earn credit.
• An incident or near miss. A missed or nearly missed obligation is evidence that the likelihood score was too low.

Scoring once a year measures last year's contracts.

How do you keep compliance risk current with continuous monitoring?

Keep compliance risk current by connecting the top residual risks to controls that are checked automatically and leave evidence as they run. Instead of re-scoring by hand each year, monitor the few obligations where a miss would cost most, and let a failing check reopen the assessment. The ranking becomes a working list rather than an annual document.

Regulated customers have reason to expect this. For material outsourcing, SS2/21 tells banks and insurers not to assume a provider's certificates and reports are sufficient evidence just because they exist, and the PRA encourages online, real-time reporting tools where they are available. A supplier that can show current evidence is easier to oversee than one that sends last year's report.

In practice, for each top-ranked obligation:

• Name the signal. Decide what record proves the obligation is met: a ticket timestamp, a sub-processor change log, a certificate expiry date.
• Automate the check. Have a scheduled job or monitoring tool test the signal and alert the owner when it fails.
• Keep the evidence. Store each result, so the next customer audit draws on a history, not a scramble.
• Close the loop. When a check fails, re-score that obligation and record what changed.

A certificate on your trust page is a promise, not a control.

What are the common mistakes in a compliance risk assessment?

The common mistakes in a compliance risk assessment are treating every customer clause as equal, building the register once for one deal and never updating it, assessing frameworks but not contracts, and crediting controls that leave no evidence. Each one makes the ranking look calmer than the obligations really are.

1. Treating every clause as equal. A bespoke notification window and a standard confidentiality clause do not carry the same risk. Scoring them the same buries the one that matters.
2. Building the register for one deal. A register made to answer one customer's due diligence is a snapshot of one negotiation. It goes stale at the next contract.
3. Assessing frameworks but not contracts. Holding ISO 27001 does not mean you meet one customer's bespoke notification window. The certificate tests your management system; the contract tests the specific term.
4. Crediting controls without evidence. If no record shows the control ran, give it no credit, however sure the owner is.

A useful test for the finished assessment: could the person who owns each top-ranked obligation show you its evidence today? If not, the ranking is a plan, not yet an assessment.

Frequently asked questions