Rather than simply presenting the contents of the CMDB, TekTrust compares BMC Discovery and ServiceNow on every sync, identifying where the same CI differs and retaining the evidence required to investigate the discrepancy.
The CMDB is far more than an inventory of technology. It provides operational context for change management, incident response, service management, infrastructure governance and technology risk. But there is an uncomfortable question behind every process that depends on it. Having multiple data sources does not necessarily solve the problem. Discovery may identify one version of an infrastructure asset. ServiceNow may contain another. Identification and reconciliation rules determine whether records are created or merged, while precedence rules determine which attributes ultimately populate the CI. The result can be a CMDB that appears complete while containing discrepancies that are difficult to see from inside the CMDB itself.
Most organisations have controls governing how data enters the CMDB. That does not necessarily prove that the resulting record accurately represents the underlying infrastructure. The TekTrust approach is different. It creates an independent validation layer across the discovery and CMDB environments. TekTrust uses the organisation's existing BMC Discovery data and reads ServiceNow without installing components into it. Importantly, the architecture is read-only: TekTrust does not write changes back into the CMDB. TekTrust is not trying to become another source competing to determine the truth. Its job is to test the evidence behind the truth already being presented to IT operations.
At its simplest, the TekTrust process can be understood as:
Discover → Compare → Validate → Evidence → Investigate → Act
Each synchronisation provides another opportunity to test the state of the CMDB against the underlying discovery data. TekTrust focuses on several technically important conditions.
The first test asks whether infrastructure identified by BMC Discovery is represented correctly in ServiceNow. TekTrust identifies devices that Discovery has found but which have not made it into the CMDB, as well as records that were previously present but have subsequently disappeared. These findings can be analysed by class, helping technical teams understand whether discrepancies are isolated or concentrated within particular areas of the estate. For a financial institution with a large and constantly changing technology estate, that distinction is significant. A server existing in the infrastructure but not appearing in the expected CMDB dataset is not simply a data-quality issue. It creates a potential gap in the operational model used by other teams and processes.
A CI can exist in both systems and still be wrong. TekTrust therefore performs field-level comparison between the value held within ServiceNow and the value identified by Discovery. Where they differ, TekTrust surfaces the affected attribute, including situations where a field is blank. This allows engineers to see both the discrepancy and the value Discovery is reporting. This is important because CMDB accuracy cannot be measured purely by asking:
"Does the CI exist?"
The more useful question is:
"Is the information describing that CI accurate?"
Hostname, operating system, infrastructure characteristics and other critical attributes can influence downstream operational decisions. A CI with inaccurate attributes may therefore be more dangerous than an obviously missing CI because the record exists and can appear trustworthy. TekTrust makes that discrepancy visible.
One of the more technically interesting problems addressed by TekTrust is over-merging. Identification and reconciliation processes exist to prevent multiple records representing the same infrastructure object. The opposite problem can also occur. Multiple real devices can become associated with a single ServiceNow record. From a CMDB perspective, the record exists. From an operational perspective, the model may be wrong. TekTrust identifies situations where two or more real devices appear to be hidden behind a single CMDB record and surfaces each underlying device with the supporting evidence. Crucially, these findings are ranked by confidence and presented as candidates for investigation rather than automatically asserted defects. TekTrust isn't blindly replacing one automated decision with another. It is giving technical teams the evidence needed to investigate the condition intelligently.
Infrastructure does not operate as a collection of isolated CIs. Relationships matter. Applications depend on infrastructure. Infrastructure depends on networks, platforms and other technology components. Those relationships provide much of the context required for impact analysis and service management. TekTrust therefore also checks for relationships identified through Discovery that are absent from the CMDB. This moves the conversation beyond:
"Do we have the asset?"
towards:
"Do we accurately understand how that asset fits into the environment?"
For complex financial services infrastructure, that is a materially more useful measure of operational data quality.
Finding discrepancies is only valuable if teams can manage them. TekTrust therefore turns the comparison into an operational view of CMDB data quality. The platform provides RAG status for ServiceNow-to-Discovery pairings, allowing teams to move from an aggregated health position directly into the individual CIs behind it. Findings can be downloaded into Excel, either individually or as a full extract, while the same dataset can be made available through an API for use within Power BI. That creates two levels of information from the same evidence.
Management gets the signal.
How healthy is our operational data? Where are the concentrations of risk? Is the position improving or deteriorating?
Engineering gets the evidence.
Which CI failed? Which attribute differs? What did Discovery identify? What exists in ServiceNow? Why has the record been flagged?
As the TekTrust proposition puts it:
“Status the board understands. Detail engineers can action.”
Financial institutions operate some of the most complex technology environments in the enterprise. Legacy infrastructure can coexist with cloud services, distributed applications, third-party platforms and rapidly changing digital services. Against that complexity, CMDB quality becomes an operational dependency. If the underlying configuration data is inaccurate, uncertainty propagates into the processes consuming it. That creates several areas where TekTrust can provide significant value.
Before changing infrastructure, teams need to understand what exists and what may be affected. If CIs are missing, attributes are inaccurate or multiple devices have been incorrectly merged into a single record, the information supporting change assessment may already be compromised. TekTrust provides an additional validation mechanism for the data beneath that decision.
During a major incident, engineers need reliable information quickly. They should not have to determine whether the infrastructure information in front of them can be trusted while simultaneously trying to restore a critical service. Continuously identifying discrepancies before an incident occurs gives teams the opportunity to improve the underlying operational data proactively.
Service models depend upon accurate assets and relationships. If those foundations are wrong, the business service represented above them can also be wrong. By identifying missing infrastructure, incorrect attributes, over-merged devices and missing relationships, TekTrust can help organisations improve the data foundation supporting service modelling.
There is an important difference between saying:
"We believe our CMDB is accurate."
and being able to demonstrate:
"Here is where Discovery and the CMDB agree, here is where they don't, and here is the evidence behind every exception."
For financial institutions operating within demanding governance, audit and technology-risk environments, that distinction can be valuable. TekTrust turns CMDB quality from an assumption into something that can be inspected, measured and evidenced.
This may be the most important architectural point. TekTrust is not positioned as another discovery platform or another CMDB. It works with the technology already in place. It uses existing BMC Discovery data. It reads the existing ServiceNow environment. And because its interaction with the CMDB is read-only, it does not attempt to correct records automatically or introduce another system capable of changing the underlying data. Instead, TekTrust provides the missing validation layer between discovered infrastructure and operational record.
That gives financial institutions a way to independently answer:
What did Discovery find?
What reached the CMDB?
Where do the two disagree?
What was merged incorrectly?
Which relationships are missing?
And what evidence do we have to prove it?
The goal of TekTrust isn't simply to produce another data-quality dashboard. It is to make operational trust measurable. Every synchronisation becomes another validation point. Every discrepancy becomes an evidenced finding.
Every over-merge becomes something engineers can investigate, and every management-level status can be traced back to the technical records underneath it. For financial institutions, that changes the role of CMDB assurance.
Instead of periodically asking whether the CMDB is accurate, teams can continuously test whether the operational data supporting critical IT processes still deserves to be trusted.
For financial institutions that already have significant investment in BMC Discovery and ServiceNow, TekTrust isn't another discovery platform. It's the validation layer that helps you determine whether the data you already have can actually be trusted.