Your organisation’s security is only as strong as its weakest supplier. That sounds like a cliché until a vendor’s lax access controls take down your operations, or a regulator asks why you failed to validate the resilience of your critical partners.

Regulations like NIS2 and DORA have made supplier governance a board-level issue — not because regulators enjoy paperwork, but because supply chain incidents have become too frequent and too damaging to treat as someone else’s problem. This article gives you a practical, no-filler framework to move beyond basic vendor questionnaires. You will learn where most supplier risk actually starts, how to spot concentration issues before they hurt you, and why exit planning is not optional.

Risk Starts Before the Contract

A huge amount of third-party risk is accepted the moment procurement, legal, and security are not in the same room. Too many deals are signed where security is brought in as a rubber-stamp after the commercial terms are already locked. That leaves you with contracts that have weak audit rights, vague incident notification language, and no practical accountability.

The best supplier governance begins with the standards you are willing to enforce during negotiation — not after. A simple rule: if a critical supplier refuses a right-to-audit clause, that is a risk decision that needs an owner and a documented acceptance, not a shrug.

Consider a manufacturing client that signed a multi-year contract with a new cloud ERP provider without embedding security requirements in the SLA. When the relationship ran into trouble, the provider refused to share critical audit reports. The remediation cost six figures and took months. The lesson was not that the vendor was difficult. The lesson was that nothing in the contract compelled them to cooperate.

Right-to-audit clauses, incident notification windows, data handling obligations, and exit terms are not legal extras. They are security controls written in commercial language. If they are not in the contract, they do not exist.

The NIS2 Reality: You Are Accountable for Their Failure

Under NIS2, if a critical supplier is compromised and your service goes down, the regulator will hold you accountable — not just the vendor. The Directive is explicit: essential and important entities must manage the security risks posed by their suppliers and service providers.

That is not a general expectation of good behaviour. It is a compliance obligation with enforcement consequences.

I worked with an energy company that assumed their SCADA maintenance provider was secure. A gap assessment revealed the provider used shared, unpatched admin credentials across multiple clients. We fixed it before it became a breach notification. That is the level of active validation regulators now expect. Asking “are you compliant?” is not enough. You need to see evidence, and you need to keep seeing it on a regular cycle.

The minimum most organisations should be doing with their critical suppliers:

  • Annual security questionnaire validated against evidence, not self-attestation
  • Right-to-audit clause that you actually use
  • Incident notification obligations with defined timelines
  • Evidence of their own testing and resilience capability

For your highest-criticality suppliers, that baseline is only the starting point.

What a Good Third-Party Register Actually Tells You

Listing your vendors is just the starting point. The real value is what the register reveals.

For a banking client, simply listing vendors was not enough. We enriched their register to show that 40 per cent of their critical payment processing relied on a single cloud region in Frankfurt. That visibility allowed them to design a multi-region failover strategy before a regional outage could affect customers. The register did not tell them to do it — but it made the exposure impossible to ignore.

A mature third-party register shows:

  • Concentration risk — how many critical services depend on one provider or one geography
  • Weak exit options — where you have no practical way out if a relationship fails
  • Fragile dependencies — where a supplier is a single point of failure for a business-critical process
  • Contract quality gaps — where the contractual protections do not match the business criticality of the relationship

Under DORA, financial entities are required to maintain a register of information on all contractual arrangements with ICT third-party service providers. The regulation is specific about what that register must contain. But even outside financial services, the principle holds: if your register does not help you spot risk, it is just a spreadsheet with extra steps.

Shared Responsibility Is Not a Get-Out Clause

Too many organisations migrate to AWS, Azure, or Google Cloud and assume the provider handles everything. The shared responsibility model is precise, not vague. AWS secures the cloud. You are responsible for what you put in it — the data, the configuration, the access, the monitoring, and the backups.

A client suffered a data leak because they assumed their SaaS provider was backing up configuration data. The provider’s terms and conditions explicitly stated that was the customer’s responsibility. Nobody had read them carefully. Assumptions became exposure.

A clear cloud governance model removes that ambiguity. Document who owns logging, who owns recovery, who owns access management, and who is responsible for incident response. Then test it, because an undocumented assumption and a documented assumption that has never been tested are equally dangerous in a real incident.

Exit Planning Is Part of Resilience

You do not truly manage a dependency if you have no credible way out of it. That applies to cloud providers, managed services, software platforms, and specialist consultancies alike.

During a DORA readiness project for an insurer, we asked their core policy administration vendor a simple question: “If you go bankrupt tomorrow, how do we get our data back in 48 hours?” The vendor had no automated export process. It would have taken weeks, possibly longer, to retrieve the data in a usable format. We mandated a monthly data escrow deposit as a condition of contract renewal.

If your critical supplier contracts lack an exit clause with practical steps — data format, timeline, responsible party, and cost — you are not resilient. You are locked in, and you will only find out how locked in you are when it is too late to negotiate.

Exit planning is not about expecting relationships to fail. It is about retaining the ability to act when they do.

Onboarding Is Where Standards Become Real

A supplier policy is only useful if the onboarding process enforces it. Many organisations have strong policies on paper and weak gates in practice. The moment a new vendor needs access is often the moment standards quietly disappear under commercial pressure.

I designed an onboarding workflow for a financial firm where no supplier could be provisioned in the identity management system until their SOC 2 Type II report had been reviewed, their incident contact details were verified and loaded into the GRC tool, and their data classification obligations were confirmed. It stopped three high-risk vendors from accessing the network in the first month of operation.

Practical gates around access provisioning, data handling confirmation, evidence review, and incident contact registration turn a good policy into an actual control. Without those gates, onboarding is just a welcome email.

SaaS Sprawl Is a GRC Problem, Not Just an IT Inventory Problem

Marketing departments subscribe to tools using corporate credit cards. Nobody reviews them for security. Over time, the number of ungoverned platforms in an organisation grows steadily, and so does the exposure.

I have seen customer lists uploaded to train public machine learning models because nobody checked the vendor’s terms of use. The marketing team had no idea. The IT team had no visibility. The GRC team was not informed. The data was already public before anyone noticed.

SaaS sprawl creates access drift, unclear data ownership, unreviewed contractual terms, and hidden supplier exposure. It is a GRC topic because the risks are governance risks — accountability, data handling, third-party oversight, and incident response — not just technical ones.

If your SaaS estate is growing faster than your oversight, the starting point is a discovery exercise. You cannot govern what you do not know exists.

Conclusion and Next Steps

Third-party risk is no longer a back-office compliance task. It is core to operational resilience and, under NIS2 and DORA, a direct legal obligation for a broad range of European organisations.

By embedding security into procurement before contracts are signed, enforcing strict onboarding gates, maintaining a register that reveals concentration and exit risk, and keeping oversight of your cloud and SaaS estate, you turn your supply chain from a vulnerability into a managed, resilient ecosystem.

Next step: Download the free Supplier Contract Audit Checklist for NIS2 and DORA at Supplier Contract Audit Checklist for NIS2 and DORA. No email wall — just a direct download. We want you to use it.

If you would prefer to talk through your current third-party risk model first, the GRC Force team is available for a short diagnostic call. You can book directly at contact GRCForce.

Published by GRC Force — practical governance, risk, and compliance for European organisations. © GRC Force 2026 — grcforce.com