Governance reference
Vendor governance is the decision structure wrapped around a vendor relationship — who is allowed to decide what, on what evidence, and how often that decision is revisited. It is distinct from vendor management, which is the day-to-day running of the relationship. This page sets out the six artefacts a working vendor governance framework produces, who owns each one, and the cadence that keeps them current.
Most organisations have good vendor management and no vendor governance. Management asks whether a vendor is delivering; governance asks whether the organisation should still accept the exposure, and records who decided that. The distinguishing test is whether a risk acceptance survives the departure of the person who accepted it.
Qeluntra connects authorized supplier, contract, procurement, finance, logistics, inventory, and operating context. AI-assisted recommendations remain explainable and consequential actions remain subject to human approval.
These two terms are used interchangeably and they should not be. The distinction is the single most useful thing on this page, because almost every organisation that says it has a vendor governance problem actually has good vendor management and no governance at all.
| Vendor management | Vendor governance | |
|---|---|---|
| Question it answers | Is this vendor delivering? | Should we still be exposed to this vendor, and who says so? |
| Run by | The relationship or category owner | A forum with authority to stop something |
| Cadence | Continuous | Scheduled, and event-driven |
| Output | Performance against SLA | A recorded decision with a named owner |
| Failure looks like | Missed deliverables | Nobody can say who accepted the risk |
The practical test: when a vendor's penetration test comes back with two criticals, who is allowed to decide you will keep using them anyway, and where is that decision written down? If the answer is "the person who noticed", you have vendor management without vendor governance. Governance is the part that makes a risk acceptance survive the departure of the person who accepted it.
A vendor governance framework is not a document. It is a small set of artefacts that each answer one question and are each owned by one person. If you produce these six and keep them current, you have vendor governance; if you produce a forty-page policy and none of these, you do not.
| Artefact | Answers | Typical owner | Review |
|---|---|---|---|
| Vendor inventory | Who do we actually pay, and for what? | Procurement | Continuous |
| Tiering model | How much governance does each one warrant? | Risk | Annual |
| Supplier risk register | What could go wrong, who owns it, what is the treatment? | Risk owner per vendor | Quarterly (tier 1) |
| Contract and obligation register | What did we promise and what did they? | Legal | On change, plus annual |
| Assurance evidence file | What proof do we hold, and when does it expire? | Security / compliance | On expiry |
| Decision log | What did we accept, who accepted it, until when? | The governance forum | Append-only |
The decision log is the one almost nobody has, and it is the one an auditor asks for. The other five describe a state of the world. The decision log records that a human being with authority looked at that state and said yes. Without it, every other artefact is data with no accountability attached, and an "accepted risk" is indistinguishable from an unnoticed one.
An append-only decision log needs four fields and no more: what was decided, by whom, on what evidence, and when it expires. The expiry is what makes it governance rather than filing — a risk acceptance with no end date is a permanent exception in disguise.
Vendor governance sits badly in most org charts because it spans procurement, security, legal, finance and the business unit that actually wanted the vendor. The common failure is to give it to one of them entirely. Procurement-owned governance becomes a contracting checkpoint; security-owned governance becomes a questionnaire factory that the business routes around.
The arrangement that tends to survive is a named risk owner per vendor in the business, supported by a central function that maintains the artefacts and convenes the forum. Expressed as a RACI:
| Activity | Responsible | Accountable | Consulted |
|---|---|---|---|
| Proposing a new vendor | Business requester | Budget holder | Procurement |
| Tiering the vendor | Procurement | Risk function | Security |
| Running due diligence | Security / compliance | Risk function | Legal |
| Accepting a residual risk | Risk owner | Governance forum | Security, Legal |
| Keeping evidence current | Compliance | Risk owner | Vendor |
| Exit or termination | Procurement | Budget holder | Legal, IT |
One row matters more than the rest. Risk acceptance must be accountable to the forum, not to the person who wants the vendor. When the budget holder can accept their own residual risk, the governance framework is decorative — and that single line is usually the difference between a framework that changes outcomes and one that generates paperwork.
Governance that happens only when something goes wrong is incident response. The cadence is what makes it governance. A workable annual rhythm, assuming a three-tier model:
| Frequency | Activity | Applies to |
|---|---|---|
| Continuous | Inventory updates as contracts are signed; adverse-media and breach alerting | All vendors |
| Monthly | Expiring-evidence sweep — certifications, insurance, attestations | Tier 1 and 2 |
| Quarterly | Risk register review; open treatment actions; new and exiting vendors | Tier 1 |
| Semi-annual | Concentration and dependency review — where are we single-sourced? | Portfolio |
| Annual | Re-tiering; questionnaire refresh; exit-plan testing; policy review | All tiers, sampled |
| Event-driven | Breach, ownership change, sanctions listing, material service change, adverse audit finding | Any vendor |
The event-driven row deserves more weight than it usually gets. Scheduled review catches drift; almost every vendor failure that becomes a board matter arrives between scheduled reviews. A framework with no defined trigger for "this vendor was just acquired by a competitor" is a framework that will learn about it from the trade press.
The fastest way to kill a vendor governance programme is to apply it evenly. Sending a 280-question assessment to the company that services the coffee machines trains the whole organisation to treat the process as theatre, and ensures that the assessment for the payroll processor gets the same five minutes of attention.
Tier on consequence, not spend. Spend correlates weakly with exposure: a £4,000-a-year monitoring tool with an API key into production is a larger risk than a £400,000 facilities contract.
| Tier | Trigger — any one is enough | Governance applied |
|---|---|---|
| 1 — Critical | Supports a critical business service; processes special-category or large-volume personal data; privileged access to production; no practical substitute inside 30 days | Full assessment, annual on-site or evidenced re-review, quarterly register review, tested exit plan, named executive owner |
| 2 — Material | Processes personal data; integrates with a core system; interruption is disruptive but survivable | Standard assessment, annual refresh, evidence expiry tracked, documented exit route |
| 3 — Routine | No personal data, no system access, readily replaceable | Short screening at onboarding, sanctions and adverse-media check, no periodic reassessment |
Expect roughly 5–10% of a vendor population in tier 1 in most organisations. If a third of your vendors are critical, the tiering criteria are wrong, and the consequence is that nothing is treated as critical.
Vendor governance obligations are scattered across instruments rather than consolidated, which is why they are easy to miss. The ones that most often bite a UK or EU organisation:
| Instrument | Provision | What it requires of you |
|---|---|---|
| UK / EU GDPR | Article 28 | Use only processors able to demonstrate they meet the Regulation's requirements; a written contract with the prescribed terms; authorisation and flow-down for sub-processors |
| DORA (EU) 2022/2554 | Articles 28–30 | Maintain a register of information on all ICT third-party arrangements; specified contractual terms; exit strategies for arrangements supporting critical functions |
| EU AI Act | Article 26 | Deployer duties for high-risk AI systems — use per instructions, assign competent human oversight, monitor operation, retain logs. These land on you even where the system is a vendor's |
| NIS2 | Article 21(2)(d) | Supply chain security as a named element of required risk-management measures |
| ISO/IEC 27001:2022 | Annex A 5.19–5.23 | Supplier relationships, agreements, ICT supply chain, monitoring and review, and cloud services specifically |
The EU AI Act row is the one that has changed most recently and is least reflected in existing frameworks. Article 26 places obligations on the deployer — the organisation using the system — not only on the provider who built it. "We bought it, so it is their compliance problem" is not available as a position. Most vendor governance frameworks written before 2024 have no field anywhere for whether a vendor's product contains an AI system, let alone what risk class it falls in.
Applicability varies by sector, establishment and the nature of the service, and implementation timelines differ between instruments. Treat the table as a map of where to look, and take advice on which apply to you.
Five failure modes account for most of it. They are worth naming because each has a specific fix, and because a framework that has not been checked against them tends to fail in all five at once.
A SOC 2 report covers a defined window that ended before you read it. An ISO certificate has a scope statement, and the scope frequently excludes the service you are buying. Record the expiry and the scope, not just the fact of possession.
Procurement owns the purchase, the business owns the usage, and the risk belongs to whoever is unlucky. Name a risk owner at onboarding, as a required field, before the contract is countersigned.
Your vendor is on the register. Their hosting provider, their payment processor and the single open-source maintainer they depend on are not. Concentration risk lives one layer below the register in almost every organisation — and fourth-party concentration is what turns a single provider's bad afternoon into six of your services failing at once.
A forum that reviews a dashboard is a reporting meeting. A governance forum produces decisions with owners and expiry dates. If the minutes contain no verbs like "accepted", "rejected" or "required by", it is not governing.
"We would migrate to an alternative provider" is not an exit plan unless someone has established that the data is exportable in a usable format, that a substitute has capacity, and roughly what the switch would cost. DORA asks for this explicitly for critical functions; it is good practice regardless.
The six artefacts work as spreadsheets and shared drives up to stage 3 of the model below. What breaks at scale is not any single artefact — it is that they are six separate copies of the same vendor, and keeping them agreeing with each other becomes the job.
| Artefact | Held as a document | Held on one data model |
|---|---|---|
| Vendor inventory | Exported from finance, immediately behind | The supplier record itself — supplier management |
| Tiering model | A rule applied by hand at onboarding | A property set when the supplier arrives, driving what happens next |
| Supplier risk register | A spreadsheet reconciled quarterly | A view over live records — supplier risk management |
| Contract and obligation register | A folder plus a reminder | Contract intelligence, against the same supplier |
| Assurance evidence file | A drive with expiry dates in someone's calendar | Attached to the record, with expiry driving the sweep |
| Decision log | Usually absent entirely | Append-only against the supplier, with the acceptance expiry enforced |
That is what Qeluntra is for: source-to-pay, supplier onboarding and supplier risk on one data model, so a supplier arrives already assessed rather than assessed afterwards, and the register is a live view rather than a periodic exercise.
Two honest caveats. First, the jump from stage 2 to stage 3 — tier the population, name risk owners, put expiry dates on evidence, start a decision log — is organisational and costs nothing in software. Do that before buying anything; a platform will not supply the tiering rule or the willingness to say no. Second, the decision log is the artefact most organisations lack, and it is the one an auditor asks for — no system creates the discipline of recording who accepted what and until when.
Where software earns its place is stage 4, when the register cannot drift because it is not a separate artefact. Qeluntra's free plan needs no card if you want to see the shape of that before committing.
Useful mainly for locating yourself honestly. Most organisations that believe they are at stage 3 are at stage 2, and the tell is the decision log.
| Stage | Characteristic | The constraint |
|---|---|---|
| 1 — Contractual | Governance happens at signature and nowhere else. The register is the accounts-payable list. | Nobody knows what changed after signing |
| 2 — Periodic | Annual questionnaires, a spreadsheet register, evidence in a shared drive. | Accurate on the day it is compiled and drifting by the following week |
| 3 — Continuous | Tiering drives effort; evidence expiry is tracked; a forum makes recorded decisions; events trigger review. | Effort concentrated where consequence is |
| 4 — Integrated | Governance state is a property of the vendor record itself, so onboarding, contracting, risk and payment read the same data. | The register cannot drift, because it is not a separate artefact |
The jump from 2 to 3 is organisational and costs almost nothing in tooling: tier the population, name risk owners, put expiry dates on evidence, and start a decision log. The jump from 3 to 4 is where tooling actually matters, because it requires the register and the operational record to be the same data rather than two systems someone reconciles.
Vendor governance is the set of rules about who decides what regarding a vendor, on what evidence, and how often those decisions are revisited. In practice it is six artefacts — an inventory, a tiering model, a risk register, a contract register, an evidence file and a decision log — each with a named owner and a review cadence.
Vendor management asks whether a vendor is delivering and is run continuously by the relationship owner. Vendor governance asks whether the organisation should still accept the exposure, and is exercised by a forum with the authority to stop something. Management produces performance data; governance produces recorded decisions with named owners and expiry dates.
A named risk owner in the business for each vendor, with a central function maintaining the artefacts and convening the forum. The one rule that matters is that residual risk acceptance is accountable to the forum rather than to the budget holder who wants the vendor — otherwise the framework has no ability to say no.
Quarterly register review for critical vendors, monthly sweeps for expiring evidence, annual re-tiering and questionnaire refresh across the population, plus defined event triggers: breach, change of ownership, sanctions listing, material change of service, or an adverse audit finding. The event triggers catch more real failures than the calendar does.
A vendor list that is complete, a tiering rule based on consequence rather than spend, a named risk owner per tier 1 and tier 2 vendor, expiry dates recorded against every piece of assurance evidence, and an append-only decision log. That is achievable in a spreadsheet and outperforms a detailed policy nobody operates.
It needs the tiering and the decision log, and can reasonably skip the rest until the vendor population grows. A ten-person company with two critical vendors still has to be able to say who accepted the residual risk on those two and when that acceptance lapses. Contractual obligations under GDPR Article 28 apply regardless of headcount.