What Goes in a Bag Sourcing Risk Register Before You Ship?
Ten entries, each with a trigger that carries a date, a mitigation that has already been decided and a named owner. Ten is the working size: a longer register is not read and a shorter one misses the categories that actually cause loss.
A bag sourcing risk register is ten entries, each with a trigger that carries a date, a mitigation that has already been decided, and a named owner. Ten is the working size: a longer register is not read and a shorter one misses the categories that actually cause loss. The register is reviewed weekly and it lives beside the calendar rather than inside it.
Risk on a sourcing programme is not primarily about dramatic events. It is about a set of predictable things that happen with tedious regularity, most of which are visible a month before they land: a dye lot that drifts, a vessel that is full, a document that does not match, a substitution nobody mentioned, a colourway that does not sell. Each is individually manageable and each is individually forgotten until it happens.
A register is the instrument that stops them being forgotten. Not a document produced for a tender and filed, but a short list reviewed weekly, with the entries written so that each one says when it has happened rather than what might happen. The distinction matters more than the format: "dye lot may drift" is a worry, and "if the lab dip is not approved by Friday the bulk window moves a week" is a plan.
This piece sets out the ten entries that cover most bag programmes, how to write each one so it carries a date, and how to run the review so it changes something. The Running a Bag Sourcing Project note covers the gate structure the register sits beside.
Why Ten Entries and Not Forty?
Because the register has to be read every week by someone who is busy. Ten entries fit on one page, they can be scanned in a minute, and they cover the categories that produce loss. Forty entries do not get read, and a register that is not read is worse than no register, because it creates the impression that risk is being managed while it is not.
| Category | What it covers | Why it earns a slot |
|---|---|---|
| Specification | Revision control, tech pack completeness, change after sign-off | The most common cause of a second sampling cycle |
| Colour | Lab dips, dye lots, retained swatches, shade tolerance | The most common cause of a reorder disappointment |
| Capacity | Whether the line is free in the needed window | Seasonal and predictable, therefore manageable |
| Freight | Booking, rate, transit, the peak | The largest single variable after the unit price |
| Customs and duty | Classification, origin, entry documents, rate movement | The largest single cause of a held arrival |
| Compliance | Test reports, declarations, labelling, file currency | The largest single cause of a blocked sale |
| Quality | Defect classes, inspection results, re-work | The only category measured on every run |
| Supplier continuity | Licence, audit currency, substitution, change control | Low frequency, high impact |
| Design protection | Filings, tooling ownership, disclosure | Low frequency, permanent consequence |
| Demand | Forecast, colourway split, sell-through | The one the buyer owns entirely |
How Should an Entry Be Written?
- Risk
- One sentence, describing the event rather than the worry
- Trigger
- The observable event, with a date where one exists
- Impact
- What it costs, in days or in money, stated plainly
- Mitigation
- What has already been decided, not what could be considered
- Owner
- One named person
- Status
- Open, watching, or closed — reviewed weekly
The mitigation field is where most registers fail. "Review options" is not a mitigation. "Book at sample approval" is. "Monitor the dye lot" is not. "Require a lab dip against the retained swatch, approved before cutting" is. A mitigation that has already been decided can be executed on the day the trigger fires, without a meeting.
The owner field is the one most often filled in with a role rather than a person, and it is the reason entries stall. A role is a queue; a person is an instruction. The test is simple: if the trigger fired this afternoon, would one named individual know that they were the one to act, without being told? Where the answer is no, the entry has no owner and it will sit open until it becomes a problem.
What Are the Ten Entries for a Bag Programme?
| # | Risk | Trigger | Mitigation | Owner |
|---|---|---|---|---|
| 1 | The tech pack is never signed off | No revision number by the agreed date | A default approval date, and a named signatory | Buyer |
| 2 | Shade drifts between the dip and bulk | The bulk dip reads outside the stated tolerance | A retained swatch, a stated tolerance, a dip before cutting | Buyer |
| 3 | The line is full in the needed window | No confirmed slot at quotation | A second qualified base, or an earlier booking | Programme desk |
| 4 | Freight is unavailable or the rate moves | Booking not confirmed by sample approval | Book at approval; a fallback mode agreed in advance | Forwarder |
| 5 | The entry is held on a document | Invoice and packing list disagree at draft stage | A draft checked by the broker a week before arrival | Broker |
| 6 | A compliance document is out of date | The declaration predates the current list | Re-date and re-issue at each reorder | Buyer |
| 7 | The lot fails inspection | Counts above the accept number at AQL 2.5 | Inspect in process; hold the balance against a passed report | Inspector |
| 8 | A material is substituted without notice | Any unnotified change to a specified material | Written notice with a lead time and a re-test right | Programme desk |
| 9 | The design appears elsewhere | A copy found in a listing or a catalogue | Filings in place, tooling owned, evidence assembled | Buyer |
| 10 | The colourway split is wrong | Sell-through diverges from the forecast | A pilot measured per colourway before the scale-up | Buyer |
How Should Likelihood and Impact Be Scored?
Coarsely. A three-point scale on each — low, medium and high — is enough, and anything finer is false precision on a sample of one programme. What matters more than the score is the rule attached to it: a high-impact entry gets a mitigation decided in advance regardless of likelihood, and a high-likelihood entry gets a dated trigger regardless of impact.
The useful output of scoring is not a number, it is the decision about which entries are reviewed weekly and which are reviewed monthly. High-impact and high-likelihood entries are read every week; the rest are read when the programme review comes round. That triage is what keeps the weekly session to five minutes.
One caution about scoring is that impact is usually understated on the day the entry is written and overstated on the day it fires. The entry written in March says a slipped gate costs a week; the same entry in November, with a seasonal date behind it, costs the season. Re-read impact at each programme review against the calendar as it now stands, because the score is only meaningful while it reflects the current position.
What Happens When Two Risks Fire Together?
They usually do, because the causes are connected. A capacity squeeze and a freight squeeze arrive in the same season; a document problem and a compliance problem arrive from the same missing artefact; a shade problem and a substitution problem arrive from the same material decision. A register that treats entries as independent will be surprised by a cluster that was visible in the structure.
| Cluster | Common cause | Combined mitigation |
|---|---|---|
| Capacity and freight | The seasonal peak | Book at sample approval and confirm the slot at quotation |
| Documents and compliance | A file that was never assembled | Assemble the file during sampling, not after bulk |
| Shade and substitution | A material decision made late | Fix the material at sign-off and require notice before a change |
| Quality and demand | A specification the market described loosely | Measure sell-through per colourway before the scale-up |
| Design and supplier continuity | A relationship with no written controls | Own the tooling and require written notice |
How Does the Register Fit With the Compliance File?
The compliance entry is the one that connects them. A test report that has expired, a declaration that predates the current restricted-substance list, or a label in the wrong language is both a compliance failure and a customs-entry failure, and it sits in the register under one trigger rather than two.
The practical arrangement is to hold the compliance dates on the same page as the register: the declaration date, the report date, the audit date and the renewal moment for each. One page then answers both questions — what is at risk this week, and what is about to lapse.
Who Owns Each Entry?
Five rules for ownership
- One owner per entry; a shared entry has no owner.
- The owner is the person who can execute the mitigation, not the person who noticed.
- The buyer owns the entries decided on the buyer side of the border.
- The programme desk owns the entries decided at the production end.
- The forwarder and broker own the entries decided at the border.
The second rule is the one that matters. A risk owned by the person who spotted it is a risk owned by someone who cannot fix it. A capacity risk is owned by whoever can qualify a second base; a document risk is owned by whoever can prepare the draft; a demand risk is owned by whoever sets the forecast.
The third rule is the one that keeps the buyer honest. Entries decided on the buyer side of the border — the forecast, the colourway split, the filing, the sign-off date — are the ones a buyer is tempted to attribute elsewhere, because a supplier failure is more comfortable than a forecast failure. The register does not care where the discomfort sits. A demand entry owned by nobody is still an entry that will fire.
How Is the Register Run?
Weekly, in the same session as the status report, and it takes five minutes. Each open entry is read for one question: has the trigger fired? If it has, the mitigation is executed and the entry moves to closed. If it has not, the entry stays open. Entries that have not changed for a month are reviewed for whether they are still real.
| Review step | Question | Action |
|---|---|---|
| Read the triggers | Has any trigger fired since last week? | Execute the pre-decided mitigation |
| Check the dates | Is any trigger date now inside the window? | Escalate or re-plan |
| Check the owners | Is each owner still able to execute? | Reassign where someone has left the project |
| Prune | Has anything been open a month with no movement? | Close or rewrite it |
| Add | Has anything new appeared? | Write it with a date, or leave it out |
What Does the Register Do That a Plan Does Not?
A plan says what should happen. A register says what has happened when it goes wrong, and what is already decided. That is the difference between a programme that recovers from a slipped gate and one that spends a week deciding how to recover, which is usually the difference between hitting a seasonal date and missing it.
A second thing it does is keep decisions out of the moment, which is where bad decisions are made. A choice taken under pressure, on the day a vessel is missed, is worse than the same choice taken in March when it costs nothing to think about. A register with pre-decided mitigations converts a set of future panics into a set of past agreements.
How Do You Write a Trigger That Actually Fires?
By attaching it to an event someone will notice rather than to a condition someone has to assess. "Freight risk" never fires; "the booking is not confirmed by sample approval" fires on a known day, and someone is accountable for confirming it. Every entry should be rewritten until its trigger is an event with a date or an observable state.
The second test is whether the trigger is visible to the owner without extra work. A trigger that requires someone to go and look is a trigger that will be missed in a busy week. The best triggers ride on things that already happen: the weekly report, the draft invoice, the dip approval, the booking confirmation.
What Should Not Be in the Register?
Anything without a trigger, anything without an owner, and anything the programme cannot influence. A register entry that says "freight rates may rise" has no trigger and no response, so it occupies a slot and does nothing. The same event written as "if the booking is not confirmed by sample approval, fall back to the agreed mode" has both.
Also excluded: a list of everything that could conceivably go wrong, and any entry written in the language of worry rather than the language of events. That is a different document and it is not useful weekly. Ten entries is a discipline rather than a limit, and the discipline is that an entry has to earn its slot by being readable, triggerable and actionable.
One further habit turns a register from a list into an instrument: record the near misses. An entry whose trigger came within a day of firing, or whose mitigation was executed without anyone noticing, tells the programme more than an entry that never moved. Those are the ones that will fire next time, and a note that says so is worth keeping.
How Does the Register Change for a Reorder?
It gets shorter and more specific. The entries that were open on the first run and did not fire can often be closed or demoted, because the programme now has history. What replaces them are the entries the pilot actually produced: the defect pattern, the shade behaviour, the arrival condition. A second-run register reflects what the first run taught rather than what might happen in general.
The one entry that should never be demoted is the substitution one. Programmes relax it after a clean first run, and that is exactly when a material change arrives unannounced and invalidates a file that took a year to build. Keep it, keep the notice period, and keep the re-test right.
What Does a Good Register Leave Behind?
A record of what actually happened, which is the most useful artefact a programme produces and the one nobody keeps. A register at the end of a year says which risks fired, which did not, which mitigations worked and which were theatre. That is worth more than the risk analysis done at the start, because it is measured rather than imagined.
Put ten entries on one page
Send the programme and the market. You get a quotation and a one-page register with triggers and owners, within one business day.
Frequently Asked Questions
What is a bag sourcing risk register?
Ten entries, each with a dated trigger, a pre-decided mitigation and a named owner, reviewed weekly beside the project calendar.
Why only ten entries?
Because it has to be read every week by someone busy. Ten fit on one page and cover the categories that produce loss; forty do not get read.
What makes a good risk entry?
A trigger that is observable, a mitigation that has already been decided rather than considered, and one named owner who can execute it.
What should not be in a register?
Anything without a trigger, anything without an owner, and anything the programme cannot influence.
How do I write a trigger?
Attach it to an event with a date or an observable state — the booking is not confirmed by sample approval — rather than to a condition someone has to assess.
How often should it be reviewed?
Weekly, in the same session as the status report. Five minutes: has any trigger fired, and is any trigger date now inside the window.
Who owns which entries?
The buyer owns what is decided on the buyer side, the programme desk owns what is decided at the production end, and the forwarder and broker own what is decided at the border.
How is it different from a project plan?
A plan says what should happen. A register says what has happened when it goes wrong, and what is already decided about it.
Which entry causes the most loss?
Across most programmes it is the document one: an invoice that disagrees with a packing list, or an origin claim with no evidence behind it.
Does the register change on a reorder?
Yes. Entries that did not fire can be closed, and what replaces them is what the first run actually produced.
Which entry should never be dropped?
The substitution one. Programmes relax it after a clean first run, which is when an unannounced material change invalidates a file.
How does this relate to the inspection plan?
The inspection plan is the mitigation for the quality entry. AQL 2.5 to ISO 2859-1 at Level II, with a class list agreed before the run.
What does a register leave behind?
A record of what actually fired and which mitigations worked, which is more useful than the analysis done at the start.
People Also Ask
What should be in a bag sourcing risk register?
Ten entries covering specification, colour, capacity, freight, customs, compliance, quality, supplier continuity, design protection and demand.
How do I write a risk entry?
An observable trigger with a date, a mitigation that is already decided, one named owner, and an impact stated in days or money.
How often should a risk register be reviewed?
Weekly, in five minutes, asking whether any trigger has fired and whether any trigger date is now inside the window.
What is the most common sourcing risk?
On most programmes it is documentation: an invoice that disagrees with the packing list or an unsupported origin claim.
Who should own each risk?
The person who can execute the mitigation, not the person who noticed the risk.
Sources and further reading
Every figure on this page is either our own programme data or attributed below. Open the originals before you write them into a specification.
- ICC — Incoterms 2020 rules for sale of goodsInternational Chamber of Commerce
- ISO 2859-1:1999 — sampling procedures for inspection by attributesInternational Organization for Standardization
- WTO — tariff, trade and trade-agreement informationWorld Trade Organization