Asset Inventory: The Foundation of Security Visibility in India

You cannot secure what you cannot see. Asset inventory is a live, accurate record of every server, endpoint, SaaS tenant, cloud account, domain, subdomain, certificate, API, data store, and third-party integration an organisation runs — plus who owns each one. Without it, patching is guesswork, VAPT scope is incomplete, and incident response starts with "wait, we have a server doing what?" For Indian SMBs scaling fast, asset inventory is not a compliance checkbox — it is the control every other security control depends on.

Why asset inventory comes before everything else in security

Security programs love to start with the exciting parts — a penetration test, a shiny SIEM, a firewall review. But every one of those controls can only answer correctly if you already know what exists. A VAPT engagement can only test systems it is told about; a patch process can only patch servers it knows are running; a SOC can only monitor log sources it has onboarded. An asset missing from the inventory is invisible to every downstream control — exactly where attackers look first.

This is not new. The Center for Internet Security (CIS) places "Inventory and Control of Enterprise Assets" and "Inventory and Control of Software Assets" as Controls 1 and 2 of its 18 Critical Security Controls — deliberately first. NIST's Cybersecurity Framework builds its "Identify" function (ID.AM — Asset Management) around the same premise: you cannot manage risk on assets you have not catalogued.

What counts as an asset in 2026

A decade ago, "asset inventory" meant a spreadsheet of servers and laptops. That is now dangerously incomplete. A modern SMB's asset surface includes:

1. Compute — on-prem servers, cloud VMs, containers, serverless functions.
2. Endpoints — laptops, mobile devices, and BYOD hardware touching company data.
3. SaaS tenants — every SaaS product a team signed up for, not just what IT provisioned.
4. Cloud accounts — every AWS, GCP, Azure, or hosting-panel account, including a contractor's, opened with a company card.
5. Domains and subdomains — the primary domain, marketing microsites, staging subdomains, campaign domains never decommissioned.
6. TLS certificates — including self-signed and expired ones, often the first sign a subdomain is unmanaged.
7. APIs — internal and externally exposed, including partner integrations and any public API doc left open.
8. Data stores — databases, object storage, backups, and analytics warehouses.
9. Third-party integrations — payment gateways, CRMs, and tools with API or data access.
10. The people who own each asset — one without a named owner is one nobody will patch or decommission.

How shadow IT and forgotten subdomains become the breach path

Shadow IT is not hypothetical — it is the predictable outcome of how teams work. A marketing team spins up a landing-page builder for a campaign; a developer stands up a staging subdomain to demo a feature; a finance team signs up for an expense tool with no IT ticket involved. Each is a fast, legitimate decision that creates an asset outside the inventory, with no patch cycle, owner, or expiry date.

IBM's Cost of a Data Breach Report has consistently found that breaches involving data or systems the organisation did not know it had — what IBM terms shadow data — took meaningfully longer to identify and contain, and cost more on average, than breaches confined to known, managed systems. The cost is not just the incident; it is the extra weeks spent figuring out what was even compromised.

The pattern repeats at the DNS layer. A subdomain pointed at a cloud resource later decommissioned but never removed from DNS becomes a dangling record an attacker can claim to serve malicious content under your trusted domain. This issue, subdomain takeover, exists purely because nobody was tracking the mapping.

Practical discovery methods for a small Indian team

You do not need an enterprise CMDB to build a working inventory. A small team can get most of the way there with a repeatable, mostly free process:

1. External attack surface discovery. Passive and active subdomain enumeration (amass, subfinder, certificate transparency logs — all free, open source) surfaces subdomains DNS still points to but nobody remembers registering.
2. Cloud provider APIs. Every major cloud provider exposes an API or CLI to list every resource in every account. Script this quarterly to catch drift.
3. Internal network and endpoint scans. A basic authenticated scan surfaces devices never formally provisioned but live on the network.
4. SaaS and expense-record cross-checks. Pull active subscriptions from finance and your SSO's connected-apps list, then diff the two. A mismatch either way is worth a conversation.
5. Certificate transparency monitoring. Free CT log monitors alert you the moment a new TLS certificate is issued for any subdomain — often the earliest signal of a new asset.
6. People, not just tools. A quarterly email to every team lead — "list every tool and domain your team owns" — surfaces assets no scan will find, because they live entirely inside a SaaS vendor's system.

Assigning ownership and criticality

Discovery only produces a list. It becomes an inventory once every entry has an owner and a criticality rating. Ownership answers "who gets paged"; criticality answers "how fast."

How the inventory drives patching, VAPT scope, and incident response

An accurate, owned, criticality-rated inventory is the input every other security process consumes:

1. Patch management uses criticality to set SLAs and ownership to know who executes the patch.
2. VAPT scope is only as complete as the inventory it is drawn from. A test scoped against last year's asset list misses every subdomain stood up since — it passes cleanly while real exposure goes untested. This is why a free VAPT scan should be paired with a current inventory, not last year's memory.
3. Monitoring and detection need the inventory to know what "normal" looks like for each asset, and which log sources should exist but are silent.
4. Incident response lives or dies on inventory speed. The first hour is spent answering "what does this system talk to, who owns it, what data does it hold" — questions an inventory answers in seconds, an ad hoc investigation in days.

The inventory lifecycle

The loop matters as much as any single step. An inventory is a snapshot the day it is built and a liability the day it stops being refreshed. Scheduled re-discovery keeps the "unknown or unowned asset" branch small instead of growing quietly.

Where unknown assets typically hide

The following breakdown is illustrative, based on common patterns across SMB environments rather than a single cited survey — actual proportions vary by organisation and how long shadow IT has accumulated.

Forgotten subdomains and unmanaged SaaS signups dominate for a structural reason: both can be created by a single employee in minutes, with no procurement process and no natural expiry trigger. Legacy on-prem boxes and contractor-owned cloud accounts are fewer but riskier per asset, since they tend to run outdated software with nobody watching for advisories.

Building the habit, not just the spreadsheet

Organisations that keep an accurate inventory over time are rarely the ones with the fanciest tooling — they treat it as a recurring process owned by a named person, with scans on a calendar and a review step in every new-tool and offboarding workflow. Open-source tooling closes the technical gap cheaply; re-running it closes the security gap.

If your team is planning a VAPT engagement, treat the inventory refresh as step zero — with a CERT-In empanelled partner where formal attestation is required, a current asset list is what turns a test into a genuinely complete one.

For more, see the blog, or start with a free VAPT scan to see how your asset visibility holds up. References: NIST Cybersecurity Framework, CERT-In advisories, CIS Critical Security Controls.

Dhisattva AI Pvt Ltd built Bachao.AI on the principle that continuous discovery keeps an inventory — and the controls built on it — honest.