The Decorative Risk Register at NordFlow Logistics
NordFlow Logistics operates three distribution hubs and 620 staff, moving 45,000 pallets a week for 30 retail clients. Top management has committed to ISO 9001:2015 with a target certification date 14 months away. Planning is led by a newly hired QMS coordinator. The risk register contains 42 entries produced in a two-day workshop, mostly generic (fire, IT failure, reputational damage); none are linked to processes, and no owner or review date is assigned. The only quality objective is 'on-time delivery at or above 98%' at company level; hubs are not required to set targets. Client contracts include penalties for late delivery, and two clients demand 24-hour recovery plans. A new automated sortation system goes live at Hub B in five months, removing 20 manual sort roles and changing the picking process. The internal audit schedule and management review calendar have not been drafted, and the coordinator asks whether she needs a formal risk management standard such as ISO 31000 to satisfy clause 6.1.
1. Does NordFlow need ISO 31000? Evaluate whether the existing 42-entry risk register satisfies clause 6.1, and describe what a proportionate replacement would contain.
Read the worked answer
No ISO 31000 is required, but the register as built does not satisfy 6.1.
6.1.1 requires the organization to determine risks and opportunities that can affect conformity of products and services and customer satisfaction, and 6.1.2 requires it to plan actions to address them and evaluate their effectiveness. There is no prescribed format - a risk register is a tool, not a requirement - but the content must be relevant and connected to the QMS.
Problems with the 42-entry list:
- Generic corporate risks may matter, but they must be traced to processes and to the QMS's ability to deliver. A list that could belong to any company shows no analysis of NordFlow's actual processes: line-haul subcontracting, hub transfer, sortation, client penalties, 24-hour recovery obligations.
- No owners or review dates means no evaluation of effectiveness; 6.1.2 is a planning requirement, not a brainstorming output.
Fix: rebuild as a process-linked risk and opportunity table - process, risk or opportunity, likelihood/impact (a simple 3x3 is enough), action, owner, due date, effectiveness check. Include opportunities (for example, automation reducing mis-sorts). Review at management review (9.3.2). Keep it proportionate: 12 to 20 live entries that people use beat 42 decorative ones.
2. Cascade the 98% on-time delivery objective to functions and levels, and explain how you would test that the cascade is credible rather than cosmetic.
Read the worked answer
The 98% company objective is not sufficient. 6.2.1 requires objectives at relevant functions, levels and processes, measurable, consistent with the quality policy, monitored, communicated and updated. A single corporate target leaves hubs and functions with no owned target and no line of sight.
Cascade by process, not by copying the same number:
- Hub level: on-time delivery by hub (they may differ; Hub B's automation may cause a temporary dip), mis-sort rate, dock-to-dispatch time, recovery-plan test completion.
- Client services: complaint acknowledgement within two hours, penalty value, 24-hour recovery plans validated for the two demanding clients.
- Procurement: carrier performance score, late tender rate.
- Support functions: agency driver competence completion, system availability.
Then apply 6.2.2: for each objective state what will be done, the resources, the responsible person, the completion date, and how results will be evaluated.
Credibility test: do the hub targets actually sum to the company target? If Hub A runs at 94% and Hub B at 97%, a 98% aggregate is arithmetically unrealistic without a step change. That gap should drive the improvement plan (10.1), not be left as an aspiration. Also check that each objective has a data source and a review rhythm - an objective nobody measures monthly is decoration.
3. The Hub B automation goes live in five months. What must the planning work cover under clause 6.3, and what could go wrong if it is treated as an engineering project only?
Read the worked answer
6.3 applies to any planned change to the QMS, and the automation is exactly that. Before go-live the coordinator should produce a change plan covering the 6.3 inputs:
- Purpose and consequences: faster sortation, but fewer manual checks mean mis-sorts may reach clients undetected; assess penalties and the two clients' recovery requirements.
- Integrity of the QMS: update the process map, work instructions, inspection points, KPIs (mis-sort rate, not just on-time delivery), and the risk register. The change alters the controlled conditions in 8.5.1.
- Resources and responsibilities: 20 roles removed - redeployment, training (7.2), competence records; maintenance and IT support; named responsibility for system availability.
- Validation: prove the sortation reads labels correctly across the client mix before relying on it; define acceptance criteria and a parallel-run period.
Also plan communication (7.4) and, where delivery could be affected, inform affected clients (8.2). Schedule a post-implementation review to confirm the change achieved its purpose and did not create new risks - that links back to 6.1 and 10.1.
If treated as an engineering project only, the likely failures are: no updated process documentation, no competence records for redeployed staff, no revised KPIs, and a mis-sort problem discovered by a client rather than by the QMS.