Ask most companies how many domains and subdomains they operate, and the number they give you is almost always wrong, not because anyone is lying, but because nobody has actually looked. A recent pilot program running expanded subdomain discovery across 60 organizations found that every single one, without exception, turned up more related subdomains than they knew they had, and nearly a quarter of them discovered more than fifty they'd never accounted for . Separate research on unmanaged cloud services puts the average organization at over 900 unknown cloud services running somewhere in its environment . That's the actual starting condition most businesses are working from when they think about security: a real attack surface meaningfully larger than the one anyone's actually testing.
A vulnerability assessment or penetration test is only as good as its scope, and scope is only accurate if the asset inventory behind it is complete. Here's how to actually build that inventory before you schedule your next audit.
Why this step gets skipped, and why that's expensive
Most businesses scope a security assessment around the assets they think about daily: the main corporate website, maybe the primary product application. That's a reasonable starting instinct, and it's also almost always an incomplete picture. Attack surface accumulates the way organizational sprawl always does, through acquisitions, marketing campaigns, departed employees, abandoned projects, and vendor relationships nobody formally tracked. None of that shows up on anyone's radar until either an assessment specifically goes looking for it, or an attacker finds it first.
The uncomfortable reality is that the second scenario happens constantly, and it's not sophisticated. Attackers use the exact same public data sources a legitimate assessment does, certificate transparency logs, passive DNS records, and automated subdomain enumeration, to build a target list of exactly the assets a company forgot existed . A security program that only tests the assets it remembers is, by definition, leaving the forgotten ones completely uncovered, and forgotten assets are consistently where the weakest security controls live, because nobody's been maintaining them.
Documenting primary domains
Start with what seems obvious, because it's usually less complete than assumed. Most businesses run more than one primary domain: the main corporate domain, regional or country-code variants, alternate spellings registered defensively, and old domains from a previous brand name that still redirect or, worse, still resolve to something live nobody remembers deploying. Each one needs to be documented with what it actually points to, whether it's actively serving content or just forwarding, and who currently owns the registration and DNS management, since domain ownership quietly changing hands between departments or agencies over the years is more common than most companies realize.
Subsidiaries and acquired brands
Every subsidiary, acquired company, or sub-brand typically runs its own separate web presence, frequently on infrastructure and vendor stacks that have nothing in common with the parent company's, especially in the months or years immediately after an acquisition when integration hasn't fully happened yet. This is exactly the blind spot that shows up in cybersecurity due diligence gone wrong: a parent company's security program covers what it built, and treats what it acquired as someone else's responsibility, right up until a breach in the acquired subsidiary's neglected infrastructure becomes the parent company's problem anyway.
Documenting this layer means listing every subsidiary and acquired brand, confirming who currently owns security responsibility for each one's digital footprint, and being explicit about whether that ownership was ever formally transferred or just quietly assumed. An acquired company's legacy website, still running on infrastructure nobody from the parent company has ever logged into, is a common and completely avoidable finding.
Marketing websites and campaign microsites
Marketing teams and agencies spin up standalone campaign sites and microsites constantly, often on completely separate hosting from the company's core infrastructure, frequently under a memorable campaign-specific domain rather than a subdomain of the main site. These get built fast, launched for a specific promotion or event, and then abandoned the moment the campaign ends, still live, still indexed, still technically part of the company's public-facing footprint, with no one specifically responsible for patching or monitoring them once the marketing calendar moves on.
This category is a recurring finding precisely because it falls into an ownership gap. IT doesn't know it exists because marketing built it directly with an agency. Marketing considers the project finished the day the campaign ends. The agency's contract usually ended with it too. The site itself, meanwhile, is still sitting on the internet, often running outdated CMS software or plugins nobody's touched since launch.
Forgotten subdomains
This is where the real volume tends to hide. Staging environments, development and test subdomains, demo instances built for a sales presentation and never taken down, old product lines that were sunset without the DNS record being cleaned up, and one-off subdomains an individual engineer spun up for a project that quietly died, all of it accumulates over years and rarely gets audited unless something specifically forces the question.
Finding these systematically means going beyond an internal list, since internal lists are exactly what's incomplete here. Certificate transparency logs are one of the most reliable sources, since every publicly trusted TLS certificate ever issued for a subdomain gets permanently logged, meaning a staging environment that had a certificate issued three years ago and was never decommissioned is still discoverable today. Passive DNS records, historical records of what a subdomain has resolved to over time, catch assets that certificate logs alone miss, particularly ones that never had a properly issued certificate at all. Between these two sources, a proper discovery pass routinely turns up a materially larger list than whatever inventory a company's IT team maintains internally, which is exactly the pattern the pilot data above reflects.
Externally hosted services
The last category is the one most companies genuinely don't think of as part of their attack surface at all: services hosted entirely on third-party infrastructure but branded and accessed as if they were the company's own. A support portal on a helpdesk platform, a status page, an API developer portal, a careers site running on an applicant tracking system, a knowledge base, a payment or billing portal, a marketing automation login page. Each one typically lives on a custom subdomain of the company's own domain, pointed at a vendor's infrastructure, which means the branding, and the customer trust, are entirely the company's, while the actual security of the underlying platform sits with a vendor the company has limited visibility into and effectively no control over.
This is where third-party risk and attack surface management overlap directly. A misconfiguration or breach on the vendor's side still shows up as a security incident tied to the company's own domain and brand, regardless of who actually controls the infrastructure behind it. Documenting this layer means listing every externally hosted service pointed at a company-owned subdomain, what vendor operates it, what data flows through it, and whether that vendor relationship has ever actually been reviewed for security posture rather than just onboarded for functionality.
Building the actual inventory
The practical output of all of this should be a single, maintained asset inventory, not a mental list or a folder of old emails from when the marketing site was built. For every domain, subdomain, and externally hosted service, record what it is, who owns it internally, what vendor or infrastructure it runs on, what its actual purpose is, when it was last reviewed, and whether it's currently considered in scope for security testing. Anything that can't be clearly answered on that last point is exactly the kind of asset most likely to be the one that gets exploited, precisely because nobody's claimed responsibility for it.
Why this determines whether your next assessment actually means anything
A vulnerability assessment scoped only to the assets a company remembers to list isn't wrong, it's just answering a narrower question than most people assume it's answering. A clean report on ten known assets says nothing about the forty forgotten subdomains, three abandoned campaign sites, and one still-live subsidiary website that never made it onto the list in the first place. This is exactly why the scoping conversation at the start of a proper engagement matters as much as the testing itself, agreeing on which assets are actually being tested, and being explicit about what's being left out, rather than letting an incomplete inventory silently define the boundaries of what gets checked.
A core vulnerability assessment covering up to ten internet-facing assets in a single engagement only delivers real value if those ten are actually the highest-priority ones, which requires the discovery step above to happen before scoping, not as an afterthought during it. For organizations whose actual footprint turns out to be larger, multiple subsidiaries, several campaign properties, a long tail of forgotten subdomains, that's exactly the case for scoping a broader engagement rather than assuming the main website represents the whole picture.
Why this isn't a one-time exercise either
Attack surface doesn't hold still. New campaign microsites launch every quarter. New subdomains get spun up for new projects. New third-party services get connected under a company subdomain as vendor relationships change. An asset inventory built once and never revisited degrades the same way an annual-only assessment does, accurate on the day it was built and progressively less accurate every month after. Pairing a recurring inventory review with a recurring quarterly assessment cadence is what keeps scope current instead of letting it quietly drift out of sync with what the company is actually running.
Where to start
If you've never done this exercise, assume your actual attack surface is meaningfully larger than what's in your head right now, the data above suggests it almost certainly is. Before scoping your next audit, whether that's a vulnerability assessment against your core assets or a deeper penetration test across a more complex environment, take the inventory step seriously first. An assessment is only as complete as the list of what it was asked to test, and the assets nobody thought to include are, reliably, the ones with the least oversight and the most exposure sitting untested behind them.
