The 15 DORA Templates Explained: What Each One Captures

The DORA Register of Information isn't a single form—it's a system of 15 interconnected templates that together document your organization's ICT third-party arrangements. Understanding what each template captures, and how they link together, is essential for a successful submission.

In the ESA dry run, 86% of validation errors stemmed from missing mandatory information, and many of those gaps occurred because compliance officers didn't fully understand what each template required. This guide explains all 15 templates, their purposes, relationships, and the common mistakes that trip firms up.

The Template Structure: Understanding the Framework

Before diving into individual templates, it helps to understand how the ESAs organized them.

Template Groupings

How Templates Connect

The templates form a web of relationships. Understanding these connections prevents the cross-reference errors that affected 15% of dry run submissions:

• B_01 (entities) → referenced by B_02, B_03, B_04, B_06
• B_02 (contracts) → referenced by B_03, B_04, B_05
• B_05 (providers) → referenced by B_02, B_03
• B_06 (functions) → referenced by B_02, B_07

A provider in B_05 must match the provider referenced in B_02. A function in B_06 must exist before B_02 can reference it. These cross-template relationships are where validation often fails.

Template B_01: Entity Identification (3 Templates)

The B_01 group establishes who you are—the foundation for everything else in the register.

B_01.01: Entity Maintaining the Register of Information

Purpose: Identifies the financial entity responsible for the register.

Key Fields:

• Legal Entity Identifier (LEI)
• Legal name (exactly as registered)
• Entity type (from ESA classification)
• Country of registration (ISO code)
• Competent authority identifier
• Reporting reference date

Common Mistakes:

• Using a lapsed or expired LEI (32% of dry run submissions had LEI issues)
• Wrong entity type classification
• Incorrect country code format (use ISO 3166-1 alpha-2, e.g., "DE" not "Germany")

B_01.02: List of Entities Within the Scope of Consolidation

Purpose: Documents all entities in your group—parent companies, subsidiaries, and their relationships.

Key Fields:

• Entity identifiers (LEI for each entity)
• Parent undertaking relationships
• Ultimate parent undertaking
• Total assets per entity
• Date of integration into scope
• Country of registration

Common Mistakes:

• Missing subsidiaries that use ICT services
• Incorrect parent/subsidiary hierarchy
• Omitting entities recently acquired

B_01.03: List of Branches

Purpose: Identifies branches of financial entities located outside their home country.

Key Fields:

• Branch identifier
• Host country (where branch operates)
• Home country (parent entity's country)
• Branch type
• Link to parent entity in B_01.01 or B_01.02

Common Mistakes:

• Confusing branches with subsidiaries (branches are not separate legal entities)
• Missing branches that use distinct ICT services
• Incorrect host country codes

Template B_02: Contractual Arrangements (3 Templates)

The B_02 group documents your actual contracts with ICT providers—the core of the register.

B_02.01: Contractual Arrangements – General Information

Purpose: Lists all contracts with direct ICT third-party providers.

Key Fields:

• Contract reference number (your internal ID)
• Type of contractual arrangement
• Contract start date
• Contract end date (or perpetual flag)
• Total annual expense (currency and amount)
• Provider identifier (links to B_05.01)

Common Mistakes:

• Missing contract dates (affected 22% of dry run submissions)
• Inconsistent contract reference numbers across templates
• Wrong currency codes (use ISO 4217)
• Forgetting contracts that renewed automatically

B_02.02: Contractual Arrangements – Specific Information

Purpose: Details about each contract—services provided, SLAs, data locations, and exit provisions.

Key Fields:

• Contract reference (links to B_02.01)
• ICT service description
• Functions supported (links to B_06.01)
• Notice period for termination
• Governing law jurisdiction
• Data processing location (ISO country codes)
• Data storage location
• Level of reliance on the service
• Substitutability assessment

Common Mistakes:

• Incomplete SLA information (27% of submissions)
• Missing data location codes (13% of submissions)
• Vague service descriptions
• Forgetting to document exit provisions

B_02.03: List of Intra-Group Contractual Arrangements

Purpose: Maps relationships between intra-group contracts and external ICT provider contracts.

Key Fields:

• Intra-group contract reference
• Related external contract reference
• Nature of the arrangement
• Entities involved (links to B_01.02)

Common Mistakes:

• Missing the link between internal shared services and underlying vendor contracts
• Not documenting group-level arrangements that individual entities rely on

Template B_03: Signing Parties (3 Templates)

The B_03 group captures who actually signs contracts—which isn't always the entity using the service.

B_03.01: Entities Signing Contractual Arrangements for Receiving ICT Services

Purpose: Identifies which financial entity signed each contract for receiving ICT services.

Key Fields:

• Contract reference (links to B_02.01)
• Signing entity identifier (links to B_01)
• Date of signature
• Role in the arrangement

Common Mistakes:

• Assuming the user entity always signs (group procurement may sign centrally)
• Missing co-signing arrangements

B_03.02: ICT Third-Party Service Providers Signing Contractual Arrangements

Purpose: Identifies which ICT provider entity signed the contract to provide services.

Key Fields:

• Contract reference (links to B_02.01)
• Provider identifier (links to B_05.01)
• Legal entity that signed
• Relationship to provider group

Common Mistakes:

• Using the provider's trading name instead of the legal entity name
• Not verifying which legal entity within a provider group actually signed

B_03.03: Entities Signing Arrangements for Providing ICT Services to Others

Purpose: Documents when your financial entity provides ICT services to other group members.

Key Fields:

• Arrangement reference
• Provider entity (your entity providing services)
• Recipient entities (group members receiving services)
• Nature of services provided

Common Mistakes:

• Overlooking internal IT shared services as ICT provision
• Not documenting group-level IT services to subsidiaries

Template B_04: Service Users (1 Template)

B_04.01: Entities Making Use of the ICT Services

Purpose: Identifies all financial entities and branches that actually use ICT services under registered contracts.

Key Fields:

• Contract reference (links to B_02.01)
• User entity identifier (links to B_01)
• Service identifier
• Nature of use
• Start date of use

Common Mistakes:

• Missing branches that use services
• Not documenting all entities benefiting from group contracts
• Confusing "signing" with "using"

Template B_05: ICT Service Providers (2 Templates)

The B_05 group documents your providers and their supply chains—critical for understanding concentration risk.

B_05.01: ICT Third-Party Service Providers

Purpose: Lists all ICT providers—direct providers, intra-group providers, and subcontractors.

Key Fields:

• Provider identifier (LEI preferred, or EUID, or national registration)
• Legal name
• Country of registration
• Provider type classification
• Ultimate parent undertaking (for group providers)
• Criticality assessment

Common Mistakes:

• Missing LEIs for providers that have them (18% of submissions)
• Using trading names instead of legal names
• Incomplete subcontractor documentation
• Not identifying ultimate parent undertakings

B_05.02: ICT Service Supply Chains

Purpose: Maps the relationships between ICT providers in supply chains—who subcontracts to whom.

Key Fields:

• Provider identifier (links to B_05.01)
• Subcontractor identifier
• Supply chain rank (1 = direct, 2 = sub of direct, etc.)
• Services subcontracted
• Subcontractor recipient entities

Common Mistakes:

• Missing the subcontractor layer entirely
• Not knowing your cloud provider's infrastructure partners
• Incomplete supply chain mapping

Template B_06: Functions Identification (1 Template)

B_06.01: Functions Identification

Purpose: Documents the business functions supported by ICT services, particularly critical or important functions.

Key Fields:

• Function identifier (unique code)
• Function name and description
• Function type classification
• Critical/important function flag
• Entities performing the function (links to B_01)
• ICT services supporting the function (links to B_02)

Common Mistakes:

• 18% of submissions misclassified critical functions
• Missing functions supported by ICT services
• Inconsistent function naming across templates

Template B_07: Assessments (1 Template)

B_07.01: Assessments of the ICT Services

Purpose: Captures risk assessments for ICT services supporting critical or important functions.

Key Fields:

• Assessment reference
• ICT service reference (links to B_02)
• Assessment date
• Risk assessment outcomes
• Substitutability assessment
• Exit strategy documentation
• Impact assessment results

Common Mistakes:

• Incomplete assessments for critical services
• Missing exit strategy documentation
• Not updating assessments after service changes

Template B_99: Definitions (1 Template)

B_99.01: Definitions from Entities Making Use of ICT Services

Purpose: Documents entity-specific definitions and meanings for indicators used throughout the register.

Key Fields:

• Definition reference
• Term being defined
• Entity-specific meaning
• Context of use
• Related template references

Common Mistakes:

• Leaving this blank when you've used non-standard terminology
• Inconsistent definitions across the register

Template Relationships: The Connection Map

Understanding how templates connect prevents cross-reference errors. Here's the complete relationship map:

B_01.01 (Reporting Entity)
    ↓
B_01.02 (Group Entities) ↔ B_01.03 (Branches)
    ↓
B_02.01 (Contracts) ↔ B_02.02 (Contract Details) ↔ B_02.03 (Intra-group)
    ↓
B_03.01/02/03 (Signing Parties)
    ↓
B_04.01 (Service Users)
    ↓
B_05.01 (Providers) ↔ B_05.02 (Supply Chains)
    ↓
B_06.01 (Functions)
    ↓
B_07.01 (Assessments)
    ↓
B_99.01 (Definitions)

Critical Cross-References:

• Every contract in B_02.01 must reference a valid provider in B_05.01
• Every service user in B_04.01 must exist in B_01.01, B_01.02, or B_01.03
• Every function in B_06.01 referenced by B_02.02 must exist
• Every assessment in B_07.01 must reference a valid contract

Common Mistakes by Template

Based on the ESA dry run results, here are the highest-error templates:

Practical Tips for Completing All 15 Templates

1. Start with B_01 (Entities)

Get your organizational structure right first. Every other template references these entities. Errors here cascade everywhere.

2. Build Your Contract Inventory (B_02)

Create a master list of all ICT contracts before opening the templates. Include:

• Cloud services (AWS, Azure, GCP)
• Software licenses (SaaS, on-premises)
• Managed services (IT support, security monitoring)
• Payment processing arrangements
• Telecommunications contracts
• Data storage and backup services

3. Map Providers Before Entering Data (B_05)

For each contract, identify:

• The legal entity you contracted with (not the brand name)
• Their LEI or alternative identifier
• Their corporate parent
• Any known subcontractors

4. Identify Critical Functions Early (B_06)

Review your business continuity plan. Which functions must operate? Which ICT services support them? This determines what needs detailed assessment in B_07.

5. Validate Cross-References Continuously

After completing each template, verify:

• All entity references point to valid B_01 entries
• All contract references point to valid B_02 entries
• All provider references point to valid B_05 entries
• All function references point to valid B_06 entries

FAQs

Q: Do I need to complete all 15 templates?

A: Most templates are required for all financial entities. B_02.03 (intra-group arrangements) and B_03.03 (providing services to others) only apply if those situations exist. B_99.01 (definitions) is optional but recommended if you use non-standard terminology.

Q: Can I leave templates blank if they don't apply?

A: Yes, for conditional templates like B_02.03. The ESAs expect empty templates for situations that don't exist. However, mandatory templates must contain data.

Q: What if I don't know my provider's subcontractors?

A: Request this information from your providers. DORA gives financial entities leverage to demand supply chain transparency. Document what you've requested even if providers haven't responded.

Q: How do I handle perpetual contracts in B_02.01?

A: Use the perpetual contract flag rather than entering a far-future date. The ESAs have specific handling for ongoing arrangements without fixed end dates.

Q: Which templates need the most time?

A: B_02.02 (contract details) typically requires the most effort—you need to extract specific terms from each contract. B_05.02 (supply chains) can also be time-consuming if you have complex provider relationships.

Q: How often must the register be updated?

A: The register must be maintained and updated when material changes occur. At minimum, annual submissions are required. Significant contract changes, new critical providers, or organizational changes should trigger updates.

Conclusion

The 15 DORA templates form a comprehensive system for documenting ICT third-party arrangements. Each template serves a specific purpose, and together they give regulators visibility into your operational resilience posture.

Understanding what each template captures—and how they connect—is the first step toward a clean submission. The key takeaways:

1. B_01 is your foundation—get entity identification right first
2. B_02 requires contract-level detail—budget time for this
3. Cross-references matter—errors in one template cascade to others
4. B_05 and B_06 are where misclassification errors concentrate
5. B_07 assessments are required for critical function services

Take the time to understand the template structure before entering data. A systematic approach prevents the rework that plagued 93.5% of dry run participants.