Field specification
A supplier risk register is the record of what could go wrong with each supplier you depend on, who owns that risk, and what is being done about it. It is not a list of suppliers — that is an inventory. This page gives the column specification, the scoring method, and worked rows, so you can build one that survives an auditor asking to see it.
The artefact most often filed under this name is a supplier list with a red, amber or green column attached, which is an inventory with a mood. The unit of record has to be a risk rather than a supplier, because only then can each entry carry an owner, a treatment, a due date and an expiry.
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.
The most common thing filed under this name is a supplier list with a red/amber/green column bolted onto it. That is an inventory with a mood attached. A supplier risk register has a different unit of record:
The row is a risk, not a supplier. One supplier can generate five rows; four hundred routine suppliers can generate none.
This distinction decides everything about the structure. If the row is a supplier, the register can only hold one judgement per supplier and has nowhere to put a treatment action, an owner or a due date. If the row is a risk, each entry can be owned, treated, escalated and closed independently — which is what makes the artefact operational rather than descriptive.
The test an auditor applies: pick a row at random and ask who owns it, what the current treatment is, when it was last reviewed, and what would have to change for it to be closed. A register that cannot answer those four questions for an arbitrary row is documentation, not a control.
Nineteen fields, grouped. The first eight are the minimum viable register; everything after is what turns it from a record into something that drives action. Start with the first group and add the rest as the population grows.
| Field | Type | Why it exists |
|---|---|---|
risk_id | Stable key | So a risk can be referenced in minutes, audits and contracts without ambiguity. Never reuse a retired id. |
supplier | Reference | Points at the inventory record, not a typed name. Typed names are how one supplier becomes three entries. |
service_affected | Reference | A supplier is rarely uniformly risky. The risk attaches to a service, which is what lets you aggregate by business impact later. |
tier | 1 / 2 / 3 | Denormalised from the inventory so the register can be filtered without a join. Governance effort follows this column. |
| Field | Type | Why it exists |
|---|---|---|
category | Controlled list | Financial, operational, information security, data protection, regulatory, concentration, geopolitical, ESG, reputational, contractual. A controlled list is what makes portfolio reporting possible. |
description | Free text, structured | Written as cause → event → consequence. "Supplier is risky" is not a risk. "Sole-source supplier of the payment gateway has a single region deployment, so a regional outage stops card takings" is. |
date_identified | Date | Age of an open risk is the single most diagnostic metric in the whole register. |
source | Controlled list | Questionnaire, audit, incident, adverse media, monitoring alert, self-declared, internal observation. Tells you which detection channel is actually working. |
| Field | Type | Why it exists |
|---|---|---|
likelihood_inherent | 1–5 | Before controls. Recording inherent separately is what lets you show a control is doing work. |
impact_inherent | 1–5 | Scored against a published impact scale, not intuition. See below. |
velocity | 1–5 | How fast it materialises once it starts. Routinely omitted and it should not be — see the scoring section. |
controls_in_place | Text / reference | What is actually mitigating this now. If it is empty, residual must equal inherent, and a register where those differ with no controls listed is being scored optimistically. |
likelihood_residual | 1–5 | After controls. |
impact_residual | 1–5 | After controls. Usually unchanged — most controls reduce likelihood, not consequence. |
| Field | Type | Why it exists |
|---|---|---|
risk_owner | Named person | A person, not a team or a role. Teams do not accept risk; people do. |
treatment | Controlled list | Accept, mitigate, transfer, avoid. Exactly four options. "Monitor" is not a treatment — it is acceptance with better manners. |
action | Text + due date | Required whenever treatment is mitigate. A mitigate with no dated action is an acceptance that has not admitted it. |
acceptance_expiry | Date | Required whenever treatment is accept. This is the field that stops accepted risks becoming permanent. |
last_reviewed | Date | Drives the staleness report, which is the only thing that keeps the register honest. |
Three rows showing the description convention and how treatment interacts with the expiry fields. Abbreviated to the columns that carry the argument.
| Id | Risk (cause → event → consequence) | Cat. | L×I×V | Treatment | Owner / date |
|---|---|---|---|---|---|
SR-0114 | Payment gateway supplier runs a single-region deployment, so a regional cloud outage halts all card takings until failover is manual | Concentration | 2×5×5 | Mitigate — secondary gateway contracted, routing tested quarterly | H. Osei, due 2026-11-30 |
SR-0119 | Payroll bureau's ISO 27001 scope statement excludes the hosting of the employee portal, so the certificate does not cover the system holding our personal data | Data protection | 3×4×2 | Mitigate — targeted assurance requested for the portal; contract amendment for Art 28 terms | L. Marsh, due 2026-10-15 |
SR-0121 | Facilities cleaning contractor holds no cyber insurance, against a policy threshold of £1m for on-site suppliers | Contractual | 2×1×1 | Accept — no system access, no data, consequence immaterial | D. Whitaker, expires 2027-09-23 |
Note what row SR-0119 demonstrates: the risk is not "supplier lacks certification". The supplier has the certificate. The risk is that the scope statement excludes the thing you care about, which is one of the most common and least-noticed findings in supplier assurance. Registers that record "ISO 27001: yes" as a boolean cannot represent it at all.
Likelihood × impact is the standard and it is incomplete for suppliers specifically. Two risks scoring 3×4 can behave completely differently:
Velocity — how fast the risk materialises once it begins — is what separates them, and it is what determines whether your treatment can be a plan or has to be a pre-built capability. A high-velocity risk cannot be treated with "we would find another supplier"; there is no interval in which to do it.
| Velocity | Time from onset to full exposure | What treatment must therefore be |
|---|---|---|
| 1 | More than 12 months | Monitoring and periodic review is genuinely sufficient |
| 2 | 3–12 months | A documented plan, reviewed at each cycle |
| 3 | 1–3 months | A plan with identified alternatives and known switching cost |
| 4 | Days to weeks | A contracted alternative, not an identified one |
| 5 | Hours | A live, tested failover. Anything else is acceptance. |
On impact scales: publish yours, in the units your organisation argues in. An impact of 4 should read something like "£250k–£1m, or a reportable personal-data breach, or a critical service down beyond its maximum tolerable outage", not "major". Unpublished scales produce registers in which every risk is a 3, because 3 is what people choose when they are guessing.
Do not average the three numbers into one score. Multiplying or averaging destroys exactly the information you collected them for: 2×5×5 and 5×2×2 both yield 50 and demand completely different responses. Sort by impact, then velocity, and use likelihood to decide how much attention to spend — not to suppress a catastrophic-but-unlikely row down the list.
Supplier risk registers are frequently built by copying the corporate risk register template, and three things break when you do.
On a corporate register, "implement control X" is a treatment you can execute. On a supplier register, it is a request to another company with its own priorities, and your only levers are contractual, commercial or exit. Treatment actions need to name the lever, not the outcome: "contract amendment at renewal requiring 72-hour breach notification" rather than "supplier improves incident response".
Everything you know about a supplier's controls came from them, through a questionnaire or a report covering a period that has ended. A corporate register is scored on evidence you can go and look at. A supplier register is scored on assertions with a shelf life — which is the argument for the source and last_reviewed columns doing real work.
Supplier risks are not independent. Forty suppliers with different names can share one cloud region, one payment processor, or one authentication provider. A register that scores each row in isolation systematically understates the portfolio, and the only fix is a concentration view that aggregates by fourth-party dependency rather than by supplier — which requires you to have asked the fourth-party question in the first place.
Worth separating clearly, because they are often conflated. DORA requires a register of information on ICT third-party arrangements (Regulation (EU) 2022/2554, Article 28(3)), with prescribed content covering contractual arrangements, the functions supported and whether they are critical or important. It is a contract-and-dependency register.
Your supplier risk register is a different thing: it records risks and their treatment, not arrangements and their attributes. They share source data — the supplier inventory, the tiering, the service mapping — and should be generated from it rather than maintained as two disconnected spreadsheets that disagree by the second quarter.
Similarly, ISO/IEC 27001:2022 Annex A 5.19–5.23 asks for supplier relationship management, agreements, ICT supply chain treatment, and monitoring and review — an auditor will ask to see the register as evidence of 5.22, and the columns that satisfy them are last_reviewed, risk_owner and the treatment fields.
Five of the six mistakes in the next section are discipline problems you can fix in a spreadsheet this week. The sixth — the register living apart from the supplier record — is structural, and it is where most staleness actually comes from.
The shape of it: the register holds a supplier, onboarding holds the same supplier, contracting holds them again, and finance holds a fourth version with a different name. Every review cycle begins with reconciling four lists before anyone looks at a risk. By the second quarter the register is describing a supplier relationship that has changed twice.
| Column | Separate register | One data model |
|---|---|---|
supplier, service_affected, tier | Re-keyed, and drifts from the source | References the live record; cannot disagree with it |
source | Recorded if someone remembers | Set by the step that produced the finding — onboarding or assessment |
controls_in_place | Free text, last updated at unknown date | The evidence actually held, with its expiry |
last_reviewed, acceptance_expiry | Dates nobody watches | Dates that trigger the sweep |
risk_owner, treatment, action | Yours either way | Still yours. Nothing assigns accountability for you |
Qeluntra's supplier risk management works this way — risk is scored when a supplier arrives through source-to-pay and onboarding, so the register is a view over the live record rather than a document someone refreshes.
Do not buy software to fix the other five mistakes. Rows that are suppliers rather than risks, descriptions with no consequence, acceptances with no expiry, everything scoring 3×3, reviews that re-read rather than re-source — all five survive migration to any platform intact, because they are how the register is written rather than where it is stored. Fix those first; they are free.
acceptance_expiry, the register accumulates permanent exceptions that no one ever revisits.The staleness report is the cheapest thing you can add and the most effective: count open risks where last_reviewed is older than the tier's review cycle, and report that number at every governance forum. A register with 40% staleness is not a control regardless of how good the columns are.
A supplier risk register is a record in which each row is a specific risk arising from a supplier relationship — written as cause, event and consequence — with a named owner, an assessed score, a chosen treatment and a review date. It is distinct from a supplier inventory, which lists who you buy from.
The minimum viable set is eight: risk id, supplier, category, description, likelihood, impact, risk owner and treatment. A complete specification adds service affected, tier, date identified, source, velocity, controls in place, residual likelihood and impact, action with due date, acceptance expiry, and last reviewed.
Score likelihood and impact against published scales, separately before and after controls, and add velocity — how fast the risk reaches full exposure once it begins. Do not combine the three into a single number; that discards the distinction between a slow, survivable risk and a fast, total one that happen to multiply to the same figure.
Quarterly for risks attached to tier 1 suppliers, annually for tier 2, and on event triggers regardless of tier: a breach, a change of ownership, a sanctions listing, a material service change or an adverse audit finding. Track staleness as a metric and report it at each governance forum.
No. DORA Article 28(3) requires a register of information about ICT third-party contractual arrangements — what is contracted and which functions it supports. A supplier risk register records risks and their treatment. They draw on the same underlying inventory and should be generated from it rather than maintained separately.
Yes, and for a small supplier population it is the right answer. It stops working when you need the register to agree with the onboarding record and the contract register — at that point you are maintaining three copies of the same supplier and reconciling them by hand, which is where most of the staleness comes from.