How the Backstage catalog supports a DORA ICT asset inventory
A compliance lead at a financial entity in scope of DORA needs an ICT asset register that records, for each asset, its owner, the business functions it supports, its interdependencies and the other fields Article 4 of Delegated Regulation (EU) 2024/1774 lists. The Backstage software catalog can carry a useful share of that record. Ownership maps to the spec.owner field on components and systems, business functions can be modeled as domains and systems, and dependencies can be expressed as dependsOn and dependencyOf relations between components, resources and APIs. Classification, such as criticality tier or data sensitivity, has no native field and is best held in custom annotations that a template or entity provider sets from a controlled source. Confirm the exact annotation keys and catalog model with your team before you build on them, because the mapping decisions are yours to make, not the framework's.
The catalog will not hold everything the article asks for. Recovery time objective and recovery point objective values are not part of the default descriptor model, and neither are unique hardware identifiers, physical locations, external network exposure or supplier end-of-support dates. Those fields need a named source of truth, such as your configuration management database, a supplier register or a recovery testing record, with the catalog entry linking to it. Article 8(5) of DORA also asks you to document processes that depend on ICT third-party providers, which the catalog only partly covers. Decide early which system owns each field, who approves changes and how stale entries are detected, because an auditor will test the register against the source rather than against the portal.
DORA sets no certification scheme, and DeployOpen does not issue audit reports, attestations or certifications. Competent authorities supervise compliance using their powers under Article 50, and the Regulation's only authority-issued attestation concerns threat-led penetration testing. DeployOpen can design the catalog model, build the annotations and ingestion, document the controls and assemble evidence from the portal and its sources, so that your assessor can test it. The conclusions about whether your register meets DORA remain with your compliance function and the supervisor. Ask any implementation partner, including DeployOpen, to state in writing which fields are populated automatically, which are maintained by hand and which come from outside Backstage.
Mapping DORA and RTS asset record fields to Backstage catalog data
This table maps each asset record field that Article 4 of Delegated Regulation 2024/1774 asks for, plus the process and register links in DORA, to a Backstage entity, field or annotation. Read the status column first: native fields need only a descriptor, annotations need a convention your team maintains, and outside-the-catalog items need a separate register or contract record.
| Requirement | Backstage entity or field | Configuration | Status |
|---|---|---|---|
| Unique identifier | Entity metadata name and namespace | Set metadata.name and metadata.namespace to a stable value, and add your internal asset ID as a tag or annotation | Native |
| Location | Component or Resource entity, plus location annotations | Use the annotation for the hosting cluster, cloud account or data center, and link the source repository location | Annotation |
| Classification | Entity tags or custom annotation | Add a criticality tag or a custom annotation such as a DORA classification key, with allowed values set by your policy | Annotation |
| Owner | spec.owner on Component, System and Resource | Reference a Group or User entity so ownership resolves to a named team in the catalog | Native |
| Supported business functions | System entity (spec.domain) and Domain entity | Model each business function as a Domain, and attach the systems that support it through spec.domain | Native |
| Recovery time and recovery point objectives | Custom annotation on System or Component | Add annotations for RTO and RPO values agreed with the business owner, and confirm the field names with your RTS mapping | Annotation |
| External network exposure | Component tags or custom annotation | Record whether the service is internet-facing, partner-facing or internal, and keep it in sync with the gateway or ingress definition | Annotation |
| Interdependencies | dependsOn and dependencyOf relations | Declare dependsOn to Component, API and Resource entities, and verify the graph against runtime data before relying on it | Native |
| Supplier end-of-support dates | Custom annotation on Component or Resource | Store the vendor end-of-support date and link to the supplier record, since the catalog does not track vendor lifecycles | Annotation |
| Process dependencies on ICT third-party providers (Article 8(5)) | Resource or Component linked to a provider entity | Model each third-party provider as a Resource with a dependsOn relation from the services it supports, then document the processes they serve separately | Annotation |
| Register of information link (Article 28(3)) | Provider entity reference or external record ID | Store the register reference ID as an annotation that points to the register held outside the catalog | Outside the catalog |
| Exit strategy and transition plans (Article 28(8)) | Not a catalog field | Keep tested exit plans in your governance system and reference them from the provider entity by link only | Outside the catalog |
| Contract terms on location and data return (Article 30(2)) | Not a catalog field | Hold contract clauses in procurement records and confirm them against the provider's contract before audit | Outside the catalog |
Modeling business functions as domains and systems
The core design decision for a DORA-oriented catalog is how to map business functions, the services that support them, and the infrastructure underneath onto Backstage's system model. Use a domain for each business function that DORA Article 4 records must trace, such as payments, lending or customer onboarding, then a system for each supported service that serves that function, and resources for the infrastructure a system needs, such as databases, queues and storage buckets. Components and APIs sit between these layers and carry the software detail. Because the Article 4 records ask for supported business functions, a domain-to-system structure lets you answer that question from the catalog directly. Confirm the current entity kinds, their allowed spec fields and the relation names against the Backstage documentation before you build the model, since the schema is maintained by the project and may change between releases.
Granularity is the trade-off that matters most. Too coarse, and a single system such as a core banking platform hides the dependencies and recovery requirements of its batch jobs, databases and integration points. Too fine, and the catalog holds thousands of entries that owners will not keep current. A practical test is whether each entity can have its own recovery time and recovery point objectives and its own supplier end-of-support date, since Article 4 expects those per asset. Where a sub-component shares those values with its parent, model it as a resource or component under the system rather than as a separate system. Record the decision as a short written rule so that teams model new services the same way.
Every entity needs exactly one owner, expressed as a spec.owner reference to a group rather than an individual. Groups survive staff changes, and a group can be mapped to a team in your identity directory, which gives auditors a stable answer to who is accountable. Dependencies are expressed through spec.dependsOn on components and resources and spec.dependencyOf on the other side, and the catalog exposes these as relations that can be queried. That queryability is what turns the catalog into an interdependency record: you can list every business function that depends on a given database or third-party API. Check that your ingestion pipeline populates these references, because an unresolved or missing dependsOn target is the most common reason the dependency view looks incomplete.
Fields Backstage does not provide, such as RTO and RPO
The default catalog model has no place for recovery objectives, end-of-support dates or hosting location, all of which Article 4 of the asset management RTS requires for each ICT asset. Each field below needs a defined annotation or metadata key, a named maintainer and a confirmed source of truth outside Backstage.
Recovery time and recovery point objectives
Article 4 of Delegated Regulation (EU) 2024/1774 requires recovery time and recovery point objectives for each ICT asset. Backstage has no built-in fields for either, so define custom annotations such as an RTO and RPO key on each system entity, with values copied from the approved business continuity plan rather than estimated by the catalog team. Confirm with the business continuity owner which unit the values use, whether they apply per business function, and how a change to the plan triggers an update to the entity.
Supplier end-of-support dates
The RTS asks for supplier end-of-support dates on each ICT asset, so a platform component that is out of vendor support must be visible in the inventory. Store the date as an annotation on the component or resource entity, and record the source, such as the vendor lifecycle page, alongside it. Assign the vendor manager as the maintainer, and check with the platform team whether dates for open-source components come from the upstream project or from a commercial support contract.
External network exposure
Each asset record must state whether it is reachable from outside the organization network. Use a tag or annotation with a closed set of values, such as internal, partner or public, and tie it to the ingress or DNS entry that proves it. Security operations should own the value, and a review should run whenever a route is published through the API gateway or a load balancer. Confirm with the network team which firewall or edge records are authoritative.
Physical location of hosting and data
Article 30(2) of DORA requires contracts to state where services are provided and data processed, so the location of each asset must be recorded at the level the regulator expects. Add an annotation for hosting region, data center or country, and for any sub-processor location where it differs. Procurement or the cloud platform owner should maintain it, and the business continuity owner should confirm that backup and recovery sites are included.
Classification of assets
The RTS requires each ICT asset to carry a classification that reflects its importance to business functions. Backstage offers the spec.lifecycle and metadata.tags fields, but neither captures a criticality tier, so define a single annotation with a fixed list of values agreed by risk management. Record who approved the scheme, and confirm with the risk owner how an asset that supports a critical or important function is marked.
Stable unique identifiers across renames
Each asset needs a unique identifier that survives a rename, a team reorganization or a repository move. Entity names in Backstage can change, so keep an immutable identifier annotation, such as an asset ID issued by the CMDB or GLPI, and treat it as the join key for evidence exports. Assign ownership of ID issuance to the inventory administrator, and confirm with the operations team that retired IDs are never reused.
Configuring the catalog for the asset record
This sequence turns the catalog into a DORA-ready asset record by agreeing the fields with risk and resilience owners, adding the fields Backstage does not model out of the box, and connecting owner data to sources that stay current. The result is a catalog whose entries can be exported and reviewed as ICT asset evidence.
Agree the asset record schema
Before any YAML is written, sit down with risk, resilience and business continuity owners and map each field required by Article 4 of Delegated Regulation (EU) 2024/1774 to a place in the catalog. Standard fields such as owner, system, dependencies and lifecycle map to existing descriptor keys. Recovery time objective, recovery point objective, external network exposure, classification, location and supplier end-of-support date usually need custom keys. Record the agreed schema in a short document with one row per field, the source of truth for each value and the named owner who approves changes. The step is done when that owner has signed off the schema and nobody is adding fields informally.
Define custom annotation keys and validation
Choose a naming prefix for custom keys, such as a domain of your own, so they do not collide with keys from plugins. Define each key with an allowed format, for example a fixed set of classification labels, a numeric RTO in agreed units, or a date for supplier end of support. Enforce these rules in CI by validating descriptors against a schema before merge, so a missing or malformed value fails the pull request rather than reaching the catalog. Confirm the exact annotation and validation mechanisms against the descriptor format in your installed version. The step closes when a deliberately broken test entity is rejected by the pipeline.
Add descriptor fields through templates
Update the software templates that create new components so they prompt for, or pre-fill, the custom annotations and owner references. Engineers creating new systems then supply recovery values at creation time, not months later during an audit. Templates should also reference the business function a system supports, which links it to the domain structure. Test each template end to end in a non-production catalog and check that the generated descriptor contains every required key. The step is complete when a newly scaffolded system appears in the catalog with all required fields populated.
Populate existing entities with a catalog processor
For systems that predate the templates, add a catalog processor or a custom entity provider that reads recovery and classification values from the source your risk team already maintains, such as a controlled spreadsheet export or a configuration management database. Keep the mapping explicit so each catalog field traces back to one source. Confirm which processors and providers your Backstage version supports and how they handle updates and deletions. The step is done when a sample of existing systems shows values sourced from the agreed system of record, with differences flagged rather than silently overwritten.
Connect owners from the Git platform and directory
Owner fields are only useful if they point to real people and teams. Connect the catalog to your source control platform so repositories are discovered and to your identity directory so user and group entities are populated from HR-controlled groups. Use the integrations documentation for the exact provider configuration in your environment. Then check that each critical system has an owner group that exists in the directory and has a named accountable person. The step is done when orphaned systems, meaning those whose owner group does not resolve, are listed in a report that the owning team must clear.
Set sign-in resolvers to one identity per person
Owners often sign in with more than one provider, and an asset record is weakened if the same person appears as several catalog users. Configure sign-in resolvers so every provider resolves to the same identity, following the authentication guidance. Also turn off guest access for any environment that holds asset data. Test with an account that signs in through two providers and confirm one user entity is used and that its group memberships match the directory. The step closes when the test account shows a single identity with the expected ownership rights.
Schedule reviews and protect the schema through upgrades
Set a recurring review, owned by the risk function, that checks recovery values, owners and end-of-support dates against the source records and records the outcome. Store review results as evidence alongside Git history of descriptor changes. Before any Backstage upgrade, run yarn backstage-cli versions:bump in a branch, then confirm that custom annotations still render, validation still runs and custom processors still load. Use the Backstage Upgrade Helper to review template changes that could affect your custom fields. The step is complete when a dated review record exists and a test upgrade has passed the annotation and processor checks.
What the catalog does not cover for DORA
The catalog can hold the asset records DORA asks for, but several required items live in contracts, recovery test reports, procurement files, facilities records and business process reviews. Each card names the item, the system or process that should own it, and what to check before an assessor asks.
Register of contractual arrangements
Article 28(3) requires a register of information covering all contractual arrangements for ICT services. Backstage can link a system to its provider, but the contract records themselves belong in procurement or contract management. Check that every provider name in the catalog matches a row in the register, and that the register carries contract identifiers the catalog can reference. Use a shared identifier so the two sources do not drift apart.
Tested exit strategies
Article 28(8) requires documented and tested exit strategies and transition plans for ICT services that support critical or important functions. A catalog entry can flag which systems support those functions, but it cannot show that an exit plan exists or was rehearsed. Keep exit plans in your risk or continuity repository, and record the test date and outcome there. Confirm that each flagged system has a plan reference.
Data location and return terms
Article 30(2) requires each ICT services contract to state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. The catalog can record a data location attribute, but the contractual commitment sits in the agreement. Ask legal or procurement to confirm these terms for each provider. Treat any system without a signed location clause as an open finding.
Recovery test results
The catalog can hold RTO and RPO values as annotations, but those values are targets until a recovery test proves them. Test reports from backup restores, failover exercises and continuity drills should be kept in your resilience program, with dates and measured results. Compare measured times against each annotated target. Where a system has never been tested, mark its recovery values as unverified.
Hardware and physical asset records
Asset management under the RTS covers ICT hardware, network devices, storage and facilities, not only software services. Backstage models components and resources but is not designed as a hardware register. Keep serial numbers, rack locations, device lifecycle dates and end-of-support data in your CMDB or asset management tool, and link those records to catalog systems by identifier. Confirm that every hosting resource appears in one of the two sources.
Business process dependency analysis
Article 8(5) requires identifying and documenting processes that depend on ICT third-party providers. Those processes come from business owners walking through how work is done, not from code or deployment metadata. Run dependency workshops with each function, record the systems and providers they rely on, and then reference those process records from the catalog. Catalog links show what a system supports, but only the business can confirm which processes stop when it fails.
Questions buyers ask about DORA and the Backstage catalog
Does a Backstage catalog alone meet DORA Article 8 and the asset management RTS?
No. The catalog can hold much of the asset inventory, but it does not meet the requirement by itself. Article 4 of Delegated Regulation (EU) 2024/1774 asks for a record per ICT asset that includes a unique identifier, location, classification, owner, supported business functions, recovery time and recovery point objectives, external network exposure, interdependencies and supplier end-of-support dates. Backstage natively covers owners, systems, dependencies and some metadata. Recovery objectives, classification and exposure need custom annotations or a companion source, and Article 8(5) process documentation sits outside the catalog. Ask your compliance lead to map each RTS field to a catalog field, a source system or a document before design starts.
What drives the cost of building the inventory in-house versus hiring help?
The cost is driven by scope, the number of systems in the inventory, how many sources must be integrated, how much annotation design is needed, and how much business input is required. Your internal team pays for the time of platform engineers, architects and the business function owners who confirm recovery figures and contract data. An outside partner would be paid for the scoped work, typically under a fixed-scope agreement with deliverables and timelines written down before work starts. One-time costs cover design, ingestion and the first full review. Recurring costs cover keeping recovery figures and owners current. Ask any quote to separate these and to state which data sources and business reviews are assumed.
How long does a DORA asset inventory in Backstage take?
Duration depends mainly on the number of ICT assets, the quality of existing ownership and contract data, and how quickly business owners can answer questions. A large estate with incomplete records takes longer because most of the effort goes into collecting facts, not configuring the catalog. Teams with clean records in a source control platform or a CMDB usually spend less time on ingestion. We do not publish a duration in advance. Ask for a timeline in the written scope, with milestones for the data review, the annotation model, the ingestion, and the business sign-off.
What must our internal team provide before the catalog work begins?
Your team must provide named owners for each business function and system, the recovery time and recovery point objectives agreed for each critical service, and the contract data needed for Article 28(3) and Article 30(2) style records, including where services are provided, where data is processed and end-of-support dates. Without these, the catalog will hold placeholders. Also provide access to the source platforms that will feed the catalog, such as source control and identity directories, and a decision-maker who can settle disagreements about classification. Confirm these inputs with your compliance and procurement teams before requesting a quote.
Can our own platform team build this inventory without outside help?
Yes, a capable platform team can build it, provided it has Backstage experience, the time to design annotations, and the business owners to supply recovery and contract data. The engineering work is mostly descriptor design, ingestion from source systems and a review workflow. The harder part is governance: agreeing classification, keeping owners current and proving the record is complete for an auditor. Many teams split the work, handling ingestion internally and asking a partner to review the data model against the RTS. Decide which part you can sustain after the first delivery.
How do we model RTO and RPO fields that Backstage does not provide?
Backstage does not ship recovery time or recovery point fields for components, so you add them as custom annotations on the entity descriptor, using a documented key naming convention. For example, annotations such as a recovery time objective key on a system or component entity, with the value kept in a unit your compliance team agrees on. Validate the values with a schema check in CI so missing or malformed entries fail visibly. Record who approved each value and when, because the value is only useful as evidence if its owner and date are traceable. Confirm the exact annotation keys and validation approach with your engineering and compliance leads before rollout.
Can DeployOpen certify that our DORA inventory is compliant?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can plan the catalog model, build the ingestion and annotations, and prepare the systems, controls and evidence your compliance assessment will examine. DORA sets no certification scheme, and competent authorities supervise compliance using their powers under Article 50. Your internal audit function or the authority's process decides whether your inventory meets the requirement. Ask any partner to show how the evidence will be produced and retained, and what your auditors have said they expect to see.
Where does the catalog data come from and how is it kept current?
Engineers usually keep the catalog current by reading descriptors from source control and, where available, syncing from an identity directory or asset system through entity providers. Each source of truth should be named in the design, so a reviewer knows which system owns each field. Changes should flow through pull requests so there is a change history, and stale entries should be flagged on a schedule. Plan a regular review by business owners for recovery figures and contract data, since these rarely change in code. Ask any partner how orphaned and outdated entries will be detected and who signs off on the review.
How DeployOpen scopes and delivers the asset inventory
The work starts with a written scope, agreed before any build begins. For a DORA asset inventory, that scope names the entity model (which kinds of catalog entities represent ICT assets, business functions and dependencies), the annotation set that carries the fields Backstage does not provide natively, the source integrations that keep the catalog current from Git, cloud and identity systems, and the evidence exports the compliance team will hand to assessors. Each of these items has a defined boundary, so the quote that follows reflects what is actually being built rather than an open-ended estimate. Your team should expect to confirm which of your ICT services and third-party arrangements fall inside the first phase and which are deferred.
DeployOpen prepares the system, the controls and the evidence, but it does not assess your compliance. Independent auditors and the national competent authority that supervises your entity make that judgment, and DORA sets no certification scheme that a vendor can issue. What we deliver is an inventory structure with populated records, documented ownership and an export that traces each record to its source. Ask in advance how your supervisor or auditor expects records to be presented, because the format they accept should shape the evidence exports in the written scope.
Once the inventory is live, the work does not stop. Catalog data goes stale as systems change, new providers are onboarded and recovery targets are revised, so ongoing support, upgrades of Backstage and periodic review of the annotation set are available as a retainer. Confirm during scoping who in your organization owns each field after handover, including the recovery time and recovery point values, which must come from the business and cannot be inferred from the catalog itself.
