How an open source data catalog supports DORA identification
A financial entity under DORA must identify, classify and document the ICT-supported business functions, the information and ICT assets behind them, and the dependencies between those assets. A self-hosted data catalog such as OpenMetadata or DataHub covers the data side of that work: it gives you a searchable inventory of datasets, tables, columns, pipelines and dashboards, with owners, classifications and lineage attached. It does not replace the full ICT asset register that Delegated Regulation (EU) 2024/1774 describes, and it does not cover the third-party risk process on its own. Plan for those as separate records that the catalog feeds or references.
Four obligations in Article 8 map most directly onto catalog features. Article 8(1) asks you to identify and classify the assets supporting each function and to review that classification at least yearly. Article 8(4) asks you to identify all information and ICT assets, map the critical ones, and document their configuration, links and interdependencies. Article 8(5) asks you to document processes that depend on ICT third-party providers. Article 8(6) asks you to update the inventories periodically and after every major change. In practice, the catalog's ownership fields, classifications, glossary and table, column, pipeline and dashboard lineage carry most of this, provided connectors are configured for every system in scope. Confirm with your team which systems sit outside the connector set (for example, SaaS applications or spreadsheets) and how those will be recorded by hand.
DeployOpen plans, implements and documents the catalog inside your own cloud accounts or data centers, including connector configuration, ownership bootstrapping, classification rules and the evidence pack that shows how the inventory is kept current. We do not issue attestations, and DORA sets no certification scheme; competent authorities assess compliance on their own terms. Ask any implementation partner to show how each Article 8 obligation maps to a named catalog artifact, an owner and a review cadence, and to confirm the upgrade path for OpenMetadata or DataHub, since both move quickly and carry breaking changes between major versions.
Which DORA Article 8 requirements a data catalog can meet
This table maps the DORA Article 8 and Delegated Regulation 2024/1774 Article 4 requirements to what a catalog must hold, how to configure it, and where it still depends on other controls. Read each row as a question to answer with evidence from the catalog, and note the rows marked as needing other processes. The main takeaway is that a catalog can hold the asset inventory and dependency map, but risk assessment and review decisions stay with people and separate risk tooling.
| Requirement | What the catalog must hold | How to configure it | Where the catalog falls short alone |
|---|---|---|---|
| Article 8(1): identify and classify ICT-supported business functions and their assets | Entities for business functions, applications, databases, pipelines and reports, each linked to the function it supports | Custom properties for business function and criticality, ingestion from warehouses, BI tools and pipelines, glossary terms for functions | Deciding which functions are critical is a management judgment the catalog only records |
| Article 8(1): roles and responsibilities | Owner and steward fields on every asset, with a named accountable person | Ownership fields populated from HR or CMDB extracts, ownership required before publishing, domains for each business unit | Ownership is only as good as the names entered; the catalog cannot confirm that a person still holds the role |
| Article 8(4): map critical assets and their configuration, links and interdependencies | Table, column, dashboard and pipeline lineage, plus links to the systems and hosting locations behind each asset | Scheduled ingestion from each source, OpenLineage events from orchestrators, manual lineage for systems without connectors | Lineage covers data flows, not infrastructure configuration or network paths; those need a CMDB or configuration tool |
| Article 8(4): remote sites and assets outside the main estate | Entities for SaaS and remote-site sources with an explicit location attribute | Custom properties for hosting location and provider, reviewed when new sources are onboarded | Shadow SaaS not known to IT will not appear without discovery work or procurement checks |
| Article 8(5): processes that depend on ICT third-party providers | Links from assets and pipelines to the provider that supplies or hosts them, and the functions they support | Provider entities with custom properties for contract reference and criticality, lineage from third-party feeds | Contract terms, exit plans and provider risk ratings belong in third-party risk tooling, not the catalog |
| Article 8(6): inventories updated periodically and after every major change | Last-ingested timestamps, change history and freshness status on each asset | Scheduled ingestion cadence agreed with owners, freshness checks, alerts for assets that stop updating | The catalog shows that data changed, not that a change was approved; change records stay in the change process |
| Article 8(3) and 8(7): risk assessment on major change and yearly legacy review | Flags for legacy and end-of-support assets, links to the change records that triggered reassessment | Custom tags for legacy status, review tasks assigned to owners, reports listing assets past their review date | The risk assessment itself is a separate activity covering threats and vulnerabilities; the catalog can only record that it happened |
| Article 4 of Delegated Regulation 2024/1774: unique identifier, location, classification and owner per asset | Stable fully qualified names, classification tags, owner and location properties on each record | Naming rules set before ingestion, classification tags with a documented policy, required properties enforced at publish | Catalog IDs may change if sources are renamed or re-ingested, so confirm an ID scheme that survives migrations |
| Article 4 of Delegated Regulation 2024/1774: recovery objectives, external exposure and end-of-support dates | Custom properties for recovery time and recovery point objectives, exposure and end-of-support dates | Fields populated from the BCP and CMDB owners, reviewed on the same cadence as the inventory | The catalog stores these values but does not set or test them; testing is done through continuity exercises |
Which open source catalog fits a DORA asset inventory
Article 8 of DORA expects a financial entity to know its ICT assets, their dependencies and their owners, and to keep that picture current. The options below cover the common choices for building that inventory, from a full metadata platform that follows data through pipelines and dashboards to a portal that publishes datasets.
OpenMetadata for cross-estate inventory
OpenMetadata is released under Apache-2.0 and covers table, column, dashboard, pipeline and metric lineage through OpenLineage events, along with glossaries, classifications, domains and ownership. It offers more than 130 connectors and REST, Python, TypeScript and Java access, so inventory records can be created and updated from deployment pipelines. Check that the connectors you need exist for your warehouses, BI tools and schedulers, and confirm how dependencies on ICT third-party providers will be modeled as entities.
Deployment footprint for OpenMetadata
Production options include Kubernetes on EKS, AKS, GKE or on-premises clusters, and bare metal without Kubernetes. Bare metal requires Java 21, PostgreSQL 15 or later (or MySQL 8.0.42 or later) and Elasticsearch 9.x or OpenSearch 3.x. Plan the database and search services as separate components with their own backup, patching and capacity work, since a catalog that holds your DORA inventory is itself an operational resilience dependency.
DataHub for a broad metadata graph
DataHub v1.7.0.1 is licensed under Apache-2.0 and suits organizations that want a metadata graph spanning many source systems with extensive ingestion and API integration. Its strength is breadth of connected metadata, which helps when the inventory must span pipelines, dashboards and ML assets. Ask the implementation partner to demonstrate how ownership, criticality flags and interdependency links are maintained by stewards, and how upgrades are handled, since DataHub's operating model differs from OpenMetadata's.
CKAN for a published data portal
CKAN is an open-source data management system licensed under AGPL v3.0 for building data hubs and public portals. It fits when the goal is to publish datasets, not to map internal ICT assets and their dependencies. Its DataStore and the ckanext-dcat extension support DCAT-AP metadata for publication. Choose CKAN only when a public or partner-facing catalog is the outcome, and expect that an internal DORA inventory would still need a separate system of record.
Licensing does not remove operating cost
Both OpenMetadata and DataHub are Apache-2.0, so the software license is not the main cost. The recurring costs are the database and search infrastructure, connector and lineage setup, steward time to keep owners and criticality current, and upgrades. Ask any partner to separate one-time integration work from annual operations, and to state who maintains connectors when source systems change. Vendor commercial tiers, such as Collate's premium support for OpenMetadata, should be priced separately.
Choosing by inventory scope
Pick the catalog by where your ICT assets and dependencies live. If the inventory must include pipelines, dashboards and third-party data flows, a metadata platform with lineage is the better fit. If the data is mostly curated datasets for release, CKAN may suffice. Run a short proof on a single business function, such as payments reporting, and test whether owners can keep the records current after each major change, which Article 8(6) requires.
How the inventory is built and kept current
The sequence moves from agreed scope to a catalog that records every ICT asset, its owner, its classification and its dependencies, and then keeps that record current as systems change. Each step has a named output so the inventory can be reviewed by the risk function and shown to a competent authority.
Scope business functions and critical services
Risk, operations and business owners agree which ICT-supported business functions are in scope, then identify the services that support critical or important functions. The output is a written scope list that names each function, its accountable role and the systems expected to support it. Scope is checked with the risk function before any connector is configured, so the catalog does not grow around systems no one has decided to govern.
Connect source systems and pipelines
The catalog platform is connected to the in-scope sources: databases, warehouses, BI tools, orchestration jobs and application metadata. Connectors are configured and tested in a non-production environment first, then pointed at production with credentials held in the organization's own secrets store. The check that closes this step is a connector run report listing which assets were discovered, which failed and why, so gaps are visible rather than assumed.
Bootstrap owners and classifications
Each discovered asset needs a named owner, a classification and a link to the business function it supports. Owners are often proposed from existing records such as the CMDB, service catalogue or access groups, then confirmed by the accountable business lead. Classification follows the organization's own scheme, applied as catalog tags or domains. The output is a list of assets with no owner or no classification, which is worked down until it is empty for in-scope systems.
Map dependencies to ICT third-party providers
Lineage and service relationships are recorded between assets, and each asset that depends on an ICT third-party provider is tagged with that provider and the contract it sits under. Interconnections with providers that support critical or important functions are documented explicitly. Procurement and the third-party risk owner confirm the mapping, because the catalog can only show a dependency that someone has connected or recorded. The check is a list of critical functions with every external provider in their path.
Record remote sites and configuration links
Assets on remote sites, including branch systems, regional data centers and cloud accounts outside the main estate, are added with their location and network exposure. Configuration links and interdependencies that the connectors cannot see, such as manually maintained feeds or appliances, are recorded by the owning team. Recovery objectives and supplier end-of-support dates are attached where the organization holds them. The output is a record for each in-scope asset that covers the fields the ICT asset management policy requires.
Wire ingestion and change events
Scheduled ingestion is set so that metadata refreshes at a frequency the risk function has approved, and lineage events are captured from pipelines where the tooling supports them. Change triggers are added for major changes to infrastructure or processes, such as a new system go-live, a migration or a provider change, so a risk assessment and an inventory update are requested automatically. The check is a test change that produces a ticket and a catalog update within the agreed workflow.
Review the inventory on a set cycle
The owners and the risk function review the inventory at the interval set in the governance policy, and after each major change. Reviews confirm that new assets are classified, retired assets are removed, and dependency maps still match production. Review decisions and the catalog history are retained as evidence. The closing check is a signed review record for each cycle, which shows the inventory was kept current rather than only created once.
Where scope differs for banks, insurers and ICT providers
Credit and payment institutions with many core banking, payments, risk and reporting systems usually face the widest identification task. Article 8 requires every ICT-supported business function, its supporting assets and their dependencies to be identified and documented, so the catalog has to reach past the warehouse into operational systems, file transfers and reporting tools. Most of the effort sits in reconciling overlapping inventories that were built by different teams over many years.
- Multiple inventories to reconcile: configuration databases, application registers and cloud tag exports often disagree on system names and owners, so the catalog needs an agreed identifier scheme before ingestion.
- Deeper lineage requirements: table and pipeline lineage supports the dependency mapping Article 8(4) asks for, and column lineage matters where critical figures feed regulatory reports.
- Wider connector coverage: each source system type needs a connector, a configured ingestion schedule and an owner who confirms the results.
- Change-driven updates: Article 8(6) expects inventories to be updated after every major change, so ingestion must run on pipeline and deployment events, not only on a quarterly schedule.
- Infrastructure sizing: the search and database tiers grow with the number of assets, which is a cost to plan early.
Confirm with your own data architects which systems are authoritative for each asset type before any ingestion begins.
Smaller regulated entities, such as small payment institutions or insurers with a limited set of platforms, still carry the Article 8 obligations, but the inventory is usually shorter and easier to bound. The risk is less about volume and more about key-person dependence: one or two people often hold the knowledge of how systems connect. A catalog that is set up quickly and kept small can make that knowledge explicit without a large program.
- Narrower scope to start: an initial inventory of core systems, their owners and their main data flows can be completed before extending to secondary tools.
- Lighter deployment footprint: a single-node or small clustered deployment may be sufficient for the asset count, which keeps the operating burden low. Confirm the sizing with the vendor documentation for the chosen platform.
- Manual curation carries more weight: with fewer automated connectors, owners and stewards enter descriptions, classifications and dependencies directly, so the process needs clear review steps.
- Documentation of legacy systems: older systems that remain in service still require the yearly legacy risk assessment under Article 8(7), so they must be visible in the catalog.
- Proportionality in review: the review cycle should match the risk and change rate of the entity, but the classification review must still happen at least yearly.
Ask whether the entity can justify its scope in writing and whether the same catalog can later grow without a re-platforming project.
Entities that rely on ICT third-party service providers for critical or important functions have an extra mapping obligation. Article 8(5) requires them to identify and document every process that depends on such providers and the interconnections with those providers. The catalog therefore has to record external services, their data flows and their contractual ownership alongside internal assets, which many teams have never modeled in one place.
- External assets as first-class records: SaaS platforms, cloud services and outsourced processing need entries with an owner, a location and a link to the processes they support.
- Interconnection mapping: data exchanges with providers, including APIs and file feeds, should appear as lineage or dependency edges so the interconnections can be shown on request.
- Concentration visibility: a catalog that links many processes to one provider makes concentration risk easier to see, although the risk assessment itself remains a separate activity.
- Coordination with procurement: provider records must match contract registers and exit plans, so procurement and the ICT risk function need to own shared fields.
- Evidence of current state: where a provider changes a service or location, the update should trigger a catalog review under the change requirements.
Confirm which of your providers support critical or important functions, since that determines which dependencies must be mapped in full.
Questions buyers ask about DORA asset identification
What drives the effort and cost of building a DORA asset inventory?
The main drivers are how many systems, data stores and interfaces sit in scope, how many of them have a named owner today, and how deep the dependency mapping needs to go. Costs fall into four groups: the platform infrastructure (a database and search service for OpenMetadata, or the equivalent for other catalogs), connector and lineage setup, metadata curation by business and technology owners, and ongoing operations. Open-source catalogs such as OpenMetadata are Apache License 2.0 software, so license fees are not the main line item. Ask any partner for a written scope that lists connectors, sources, owners to be engaged and the handover model before accepting a quote. DeployOpen does not publish prices; a quote follows from that scope.
How long does it take to reach a usable DORA inventory?
Duration depends on the number of source systems, how quickly connectors can be configured against them, and how fast business and technology owners confirm what each asset supports. A practical first milestone is a catalog that covers the systems supporting critical or important functions, with owners and classifications assigned, before the wider estate is added. Treat the timeline as something to agree in the written scope rather than assume from a generic figure. Ask the implementation partner to split the plan into phases with named exit criteria for each phase.
What does the financial entity need to provide before the catalog work starts?
The catalog can discover technical metadata on its own, but Article 8 asks for business context that only the institution can supply. Prepare the following before work begins:
- A list of business functions, with their roles and responsibilities
- Named owners for each system, dataset and critical function
- The ICT asset management policy under Article 4 of Delegated Regulation (EU) 2024/1774, or a draft of it
- Known third-party providers and the services they support
- Recovery objectives and supplier end-of-support dates where they already exist
Confirm the exact record fields with your compliance team and your regulator's expectations.
Can our own team build the DORA inventory without an implementation partner?
Yes, an internal team can build it, provided it has the skills to deploy and operate the catalog, configure connectors, model ownership and lineage, and keep the platform patched. The harder part is usually not the software but the cross-functional work: getting business owners to confirm functions, agreeing classification criteria and tracking exceptions. A partner is most useful when the team lacks capacity for the initial build or wants an independent view of scope. Compare an in-house plan and a partner quote against the same written list of deliverables so the comparison is like for like.
Does a data catalog alone satisfy DORA Article 8?
No. A catalog is one tool that supports the identification, classification and documentation of ICT assets, dependencies and third-party links, but Article 8 is a governance obligation that also requires risk assessment, review cycles and documented decisions. Supervisors look at the process and the evidence, and DORA sets no certification scheme that a catalog could earn. Use the catalog as the system of record for the inventory, then document the policies, review procedures and approvals around it. Confirm your supervisor's expectations with your own compliance function.
How do we keep the inventory current after the first build?
Article 8(6) requires inventories to be updated periodically and after every major change, so the catalog needs a defined trigger for updates rather than a one-off export. Practical controls include scheduled connector runs that detect new or changed assets, a change-management step that requires catalog updates before a release closes, owner attestations on a set cycle and a review of classifications at least yearly, as Article 8(1) requires. Ask the partner how ingestion failures are alerted, who approves changes to classifications and how the catalog is upgraded, since OpenMetadata 2.0 introduced breaking changes that must be planned for.
Which parts of the DORA inventory does a catalog not discover automatically?
Automated connectors read technical metadata such as databases, tables, pipelines and dashboards, and they can show lineage between them. They cannot determine on their own which business function an asset supports, how critical it is to the institution, what recovery objectives apply, or which external providers are involved in a service. Assets on remote sites, shadow tools and legacy systems without connectors need manual records. Plan for a gap list early and assign an owner to each gap, so the inventory does not look complete when it is not.
Evidence supervisors and auditors ask for from the catalog
This table maps each evidence item a competent authority or auditor is likely to request to the catalog component or export that produces it. Auditors and competent authorities judge whether the evidence is sufficient for their assessment, and DeployOpen prepares the evidence without certifying it.
| Evidence item | Produced by | What to confirm before it is requested |
|---|---|---|
| Asset register extract with unique identifiers | Catalog entity inventory, exported through the OpenMetadata REST API or Python SDK | Identifier scheme is stable across ingestion runs and matches the identifiers used in the CMDB |
| Classification records for information assets | Classification tags and glossary terms, with the tag history retained in the catalog database | Classification levels are defined in a written policy and applied to every in-scope dataset |
| Owner assignments per asset | Ownership fields on tables, dashboards and pipelines, exported as a report | Each owner is a named role or person with a documented responsibility, not a shared mailbox |
| Lineage and dependency exports | OpenMetadata table, column, pipeline and dashboard lineage, including OpenLineage events where pipelines emit them | Lineage coverage for critical functions is measured, and gaps are listed with a remediation owner |
| Interconnection records with ICT third-party providers | Service entities or custom attributes linking external providers to the assets and business functions they support | Provider records reflect contracts and exit plans held outside the catalog |
| Change logs and periodic review records | Catalog version history, ingestion run logs and dated review tasks or approvals recorded in the catalog | Reviews occur at the intervals the entity's own policy sets and after major changes |
| Ingestion audit logs | Ingestion pipeline run logs from Airflow or the OpenMetadata ingestion framework, retained in the entity's log store | Log retention period and access controls are confirmed with the entity's compliance team |
What a data catalog alone does not satisfy
A catalog gives Article 8 a current view of data assets and their lineage, but several obligations draw on sources it does not hold. The cards below set out the gaps, the other records that fill them and the checks to run before you treat the catalog as the inventory of record.
Risk assessments under Article 8
A catalog shows what depends on what, but it does not assess threats, vulnerabilities or risk scenarios. Article 8(2) calls for continuous identification of ICT risk sources, and Article 8(3) requires a risk assessment on each major change, while Article 8(7) requires a yearly assessment of legacy systems. Keep these in a risk register that links back to catalog asset identifiers, and confirm with your competent authority which evidence format it expects.
Non-data ICT assets
Article 8(4) covers all information and ICT assets, including network devices, endpoints, virtual machines, cloud accounts and assets on remote sites. A data catalog models tables, pipelines and dashboards, so these components need a configuration management database or an asset register with its own discovery feed. Check that each non-data asset has a unique identifier that can be referenced from a data flow.
Recovery objectives and end-of-support dates
Delegated Regulation (EU) 2024/1774 requires records of recovery time and recovery point objectives and supplier end-of-support dates for each ICT asset. These usually come from business continuity plans, backup tooling and vendor lifecycle notices. Ask whether the catalog can hold these as custom properties, and decide which system is authoritative so values do not drift between the two.
ICT third-party contracts and interconnections
Article 8(5) requires documented processes that depend on ICT third-party providers and the interconnections with providers supporting critical or important functions. Lineage can show a data flow into a vendor system, but the contract, exit plan, subcontractor chain and service location sit in procurement and third-party risk registers. Confirm which register holds each provider, and link the vendor record to the catalog entries it touches.
Ownership, classification decisions and stewardship time
A catalog can record an owner and a classification label, but it cannot decide either. Business owners must confirm that a function depends on an asset, and risk or compliance staff must approve classifications under Article 8(1), which requires review at least yearly. Budget steward time for these reviews as a recurring cost, and ask any implementation partner how review tasks, reminders and sign-off are recorded.
Freshness depends on change control
Article 8(6) requires inventories to be updated periodically and after every major change. A connector only sees what it scans, so changes made outside pipelines, such as manual infrastructure edits or emergency fixes, can leave the catalog behind. Tie catalog updates to change management tickets and run a periodic reconciliation against cloud and configuration inventories before you rely on the catalog for a supervisory submission.
How DORA applies and what changes in review
Since when does DORA apply to financial entities?
DORA has applied since 17 January 2025, under Article 64. It entered into force on the twentieth day after its publication in the Official Journal (OJ L 333) on 27 December 2022, which places entry into force on 16 January 2023. As a regulation, DORA is directly applicable in all member states, so it does not wait for national transposition. The asset identification duties in Article 8 therefore already apply to in-scope entities. Entities should confirm with their national competent authority how it expects the ICT asset inventory to be evidenced during supervision.
Who supervises DORA compliance for a financial entity?
The national competent authority for each type of financial entity supervises compliance, as listed in Article 46. For credit institutions classified as significant, the ECB is responsible. Critical ICT third-party service providers are overseen directly by the European Supervisory Authorities acting as Lead Overseers under Articles 31 to 44. DORA sets no certification scheme. Supervisors use the powers in Article 50, and the only authority-issued attestation the Regulation provides for is the one that a threat-led penetration test met the requirements under Article 26(7). Ask your supervisor which evidence it expects for the asset inventory.
What is the Digital Omnibus proposal and does it change DORA?
The Digital Omnibus is the European Commission proposal COM(2025) 837, tracked under procedure 2025/0360(COD) in the European Parliament Legislative Observatory. It proposes changes to a set of digital rules and is still pending in the legislative process. Its effect on DORA Article 8 and the asset inventory duties is not confirmed in the sources used for this page. Confirm the current status of the procedure and whether any proposed amendment touches Article 8 or the related delegated regulations before you change your inventory design.
When will the Commission review DORA?
Article 58(1) requires the Commission to review DORA and report to the European Parliament and the Council by 17 January 2028. The review covers, among other things, the criteria for designating critical ICT third-party providers and the voluntary nature of significant cyber threat notification. Asset inventories built now should be designed to adapt to outcomes of that review, so keep classification rules and ownership fields in configuration that can be changed without rebuilding the catalog.
How does the Article 8 inventory duty relate to the ICT asset management policy?
Article 8 sets the identification and documentation duties, and Article 4 of Delegated Regulation (EU) 2024/1774 sets the record fields that an ICT asset management policy must keep. Those fields include 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. A catalog that holds these fields as structured metadata makes the policy testable. Map each field to a catalog attribute, such as a custom property, owner, domain or lineage edge, before the first population run.
Can our team run the DORA asset inventory without an implementation partner?
Many entities can start internally, since OpenMetadata and DataHub are both released under Apache-2.0 and the cost of the software itself is not a license fee. The harder work is connector setup, lineage capture, ownership assignment and recurring review, which need named people with time and authority. A partner can take on the platform build and integration, while business owners still confirm dependencies and classifications. Ask any partner to split its written scope into platform work, integration work and stewardship support so you can see which parts your team keeps.
What should we check first when the catalog is already in use?
Check whether the catalog is tied to a documented review cycle that meets the yearly review in Article 8(1) and the update after every major change in Article 8(6). Then confirm that critical assets, remote sites and third-party dependencies are present, since Article 8(4) and 8(5) call for them specifically. Finally, check that a change in an upstream pipeline or a new third-party service triggers an update, because an inventory that drifts from the live estate fails the purpose of the review. Confirm these points with your competent authority's expectations and your internal audit function.
How DeployOpen implements and evidences the catalog
DeployOpen plans and deploys the catalog inside your own cloud accounts, data centers or air-gapped network under a fixed written scope. For DORA identification, the first decision is which platform fits the estate: OpenMetadata, which is Apache 2.0 licensed and documents production deployments on Kubernetes or bare metal, or DataHub, which is also Apache 2.0. The work then covers the database and search prerequisites, the connector set for each source system that supports an ICT-supported business function, and the ownership model. Each ICT asset record should carry the fields Article 4 of Delegated Regulation (EU) 2024/1774 expects, including a unique identifier, location, classification, owner, supported business function, recovery objectives, external exposure and supplier end-of-support date. Confirm with your ICT risk team which of these fields already exist in a CMDB and which must be captured in the catalog.
DeployOpen configures ownership and classification as governed metadata rather than free text. That means defining domains, glossary terms and classification tags, assigning owners to each asset, and setting review workflows so the classification is revisited at least yearly and after every major change, as Article 8 requires. Lineage is set up from pipelines and BI tools where connectors support it, and gaps are logged as named exceptions with an owner and a date. Dependencies on ICT third-party providers are tagged so they can be exported for the register of information. Ask any partner how they will test lineage completeness against a sample of critical functions before signing off the inventory.
Evidence is produced as part of the work, not assembled at audit time. DeployOpen documents the inventory procedure, the role definitions, the change triggers, the connector configuration, and exports of asset records and review logs, stored in your own systems. These artifacts support the assessments your competent authority or internal audit may request. DeployOpen does not issue audit reports, attestations or certifications; those come from independent auditors and supervisors. Before scoping, ask for a written list of deliverables, acceptance criteria for each one and a plan for operating the catalog after handover.
How DeployOpen scopes, delivers and supports the DORA inventory
DeployOpen plans and implements self-hosted open-source catalogs such as OpenMetadata inside the client's own infrastructure, with the DORA asset inventory defined in writing before any work starts. Engagements are fixed-scope, so the inventory fields, sources, owners and deliverables are agreed up front.
How we scope
- Agree which ICT-supported business functions and assets the inventory must cover, in writing, before deployment starts.
- Confirm the record fields to be kept per asset, such as identifier, location, classification, owner and recovery objectives.
- List the source systems, connectors and third-party service providers whose dependencies must be mapped into the catalog.
How we build
- Deploy the catalog in your cloud account, data center or air-gapped network, with database and search services sized for the agreed scope.
- Configure connectors, lineage capture and classifications for the systems in scope, and test that records populate as expected.
- Set up ownership assignment, glossary terms and review workflows so the inventory can be updated after major changes.
How we hand over
- Document the configuration, connector settings, record templates and update procedures so your staff can operate the catalog.
- Provide written evidence of the inventory design and review steps for internal audit and compliance assessments.
- Train named owners on maintaining records, reviewing classifications and raising gaps in the dependency map.
How we support
- Offer ongoing support, upgrades and maintenance as a retainer, scoped separately from the initial implementation.
- Plan catalog upgrades, including breaking changes in new releases, with testing before they reach production.
- Confirm with your team which yearly and event-driven review cycles the retained support will cover.
