--- title: "Public Cloud And Unsanctioned Technology: What Your CMDB Isn't Seeing" description: Cloud accounts opened on a credit card never reach the CMDB. How to find unsanctioned cloud and software, bring it into view, and give it an owner. --- [Latest blog and updates | Apex Configuration Group](https://www.apexconfiguration.com/blog) # [Public Cloud And Unsanctioned Technology: What Your CMDB Isn't Seeing](https://www.apexconfiguration.com/blog/public-cloud-and-unsanctioned-technology-what-your-cmdb-isnt-seeing) Written by [Warren O'Neill](https://www.apexconfiguration.com/blog/author/warren-oneill) | Oct 3, 2026, 8:00:01 AM Public cloud makes it easy for any team to create infrastructure without going through the people who run the configuration management database (CMDB). An account opened on a company card, a subscription created by a project team, or a software service signed up to by one department can all run production workloads that no discovery schedule knows about. That unsanctioned technology has no owner in the CMDB, no place in change impact, and no coverage in vulnerability reporting. Bringing it into view starts with finding the accounts, then connecting them, then giving every resource an owner. ## Why cloud resources escape the CMDB Traditional discovery scans network ranges from servers you control. Cloud resources often sit outside those ranges entirely, in accounts the configuration management team has never been given access to. - Accounts and subscriptions are created outside central procurement. - Resources are short-lived and change faster than scheduled scans. - Identifiers are provider-specific and don't match anything discovery already holds. - Software services have no network presence in your estate at all. Each of those means the CMDB can look complete while a growing share of your real estate isn't in it. ## Step one: find the accounts You can't connect what you don't know exists. Build an account register from sources outside the technology team. | Source | What it reveals | | --- | --- | | Cloud provider organisation or billing views | Accounts and subscriptions already under central management | | Finance and expense records | Cloud and software charges paid on cards or local budgets | | Identity provider sign-in logs | Software services staff are signing in to | | Network egress and proxy logs | Heavy traffic to providers not in the register | Record each account with its provider, the team using it, a named owner and whether it's sanctioned. An unsanctioned account isn't automatically a problem. An unsanctioned account nobody owns is. ## Step two: connect accounts at the right level For the major cloud providers, connect at the organisation or management group level where you can, so new accounts are picked up automatically. Service Graph Connectors and cloud discovery bring in resources using the provider's own identifiers. Decide identification and precedence before connecting. If another tool already reports cloud resources, the two sources must agree on identifiers, or you'll create a parallel copy of the estate. On one estate of tens of millions of configuration items (CIs), a security platform created cloud server CIs that discovery also held, with no shared identifier between them. A cloud administrator noticed the CMDB held twice as many servers as his console showed. Switching that class to the cloud provider's own connector fixed it. Our article on [multi-source data precedence](https://www.apexconfiguration.com/blog/multi-source-data-in-servicenow-why-precedence-starts-before-reconciliation) covers the design. ## Step three: make every resource ownable Cloud resources are too numerous to assign owners one by one. Use provider tags. **Agree a minimum tag set.** Owner, cost centre and application service are the usual core. **Enforce it at the provider.** Use the provider's policy tools to require the tags on creation, so untagged resources can't be created in sanctioned accounts. **Map tags into the CMDB.** Bring tag values in with the resource, and use them to set ownership and link the CI to its application service. **Default to the account owner.** Any resource without an owner tag inherits the account owner, so nothing is ownerless. ## Keeping cloud visibility accurate Track key performance indicators (KPIs) that show whether the cloud estate is under control: - accounts found in finance or sign-in data that aren't in the register - resources per account in the CMDB, compared with the provider's own count - resources missing mandatory tags - cloud CIs not linked to an application service The count comparison catches both duplicates and gaps. Run it monthly per account, and after any integration change. Handle short-lived resources deliberately. Let the connector retire CIs when resources disappear, and keep enough history to answer questions about what existed during an incident. Give each account owner a place in the RACI (responsible, accountable, consulted, informed) for configuration management. Put new account creation behind a simple request that captures owner and purpose, and makes connection to the CMDB part of set-up. For how cloud visibility connects to cost, see our article on [reducing cloud spend](https://www.apexconfiguration.com/blog/cloud-cost-optimisation-reduce-cloud-spend). ## How Apex helps Our discovery and integration coverage review establishes what is missing from your estate view, where, and what it costs during an incident. For cloud, that means which accounts and subscriptions aren't connected, where connectors duplicate other sources, and how much of the cloud estate lacks an owner. We scope it with you at an initial consultation. [Book a CMDB diagnostic call](https://www.apexconfiguration.com/cmdb-diagnostic-call) or [arrange a meeting with a consultant](https://www.apexconfiguration.com/book-a-meeting). ## Frequently asked questions ### Should we block unsanctioned cloud accounts? That's a policy decision for your organisation. Whatever you decide, find and register them first, so the decision is made with the facts. ### Do software services belong in the CMDB? Those that support business services do, typically as application services or related CIs with an owner. Identity sign-in data is the easiest way to find them. ### How do we handle resources that exist for minutes? Let the connector create and retire them automatically, and keep history. Manual processes can't keep up. ### What if tags are missing or wrong? Enforce them at creation in sanctioned accounts, default ownership to the account owner, and report untagged resources to that owner.     *Written by Iain Moone, Apex Configuration Group.* [View full post](https://www.apexconfiguration.com/blog/public-cloud-and-unsanctioned-technology-what-your-cmdb-isnt-seeing) ```json { "@context" : "http://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Warren O'Neill" }, "dateModified" : "2026-10-03T08:00:01.286Z", "datePublished" : "2026-10-03T08:00:01Z", "headline" : "Public Cloud And Unsanctioned Technology: What Your CMDB Isn't Seeing", "image" : { "@type" : "ImageObject", "height" : 916, "url" : "https://147949153.fs1.hubspotusercontent-eu1.net/hubfs/147949153/AI-Generated%20Media/Images/Public%20Cloud%20And%20Unsanctioned%20Technology%20Banner.png", "width" : 1717 }, "mainEntityOfPage" : "https://www.apexconfiguration.com/blog/public-cloud-and-unsanctioned-technology-what-your-cmdb-isnt-seeing", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "height" : 60, "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png", "width" : 60 }, "name" : "Latest Blog & Updates" } } ```