Deploying EUDR at Pace, Part 1: Assess and Plan
Most organisations now understand what the regulation requires. The difficulty is making it work across procurement, sustainability, legal, IT, logistics and the supply chain, when no single function owns it.
This is the first of four articles on deploying EUDR at pace. It covers the first stage: setting up the people who will make the decisions, finding out where you stand, and agreeing a plan. Later articles cover designing your procedures, going live, and keeping your framework current.
1. Set up a Steering Committee that can actually decide
EUDR touches too many functions for any one of them to drive it alone. Without a group that can make decisions across functions, every question waits for someone else. Set the committee up first, before any assessment or design work starts.
Who should chair it. The chair should be a senior executive who can move budget and settle disagreements between functions. In most organisations that is the chief operating officer, the supply chain director or the chief procurement officer. If the chair cannot overrule a functional head, the committee will stall on the first difficult decision.
Who should sit on it. Keep it to five to seven people:
The Framework Owner, who runs the deployment day to day and brings decisions to the committee.
A compliance or legal lead, who is accountable for the regulatory position.
The head of procurement, because suppliers and their data sit at the centre of EUDR.
A sustainability lead, who often owns risk assessment.
A supply chain or logistics lead, including customs, where due diligence references meet shipments.
The owner of the main IT systems, because the data has to live somewhere and link to orders.
Internal audit can attend as an observer. Resist adding more members. A committee of twelve becomes a briefing session, not a decision-making body.
How it should run. Meet monthly during deployment and quarterly once you are live. Agree in advance which decisions belong to the committee: the scope, the plan, the procedures, each go-live and any significant change. Leave everything else to the Framework Owner. Send papers at least three working days before each meeting, and record every decision with the evidence it was based on.
Agree two rules at the start. First, no decision is taken without the chair, the Framework Owner and the compliance lead in the room. Second, agree how urgent decisions will be taken in writing between meetings. You will need that when a regulatory change takes effect before your next meeting.
The first meeting. Keep the agenda to three items: confirm the mandate and who leads, agree the scope, and approve a one-page case for change.
2. Agree the scope on one page
The questions that cause most trouble later are simple ones asked too late. Answer them on one page and have the committee approve it:
Which legal entities place relevant products on the EU market, or export them from it?
For each entity, are you an operator, a trader, or both?
Which of your products fall under Annex I of the Regulation, and which commodities do they contain?
Which countries do those commodities come from?
Which application date applies to you?
A practical way to answer the product question is to export your product codes from your ERP system and match them against Annex I. It is quicker than asking each business unit, and it shows you the real volume of affected product flows.
Record what is out of scope and why. When your business changes, for example through a new product or a new entity, you will know exactly which decision to revisit.
3. Map your existing processes, technology and people
You already do much of what EUDR needs, in pieces, across several teams. Before designing anything, find out what exists. Map three things: processes, technology and people.
Processes: follow a product, not the organisation chart. Take one product and trace it from supplier onboarding through purchasing, receipt of documents, risk review and shipment to customs. Run short workshops with each function along the way, around two hours each. Ask people to walk you through what they actually do, with real examples. Where the written procedure says one thing and people do another, record what people do. That gap is often the most useful finding.
Technology: find where the data lives. List every system that holds or moves EUDR-relevant data. Typically that includes:
the ERP supplier master and purchase orders;
supplier portals and questionnaires;
spreadsheets kept by sustainability or procurement teams;
document management systems and shared drives;
mapping or GIS tools, if you have them;
email, which is often where geolocation data actually arrives.
For each one, ask two questions. Can the data be linked to a specific purchase order or shipment? And who checks it? Data that cannot be linked to a shipment will not support a due diligence statement.
People: name who does what, including outside the business. For each activity, record who performs it and who owns it. Include third parties: sourcing agents, customs brokers, certification bodies and data providers. "The broker handles it" is not an answer. You remain responsible for what is done on your behalf, so record how you control it.
Rate what you find. For each activity, record whether it is covered, partly covered or not covered at all. Flag where two teams do the same thing differently, and where a third party is involved. Do not start redesigning during mapping. Record what exists now.
A typical finding looks like this: plot coordinates arrive by email from a sourcing agent and are filed without anyone checking them. The documents exist, but the data behind them has never been validated. That one finding can change your priorities.
4. Measure maturity honestly
Mapping tells you what exists. A maturity assessment tells you how well it works. The two are different: an activity can be fully covered and still be weak.
Score each area on evidence, not opinion. For every score, ask "show me". A policy saying risk assessments happen is not evidence; a completed risk assessment is. Ask contributors to say so plainly where no evidence exists, and make it clear that this is a useful answer, not a failure. A gap admitted now costs far less than one found after go-live.
Score each area at the level of its weakest part, not the average. Strong document handling does not make up for traceability that cannot link a product to the plot it came from.
Expect the results to be lower than people expect. That is normal, and it is the point. It shows you where to start, and where you can save effort because you are already in good shape.
5. Check the baseline, then plan in waves
Before anyone writes a plan, take the scope, the mapping and the maturity results to the Steering Committee and ask one question: is this complete enough to plan against? Check that every in-scope activity has been mapped and confirmed with its owner, that every maturity score has evidence behind it, and that any challenge raised has been resolved. If the answer is no, send each gap back to its owner with a date. Planning on an incomplete baseline is how deployments end up redoing work halfway through.
Trying to switch everything on at once is the slowest way to deploy. Plan in waves instead, and rank the gaps by four things: legal exposure, the application date that applies, the volume of product flows affected, and what depends on what.
Dependency matters most. A sensible order is:
Foundations: access to the EUDR Information System, record keeping, and a way of engaging suppliers.
Scope and route: deciding, for each product flow, whether EUDR applies and what role you play.
Evidence: traceability first, then geolocation, legality evidence and verification.
Declaration: due diligence statements and reference numbers.
Monitoring and improvement: keeping the live system under control.
Do not plan declarations before you can trace the evidence behind them. You can bring an area forward where your exposure is high, such as crisis management, as long as it does not depend on something not yet in place.
Once the plan is approved, write to your suppliers straight away. Tell them what information you will need, such as geolocation of the plots of land and evidence of legal production, and from when. Ask them to tell you early if any of it will be difficult. Supplier data takes far longer to arrive than procedures take to write.
6. Engage your staff from day one
For many of your people, the deployment will be the first time they hear about EUDR in any detail. What they hear first, and who they hear it from, shapes how they respond for the rest of the programme. Staff engagement is not something to start at go-live. It starts in the planning stage.
Work out who is affected. List every group the deployment touches. For EUDR that usually includes the board, procurement and buyers, compliance and sustainability, logistics and customs, sales and customer service, IT, finance, internal audit and operational users. For each group, ask two questions: how much influence do they have, and how much does the change affect them? Groups high on both need to be involved in shaping the procedures. Groups low on both only need general updates.
Write down what changes for each group. For every group, be specific about what will be different in their daily work: new tasks, new decisions, new systems or data, new records, and new requests they will have to make of suppliers. Rate the impact as high, medium or low. High-impact groups need role-based training and close involvement. If too many high-impact groups fall into the same wave, split the wave.
Check whether you need to consult. Where working practices change significantly and you have employee representatives, check early whether you need to inform or consult them, and record the outcome. Finding this out late can stop a go-live.
Write the case for change before announcing anything. Keep it to one page and answer six questions: why are we changing and why now, what is at stake, what changes and for whom, what does not change, when will it happen, and how will we know it has worked. Keep it factual. State the obligation and the dates without overstating the consequences. Every later message will be built on it.
Announce from the top, once the plan is approved. The executive sponsor should send the first announcement to all staff. Explain why in two or three sentences, then reassure people: many will see little change, and those whose roles are affected will hear from their manager and be trained before anything changes. Name who people can go to with questions.
Let managers explain the detail. The sponsor explains why. Line managers explain what changes for their team. A general announcement does not change behaviour; a buyer needs to know what they will do differently, and from when.
Listen for concerns early. Most concerns point to a real gap in the plan, the training or the timing. Buyers, for example, often worry that new evidence requests will damage long-standing supplier relationships. Hearing that during planning gives you time to respond, for instance by having a senior leader join the first supplier conversations.
Say what will not change. It removes much of the uncertainty, and it is the message most often forgotten.
Next in this series: Part 2, Design and Tailor, on building procedures around the handovers between teams without weakening the controls.
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.