Who Owns Hybrid Cloud CMDB for Financial and Public-Sector-Adjacent Enterprises in Brussels?

An infrastructure team at a Brussels financial firm plans a change on a workload hosted with a public cloud provider. A reporting job that reads from that workload still runs on a server in the firm’s own data centre. The server record names one owner, while the cloud account names a different owner for the same service path. Before anyone touches either side, the team has to answer a practical question about Hybrid cloud CMDB for financial and public sector enterprises in Brussels: which record both teams would trust, and who confirms it. Each configuration record should carry one named owner per hosting layer, and a person at the firm confirms that owner before the change window opens. This opening is a labeled composite built to show the ownership gap without naming a customer firm.

That ownership gap sits beside a posture many Belgian public bodies already run. In June 2026, Smals, the IT provider for Belgian social security and government institutions, selected Google Cloud as its primary public cloud and described it as a third pillar next to its community cloud and on-premises systems, according to ITdaily coverage of the Smals choice. A later ITdaily follow-up on the Smals move framed the same direction as cloud-smart, with an expectation that applications remain able to run on-premises. Financial firms and suppliers that sit next to those estates inherit the same three-layer shape: on-premises systems, private or community cloud, and at least one public cloud account. The record that names what runs where, and who owns each item, is the evidence teams need before a change, a filing, or an exit conversation.

Who is covered, and by whom

“Public-sector-adjacent” is a useful audience label for infrastructure leaders who work beside public programmes. It remains a marketing shorthand rather than a legal category under Belgian or EU law. The duties that apply track the organisation’s licence and sector status.

Belgian DORA supervision is commonly described as split between the NBB and the FSMA by entity type, which consulting summaries such as Copla’s Belgium DORA overview also reflect. For market-infrastructure operators and the register cycle in the capital, Virima’s CMDB accuracy piece for Brussels DORA covers that lane in more depth. For NIS2 asset-visibility work in the same city, the Brussels NIS2 CMDB article stays on that duty set. No regulation on this list requires a product called a CMDB. Each regime asks for accurate technical evidence, and a maintained record is one way to produce it.

Where hybrid records split apart

Hybrid estates often split the record across three patterns. These patterns show up across industries and cities, and they are labeled here as common patterns rather than findings about one Brussels firm.

• Each hosting layer keeps its own register. On-premises teams keep a configuration list. Private or community cloud teams keep another. Each public cloud account has its own inventory and tags. Result: nobody can read one list of what runs where when a change crosses layers.
• Dependencies cross the boundary with no shared owner. Microsoft’s Cloud Adoption Framework notes that if App A constantly calls Database B, teams either move them together or keep connectivity until both sides of the pair sit in the same place, which is spelled out in the workload assessment guidance. Result: a change on one side breaks a job on the other when the relationship never lived in a shared record.
• Exit and portability plans sit apart from the inventory. A cloud-smart posture expects applications to remain runnable outside a single provider, which is the posture ITdaily described for Smals. Result: a team cannot show which services depend on which provider without opening three documents and reconciling them by hand.
• Retired systems keep a seat without a named decision. Hostnames linger after the workload is gone. Cloud projects stay billed after the service is retired. Result: the next audit or change review still treats those items as live until a named owner closes them.

When discovery sources disagree about the same object, teams also need a rule for which field wins. Virima’s Amsterdam hybrid CMDB article works that conflict rule in depth. Short-lived cloud resources raise a related question about whether a CMDB still earns its keep, which the cloud CMDB guide addresses on its own.

What the surveys say

Global and EU-wide surveys describe the same pressure Brussels teams feel when layers multiply. Every figure below is labeled by its survey scope.

• Flexera’s 2026 State of the Cloud, based on 753 cloud decision-makers, reports that 73% of organisations use hybrid cloud. The same report states that understanding application dependencies is the biggest barrier to cloud migration. Both findings come from that global survey sample.
• Flexera’s 2026 State of ITAM, based on 512 professionals across industries, reports complete IT visibility at 36%, down from 43% the prior year. Audit pressure remains expensive in that sample: 48% of organisations were audited in the past year, and 44% spent more than $1 million on audits over three years. License reuse still generates significant savings for 43% of organisations in the same survey.
• Deloitte’s DORA European Survey (2025 edition) covers financial entities across 28 countries. For 46% of those entities, the register of information is the most challenging task on the road to compliance. That figure is EU-wide rather than Brussels-specific.

Hybrid cloud CMDB for financial and public sector enterprises in Brussels: one record across three layers

A hybrid cloud CMDB for financial and public sector enterprises in Brussels is one discovery-fed record of configuration items and relationships across on-premises systems, private or community cloud, and public cloud accounts. Four mechanisms keep that record usable.

Discover both sides of the boundary. Agentless probes and agents cover on-premises and endpoint estates. AWS and Azure imports are configured in the product with the customer’s credentials. Network reach, protocol compatibility, and devices that resist automated collection still set limits. Items outside those paths need manual registration. Documented cloud imports cover AWS and Azure. Other public clouds, community clouds, and SaaS control planes stay outside that import path unless the customer registers them another way. Discovery runs on a high-frequency scheduled cadence the customer sets. Short-lived resources can appear or disappear between cycles. Credentials for discovery sit encrypted on a customer-owned Discovery App server. The IT Discovery feature page and the AWS and Azure CMDB discovery guide describe those methods in product terms.

Show what depends on what. Once people define which applications and websites make up each business service, ViVID™ builds dependency maps and can show communication flows by port and protocol across the boundary. Service composition stays a human definition. The map does not invent that composition on its own. The service mapping feature page is the product home for that capability.

Put an owner on each record. Ownership and criticality are supplied by people. Records carry a source and a timestamp so reviewers can see who asserted the field and when. The named owner confirms the assignment, and the CMDB stores that confirmed decision for later reviews.

Keep changes flowing in. Planned moves and tickets can update the same record through ITSM platforms such as ServiceNow, Jira Service Management, Ivanti, Hornbill, HaloITSM, Xurrent, and TeamDynamix. Teams connect those platforms through the integrations hub.

Teams that want the product path behind that shared record can review how Virima frames Trusted Runtime Truth as discovery-sourced operational context for change and ownership decisions. The CMDB feature page is the product home for the shared record itself.

What the CMDB settles, and what stays elsewhere

Ownership has three parts. A named person owns each record in each layer. A CMDB owner owns the system of record and its cadence. Separate teams own the decisions the record informs: sovereignty and workload policy, data classification, exit-plan design and testing, DORA and NIS2 duties and filings, resilience testing, and legal interpretation. The CMDB shows ownership while policy authority stays with those named decision owners.

For a CIO or VP of IT in Brussels, the board-ready message is direct. The record shows what exists, how it connects, who owns it, and when it was last verified. Policy decisions stay with the people who own them. Browser content and data content inside applications sit outside discovery’s reach and need other controls.

Where the efficiency and savings come from

Mechanisms below are measurable inside one firm. Survey figures remain global or EU-wide labels rather than Brussels forecasts.

Dependency work before a change. Interviews and spreadsheet reconciliation across layers consume hours for every material change. Flexera’s global cloud survey names application dependencies as the top migration barrier. Inside one firm, measure hours to build the dependency list for one change before and after a shared record exists.

Rework from missed dependencies. Rollbacks and emergency fixes after a change are a local incident metric. Count incidents per change attributed to a missed cross-layer dependency over a fixed window.

Register and filing preparation. Collecting technical details for supervisors is slow when three inventories disagree. Deloitte’s EU-wide DORA survey found 46% of financial entities call the register of information the hardest task. Inside one firm, measure hours to confirm the technical side of one register line.

Software audits and licenses. Installed versus entitled positions improve when discovery feeds a shared inventory. Flexera’s cross-industry ITAM survey reports heavy audit spend and material savings from license reuse for a large share of respondents. Financial-services ITAM context is expanded in Virima’s financial services ITAM compliance article and on the ITAM feature page.

Orphaned infrastructure. Servers and cloud resources with no named owner keep costing money and attention. After each ownership review, count records still missing a named owner and close them with a decision.

Measure those hours on your own estate against the mechanisms above.

The first 90 days

• Name an owner for the CMDB and for each layer: on-premises, private or community cloud, and each public cloud account in scope. Put those names where the change board can see them.
• Run discovery on one on-premises site and one AWS or Azure account tied to one important service. Set a cadence the team can keep on a schedule, then keep that cadence through the quarter.
• Define that service in ViVID™ with its owners, and review the communication flows that cross layers. Confirm the service definition with the people who run it.
• Reconcile discovery against each layer’s existing register. Record every gap with an owner and a decision: correct the register, correct the CMDB, or retire the item.
• List the exit or portability notes your own policy requires for that service, and link those notes to the service’s records. The policy text and its tests stay with their owners.
• Close out retired systems with a named owner decision, then update the record and rerun discovery on the next cycle so retired items leave the active view.
• ITSM handoffs for planned changes can start once the first service record is stable, using the platforms listed on the integrations hub.

Start with one site and one cloud account

Run a discovery pass on one on-premises site and one AWS or Azure account, then compare the result with the registers you keep today. Schedule a demo when you want that pass scoped with the Virima team.

FAQ