Deploying EUDR at Pace, Part 2: Design and Tailor
This is the second of four articles on deploying EUDR at pace. Part 1 covered setting up the Steering Committee, finding out where you stand and agreeing a plan. This article covers what comes next: turning that plan into procedures that fit the way your business already works.
This is the stage where good plans most often lose their shape. Each function adapts the procedures to suit itself, the handovers between teams no longer match, and controls disappear quietly in the name of simplicity. None of it shows until the first difficult case. The practical tips below are about avoiding that.
1. Design around the handovers between teams
Most EUDR failures do not happen inside a team. They happen where work passes from one team to another. Procurement collects supplier data, sustainability assesses the risk, someone submits the due diligence statement, and customs needs the reference number on the declaration. Every one of those passes is a point where information can be lost, delayed or changed.
Walk a shipment through the business. Take the product flow you mapped in Part 1 and mark every point where responsibility changes hands. Include the handovers to and from third parties, such as sourcing agents and customs brokers. Most organisations find more than they expected.
Agree what passes across each handover. For each one, write down four things:
what information passes;
in what form;
by when;
what happens if it is missing or wrong.
"Procurement sends the geolocation to sustainability" is not enough. "Procurement sends validated plot coordinates in the agreed format before the purchase order is released" is.
Name an owner on both sides. The sender owns getting it right. The receiver owns checking it and raising problems. When something goes wrong, there should be no doubt about who picks up the phone.
Learn from a typical failure. A common one sits at the very end of the chain. The customs broker lodges the declaration without the due diligence statement reference number, because nobody told the broker it was needed or where to find it, and the goods are held while the number is chased. An owner on each side of that handover, and an agreed point at which the number is sent, prevents it.
Give the cross-team handovers extra attention. Handovers within a team usually work because people talk to each other every day. The ones that cross functions, sites or company boundaries are where control is most often lost. Record them separately and review them first.
2. Choose owners who can actually own it
Every procedure and every cross-team handover needs one named owner. Not a team, not a committee: one person who can be asked a question and give an answer.
Test each owner on three things. Do they have the authority to make the procedure work, including telling other teams what they need from them? Do they have the time? And do they understand the work well enough to judge whether it is being done properly? A senior name with no time is no better than no owner at all.
Agree the time before you announce the role. Speak to each owner's line manager first and agree how much time the role needs, especially during deployment. If the time is not freed up, the role will lose out to the day job every time.
Write it into the job. Add the EUDR responsibilities to each owner's job description and annual objectives. What is measured gets done, and it means the role survives a change of manager.
Name a deputy. People go on leave, change roles and leave the business. A deputy who knows the procedure stops a single absence from halting progress.
Tell people within a week. Once owners are confirmed, tell them, their managers and the teams they will work with. Ownership that exists only in a register is not ownership.
3. Tailor the language, not the controls
Procedures that do not use your words will not be used. But tailoring is also where controls most often disappear, one sensible-looking edit at a time.
Agree the line before anyone starts editing. Write down, in one place, what can change and what cannot.
Can change: job titles, team names, system names, service levels within legal limits, templates and examples.
Cannot change: decision points, checks, escalation triggers, the evidence required before a decision, and the regulatory references.
Can be added: extra controls where your business needs them.
Keep a simple log of every change. For each edit, note what changed, why, and who approved it. It takes seconds at the time and saves hours when an auditor or a competent authority later asks why a procedure differs from the original.
Watch for merged steps. The most common way a control disappears is when two steps are combined to save time. It looks harmless, but the merged step can drop a check, such as confirming, before a product is released, that the geolocation of every plot has been verified, that the product is deforestation-free and that it was produced legally. Read every merged step against the original.
Escalate rather than delete. If a step genuinely looks unnecessary for your business, raise it with the Framework Owner and the compliance lead for a decision. Do not quietly remove it. Often the real need, such as speed, can be met another way, for example by adjusting a service level instead of removing a check.
4. Build into the systems you already have
The worst outcome is a separate EUDR manual that sits alongside everything else and is followed by nobody. EUDR should become part of how you already buy, check and ship.
Connect to your management system. Bring the procedures into your existing document control and quality management system, so they are reviewed, versioned and audited like everything else. Add EUDR risks to your risk register and EUDR checks to your internal audit plan.
Connect to supplier onboarding and purchasing. This is where the data starts. If your supplier onboarding does not ask for the information EUDR needs, every later step will be chasing it. Consider whether a purchase order should be released before the required supplier data has been received and checked.
Standardise supplier data. Agree one format for the information you ask suppliers for, such as how plot coordinates are given and which file types you accept, and use it for every supplier. Different formats from different suppliers create rework at every later step.
Talk to IT early. Your ERP and other systems may need new fields, for example to hold geolocation references or due diligence statement reference numbers, and to link them to purchase orders and shipments. System changes often take longer than procedure changes, so raise them now rather than at go-live.
Retire what you replace. Where an existing procedure covers the same activity as a new one, withdraw it. Two procedures for one activity always drift apart, and people end up following whichever is easier. Keep a list of what you have retired, so nobody finds an old version later and uses it.
5. Involve the people who will use the procedures
In Part 1, you identified the groups most affected by the change. Design is the moment to bring them in. People support what they help to build.
Name a change champion in each team. Choose someone respected by their colleagues, not necessarily a manager. Their job is to explain the change locally, answer everyday questions, collect concerns and, later, spot workarounds. Agree their time with their line manager before you name them.
Let users test the drafts. Before a procedure is finalised, ask two or three of the people who will follow it to walk through it with a real case. A buyer reading the supplier data request will tell you in ten minutes what a project team might miss in a month: the step that does not match the system, the form suppliers will not understand, the timing that clashes with the purchasing cycle.
Keep a log of concerns, and answer it. Record every concern raised during design, who raised it and what you did about it. Most concerns point to something real. Even when you decide not to change anything, explaining why builds trust.
Keep people informed while you design. Design can take weeks, and silence breeds rumour. A short update every two weeks through the champions, covering what has been decided and what is next, keeps people with you. Keep the same channel open once you go live: feedback from the champions in the first weeks is the quickest way to find what the design missed.
6. Check, approve and issue
Check before you submit. Before anything goes to the Steering Committee, have the Framework Owner and the compliance lead compare each tailored procedure against the original. Check that no control has been weakened, that the regulatory references are consistent, that the handovers match on both sides and that no duplicate procedure remains. Send anything that fails back to its owner with a clear note of what to fix.
Ask the committee for a clear decision. Send the papers at least three working days before the meeting. The committee either approves the procedures or sends them back with the changes it needs and the reasons. A decision with conditions is fine, as long as each condition has an owner and a date.
Issue through document control, once. After approval, issue each procedure with a version number through your normal document control, and withdraw anything it replaces on the same day. Archive the old versions formally, marked as superseded with the date, rather than simply removing the links to them. You may need to show later which version applied when. Tell users and their managers what has been issued and where to find it.
From this point, the issued procedures are the only basis for going live and for any future change. If someone wants to change them, it goes through the controlled route, not an email.
Next in this series: Part 3, Deploy and Embed, on training, piloting and going live in waves without losing control.
Get the step-by-step procedure
If you want this as a working procedure, with the decision points, timings and ready-to-use templates, our free EUDR Framework Deployment and Change Control sets it out step by step.
Request your free copy and we will email it to you.
If you would like support deploying EUDR in your organisation or across your supply chain, contact us.