What belongs in a technical asset inventory?
A technical asset inventory records what was observed, where the evidence came from and what remains unverified. It may include domains, hostnames, configured DNS records, IP addresses, applications and responsible owners. Those fields are not interchangeable: a DNS record is configuration evidence, not proof of an available web service or of organizational ownership.
For example, a passive tool may report portal.example.com while a DNS zone export contains portal.example.com A 192.0.2.40. These are two distinct observations. The workspace records a bare hostname as DISCOVERED instead of inventing an address record.
Each stage can add evidence. None should be silently inferred from another.
Evidence types and limits
| Evidence | What it establishes | What it does not establish |
|---|---|---|
| Authoritative-zone export | Records configured in the exported zone view | That all records resolve publicly or their destinations work |
| Passive hostname sighting | A hostname appeared in a named data source | That it currently resolves, belongs to the organization or is reachable |
| Historical snapshot | An observation existed in a supplied earlier dataset | Why it changed or whether collection conditions were comparable |
| Authorized service check | A response was observed at a time and vantage point | Permanent availability or ownership |
| Internal ownership register | A named team or service is responsible under that register | That internet-facing configuration still matches the register |
Keep the evidence type visible in your result. Otherwise, a spreadsheet full of names can create false confidence.
Scope before collection
Record the base domains and the authority under which evidence was obtained. notexample.com is not a child of example.com; scope should match the exact base domain or a subdomain boundary. Internal and external DNS views may differ. Names observed via third-party data can also belong to unrelated organizations.
When importing several files, choose the same intended scope and comparable collection methods for both periods. Our scope and normalization rules explain how unsupported and out-of-scope input is handled.
Minimum fields for an actionable record
A useful operator inventory can contain:
| Field | Example | Why it matters |
|---|---|---|
| Hostname | portal.example.com | Identifies the observation |
| Evidence type/value | A / 192.0.2.40 | Prevents confusing a sighting with a DNS answer |
| Source and time | Zone export, collection timestamp | Allows the observation to be reproduced |
| Responsible owner | Team or application owner | Establishes who can validate changes |
| Status and decision | Unverified / expected / review | Makes follow-up possible |
The free workspace exports normalized hostname, type, value and source filenames. It does not invent owners, confidence scores, collection timestamps or external verification. Add those details in the change-review worksheet alongside the original exports.
Next step
If you have one collection, generate a current inventory. If you have two comparable collections, use the worked before-and-after comparison. Treat a missing row as an absence in the supplied evidence, not proof that an asset ceased to exist.