csrdready Put me on the waitlist

Kennisbank

Ownership of control in a group with multiple entities

A control without an owner doesn't really exist

A control is a rule or check that must ensure a data point is correct: a reconciliation between two sources, an approval before a figure moves forward, a check on a range. On paper, the control is described in a process document or an audit report. But a control that no one executes is not a control. It's a sentence in a document.

In a group with one entity, that problem is usually small. There is one finance department, one controller, one person who knows who looks at what. In a group with multiple entities, that self-evidence disappears. Each entity may have its own accounting system, its own local controller, its own way of recording energy consumption or personnel data. The control that was designed at group level must be executed separately at each entity — or nowhere at all.

Who owns the control, and who executes it

Ownership of a control falls into two parts that do not always rest with the same person. There is the person who designed or approved the control — often at group level, from sustainability or finance. And there is the person who actually executes the control per entity — often a local controller, an operational manager, someone who maintains the spreadsheet.

If those two roles are not explicitly assigned, something predictable happens: the group assumes the control exists because it was designed, while at entity level no one feels responsible for executing it. That is exactly what what do you do when no one is the owner in a group with multiple entities describes: the question is not only who should own the control, but what structurally goes wrong when that question remains unanswered.

Control attaches to the data point, not the entity

A workable way to assign ownership starts not with the entity but with the data point. For every data point that recurs in the reporting — CO2 emissions per location, number of FTEs, water consumption — there is a chain: a definition, a process in which it is recorded, and a control that must demonstrate it is correct. Who owns the definition of a data point determines exactly what is measured and according to which standard. Who owns the process beneath it determines who records and supplies the data point. And above that sits the question who owns the control: who checks whether the result of that process is plausible and correct, and who signs off on it.

In a group with multiple entities, this means that each of these three roles can differ per entity, while the definition and the control itself should ideally be the same across the group. A control that is a manual reconciliation at one entity and an automated check at another produces data that is not comparable — even though both entities call it "control on energy consumption."

What a control must be able to catch

A control is only worth something once it knows what an acceptable outcome is and what is not. That requires two things that often remain implicit. First, an answer to what is a valid value: a range, a unit, a format within which an entered figure is acceptable. Without that standard, a control can only check whether something was filled in, not whether it is correct. Second, a way to flag deviations before they end up in the final report — how do you set a signal deviation is about thresholds that indicate when a figure deserves a human look, instead of every control on every data point receiving equal attention.

With multiple entities, it pays to establish these two elements — valid value and signal deviation — at group level and have them executed locally. That prevents each entity from applying its own interpretation of "normal."

Establishing ownership before adding a tool

The temptation in a group with multiple entities is to purchase a software package that automatically reconciles figures and flags deviations. That package does what it is supposed to do once the underlying question has been answered: who is responsible for what, per data point, per entity. Without that answer, a tool organizes nothing — it executes control logic on data that no one precisely knows who is watching over.

Ownership of control is therefore not a question that gets answered afterward, during implementation. It is the first question, and the question that determines whether everything that comes after it stands on something solid.

The bridge to the work scan

Once ownership of control per entity and per data point has been established, it also becomes clear what in that work is repeatable: reconciling figures, checking ranges, flagging deviations. Part of those steps is fixed enough to leave to a computer, another part requires a judgment that must remain with a human. The work scan from FTE TO AI calculates, per task, what portion of that work can be taken over by AI, so it becomes clear where automation strengthens control and where it would actually erode ownership.

Marvinde assistent van de Data Readiness Scan

Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.

Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.