Why Contractual Assurance Isn't Enough for Third-Party Risk

Read alongside our report on the pressure CNI clients are now passing down to their legal advisers: Under Pressure: How Law Firms Can Meet Rising Client Cyber & Resilience Demands.

‍

What contractual assurance actually covers (and where it stops)

Contractual assurance is the set of obligations a supplier agrees to in writing. Audit rights, service level agreements, security schedules, breach notification clauses. It's the legal foundation of a supplier relationship.

That foundation matters, and for a law firm it matters more than most. When a supplier holds privileged client data, a contract without security obligations gives your security team nothing to point to when something goes wrong, no clause to invoke, no defined notification window, no basis for remediation. Legal and security teams are right to insist on it.

But a contract is a snapshot of intent, usually taken before the relationship has properly started. It describes what a supplier agreed to do, not what they're doing eighteen months later when a new engineering team has quietly changed the infrastructure, or a cost pressure has pushed a security control down the priority list.

This is where contractual assurance and operational reality start to separate. The clause still exists. Whether it's still being met is a different question, one the contract itself can't answer. Answering it requires an ongoing view of the supplier's actual posture, not the version they signed up to. Even the NCSC's own supply chain security principles treat these as two separate stages of the same job: establishing control over the supply chain is one phase, and checking those arrangements are still working is a distinct, later one. A contract belongs to the first phase. It was never designed to do the work of the second.

The gap isn't a legal drafting problem. Tighter clauses don't fix a monitoring gap. It's a visibility problem, and it needs an operational answer, not a contractual one.

‍

Why audit rights and certifications don't prove ongoing security

An audit right is a clause that lets you inspect a supplier's controls. A certification, ISO 27001, SOC 2, is a third party's confirmation that those controls existed at the point of assessment. Both are useful. Neither tells you what's true today.

Audit rights are also harder to exercise than they look on paper. Invoking one against a small supplier is straightforward. Invoking one against a large cloud provider or a global technology vendor, the kind of supplier a law firm often has the least leverage over, is a different negotiation entirely. The clause exists. Whether a firm can realistically use it against a supplier they can't afford to lose is a separate, much harder question.

Certifications carry the same limitation from a different angle. A SOC 2 report describes a control environment at a fixed point in time, typically annually. It says nothing about the six months either side of it. A supplier can hold a valid certificate and still have drifted from the controls it describes, through a team change, a cost cut, or a rushed product release, long before the next audit catches it.

None of this makes audit rights or certifications worthless. It means they answer "did this supplier meet the bar once" and can't answer "do they still meet it now." That second question needs a different kind of evidence, closer to continuous, not point-in-time.

‍

How indirect regulatory pressure reaches law firms not directly in scope

Indirect regulatory pressure is when a regulation doesn't name your firm, but still shapes what your clients require from you. DORA and NIS2 are the clearest current examples. Law firms are rarely directly designated as Critical Third Parties by regulators, but they are increasingly classified as "critical" or "high-risk" by their own clients, forcing them to comply with the strict terms of both frameworks.

DORA applies to EU financial entities and the ICT third parties that support them. It doesn't bind UK-only regulated firms directly, though UK institutions with EU operations or EU clients still have to meet DORA's requirements for those specific activities.

The mechanism that pulls a firm in is narrower than "we have a bank client." Non-EU providers serving EU-regulated clients fall within DORA's scope specifically through their clients' own due-diligence obligations under Article 28, which apply where a supplier is delivering ICT services supporting a critical or important function, not to every professional services relationship a regulated client has.

NIS2 works on a similar but distinct principle. UK organisations supplying services to EU essential or important entities can face indirect NIS2 requirements through their customers' own supply chain security obligations, and the directive is explicit that this flow-down covers direct suppliers and service providers, not the full extended chain beneath them.

For a firm advising a DORA or NIS2-regulated client, this is the practical translation: the obligation doesn't arrive as a new regulator knocking on the door. It arrives as a due-diligence questionnaire, a revised contract clause, or a request for evidence that wasn't there during the last renewal, because your client now has to demonstrate oversight of you. Whether it applies to a given engagement depends on what the firm is actually doing for that client, holding sensitive data, supporting a system, running part of a process, not on the client's regulatory status alone.

‍

How far oversight needs to reach beyond contractual clauses

Oversight beyond the contractual clauses means confirming a supplier's controls are still working, not just that they were promised. For most law firms, "beyond the signature" starts in one place: the direct suppliers holding or processing client data, the case management platforms, e-discovery tools, and data rooms where the exposure is immediate and the impact of a failure is obvious.

That's the right place to start, but it isn't the edge of the risk. A supplier you've reviewed thoroughly can still depend on another supplier you've never heard of.

Ten different platforms your firm uses might all sit on the same underlying cloud infrastructure or use the same document-processing vendor beneath the surface, without that dependency ever showing up in any individual supplier's questionnaire.

This is concentration risk: several apparently unrelated relationships turning out to be one single point of failure. It's a genuinely different problem from "is this one supplier secure," and it needs a different kind of visibility to catch, mapping dependencies across suppliers rather than assessing each one in isolation. We've written more on why this blind spot exists and how firms are closing it.

None of this argues for reviewing every fourth and fifth-party relationship with the same intensity as a direct supplier. That's not realistic, and it isn't where the risk is concentrated anyway.

The practical order is: get solid, ongoing oversight of the direct suppliers that actually touch sensitive data or critical systems first, then extend visibility outward to where concentration risk is most likely, such as in shared infrastructure, shared processors, common dependencies, rather than trying to assess the entire extended chain at the same depth from day one.

‍

The AI-as-undeclared-supplier problem

An undeclared AI supplier is a case where a tool your firm already uses has quietly gained an AI capability, an integration, a plugin, a model call, without that change ever being flagged, assessed, or added to any supplier record. The supplier relationship was reviewed once, at onboarding. The AI wasn't there yet.

This is a genuinely different problem from deciding whether to allow ChatGPT or Copilot in the firm. Those are visible, obvious AI purchases, and most firms already have a view on them.

The harder case is the practice management tool bought three years ago, the transcription service, the document automation platform, any of which can have an engineering team quietly plug a large language model into part of the product without it ever being marketed as an "AI feature." The firm keeps using the tool exactly as before. Client data starts flowing somewhere new. Nobody signed off on that, because nobody was asked to.

For a law firm, the stakes are higher than for most sectors. Privileged material, client confidences, and case strategy are precisely the kind of content that shouldn't end up as an input into a third-party model without genuine visibility into where it goes and how it's used. A supplier's AI use isn't automatically a problem. Not knowing about it is.

The honest limitation here is that no contract signed before a supplier added an AI feature could have anticipated it. This isn't a gap that better drafting closes. It needs an ongoing way of catching when a supplier's tech stack changes, not a smarter clause.

‍

Monitoring your highest-risk, least-cooperative suppliers

A low-cooperation, high-risk supplier is one your firm can't function without, and can't get to move quickly on remediation either. It's usually a large technology vendor or global platform provider, the kind of relationship where leverage sits firmly on their side, not yours.

This is the sharpest version of the audit-rights problem from earlier in this piece. A small supplier that fails a review can be told to fix the issue or lose the contract. A large cloud provider or case management platform that half the sector depends on doesn't face that pressure from any single law firm, however large. Chasing them for a bespoke security call or a non-standard contract amendment usually gets nowhere, and firms that try to force the issue often spend months achieving very little.

The practical answer isn't to keep pushing harder on the same lever. It's to stop treating "get this supplier to change" as the only success condition, and monitor instead. That means tracking what's publicly and contractually knowable about the supplier's posture on an ongoing basis, security disclosures, breach notifications, changes to their subprocessor list, so a firm knows when something has shifted, even without the supplier's active cooperation. 

Where NCSC guidance is clear is that using a third party doesn't transfer away the underlying responsibility: an organisation relying on outsourced or cloud-based services remains accountable for protecting its essential functions regardless of who operates them. That accountability doesn't disappear just because a supplier won't engage.

Where a firm genuinely cannot get the visibility it needs and cannot walk away from the supplier either, the honest answer is that this becomes a risk the business consciously accepts, not one security quietly absorbs. Naming that trade-off explicitly, in writing, to the people who own the client relationship, is often more useful than another unanswered email to the supplier's security team.

‍

What does good ongoing oversight look like, and how does Risk Ledger support it?

Good ongoing oversight means a firm can answer, at any point, whether a supplier's controls are still what they signed up to, without waiting for the next scheduled review to find out. That's the practical test. 

In practice, that means four things working together: evidence that gets refreshed rather than going stale between reviews, visibility that extends past direct suppliers into the shared infrastructure where concentration risk sits, a way of catching supplier-side changes, including new AI use, that a static contract could never have anticipated, and a clear, honest record of where a firm has accepted risk because a supplier won't or can't cooperate further.

We built Risk Ledger because point-in-time assessment and one-off contractual sign-off were never going to close this gap on their own. Suppliers on our network maintain one security profile that updates and gets reused across every client relationship, rather than a fresh questionnaire being filled in from scratch each time.

That gives firms a live view of whether a supplier's posture has actually changed, not just a certificate confirming it once did. Because organisations are connected through the same network, we can also show relationships beyond the direct supplier, helping firms spot the shared dependencies and concentration risk that traditional TPRM misses entirely. And when a new vulnerability or supplier incident emerges, we help firms work out exposure fast, against real, current supplier data, rather than starting from a spreadsheet and a round of phone calls.

We're not a replacement for the contract. The contract still matters, still needs those audit rights and security schedules in section one's table. What we do is the part the contract was never built to do: keep watching after it's signed.

‍

Why Contractual Assurance Isn't Enough for Third-Party Risk FAQs

What's the difference between contractual assurance and third-party risk management?

Contractual assurance is the legal foundation, audit rights, security schedules, breach clauses. Third-party risk management is the ongoing work of checking whether a supplier is still meeting those terms. One is a document. The other is a process.

Can audit rights actually be enforced against large suppliers?

In principle, yes. In practice, it depends on leverage. Invoking an audit clause against a small supplier is straightforward. Doing it against a global cloud provider or platform vendor a firm can't easily replace is a different negotiation, and cooperation isn't guaranteed.

What counts as a "critical" supplier for oversight purposes?

Any supplier holding, processing, or providing system access to sensitive client data or a function the firm can't operate without. Criticality is about impact if the relationship fails, not about contract size or spend.

How often should supplier evidence be refreshed?

Often enough that a change in the supplier's posture, a new subprocessor, a lapsed control, an added AI feature, would be caught before it turns into an incident, rather than at the next scheduled annual review.

‍

_Sources

The principles of supply chain security (NCSC)
‍Principle A4: Supply Chain, Cyber Assessment Framework (NCSC)
‍Regulation (EU) 2022/2554 (DORA), Article 28: ICT third-party risk management (EUR-Lex)
‍ICT and cyber risk for DORA entities (CSSF, Luxembourg)
‍Directive (EU) 2022/2555 (NIS2), Article 21: Cybersecurity risk-management measures (EUR-Lex)