Mapping entities, contracts and providers to the templates.

The shape you are mapping to

Commission Implementing Regulation (EU) 2024/2956 defines a relational model, not a set of forms. Rows carry keys; other rows reference those keys. Nothing is repeated. Mapping therefore has two halves: deciding what each key is, and deciding which source system owns it.

The second half is the one that gets skipped. If entity identifiers come from finance, provider identifiers from procurement and function names from the risk register, the references will not resolve, because none of those systems was built to agree with the others.

Entities and the perimeter

Start here, because everything else is scoped by it. Each financial entity in the register needs a stable identifier — a legal entity identifier where one exists — together with its position in the group and the level at which the register is being produced.

• One entity list, one source. Legal entity master data, not the finance consolidation tree and not the organisational chart.
• Record the level explicitly so entity, sub-consolidated and consolidated registers can be produced from one dataset rather than three.
• Check identifier currency. A lapsed legal entity identifier fails validation as surely as a missing one.

Contracts to arrangements

The contractual arrangement is the unit. One arrangement can be governed by an overarching agreement and can have several entities as parties, so three distinct facts have to be captured separately: the arrangement itself, its relationship to any overarching arrangement, and which entity signed it as against which entities use the services under it.

Arrangements to services

This is where the register grows, usually by a factor most projects have not planned for. A single contract commonly delivers several ICT services, each with its own service type, start and end dates, notice period, governing law and data location.

Providers and the supply chain

Each direct provider is entered once, with its identifier and country, and referenced from every service it delivers. Subcontractors supporting a critical or important function are then recorded with their rank in the chain.

Rank is positional, so an omitted intermediate entity shifts everything after it and produces a chain that is internally consistent and wrong. Build the chain from the provider’s own disclosure, and where the arrangement does not require that disclosure, log it as a contractual gap — it cannot be inferred from the firm’s own records.

Functions and assessments

Functions are catalogued with their criticality determination, then mapped to the services supporting them. Two mapping rules keep this stable:

1. Function identifiers are permanent. Renumbering the catalogue part-way through a build orphans every mapping row that referenced the old numbers.
2. The mapping is many-to-many. One service supports several functions and one function depends on several services. Forcing a one-to-one relationship to simplify the build produces a register that misstates concentration.

Assessments — substitutability, exit arrangements and reintegration — attach to the arrangements supporting critical or important functions, and are the last thing mapped because they depend on every determination before them.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.