DORA Is Live and Your Internal Application Register Is Not

The DORA compliance questionnaire has been sitting on the CIO’s desk for three weeks. Most of it is finished. The licensing inventory is complete. The third-party register — the Article 28 section — was painful but procurement had the contracts. The section that remains open is Article 8: provide a complete list of ICT assets, including internally developed applications, supporting each critical or important function, along with configuration data, interdependencies, and a mapping of which business functions each asset supports.

Licensed software is straightforward. It appears in contracts, invoices, and renewal schedules. There is a vendor to call and a paper trail to follow. The applications the internal team built are different. The reporting tool finance put together three years ago. The onboarding workflow operations added last year. The data validation script a risk analyst turned into a production application using an AI coding assistant six months ago. None of those are in any contract. They do not have a vendor. What documentation exists lives in the developer’s head or in a README file nobody has updated.

Under Regulation (EU) 2022/2554 — the Digital Operational Resilience Act — that gap is a compliance gap. DORA has been in effect since January 17, 2025. The obligation to maintain a complete, accurate, and annually reviewed ICT asset register covering internally built applications is not aspirational guidance. It is the law that applies to banks, insurers, investment firms, and payment institutions operating in or serving EU markets. CloudApper AI is built specifically to address what happens when that obligation meets the reality of how financial enterprises actually develop and deploy internal applications.

What Article 8 Actually Requires

Article 8 of DORA places four distinct obligations on financial entities regarding ICT assets, and each one creates a specific documentation requirement for internally built applications.

The first is identification and classification. Under Article 8(1), financial entities must identify and classify all ICT-supported business functions and ICT assets, including their roles and dependencies in relation to ICT risk. Classification is not a list of names — each asset must be categorized according to its criticality to the functions it supports, and that classification must be reviewed at least annually.

AI Platform

Enterprise AI

Enterprise AI that's secure enough for the systems you can't risk.

Explore Now

The second is configuration and interdependency mapping. Article 8(4) requires entities to identify all ICT assets — including those on remote sites, network resources, and hardware — and to map their configurations and the links and interdependencies between them. For an internally built application, this means documenting not only that the application exists but what it connects to, what data it processes, what it depends on to run, and what would fail downstream if it went offline.

The third is continuous risk assessment tied to change. Articles 8(2) and 8(3) require risk assessments upon each major change to the network and information system infrastructure supporting critical functions. An internal application that is modified — even by a business unit using an AI coding tool — triggers this obligation if that application supports a function classified as critical or important.

The fourth is a specific legacy system obligation. Article 8(7) requires financial entities to assess all legacy ICT systems at least yearly, and specifically before connecting new technologies to them. This is not limited to mainframes. Any internally built application running on outdated infrastructure, or being connected to newer systems, falls within this scope.

National supervisory guidance, including from BaFin, interprets these obligations as requiring something structurally resembling a configuration management database: asset-by-asset documentation with business function mapping, interdependency records, change history, and evidence of ongoing review. The difference from a standard CMDB is that the DORA register must capture ICT assets that IT never formally ingested — and that distinction is where most financial enterprises currently have a problem.

AI Platform

Enterprise AI

Build AI-powered apps without exposing your data to anyone.

See How

Why Internally Built Applications Are the Hardest Assets to Document

Licensed software arrives with a built-in documentation trail. The vendor provides specifications, the procurement team holds the contract, and renewal schedules force periodic review. Internally built applications carry none of this infrastructure.

When an internal team builds an application — or when a business unit uses an AI coding assistant to create one — what typically exists is working code, some operational knowledge held by the person who built it, and whatever happens to be in version control. What rarely exists is a classification of what functions the application supports, an interdependency map, a change management record covering post-deployment modifications, or any artifact that maps the application to DORA’s Article 8 register fields.

AI Platform

Enterprise AI

AI for the enterprise — built on security, not around it.

Get Started

This is the gap most financial services IT teams have underestimated. CMDBs cover infrastructure. Service catalogs cover formally managed IT services. Internally built applications — particularly those created by business units using AI coding tools, low-code platforms, or automation builders — sit in a third category. They are operationally real, sometimes supporting functions that qualify as critical or important under DORA’s definitions, and structurally invisible to any governance process that requires a vendor trail or formal IT service record.

When applications are built on a governed platform like CloudApper AI, this problem changes character. The documentation Article 8 requires is generated as a natural output of the development process itself — function classification, change records, data mapping, infrastructure dependencies — rather than as a retrospective exercise the CIO has to commission after the application is already in production.

The Gap Inside the Gap: AI-Assisted Development and the Register’s Missing Layer

The ICT asset register problem has a second layer that most DORA compliance conversations ignore. It is not only that older internally built applications are poorly documented. Financial enterprises are currently adding new undocumented applications to their operational estate at a rate the register cannot track.

Business-unit teams — finance controllers, operations leads, risk analysts — are using AI coding tools to build automations, reporting tools, and workflow applications without going through any formal IT or architecture review. As the shadow AI development problem in financial enterprises illustrates, these tools produce working applications that acquire operational dependencies quickly. A process that ran manually for years is now automated. A critical report depends on an API call a business analyst wrote. None of this appears in the ICT asset register.

AI Platform

Enterprise AI

Modernize legacy systems with enterprise-grade AI.

Learn More

Under DORA, this matters because the register’s purpose is not documentation for its own sake. It is the foundation for disruption testing, recovery planning, and third-party dependency mapping. An asset that is not in the register is not in the resilience plan. If a DORA-mandated disruption test surfaces a critical workflow dependency that nobody registered, the question is not only “why did that fail?” It is also “why did your ICT asset register not include it?”

The governance problem of AI-built dependencies captures this precisely: the applications are operationally real, the dependencies are real, the business weight is real — and none of it appears in the governance layer DORA requires to be accurate. The applications that accumulate hidden dependencies long before they show up in a disruption test are exactly the ones Article 8 is designed to force into view.

What the Register Must Actually Say About Each Application

The compliance question is not just whether an internally built application appears in the register. It is whether the register entry satisfies Article 8’s specific content requirements.

For each internally built application supporting a critical or important function, the register should document: the business function the application supports and its criticality classification; the data the application processes, including sensitivity classification; the infrastructure the application runs on, including cloud services, third-party APIs, and dependencies on licensed systems; the change history since deployment, including modifications made with AI coding assistance; recovery objectives — what recovery time and recovery point are acceptable if this application fails; and the ownership record — who built it, who is responsible for it, and who would be contacted in a disruption scenario.

AI Platform

Enterprise AI

Enterprise AI that fits your compliance, not the other way around.

Explore CloudApper

Most financial IT teams can answer these questions for formally managed applications. For internally built ones — particularly those created by business units — the answer to most of these questions is “we would need to investigate.” That is not a compliant register. It is a documentation backlog that will surface in the first supervisory review after a disruption event.

The same structural problem that creates security review backlogs creates DORA register gaps: governance is positioned at the end of the development process rather than built into it. An application arrives at the register after it is already in production, often without the artifacts needed to complete the required fields. The governance obligations that AI-assisted code creates for financial services IT teams do not disappear because the development was fast — they accumulate as undocumented register entries waiting for the next audit cycle.

Why a CMDB Alone Does Not Close the Article 8 Problem

Many IT leaders hearing the ICT asset register requirement think of their CMDB first. A well-maintained CMDB does cover some of what Article 8 requires — infrastructure assets, network resources, formal service records. But CMDBs have a structural limitation for internally built applications that DORA’s register requirement exposes directly.

A CMDB captures what IT formally registers. Applications built by business units with AI coding tools or automation platforms are frequently never submitted to IT for CMDB entry. The CMDB entry depends on someone following the intake process — and the whole premise of AI-assisted development is that it bypasses the intake queue. The result is a CMDB that accurately reflects formal IT services and a DORA register that is missing the layer of internally built applications that operate outside formal intake.

There is also a content distinction. A CMDB row that says “finance-reporting-tool: active” does not satisfy Article 8’s requirements for interdependency mapping, function classification, change records, and recovery objectives. A CMDB is an infrastructure ledger. A DORA-compliant ICT asset register is a governance document that must be actively maintained. The distinction between a tool that tracks infrastructure and one that governs development determines whether a financial entity’s register holds up when a supervisor asks to see it.

How a Governed Platform Makes the Register Accurate by Design

The practical path to a compliant ICT asset register for internally built applications is not a documentation campaign — it is a development governance requirement applied prospectively.

When an internal application is built on CloudApper AI, the documentation Article 8 requires is produced as a byproduct of the development process. Function classification is established during design. Data classification is captured at the point where data connections are configured. Change records are generated automatically when modifications are deployed. Infrastructure dependencies are mapped by the platform, not reconstructed from memory months later. This means a new internal application can arrive in the ICT asset register with a complete Article 8 entry at launch rather than requiring a separate documentation exercise after the fact.

For the AI-development gap — business-unit teams producing functional code outside any governance process — the answer is the same: the same development capability delivered through CloudApper AI produces both the application and the documentation it needs to appear correctly in the ICT register. The platform’s architecture, security by design with centralized configuration management and deployment records, ensures that compliance is a design output rather than an investigation afterward.

How to Bring Internally Built Applications Into DORA Compliance

1. Map your critical and important functions under DORA first. Identify the business functions your financial entity performs and classify each as critical, important, or neither using the definitions in Articles 4 through 6. This classification determines which ICT assets — including internally built applications — fall within Article 8’s full documentation requirements. Start with the functions where a disruption would materially impair your ability to serve clients or meet regulatory obligations.
2. Discover all ICT assets supporting each function, including internal applications not in your CMDB. Do not rely solely on your service catalog or licensed software inventory. Conduct discovery specifically for internally built applications: interview business unit leads, review production deployments, and identify automations and workflow tools that carry operational weight regardless of whether IT formally registered them. Each gap in this discovery is an Article 8 compliance exposure.
3. Document each internal application against Article 8’s required fields. For each identified application, create a register entry covering the business function it supports, its data classification, infrastructure and third-party dependencies, change history since deployment, recovery objectives, and ownership. Flag entries where these fields cannot be completed — each incomplete entry is a documentation risk before a supervisory review.
4. Establish ongoing change management records for application modifications. Article 8’s risk assessment obligations trigger upon major changes. Require that any modification to an internal application supporting a critical function goes through a documented change process, including modifications made with AI coding tools or low-code builders by business units.
5. Require governed platform deployment for new internal applications going forward. Replace ad-hoc build processes with a governed platform that generates Article 8 documentation as a natural output of development. This closes the AI-development gap prospectively and stops the register from falling behind every time a business unit ships a new automation or workflow tool.
6. Schedule the annual review and legacy system assessment required by Article 8(7). Build Article 8’s annual review cycle into your compliance calendar, with specific legacy system assessments for any internal application running on outdated infrastructure or connecting to systems being updated or replaced. This is a separate obligation from the change-triggered risk assessments in Articles 8(2) and 8(3).

Frequently Asked Questions

Does DORA’s ICT asset register requirement apply to internally developed software?

Yes. DORA Article 8 applies to all ICT assets supporting critical or important functions, including applications developed internally by the financial entity or by its business units. The requirement is not limited to licensed software or vendor-supplied systems. Any internally developed application that supports a function classified as critical or important must appear in the register with the full documentation Article 8 requires.

What does DORA Article 8 require financial entities to document in their ICT asset register, and how should internal applications be included?

Article 8 requires financial entities to identify, classify, and document all ICT-supported business functions and ICT assets, including their roles, configuration data, interdependencies, and relationship to ICT risk. For internal applications, this means function classification, data sensitivity classification, infrastructure and third-party dependency mapping, change history, recovery objectives, and ownership records. Internal applications must be included in the register on the same basis as licensed software if they support a critical or important function.

How does AI-assisted development create new DORA compliance gaps?

Business-unit teams using AI coding tools or low-code platforms can build operational applications without going through formal IT intake, which means those applications acquire operational weight — and potentially support critical functions — without ever entering the ICT asset register. DORA’s disruption testing and recovery planning obligations depend on the register being accurate. An unregistered AI-built application that fails during a disruption test creates both an operational problem and a direct DORA Article 8 compliance finding.

How should banks and insurers map business functions, ICT services, and internal applications to build a DORA-compliant ICT asset register?

The mapping should run from function to asset: identify critical and important functions first, then identify all ICT services and applications supporting each function, then document each asset’s configuration, dependencies, and recovery requirements. Internal applications should be treated as first-class register entries, not as a secondary category below licensed software. A governed development platform simplifies this mapping by generating the dependency and configuration data automatically at the point of deployment.

What is the difference between a CMDB and a DORA-compliant ICT asset register?

A CMDB is an infrastructure ledger that captures what IT formally registers — hardware, licensed software, and formal service records. A DORA-compliant ICT asset register is a governance document covering all ICT assets supporting critical functions, including internally built applications, with function classification, interdependency maps, change records, and recovery objectives. Applications built by business units outside formal IT intake often appear in neither. The DORA register must be actively maintained and must capture assets that bypass the CMDB intake process.

How often must financial entities update their DORA ICT asset register?

Article 8 requires annual review and classification assessment of all ICT assets supporting critical or important functions. It also triggers risk assessments upon major changes to ICT infrastructure or processes. The register is not a once-a-year exercise — it is a living record. Any internally built application that is modified after deployment, including modifications made with AI coding assistance, requires a documented change record if it supports a critical or important function.

The applications internally built teams deploy are operationally real long before they appear in any governance record. CloudApper AI provides the governed development environment where DORA Article 8 compliance is a design output, not a retroactive investigation — so financial enterprises can close the ICT asset register gap without slowing the internal development their operations depend on. If your team is working through DORA compliance and finding that your register has gaps where internally built applications should be, contact CloudApper to see how governed application development addresses the Article 8 register problem directly.