Works council and whistleblowing system: what is subject to co-determination?

Many whistleblowing rollouts do not stall because of the software. They stall because the organisation treats employee participation as an afterthought. As soon as a system affects internal process rules, access rights, data visibility or communication standards, the works council question becomes real.

That is why HR, legal and management should distinguish between the legal obligation to operate a channel and the concrete way the channel is designed inside the company. The obligation itself comes from whistleblower law. The operational setup around the channel may trigger co-determination, depending on the design choices made.

What works councils usually focus on

In practice, a works council rarely asks only whether a reporting channel exists. The more important questions are usually these: can the system be used to monitor employee behaviour? Who gets access to reports? How are accused persons protected? What data is retained? What reporting or statistics are generated? And how are employees informed about the new process?

Those are exactly the topics where co-determination becomes tangible. A whistleblowing setup can touch workplace order, behaviour-related rules, data handling and the practical balance between employer interest and employee protection. That is why it is usually a mistake to present a fully finished rollout to the works council just before launch.

Co-determination is usually about the design, not the legal duty itself

Two misunderstandings are common. First, some teams assume that a legal obligation means the operational setup is automatically outside co-determination. That is too simplistic. Second, some teams assume that involving the works council means the project will slow down dramatically. In reality, early involvement often clarifies the exact issues much faster.

The most sensitive area is usually technical and procedural visibility. If the tool creates logs, behavioural statistics, structured case routing or reporting that might reveal employee-related patterns, the discussion becomes more concrete. The same applies where the rollout introduces binding rules for communication, training, internal responsibilities or escalation.

What a workable works agreement often covers

For this reason, many companies end up documenting the setup through a works agreement or a similarly structured arrangement. Typical elements include:

• purpose and scope of the reporting system
• which groups may report
• who can access reports and on what basis
• confidentiality and protection against unjustified disclosure
• handling of anonymous reports
• information obligations toward employees
• documentation and deletion logic
• limits for evaluations and management reporting

The value of such a document is not merely formal. It forces the project team to define decisions clearly instead of leaving them vague until the first difficult case appears.

How to prepare the rollout internally

A practical sequence usually works best. First, define the target operating model: which cases should the channel cover, who may report, who owns intake, who decides on follow-up? Second, translate that target model into a clear workflow. Third, discuss the employee-facing implications early with the works council. Fourth, document the final operating logic before launch.

Teams that skip these steps often rely too much on vendor slides or broad legal arguments. That rarely resolves the questions the works council actually cares about. Employee participation is not about whether the software exists. It is about how the system will shape daily practice.

Typical conflict points

The same topics come up repeatedly: should HR have full visibility into all reports? Who can see the identity of reported persons? How detailed may case documentation become? Are anonymous reports handled differently from named ones? What kind of statistics are allowed? These questions should be answered before the first live incident, not during it.

The most useful mindset is therefore this: co-determination is not an annex to the tool selection. It is part of the project design. Companies that accept that early often move faster than companies that try to avoid the discussion.

What this changes in regulated rollouts

With Works council and whistleblowing system: what is subject to co-determination?, 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 Works council and whistleblowing system: what is subject to co-determination?, 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

Before you finalise the rollout, define the operational logic first: who handles reports, what data is visible, which reports can be generated and how employees are informed. Once that is clear, the conversation with the works council becomes concrete and much more productive.

• Read the implementation checklist
• Structure the internal reporting office
• See the whistleblowing system