How DORA intra-group ICT services and group registers work for your group
When one entity in a financial group runs ICT services for others, those services sit inside DORA's third-party framework and must appear in the register of information, including every contractual arrangement and every subcontracting chain behind them. The intra-group arrangement does not remove the obligation to report. DORA defines an ICT intra-group service provider as an undertaking in a financial group that provides predominantly ICT services to financial entities in the same group or the same institutional protection scheme (Article 3(20)). Whether a given arrangement lands in that category depends on three things: who provides the service, whether that provider is predominantly an ICT provider, and where the providing entity sits in the group structure. The organization that holds the contract owns its register. An implementation partner can help collect contract data, map service chains and prepare the evidence the register needs, but only the financial entities themselves submit the register to their competent authority.
Structure decides how the register is filed. The ESAs' register FAQ states that the register must include ICT services supplied by intra-group providers, that all contracts including intra-group arrangements are reported in template B_02.01, and that intra-group subcontracting chains are linked in template B_02.03. For reporting to the ESAs, registers go in at individual level for stand-alone entities and for entities whose parent sits outside the Union with no Union parent. Otherwise they go in at the highest level of consolidation in the Union. Group entities registered outside the Union that provide ICT services to a Union financial entity in the same group are also treated as intra-group providers in the register. Confirm with your competent authority and the current ESAs FAQ how your group's consolidation level applies before you map contracts.
Start with an inventory. List every ICT arrangement between group entities, name the providing entity, record its location and confirm whether it provides predominantly ICT services, then trace each chain to the entity that ultimately runs the workload. Ask the group treasury or legal function to confirm which entities are stand-alone and which report at consolidated level, because this changes which register you file. Check whether any intra-group provider is established outside the Union and whether it serves Union entities. Where an intra-group provider uses its own staff for penetration testing, the rules on internal testers under Delegated Regulation (EU) 2025/1190 may treat those testers as internal, so confirm their employment history with the group HR records before you rely on them.
How intra-group contracts and chains appear in the register
The ESAs' register FAQ states that all contracts, including intra-group arrangements, are reported in template B_02.01. This means a service a parent or sister entity provides to a regulated group entity appears as a contractual arrangement in the register, just as a third-party supplier contract would. The intra-group nature of the provider does not remove the entry. Your register must show each arrangement, the group provider that delivers the service, and the regulated entity that receives it.
- Every arrangement, not only external ones: Shared hosting, group-run security operations and internal platform services each need their own line where they support the entity.
- Provider identity: The record should identify the intra-group ICT service provider so the authority can see the group dependency.
- Recipient entity: Each entry should name the regulated financial entity that uses the service.
- Function linkage: Show whether the arrangement supports a critical or important function.
- Consistency with contracts: The entry must match the written intra-group agreement.
The group risk or compliance function usually coordinates this tab, while the internal legal team confirms the contract terms. Confirm with your competent authority how it expects intra-group contracts to be identified in its submission format.
Where an intra-group provider relies on further providers to deliver a service, the chain must be visible. The ESAs' FAQ states that intra-group subcontracting chains are linked in template B_02.03. Reporting the top-level arrangement alone leaves the authority unable to see who else sits behind a critical service, so this tab completes the picture that B_02.01 starts.
- Links between arrangements: Each subcontracting step should connect back to the parent arrangement it supports.
- Intra-group and external steps: Show where a chain moves from a group entity to an outside supplier, because the outside step may bring its own contract and oversight questions.
- Chain depth: Record each level that the group can identify, and note where visibility stops.
- Updates: When a group entity changes its supplier, the linked chain must change with it.
The group technology team or the shared services function typically holds the technical knowledge of these chains, and procurement or vendor management usually keeps the records. Ask your competent authority how far down the chain it expects you to report and what it does when a chain cannot be fully traced.
Article 28(3) requires a register of information covering all contractual arrangements for ICT services. It applies at entity, sub-consolidated and consolidated levels, so the group must decide which entities hold which parts. The article also requires yearly reporting of new arrangements, provision of the register on request, and timely notice to the authority before planned arrangements for critical or important functions. Intra-group arrangements fall inside these obligations just like external ones.
- Three levels of scope: Each regulated entity needs its own view, and the group also needs sub-consolidated and consolidated views.
- Yearly reporting: New intra-group arrangements must be captured in the annual submission.
- On-request availability: The register must be retrievable quickly if the authority asks for it.
- Advance notice: Planned intra-group arrangements supporting critical or important functions need timely notice to the authority.
- Submission level: The ESAs' FAQ explains that stand-alone entities and groups with a non-EU parent and no Union parent report at individual level, while other groups report at the highest consolidation level in the Union.
Group compliance leads usually own this scope decision. Confirm with your competent authority which entity is the reporting entity for your group and how it wants the sub-consolidated view structured.
Group entities registered outside the Union that provide ICT services to a Union financial entity in the same group are treated as ICT intra-group service providers in the register, according to the ESAs' register FAQ. A non-EU sister company hosting a platform for an EU bank therefore appears in the register in the same way as an EU group provider. The tab matters because group structures often hide these arrangements inside global technology functions.
- Identify the provider: Map every non-EU group entity that delivers ICT services to an EU regulated entity.
- Record the service: Capture the arrangement as an intra-group ICT service, not as a generic external supplier.
- Check data and access: Note where the service runs and who can access it, since these details often drive the supervisory questions.
- Keep contracts current: Intra-group agreements with non-EU entities need the same written terms as those with EU entities.
The global IT or shared services organization often knows these arrangements best, while the EU entity's management body remains accountable for the register. Confirm with your competent authority how it expects non-EU group providers to be documented and whether it requests any additional information on them.
Article 31(8) excludes from designation as critical ICT third-party service providers financial entities providing ICT services to other financial entities, providers under Eurosystem oversight frameworks, ICT intra-group providers, and providers serving only financial entities active in the same single member state. The exclusion means an intra-group provider is not on the designated critical provider list through its group status alone. Its services still appear in your register and remain under your own risk management, which is why this tab explains the difference between designation and reporting.
- No automatic designation: Being an intra-group provider removes the entity from CTPP designation under Article 31(8).
- Reporting continues: The arrangement still appears in B_02.01 and any linked chain in B_02.03.
- Management responsibility: The financial entity keeps its ICT third-party risk obligations for group services.
- Other excluded categories: Check whether a provider falls under another exclusion, such as Eurosystem oversight, before assuming how it is treated.
- Single-state cases: Providers serving only entities active in one member state fall outside designation, but the reporting duties do not disappear.
The group risk function and legal counsel usually decide how exclusions apply to each provider. Confirm with your competent authority how it reads the Article 31(8) exclusions in your group's structure.
Non-EU group entities and which register level applies
Group structure decides where a DORA register of information is reported and which entities must appear in it. The four cards below cover the cases a group is most likely to face, from non-EU group providers to the consolidation level used for reporting to the ESAs.
Non-EU group entities serving EU entities
A group entity registered outside the Union that provides ICT services to a Union financial entity in the same group is treated as an ICT intra-group service provider in the register, according to the ESAs register FAQ. Confirm which group entities actually deliver ICT services to EU entities, including shared platforms, monitoring and development teams. Keep the intercompany agreements that define those services, because they are the evidence that the arrangement is in scope.
Individual reporting for stand-alone entities
Registers are submitted at individual level for stand-alone entities. A stand-alone entity has no group parent to consolidate under, so its own register is the reporting unit. Confirm the entity's ownership chain against the group structure chart and the legal entity register. Record the date of that check, since a change in ownership can move the entity to a different reporting level.
Non-EU parent with no Union parent
Entities whose parent is outside the Union, with no Union parent above them, report at individual level under the ESAs FAQ. The group must show that no Union parent exists in the chain, including intermediate holding companies. Evidence is the ownership map with each holding entity's domicile and the Union subsidiary list. Re-check the map when the group reorganizes, since adding a Union holding company changes the answer.
Highest Union consolidation level and sub-consolidation
Where neither of the individual-level cases applies, registers are submitted at the highest level of consolidation in the Union. Sub-consolidated registers under Article 28(3) sit between entity and group level and must still link to the same contract data. Confirm which Union entity is the top consolidating parent and which intermediate levels the supervisor expects. Keep one contract inventory that feeds every level, so the entity, sub-consolidated and consolidated views cannot drift apart.
Why intra-group providers are excluded from critical provider designation
ICT intra-group service providers are excluded from designation as critical ICT third-party service providers. Article 31(8) of DORA lists the categories that cannot be designated as critical, and intra-group providers sit alongside four others: financial entities that provide ICT services to other financial entities, providers under Eurosystem oversight frameworks, and providers that serve only financial entities active in a single member state. The exclusion means that a group's internal technology company will not appear on the ESAs' list of designated critical providers, so the Lead Overseer regime does not reach it directly. Readers should not treat that as a finding that the service is low risk. It is a decision about who supervises the provider, not about whether the service must be controlled.
The exclusion does not remove any obligation on the group. Intra-group ICT services are still ICT services under DORA, so every contractual arrangement must appear in the register of information, including the chains of subcontracting that run through group entities. The entity still has to assess the risk of each arrangement, document its use in the ICT risk framework, and set out contract terms for services that support critical or important functions. Where a service supports such a function, the notice to the competent authority before the arrangement starts still applies. Groups should map each intra-group service to the register templates and the risk assessment before assuming that the designation exclusion simplifies anything.
Scope questions are where groups get this wrong, so confirm them early. Ask the competent authority how it reads the exclusion for your entity, and check whether a provider qualifies as an intra-group provider under the Article 3(20) test, which turns on whether it provides predominantly ICT services to entities in the same group or institutional protection scheme. Check the position of any group entity established outside the Union as well, because the register treatment differs from the designation question. Record the answers in writing with the date and the authority's reference, and keep them with the register of information so that an assessor can see the basis for each classification.
Using group testers for threat-led penetration testing
Article 15 of Delegated Regulation (EU) 2025/1190 sets who may form the internal testing team in a threat-led penetration test. For a financial group, the question is whether testers sit in the entity itself or in an intra-group ICT provider, and whether their employment history can be shown.
Team composition
The internal testing team needs a test lead and at least two other members. Each card in this group concerns one part of that test. Confirm the headcount and roles in writing before the test starts, and map each named tester to a role such as test lead or tester. A team that meets the number on paper but lists a lead who cannot evidence the required employment will not satisfy the requirement.
The 12-month employment test
Each team member must have been employed by the entity or an ICT intra-group provider for the preceding 12 months. Employment is measured as a continuous history, not a current role. Contractors placed through agencies, or testers who joined the group recently, may fail this test even when their skills are strong. Check start dates and any gaps before naming the team.
The intra-group tester rule
Testers employed by an ICT intra-group service provider count as internal. This lets a group centralise its security testers in one entity and assign them to several financial entities. Confirm that the provider meets the Article 3(20) definition, that it provides predominantly ICT services to entities in the same group, and that the arrangement is documented in the register of information.
Evidence of employment history
Keep records that show each tester's employer, start date and continuity over the 12 months before the test. Typical evidence includes HR records, employment contracts, payroll extracts or intra-group secondment letters, reviewed by the group's HR and legal functions. Ask the independent assessor or competent authority which format it expects, because the records must support the team claim during supervisory review.
Scope and external testers
This section covers only the internal team rule. Whether external testers may join, how TLPT scope is set and which authority approves the test are governed by other provisions of DORA and the TLPT rules. Confirm these points with the competent authority and the testing provider before relying on group testers for any part of the engagement.
Steps to map intra-group services before the next register submission
This sequence turns an unstructured set of group arrangements into a register that shows every intra-group ICT service, its contracts and its subcontracting chains, ready for the reporting level the group has chosen. Each step produces a artifact that the next one depends on.
Inventory every group entity and ICT provider
Start by listing each entity in the financial group, including entities outside the EU, and every group function that supplies ICT services to other group entities. Ask IT, procurement, shared services and each business line which systems, hosting, support or software administration they receive from a sister company or a central group function. The output is a single inventory with one row per provider entity and per service, stating which financial entities consume it. Confirm the inventory with the group's legal entity list so no entity is missed.
Apply the Article 3(20) intra-group test
For each provider on the inventory, check whether it is an undertaking in the same financial group or institutional protection scheme and whether it provides predominantly ICT services to financial entities in that group. Record the reasoning for each provider, including borderline cases where a group function mixes ICT with non-ICT work. The output is a signed-off classification sheet that the compliance and IT risk owners both review. Keep the sheet with the ICT third-party policy so an assessor can trace each classification.
Map contracts and subcontracting chains
For every intra-group provider, collect the written arrangements that govern the service, such as service agreements, cost-sharing or recharge documents and internal service level terms, and identify each service and the financial entities that receive it. Then trace any subcontracting the group provider uses, including third parties it relies on to deliver the service. The output is a contract-to-service map and a chain diagram showing which provider sits behind each service. Gaps where no written arrangement exists should be escalated to the management body as findings.
Decide the reporting level for each entity
Determine whether each entity reports as a stand-alone entity, as an entity whose parent is outside the Union with no Union parent, or at the highest level of consolidation in the Union, following the ESAs reporting guidance. Check the group structure against the Union parent position and record which register each contract belongs to. The output is a reporting-level decision memo, with the register owner named for each submission. Confirm the approach with the competent authority contacts or the ESAs guidance before data assembly begins.
Assemble data for templates B_02.01 and B_02.03
Populate the contract-level data for template B_02.01, covering every intra-group contract, and link intra-group subcontracting chains in template B_02.03. Use the contract and chain maps from earlier steps as the source, and check that each intra-group provider appears wherever its services are consumed. Reconcile the totals against the inventory so no provider or contract is dropped between steps. The output is a draft register extract plus a reconciliation log showing every reconciling item and who resolved it.
Review the draft against the register FAQ and sign it off
Have a second reviewer, separate from the data preparer, test the draft against the ESAs register FAQ and the register-related Article 28(3) duties, including the requirement to hold the register for provision on request. Check that intra-group arrangements are reported consistently and that consolidated and entity-level views agree. The output is a signed review record and an approved register version, stored with the evidence that supports each entry.
Set an annual update routine and change triggers
Agree who updates the register each year, which systems and contract change logs feed it, and which events force an earlier update, such as a new intra-group service, a reorganization of group entities or a change in subcontracting. Article 28(3) requires yearly reporting on new arrangements, so schedule the annual cycle against the reporting calendar the competent authority confirms. The output is a documented update procedure with named owners and a change log that the next cycle can start from.
Who owns the group register and who prepares the evidence
The group parent or the compliance function that runs the consolidated view is accountable for the register of information as a whole. It decides which entities in the group are in scope, which contractual arrangements exist between them, and at which level of consolidation each submission is made. Because the register must cover entity, sub-consolidated and consolidated levels, this function usually sets the data standards that every entity follows, even where each regulated entity remains responsible for its own accuracy.
- Scope decisions: Confirm which group entities are financial entities under DORA and which are ICT intra-group providers, and record the reasoning.
- Consolidated register ownership: Hold the master list of intra-group arrangements and the chains that link them in the register templates.
- Reporting level: Decide with the authority which entity submits at individual level and which submits at the highest Union consolidation level.
- Policy and sign-off: Ensure the management body approves the ICT third-party policy that covers intra-group services.
- Yearly update: Schedule the annual reporting of new arrangements and the timely notice of planned arrangements supporting critical or important functions.
An implementation partner such as DeployOpen can help prepare mapping extracts, data cleansing and documentation for this function, but the group remains the owner of the decisions and the submitted content. Confirm who signs off the register and who answers supervisory questions before work starts.
The entity that actually runs the shared platform, data centre or software service for other group members is the intra-group ICT service provider. It knows the technical details that the register needs: service descriptions, locations, subcontractors and the systems that support each function. Its records are often the primary source for the register, so its data quality determines whether the group submission can be trusted. It also has its own resilience obligations for the services it delivers to the group.
- Service inventory: Maintain a current list of every ICT service delivered to group entities, with the receiving entity and the function it supports.
- Subcontracting chains: Record each downstream provider and the point where it is linked to the group arrangement.
- Technical evidence: Keep configuration, logging, backup and access records that show how the service runs.
- Testing staff: Where its employees act as internal testers for group entities, confirm their employment history meets the requirements for internal testing teams.
- Change notice: Inform receiving entities when services, locations or subcontractors change.
The partner may help assemble system evidence and data exports for this entity, yet the provider remains responsible for the accuracy of what it reports. Confirm the intra-group service agreement covers data access, audit rights and cooperation with the register process.
An implementation partner prepares systems, data and documentation so that the group and its providers can produce accurate register entries and supporting evidence. Its work is preparatory: it does not decide what is in scope, approve the register or give an opinion on whether the group complies. Engagements are usually fixed in scope and agreed in writing, which makes the boundary of the work clear before any data is touched.
- Data preparation: Extract and normalise contract, service and subcontracting data from existing systems into the structure the register templates require.
- Mapping: Link intra-group services to the entities, functions and chains they support, and flag gaps for the owners to resolve.
- Documentation: Draft procedures, service descriptions and evidence indexes for the group to review and adopt.
- System evidence: Collect logs, configuration exports and access records from the self-hosted platforms in the client's own infrastructure.
- Handover: Leave the group with the files, the mapping logic and the evidence trail so it can maintain the register without the partner.
The partner does not issue reports, attestations or certifications, and it should not present its output as a regulatory finding. Ask for the written scope, the named deliverables and who will review the outputs before submission.
The competent authority for each type of financial entity supervises DORA compliance, using the powers in Article 50. It receives the register on request and in the yearly reporting cycle, and it can ask questions about intra-group arrangements, subcontracting chains and the reasoning behind scope decisions. Where a credit institution is significant, the ECB carries out that role. The authority is the body that issues supervisory findings, and no other party can stand in for that determination.
- Register review: Check that the register covers intra-group contracts, chains and non-EU group entities as the ESAs register guidance describes.
- Level of reporting: Confirm that the submission level matches the entity's position in the group.
- Supervisory findings: Issue findings, requests for remediation or other measures based on its own review.
- Critical provider limits: Note that intra-group providers are excluded from designation as critical ICT third-party service providers under Article 31(8), so their supervision runs through the group's financial entities.
- Information requests: Expect questions on how the group produced its data and who checked it.
No partner, auditor or consultant can speak for the authority or pre-clear a submission. Confirm with the relevant authority which format and channel it uses before you prepare the register.
Questions about intra-group ICT services under DORA
Do intra-group ICT contracts need to be in the DORA register of information?
Yes. The ESAs' register FAQ states that the register must include ICT services provided by intra-group ICT service providers, and that all contracts, including intra-group arrangements, are reported in template B_02.01. Intra-group subcontracting chains are linked in template B_02.03, so a service a group entity buys from another group entity can appear as a chain rather than a separate direct contract. The practical driver is the contract itself: a written arrangement between group entities for a platform, hosting or support service should be inventoried like any third-party contract. Ask your compliance lead to confirm how your intra-group agreements are documented before you start populating the templates.
When does a group company count as an intra-group ICT service provider?
DORA defines an ICT intra-group service provider in Article 3(20) as an undertaking in a financial group that provides predominantly ICT services to financial entities in the same group or the same institutional protection scheme. The test is therefore about the group company's role: if its main business is supplying ICT services to sister or parent financial entities, it falls under this definition. A group company that mainly serves external customers, or that supplies ICT services only incidentally to its own group, is assessed differently. Confirm the predominance question with the entity's management body, using revenue, headcount and service catalogue evidence, and record the conclusion in your policy so an assessor can follow it.
What changes when the group parent or ICT provider is outside the EU?
Group entities registered outside the Union that provide ICT services to a Union financial entity in the same group are treated as ICT intra-group service providers in the register of information, according to the ESAs register FAQ. That means they are reported in the register even though they sit outside the EU. Reporting level also depends on structure: registers are submitted at individual level for stand-alone entities and for entities whose parent is outside the Union with no Union parent, and otherwise at the highest level of consolidation in the Union. Ask your group finance and legal teams to map each non-EU group entity that touches your ICT services, and confirm the submission level with your national competent authority before the first reporting cycle.
Do internal TLPT testers employed by a group company count as internal testers?
Yes, in principle. Article 15 of Delegated Regulation (EU) 2025/1190 requires an internal testing team with a test lead and at least two other members, all employed by the entity or by an ICT intra-group provider for the preceding 12 months. Testers employed by an ICT intra-group service provider therefore count as internal. The 12-month employment condition is the detail most often missed: a tester hired from outside the group last quarter does not meet it, and a contractor is not an employee. Check each tester's employment record against the requirement before you name the team, and keep the records available for the authority.
How often does the register of information need to be updated?
Article 28(3) requires a register covering all contractual arrangements for ICT services at entity, sub-consolidated and consolidated levels, with yearly reporting on new arrangements and timely notice to the authority of planned arrangements supporting critical or important functions. It must also be provided on request. Intra-group arrangements sit within the same register, so a new group platform or changed group subcontractor triggers the same update logic as an external contract. Set an internal trigger so that any new or changed group arrangement is logged when it is agreed, not when the annual report is due. Confirm the current submission calendar with your supervisor, since reporting mechanics are set by the authorities.
Can a partner like DeployOpen prepare the group register and intra-group evidence?
A partner can help prepare systems, documentation and evidence for the register, but it cannot own the register or decide regulatory conclusions. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in the client's own infrastructure, and it can document how a platform is deployed, operated and shared across group entities. It does not issue audit reports, attestations or certifications, and the organization remains responsible for its controls and submissions. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask for the deliverables list, the group entities in scope and who signs each document before you engage anyone.
What can a partner not do for intra-group compliance?
A partner cannot decide whether a group entity is an intra-group provider, cannot certify that the register is complete, and cannot act as the authority's contact for submissions. Those judgments belong to the financial entity's management body and compliance function, and any formal conclusion comes from the competent authority or an independent assessor. A partner also cannot change the legal structure of your group or rewrite intra-group contracts on your behalf without your legal team. Where a partner's work touches a critical or important function, the organization still needs to review the output against its own policy. Clarify these boundaries in the statement of work so that no one assumes a signature or conclusion that nobody actually owns.
How should a group handle intra-group chains when a sister entity subcontracts?
Intra-group subcontracting chains are linked in template B_02.03 under the ESAs register FAQ, so the link between the contracting entity and the group entity that ultimately delivers the service must be traceable. The engineering question is which group entity runs the underlying platform and which external providers it relies on beneath that. Map each hop, record which entity holds the contract, and flag any external provider that supports a critical or important function. Ask the group to confirm the chain at least once a year, because internal reorganizations often change who actually operates a system without anyone updating the contract.
How DeployOpen prepares group registers and evidence
DeployOpen scopes intra-group mapping in a written, fixed-scope agreement before any work starts. For a group that runs ICT services between its own entities, the agreement should name each entity that receives services, each entity that provides them, the services in question, and the contracts or intra-group arrangements that sit behind them. Those boundaries decide what goes into the register of information, which templates the data lands in, and what the financial entity can defend to its competent authority. DeployOpen works with the client to agree these boundaries, then prepares the register data and supporting evidence inside the client's own cloud accounts, data centers or air-gapped networks. Client data stays under the client's control throughout.
In practice, the preparation work covers the intra-group provider mapping, the linkage of subcontracting chains that run through group entities, the identification of any group entity registered outside the Union, and the record of which testers are employed by an intra-group provider for the internal testing requirement. Each item is handed over as documentation the client's compliance and legal teams can review, correct and approve. The organization remains the owner of its register, its contracts and its classification decisions, and it signs off what is submitted. Confirm with your competent authority and your legal counsel how they expect group-level submissions to be made for your structure.
DeployOpen does not issue reports, attestations or certifications, and it does not guarantee any regulator outcome. Only the competent authority can supervise compliance, and only an independent assessor or auditor can issue an opinion where one is required. The price of the work follows from the written scope, so the quote should list the entities in scope, the register templates to be prepared, the evidence to be assembled and the handover format. Ask for those items explicitly so that the scope, the deliverables and the client's own responsibilities are visible before the engagement begins.
