Supply Chain Act
Build a complaints procedure under the Supply Chain Act: how to make your channel fit for LkSG
How companies should design an LkSG complaints procedure so that external stakeholders, accessibility and workflow are properly covered.
The key points at a glance:
The complaints procedure under the German Supply Chain Act is often underestimated because many companies instinctively equate it with a standard whistleblowing channel. The two systems overlap, but they are not the same. If a company takes its internal reporting route and simply labels it “also for supply chain complaints”, the result is rarely an LkSG-ready procedure.
The core difference lies in reporting groups and accessibility. Traditional whistleblowing channels are often designed primarily for employees and close business contacts. The LkSG complaints procedure has to work for people affected along the supply chain or for those who perceive corresponding risks.
How the LkSG differs from a classic whistleblowing setup
A classic whistleblowing system often focuses on legal violations and serious misconduct in or around the organisation. The LkSG procedure goes further by addressing human rights and environmental risks in the supply chain. That changes the design logic of the channel.
Companies therefore need to ask different questions: is the channel understandable only for internal users, or also for external affected persons? Is the language accessible? Are the barriers low enough? Can somebody report who has no prior knowledge of the company at all?
Who must realistically be able to report
An LkSG-ready complaints procedure has to work in practice for internal and external stakeholders. That may include employees, suppliers, workers of suppliers, affected communities, NGOs or other reporting persons. This breadth is one of the clearest differences from many traditional company-only channels.
Once you take those groups seriously, one thing becomes obvious: internal corporate language or a channel visible only inside the intranet is not enough. The route must be publicly reachable, understandable and genuinely usable.
That also changes risk management. A complaints procedure under the Supply Chain Act is part of the company’s due diligence obligation, not just an extra inbox. It has to connect to supply chain management, risk assessment, and the review of human rights and environmental concerns in a way that can actually be operated over time.
Accessibility is not a side topic
Under the LkSG, accessibility quickly becomes a core criterion. This includes language, discoverability, channel choice and practical clarity. A procedure can exist formally while remaining inaccessible in reality if external stakeholders do not understand what it is for or how to use it.
That is why companies should design the channel from the point of view of external stakeholders. Even someone who has never worked with the company directly should be able to understand whether the channel fits the concern they want to raise.
What a workable procedure needs
A resilient LkSG complaints procedure needs at least the following building blocks:
- a publicly accessible channel
- a clear explanation of purpose and scope
- confidential communication options
- defined ownership for review and referral
- documented follow-up measures
- understandable feedback logic for reporting persons
In many companies, a digital system already used for whistleblowing can provide this backbone. The key, however, is that the reporting groups, texts, roles and workflows are extended accordingly. An unchanged internal-only setup is rarely enough.
That is why many teams use the existing whistleblowing system only as a starting point. The final setup still needs dedicated wording, stakeholder logic, and internal ownership that reflect supply chain complaints rather than only classic internal compliance cases.
Typical mistakes
The most common mistakes are easy to recognise: internal-only language, no public discoverability, no multilingual access despite an international supply chain, unclear ownership, missing feedback and a procedure designed only for employees. Another common weakness is naming a procedure without explaining which issues actually belong there.
Connecting the procedure to your existing system
The good news is that companies do not always need two completely separate worlds. In many cases, an existing whistleblowing system can be extended. The condition is that the complaints procedure, stakeholder logic and communication layer are genuinely adapted to LkSG needs.
This usually affects the entry copy, the ownership model, external accessibility and the link to broader compliance or procurement processes.
What this changes in regulated rollouts
With Build a complaints procedure under the Supply Chain Act: how to make your channel fit for LkSG, the real challenge is rarely a single legal question in isolation. As soon as several entities, reporting groups or external stakeholders are involved, a legal requirement turns into a coordination problem. That is the point where companies either translate the rule into an operating model, or end up with a formally correct but weak setup.
Teams often underestimate the distance between legal wording and project reality. The law may define the frame, but it does not automatically answer which roles, texts, ownership lines and escalation rules make sense in the organisation. If that translation step is skipped, the channel may exist on paper while still being difficult to use in practice.
This matters even more in Germany and Austria, where terminology, authority practice and internal expectations are not always identical in real projects. Groups with several entities or public-sector structures therefore benefit from a stable core process combined with clearly documented local differences.
Three questions to settle internally
Before approval, it helps to pressure-test the concept. In topics like Build a complaints procedure under the Supply Chain Act: how to make your channel fit for LkSG, quality usually improves when teams answer three practical questions early:
- Which groups and situations are actually in scope? Do not stop at the abstract wording of the law. Look at real reporting situations, including suppliers, applicants, former staff, subsidiaries or public-facing functions where relevant.
- Who decides difficult edge cases? Nearly every rollout produces questions that sit between legal, HR, compliance, privacy or line management. If there is no clear decision owner, uncertainty appears later during intake and follow-up.
- Which local adjustments need to be documented? Even with one platform, there may be local differences in terminology, FAQ wording, stakeholder groups or governance expectations. Those differences should be made explicit, not improvised later.
Where teams usually get this wrong
The same implementation mistakes appear again and again in legal and obligation-heavy topics:
- Optimising for the narrowest legal minimum. A setup that only aims for minimal compliance often performs poorly in terms of trust, usability and early internal reporting. Operational effectiveness matters as much as legal defensibility.
- Bringing operational owners in too late. If reporting office, privacy, HR or IT review the design only shortly before launch, core questions are reopened and timelines slip.
- Using one communication layer everywhere. A single standard text rarely works equally well across all entities and audiences. A shared core plus deliberate localisation is usually stronger.
How to turn legal requirements into an operating model
Strong projects usually connect legal interpretation with practical process design:
- Define one core process first. Clarify how intake, triage, timing, documentation and escalation work across the group or organisation. That creates consistency and reduces later exceptions.
- Document where local variation is needed. Record differences in language, committees, public-sector specifics, target groups or local responsibilities. Explicit variation is easier to govern than hidden inconsistency.
- Approve communication and training together. A setup becomes durable only when the affected roles share the same understanding of reporting groups, protections and expected handling standards.
What to do now
If you want to make your complaints procedure fit for the LkSG, start by asking whether external stakeholders can actually find, understand and use the channel today. That perspective determines whether you have an internal tool or a credible supply-chain procedure.
Sources
Supply Chain Act
A practical next step
If you want to act on this topic now, these are the most useful next steps.
