Direct answer: A procurement risk-register/risk-matrix page is not a table listing a few risks and some measures. The page should state: risk taxonomy (supply interruption, price/commodity/FX, quality, delivery, compliance/sanctions, financial/bankruptcy, ESG/labour, cyber/data, geopolitical/logistics, contract/legal, concentration); identification sources (supplier audit, financial statements, sanctions screening, market data, internal audit, incidents, questionnaires); scoring method (likelihood × impact, velocity/detectability, risk appetite/threshold); mitigation (dual source, safety stock, contract terms, insurance, monitoring, contingency/exit); owner/review/KRI/reporting; public boundary. On the rules: MOF Internal Control Application Guideline No. 7 (Procurement) requires identifying procurement risks, defining duties/authority, and supplier evaluation/contract/acceptance/payment controls; No. 16 (Contract Management) requires contract formation/performance/change/termination/disputes/archive; No. 18 (Information Systems) requires system development/change/operation/security and data controls. This article is current to 2026-11-10 and is a summary of public rules and page method, not legal, risk-management or audit advice; the company's risk policy, procurement policy and actual data control.
This article is for procurement, supply-chain, finance, legal, internal-control, audit, EHS and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby. It covers how to write and accept a procurement risk-register/risk-matrix page. The usual gap is "incomplete taxonomy, gut-feel identification, arbitrary scoring, vague mitigation, no owner, KRIs not monitored, no review closure", ending with a page that only says "strengthen risk management", while supply interruption/price spike/sanctions/quality incident still disagree.
First classify: supply/price/quality/delivery/compliance/financial/ESG/cyber/geopolitical/contract/concentration. Then score: likelihood × impact, velocity/detectability, thresholds/appetite. Finally close the loop: mitigation, owner, KRI, review/reporting. "Strengthen risk management" is not enough.
How does this page relate to supplier financial risk, sanctions screening, internal audit, supplier scorecard and contract pages?
The risk-register page answers "what risks exist, how to score, how to mitigate, who owns, how to review"; the supplier financial risk/resilience page answers "early warning, exposure, contract, assets, contingency"; the supplier sanctions/blacklist page answers "list sources, screening frequency, hit handling"; the internal-audit page answers "plan, sampling, evidence, remediation, accountability"; the supplier scorecard page answers "QCDS, rating, allocation"; the contract page answers "terms, signature, breach". The risk register is the "portfolio view" main page and cannot be replaced by a single-supplier risk page.
Common breaks: only supplier bankruptcy listed; price/FX/compliance/cyber not registered; gut-feel identification; scoring without basis; high risks without mitigation/owner; KRIs not monitored; no review update; register not linked to procurement/contract/audit. The page separates "taxonomy—identification—scoring—mitigation—governance/KRIs—review—public boundary" so procurement/supply chain/finance/legal/internal-control/audit share one vocabulary.
| Page | Question it answers | Key content | Cannot replace |
|---|---|---|---|
| Risk register | What risks/how to score/mitigate/own | Taxonomy, scoring, mitigation, KRIs, review | Single-supplier risk page |
| Supplier financial risk | Early warning/exposure/contract/assets/contingency | Financial indicators, exposure, contingency | Portfolio risk |
| Sanctions screening | Lists/frequency/hits/review | Lists, screening, hits | Risk scoring |
| Internal audit | Plan/sampling/evidence/remediation/accountability | Audit, findings, remediation | Day-to-day risk register |
| Scorecard | QCDS/rating/allocation | Score, rating, improvement | Risk matrix |
| Contract | Terms/signature/breach | Rights/obligations, compensation | Risk list |
Page relationships are editorial; the company's risk policy, procurement policy and actual data control.
How should the risk taxonomy be defined?
At least: supply interruption/concentration (sole source, region/logistics, capacity); price/cost (commodity, FX, tax, freight); quality/compliance (specification, certification, recall, material compliance); delivery/capacity (OTD, ramp-up, bottleneck); compliance/sanctions/anti-bribery (lists, end user, export control); financial/credit (bankruptcy, overdue, guarantee); ESG/labour/environment; cyber/data (supplier access, interfaces); geopolitical/natural disaster/pandemic; contract/legal (terms, disputes, IP); concentration (supplier/region/category). The taxonomy should align with category strategy, supplier segmentation and contract/audit vocabulary; do not use "supplier" as the only dimension.
Acceptance checks: taxonomy; definitions/boundaries; category/supplier mapping; concentration; compliance/financial/ESG; cyber/geopolitical; contract/legal; policy alignment. Common gaps: incomplete taxonomy; supplier only; unclear boundaries; no category mapping.
| Category | What to write | Evidence | Common gap |
|---|---|---|---|
| Supply interruption | Sole source/region/logistics/capacity | List | Bankruptcy only |
| Price/cost | Commodity/FX/tax/freight | Data | Not registered |
| Quality/compliance | Specification/certification/recall/material | Record | No linkage |
| Delivery/capacity | OTD/ramp-up/bottleneck | Report | Not assessed |
| Compliance/sanctions | Lists/end user/export control | Screening | Not done |
| Financial/credit | Bankruptcy/overdue/guarantee | Financials | Not tracked |
| ESG/labour | Labour/environment/safety | Audit | Excluded |
| Cyber/data | Access/interface/data | Assessment | Missed |
| Geopolitical/disaster | Region/disaster/pandemic/logistics | Scenario | Not assessed |
| Contract/legal | Terms/disputes/IP | Contract | Not registered |
Taxonomy is editorial; the company's risk taxonomy, procurement policy and category strategy control.
How should risk identification sources be accepted?
Identification sources should include at least: supplier onboarding/audit/scorecard; financial statements/credit reports/litigation/enforcement; sanctions/blacklist/export-control screening; market/price/FX/freight data; internal/external audit/incidents/complaints/recalls; supplier questionnaires/BCP/cyber assessment; category strategy/concentration analysis; contract/terms/performance records; industry/region/policy/disaster information. Identification should be periodic + triggered (new supplier, new category, new region, major event, M&A/sanctions/bankruptcy); each risk should have source/date/evidence/impact scope. Guideline No. 7 requires procurement risk identification/supplier evaluation; No. 16 requires contract/performance risk; No. 18 requires system/data risk.
Acceptance checks: source list; periodic/triggered; evidence/date; impact scope; supplier/category mapping; incidents/complaints; external data. Common gaps: gut feel; single source; no date/evidence; no trigger update.
| Source | What to write | Evidence | Common gap |
|---|---|---|---|
| Onboarding/audit | Qualification/site/questionnaire/score | Report | Not updated |
| Financial/credit | Financials/credit/litigation/enforcement | Report | Not tracked |
| Sanctions/lists | Sanctions/blacklist/export control | Screening | Not done |
| Market/price | Commodity/FX/freight | Data | Not monitored |
| Audit/incidents | Audit/complaints/recall/accident | Record | Not registered |
| BCP/cyber | Continuity/access/interface | Assessment | Missed |
| Concentration | Supplier/region/category | Analysis | Not analysed |
| Trigger | New supplier/category/region/event | Record | No trigger |
Identification sources are editorial; the company's risk policy, procurement policy and data sources control.
How should risk scoring/matrix be accepted?
Scoring should state at least: likelihood (frequency/probability), impact (amount/downtime/customer/compliance/safety/reputation), velocity (how fast), detectability (early warning), existing-control effectiveness; scoring basis/levels (e.g. 1–5 or high/medium/low, company-defined), matrix/threshold, risk appetite/tolerance, priority. Scoring should be explainable/reviewable: who scores, basis, date, review; high risks escalate/mitigate/assign owner. Do not use arbitrary high/medium/low; the matrix should distinguish "high impact low probability" from "low impact high probability".
Acceptance checks: dimensions; basis/levels; matrix/threshold; appetite/tolerance; scorer/basis/date; review; high-risk escalation. Common gaps: likelihood only; no impact basis; arbitrary matrix; no appetite; no review.
| Dimension | What to write | Evidence | Common gap |
|---|---|---|---|
| Likelihood | Frequency/probability/history | Data | Gut feel |
| Impact | Amount/downtime/customer/compliance/safety/reputation | Basis | No basis |
| Velocity | How fast/warning window | Assessment | Ignored |
| Detectability | Early detection/monitoring | Assessment | Ignored |
| Control effectiveness | Existing control/residual risk | Record | Not assessed |
| Levels/matrix | 1–5 or high/medium/low, matrix/threshold | Policy | No matrix |
| Appetite/tolerance | Risk appetite/tolerance/escalation line | Policy | No appetite |
| Review | Scorer/basis/date/review | Record | No review |
Scoring/matrix are editorial; the company's risk appetite, scoring standard and governance control.
How should risk mitigation be accepted?
Mitigation should state at least: avoid (exit/do not enter), reduce (dual source/safety stock/contract terms/quality agreement/insurance/monitoring), transfer (insurance/guarantee/outsourcing), accept (low risk/cost-benefit), contingency (BCP/alternative/transfer/last buy); each measure needs owner/deadline/budget/evidence/residual risk/review. Measures should match risk level: high risks cannot be "strengthen communication"; contract terms (breach/compensation/audit rights/exit), supplier development/second source, inventory/capacity reservation, insurance/guarantee, monitoring/KRIs should be specific. Guidelines No. 7/16 require contract/acceptance/performance controls; No. 18 requires system/data controls.
Acceptance checks: strategy; measures; owner/deadline/budget; evidence; residual risk; review; match to level. Common gaps: vague measures; no owner; no deadline; no review; high risk low mitigation.
| Strategy | What to write | Evidence | Common gap |
|---|---|---|---|
| Avoid | Exit/do not enter/stop | Resolution | Not executed |
| Reduce | Dual source/inventory/contract/quality/insurance/monitoring | Record | Vague |
| Transfer | Insurance/guarantee/outsourcing | Policy/contract | Not transferred |
| Accept | Low risk/cost-benefit/approval | Approval | Default accept |
| Contingency | BCP/alternative/transfer/last buy | Plan | No plan |
| Owner | Name/role/deadline/budget | Register | No owner |
| Residual risk | Post-measure score/review | Record | No review |
| Evidence | Contract/policy/inventory/drill | Record | No evidence |
Mitigation is editorial; the company's risk strategy, contracts and budget control.
How should governance, KRIs and review be accepted?
Governance: risk owner (procurement/category/supplier/finance/compliance), risk committee/management/board (by threshold), meeting frequency, escalation path, linkage to internal audit/audit committee. KRIs: price index/FX, supplier financial/overdue, OTD/quality, sanctions hits, concentration, inventory/capacity, incidents/complaints, contract expiry/breach; define/data source/threshold/frequency/owner/trigger. Review: periodic (monthly/quarterly/annual) + post-event; update register/scoring/mitigation/owner; report/retain. Guidelines No. 7/16/18 provide procurement/contract/system control bases. The page should state "who looks, how often, at what, triggering what".
Acceptance checks: owner; committee/threshold; meetings; escalation; KRI definition/data/threshold; review; reporting; linkage. Common gaps: no owner; no meeting; KRIs not monitored; no review; no audit linkage.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Owner | Procurement/category/supplier/finance/compliance | Appointment | No owner |
| Committee/threshold | Management/board/escalation line | Policy | No governance |
| Meeting | Frequency/agenda/minutes | Minutes | No meeting |
| KRI | Definition/data/threshold/frequency/owner | Report | Not monitored |
| Trigger | Threshold/event/escalation/mitigation | Record | No trigger |
| Review | Periodic/post-event/update | Report | No review |
| Reporting | Monthly/quarterly/annual/board | Report | No reporting |
| Linkage | Internal audit/contract/budget/category | Record | No linkage |
Governance/KRIs/review are editorial; the company's risk governance, procurement policy and audit requirements control.
How should the website page be written, and what must not be published?
Suggested sections: (1) risk taxonomy/definitions; (2) identification sources/frequency; (3) scoring/matrix/appetite; (4) mitigation strategies/owners; (5) KRIs/review/reporting; (6) contact window/update date. The public page explains "taxonomy, method, scoring, mitigation, governance, boundaries" and does not publish specific risk lists/scores, supplier names/financial/sanctions hits, contract terms, inventory/capacity, customer information, system screenshots or undisclosed incidents/disputes. The English page should use consistent terms (procurement risk, risk register, risk matrix, likelihood/impact, velocity/detectability, risk appetite/tolerance, mitigation, KRI, review, escalation) and state the cut-off date.
Do not turn the risk page into a "strengthen risk management" slogan, and do not claim "zero risk/no interruption" if it cannot be proven. The page should let suppliers/customers/auditors judge "how to classify, score, mitigate, review", without exposing risk lists and supplier information.
Go-live acceptance checklist
Ten checks: taxonomy/definitions; identification sources/triggers; scoring/matrix/appetite; mitigation/owner/residual risk; KRIs/thresholds; governance/meetings/escalation; review/reporting; linkage to audit/contract/budget; archive/permissions; public boundary. Each needs evidence and a review date. The pass standard is not "there is a register", but that procurement/supply chain/finance/legal/internal-control/audit can judge where the risk is, how big, who owns it, how to mitigate and when to escalate.
Before go-live, run a tabletop exercise with a real (redacted) category: identify → score → mitigate → KRI → incident → review → update, simulating "sole-source interruption", "raw material price spike" and "sanctions hit", to see whether the page and process work.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Taxonomy/definitions | Supply/price/quality/delivery/compliance/financial/ESG/cyber/geopolitical/contract | List | Add taxonomy |
| Identification sources | Audit/financial/screening/market/audit/incidents/questionnaire | Record | Add sources |
| Scoring/matrix | Likelihood/impact/velocity/detection/control/threshold | Policy | Add basis |
| Mitigation | Strategy/measure/owner/deadline/residual risk | Register | Add measures |
| KRI | Definition/data/threshold/frequency/trigger | Report | Add monitoring |
| Governance | Owner/committee/meeting/escalation | Minutes | Add governance |
| Review | Periodic/post-event/update/report | Report | Add review |
| Linkage | Internal audit/contract/budget/category | Record | Add linkage |
| Archive/permissions | Version/trail/access | Archive | Add permissions |
| Public boundary | No risk lists/suppliers/incidents | Page/permissions | Take down |
The acceptance list is editorial; the company's risk policy, procurement policy and audit requirements control.
Who should read it, who should not, and what decisions does it support?
For procurement, supply-chain, finance, legal, internal-control, audit, EHS and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby; also for companies handling "incomplete taxonomy, gut-feel identification, arbitrary scoring, vague mitigation, no owner, KRIs not monitored, no review closure". Not for teams without procurement risk management, or that want one page to replace legal/risk-management/audit advice.
Read it if: building a risk-register/matrix page; only "strengthen risk management"; incomplete taxonomy; no identification source; no scoring basis; vague measures; no owner; KRIs not monitored; no review. Not suitable if: treating "register" as "a list"; "scoring" as "gut feel"; "mitigation" as "a slogan"; "page" as "risk policy/audit conclusion". Supports: taxonomy/identification, scoring/matrix, mitigation/owner, KRIs/review and public-boundary self-checks.
FAQ
What is the difference between a procurement risk register and supplier financial-risk/internal-audit pages?
The risk register is the "portfolio view": it puts supply, price, quality, delivery, compliance, financial, ESG, cyber, geopolitical, contract and concentration risks in one register, scores/ranks them, assigns owners and tracks KRIs; the supplier financial-risk page focuses on one supplier's financial resilience, and the internal-audit page focuses on audit plan/sampling/remediation. They complement each other.
How should the risk taxonomy be defined?
At least cover supply interruption/concentration, price/cost (commodity/FX/tax/freight), quality/compliance, delivery/capacity, compliance/sanctions/anti-bribery, financial/credit, ESG/labour/environment, cyber/data, geopolitical/disaster, contract/legal and concentration; the taxonomy should align with category strategy, supplier segmentation and contract/audit vocabulary, not just "supplier".
How should risk scoring be done?
At least score likelihood, impact (amount/downtime/customer/compliance/safety/reputation), velocity, detectability and existing-control effectiveness; define scoring basis/levels (1–5 or high/medium/low, company-defined), matrix/threshold, risk appetite/tolerance and priority; scoring should be explainable/reviewable (who/basis/date/review); high risks need escalation/mitigation/owner. Do not score on likelihood alone or use gut feel.
How should mitigation be chosen?
By risk level/cost-benefit: avoid (exit/do not enter), reduce (dual source/safety stock/contract terms/quality agreement/insurance/monitoring), transfer (insurance/guarantee/outsourcing), accept (low risk/approval), contingency (BCP/alternative/transfer/last buy); each has owner/deadline/budget/evidence/residual risk/review. High risks cannot be "strengthen communication" only.
How often should the register be updated, and who owns it?
At least quarterly/annual review, plus triggers on new supplier/category/region or major events (sanctions/bankruptcy/recall/interruption/price spike); each risk has an owner (procurement/category/supplier/finance/compliance), a risk committee/management reviews by threshold; KRIs monitored monthly/quarterly; after review update scoring/mitigation/owner and retain evidence.
How should KRIs be set?
KRIs should match risks: price index/FX, supplier financial/overdue, OTD/quality, sanctions hits, concentration, inventory/capacity, incidents/complaints, contract expiry/breach; each KRI has definition/data source/threshold/frequency/owner/trigger. KRIs are not "nice reports"; they should trigger escalation/mitigation; thresholds are company-defined by risk appetite.
Should the website publish risk lists/supplier risks?
Usually not specific risk lists/scores, supplier names/financial/sanctions hits, contract terms, inventory/capacity, customer information, system screenshots or undisclosed incidents/disputes; it can publish risk taxonomy/method, scoring/mitigation/governance principles, KRI/review process, contact window and update date. The goal is to let suppliers/customers understand the management method, not to disclose risk positions.
One-sentence takeaway
The procurement risk-register/risk-matrix page on a Changzhou manufacturer's website is not about "strengthen risk management"; it is about turning risk taxonomy, identification sources/triggers, scoring/matrix/appetite, mitigation/owner/residual risk, KRIs/thresholds, governance/meetings/escalation, review/reporting, linkage to audit/contract/budget, archive/permissions and public boundaries into a checkable list, so procurement/supply chain/finance/legal/internal-control/audit can judge where the risk is, how big, who owns it, how to mitigate and when to escalate.
Research method and limitations
This article is a summary of public rules and page method, not legal, risk-management or audit advice. It uses no unpublished company risk lists/scores, supplier names/financial/sanctions hits, contract terms, inventory/capacity, customer information, system screenshots or undisclosed incidents/disputes; the tables and acceptance items are editorial and not legal/risk-management/audit conclusions. MOF Internal Control Application Guideline No. 7 (Procurement), No. 16 (Contract Management) and No. 18 (Information Systems) are public sources; the company's risk policy, procurement policy and actual data control. This article does not decide whether any specific risk score/threshold is reasonable, and does not promise "zero risk/no interruption"; companies should set them item by item based on category, supplier, contract, data and governance.
Sources and basis
Current to 2026-11-10; the official pages below control.
- MOF Internal Control Application Guideline No. 7 — Procurement (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Procurement risk, duties/authority, supplier evaluation/admission, contract, acceptance, payment and records.
- MOF Internal Control Application Guideline No. 16 — Contract Management (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Contract formation/review/signature/performance/change/termination/disputes/archive and annual evaluation.
- MOF Internal Control Application Guideline No. 18 — Information Systems (Cai Kuai [2010] No. 11): Linyi Finance Bureau. System development/change/operation/security and data controls; used here for risk data/permissions/logs/reporting.