DORA Article 8 Compliance: APIs You Don't Know You Have

"Financial entities shall identify, classify, and adequately document all information and ICT assets." - DORA Article 8

The number of APIs an organization knows about is (always) smaller than the number actually running in production. That gap between the two is where DORA non-compliance lives.

Most organizations use configuration management databases (CMDB) to list their ICT assets. However, CMDB doesn't capture the API layer, creating a significant visibility/classification gap. It's simply incomplete.

A server inventory that you get from CMDB tells you that a payment application exists. But it doesn't tell you which of its 47 endpoints handle cardholder data, which three are undocumented, or which one a contractor added and security never reviewed.

DORA Article 8 compliance requires a complete and continuously maintained inventory of all ICT assets.

Complete means you need to include the entire API estate, including shadow services deployed outside normal change management, and third-party integrations that accumulated over the years without central oversight.

Continuously maintained means that you can't query static records and call it a day. You need runtime data that always provides a list, not just when asked.

Why Most ICT Inventories Miss the API Layer

CMDBs are designed to store info about infrastructure such as servers, network devices, and applications as discrete units. They record what IT provisions through formal processes. They have no mechanism to detect a service deployed by a development team outside the normal process.

A single registered application in your CMDB might expose dozens or hundreds of individual API endpoints. Each one is a discrete attack surface and a potential critical function under DORA's definitions. Article 8's requirement to map information flows and identify interdependencies applies at this level, not at the application level.

API gateways are a good starting point, but they come with their own blind spots. Gateways record the APIs intentionally routed through them.

However, they don't pick up services communicating directly between internal systems, test environments that were never decommissioned, or legacy integrations predating the gateway architecture.

Relying on a gateway gets you halfway there, but most organizations with complex, multi-cloud, or post-merger infrastructure need a more comprehensive solution. And a gateway by itself isn't enough.

The Shadow API Problem in Financial Services

Shadow APIs are endpoints that run in production without any documentation, monitoring, or inclusion in the inventory. You can find shadow APIs in any large financial institution's API layer. They're a rule, not an exception.

They happen for various reasons, with the most common one being a short deadline that doesn't allow development teams to update the registry. When a company does mergers and acquisitions (M&A), the acquired systems bring their own set of shadow APIs.

Every single shadow API falls within the definition of an ICT asset under Article 8, and each must be identified, classified, and adequately documented. Failure to comply leads to direct compliance exposure:

• An API missing from your inventory isn't covered by your ICT risk management framework.
• It isn't subject to the continuous monitoring required by Article 10.
• It isn't included in the incident classification capability Article 18 demands.
• If it handles sensitive customer data, that's a GDPR gap running alongside the DORA gap.

The fact that an organization didn't know the endpoint existed is not a position that holds up in a regulatory examination.

Third-Party API Dependencies: The Hidden Side of the Register

The ICT asset inventory is under DORA's Article 8. That's directly tied to the register of ICT third-party arrangements that's under DORA's Article 28. So you need to inventory all of your ICT assets and do the same for your third-party service providers. To do that, you need traffic-based API discovery.

Building the ICT register from contracts alone consistently produces an incomplete picture. Organizations that map their third-party API dependencies through runtime traffic analysis routinely find integrations that don't appear in the contracts database.

For banks handling correspondent banking relationships, insurers with broker distribution networks, and telcos providing ICT services to financial entities, the third-party API estate can be extensive enough that contract-only mapping misses meaningful portions of it. A third-party API integration that isn't in your Article 28 register means the associated risk assessment, contractual governance, and exit strategy obligations under DORA simply haven't been addressed.

Runtime Discovery Versus Static Inventories

The difference between static inventory methods and runtime discovery lies in their architectures.

Static methods, such as CMDBs, gateway registries, and manual documentation, record what was intentionally created and registered. They produce point-in-time snapshots that degrade the moment new APIs are deployed or existing ones change. For organizations releasing software continuously, the decay rate of a static inventory can be significant. An API governance framework built on API design-time governance tools is valuable, but doesn't solve the discovery problem on its own.

Contrary, a runtime intelligence platform observes actual production traffic and builds inventory from what's genuinely running. When an endpoint starts receiving requests, it appears in the catalog, regardless of whether a change request was filed. Shadow services surface automatically. Third-party API calls are identified from traffic patterns, not from a contract database that may not reflect current production integrations.

Article 8 requires continuous identification and classification, not periodic audits. Runtime discovery is the architecture that matches what the regulation actually demands.

Building a DORA Article 8 Inventory With Treblle

Treblle's API Discovery product uses three parallel mechanisms to build and maintain the inventory:

• source code scanning from connected GitHub repositories,
• direct integration with API gateways to inventory registered APIs, and
• continuous traffic capture to surface anything not covered by the first two.

The combination matters because no single mechanism provides complete coverage.

Source code scanning finds APIs before they receive traffic. Gateway integration captures the registered estate. Traffic monitoring catches the remaining shadow services, undocumented endpoints within existing services, and direct service-to-service calls that bypass the gateway entirely.

When a new service starts receiving production traffic, it appears in our catalog. Treblle's Shadow API Detection and Shadow Endpoint Detection run continuously, not as scheduled scans, so the inventory reflects the current state of the estate rather than its state at the last quarterly review.

The Unified API Catalog gives architecture and compliance teams a single view across cloud providers, gateways, and technology stacks. For financial organizations running multi-cloud or hybrid infrastructure, this consolidated view is what Article 8's regulatory reporting obligation actually requires. A compliance officer needs to see a single authoritative inventory, not three gateway admin consoles and a spreadsheet.

For the Article 28 register, Treblle's Consumer Intelligence shows which consumers are calling each API, how frequently, and from which systems. Traffic-based discovery surfaces third-party integrations that don't appear in the contracts database, giving the team responsible for the third-party risk register a starting point that reflects actual production dependencies rather than only documented contractual ones. Organizations that use Treblle find these third-party integrations before a regulator comes looking in.

A solid DORA compliance approach treats the API governance framework and the Article 8 inventory as connected: you can't govern what you don't see.

If your current gap assessment has the ICT asset inventory as an open item, the inventory is where the work starts - because Article 10 monitoring, Article 18 incident classification, and Article 28 third-party risk management all depend on knowing what you're supposed to be monitoring.

Get the full DORA compliance ebook for free.