Open a typical technology inventory and the first rows may look reassuring: product name, vendor, version, quantity, purchase date. Then ask a few operational questions.

Who can approve a change to this service? Which customer process stops if it fails? Where is the recovery procedure? What data does it expose to an external provider? Which contract must be canceled before renewal? Can an AI agent use its API to change records?

The spreadsheet suddenly becomes less reassuring.

Counting technology is useful, but a count cannot carry accountability. A decision-ready asset register connects each important piece of technology to its purpose, owners, dependencies, evidence, operating obligations, and next lifecycle decision. That is what lets leaders fund, secure, recover, modernize, or retire the estate without relying on organizational memory.

The practical starting point is not a perfect configuration management database. It is a minimum viable register that can answer real decisions and improve as evidence arrives.

Start with the questions the register must answer

A useful register is designed backward from recurring decisions. If no decision depends on a field, that field may not deserve attention yet. If a decision cannot be made from the register, an important field or relationship is missing.

This framing keeps the work grounded. Procurement may need renewal visibility. Security needs exposure and privilege information. Finance needs allocation. Operations needs support and recovery details. Product and business teams need to know which workflows depend on the asset. Architecture needs to see duplication and coupling.

Those are different views of the same estate, not reasons to build five unrelated lists.

Decide what deserves its own row

An asset register can collapse under its own ambition. At one extreme, it records only laptops and named applications. At the other, it tries to give every container, package, prompt, and temporary cloud object a manually maintained row.

A better unit is a decision-capable asset: something that can be independently funded, owned, operated, risk-accepted, recovered, or retired. The detailed components can remain in the systems that already manage them, with links from the register.

That usually brings the following into scope:

• business applications and departmental tools;
• SaaS subscriptions and externally hosted services;
• cloud accounts, projects, subscriptions, and material shared services;
• internally developed services and APIs;
• integrations that move data or trigger actions;
• data platforms and governed data products;
• end-user, server, network, operational, and connected-device estates;
• AI systems, models embedded in workflows, and agents with tools or permissions;
• outsourced operational services and support arrangements.

Not every dependency is another top-level asset. A production service might be one register entry linked to a repository, deployment inventory, component inventory, runbook, data catalog entry, and cloud cost view. The register provides the management context; specialist systems retain technical detail.

This separation matters. A register should not become a weak copy of an endpoint platform, cloud resource graph, software bill of materials, data catalog, model registry, or secrets manager. It should point to those sources and expose the relationships leaders need.

The NIST Cybersecurity Framework 2.0 supports this wider scope. Its asset-management outcomes cover hardware, software, services, systems, supplier-provided services, data and corresponding metadata, and lifecycle management. NIST’s implementation examples explicitly include cloud services, SaaS, APIs, containers, virtual machines, and externally hosted applications. Modern asset management is already broader than a device list.

Use a minimum viable technology register

The first version needs enough structure to support action, but not so many mandatory fields that teams avoid it. The following template is a workable core.

Keep credentials out of the register. Record the responsible identity, privilege level, and link to the approved secrets system, never the secret itself.

Separate business ownership from technical stewardship. A platform team may run a service without owning the business outcome. A department may sponsor a SaaS tool without being able to patch an integration. A security team may set minimum controls without becoming accountable for every workflow. One person can fill multiple roles in a small organization, but the responsibilities should still be named.

Decision authority also deserves its own field. “Owner” is often too vague. One person may approve spending, another may accept operational risk, and another may authorize a model or agent to act. If those rights differ, the register should show the difference rather than forcing false simplicity.

Discover from evidence before asking for declarations

Sending every department a blank template is fast, but it produces a list of what people remember and are willing to report. Discovery is stronger when it begins with evidence and uses interviews to resolve meaning.

Work through a bounded area, such as one customer journey, one business unit, or one critical service:

1. Define the boundary and the decision. State what is being mapped and why. A renewal review needs different depth from a recovery exercise.
2. Collect candidate records. Pull evidence from endpoint and network tools, cloud organization structures, identity and SSO catalogs, finance ledgers, procurement systems, expense data, license portals, repositories, deployment pipelines, API gateways, DNS and certificate records, service desks, data catalogs, model gateways, and vendor contracts.
3. Normalize without hiding disagreement. Match names, tenants, vendors, domains, accounts, and cost centers. Preserve uncertain matches as candidates instead of merging them prematurely.
4. Ask owners to confirm purpose and consequence. Evidence can show that a service exists. People still need to explain why it matters, who may change it, and what failure means.
5. Trace one important workflow end to end. Follow identity, data, integrations, external services, approval points, support, and recovery. This reveals dependencies that flat lists miss.
6. Assign a disposition. Confirm, restrict, remediate, replace, retire, or investigate. Discovery without a next action becomes another archive.

No single discovery source is complete. SSO logs miss applications that use local accounts. Finance sees payment but not free services, open-source software, or cloud resources hidden inside a broader bill. Network discovery misses offline dependencies and externally hosted workflows. Code repositories reveal integrations that may no longer run. Interviews miss forgotten automation.

Coverage comes from reconciliation.

CISA makes a related distinction in its asset visibility directive: visibility is not an end in itself; it enables configuration, lifecycle, and vulnerability work. The directive applies to United States federal civilian agencies, so its required cadence is not a universal rule. Its operating principle is still useful: measure how often discovery runs, what coverage it achieves, and how current the evidence is.

Treat uncertainty as data

Technology discovery often produces contested ownership. A department says IT owns an application because IT configured SSO. IT says the department owns it because the department selected the vendor. Procurement owns the contract but not the service outcome. The original sponsor has left. An integration is business-critical, yet nobody has authority to stop it.

Do not solve this by assigning the nearest name in the organization chart.

Use explicit evidence states:

• Observed: directly detected in an authoritative technical or commercial source.
• Confirmed: purpose and accountability verified by the relevant owner.
• Inferred: supported by evidence, but not yet confirmed.
• Disputed: teams disagree about ownership, scope, or status.
• Unknown: a required fact has no credible evidence yet.

Then give every disputed or unknown high-impact record a resolution owner and date. The owner of the resolution does not automatically become the owner of the asset.

This approach makes incompleteness visible without pretending that an incomplete register is useless. It also lets leaders distinguish two very different situations: “we have not verified this field” and “we verified that no accountable role currently exists.” The second is an operating-model problem, not a data-cleaning task.

Map dependencies in layers, not all at once

Attempting to map every technical relationship across the enterprise before making a decision can consume months. Flat inventories fail because they show no consequences; exhaustive maps fail because they become too expensive to maintain.

Use layers.

Start with the business service or workflow. Link the applications, data products, external services, integrations, identities, and infrastructure whose failure would materially affect it. Add the support team, recovery path, and authority boundary. Go deeper where impact, uncertainty, change frequency, or concentration risk justifies it.

For AI systems, register the operational system rather than only the model name. A useful entry may need to link the model provider, grounding data, prompts or policy versions, evaluation set, tool endpoints, agent identity, permissions, human approval point, monitoring, incident process, and stop mechanism. A model embedded in a SaaS product is still part of the organization’s technology dependency even when the vendor hides most implementation details.

NIST’s AI Risk Management Framework Playbook is specific on this point. Govern 1.6 recommends mechanisms to inventory AI systems, a defined maintainer, documented scope and attributes, and links to artifacts such as data dictionaries, source code, and incident plans. Govern 1.7 connects decommissioning to downstream dependencies and accountability. An AI inventory that records “approved chatbot” without its data, actors, tools, and lifecycle cannot support those outcomes.

This also explains why discovery should connect with architecture. The register identifies where a decision is needed; architecture clarifies boundaries and tradeoffs. The decision map in Why Modern AI Teams Need Architecture Decisions is a useful companion when one asset crosses teams, platforms, or risk domains.

Make maintenance part of normal change

A one-time cleanup creates a photograph. The estate continues moving.

Applications are purchased, cloud projects appear, teams create service accounts, vendors add AI features, APIs gain write access, models change, employees leave, contracts renew, and experiments quietly become operational. A quarterly request asking everyone to “update the spreadsheet” cannot carry that load by itself.

Connect updates to events that already occur:

• purchase, renewal, or expense approval;
• SSO application onboarding and privileged-access changes;
• creation of a cloud account, project, subscription, or production environment;
• first production deployment from a repository;
• publication of an API or data product;
• registration of a model, agent, or model-provider connection;
• incident, recovery test, major architecture change, or risk exception;
• owner transfer, team reorganization, and employee offboarding;
• replacement approval and decommission completion.

Automation should create evidence and candidate updates, not silently make business judgments. A cloud scanner can discover a project; it cannot determine the business owner or whether the workload is still valuable. A finance feed can expose a subscription; it cannot describe the recovery consequence. A model gateway can identify usage; it may not reveal AI embedded inside a vendor application.

Use risk-based review as a second line. High-impact, rapidly changing, externally exposed, or weakly evidenced assets need more attention than stable low-impact tools. The review should test the record against evidence, not merely refresh the date.

The operating model can stay federated. A central technology or governance function may own the schema, quality rules, shared tooling, and escalation process. Business and product teams own purpose and outcome. Platform teams maintain operational links. Security, privacy, finance, procurement, data, and architecture contribute the fields they can validate. Central visibility does not require central control of every decision.

This is closely related to governing shadow AI without killing useful work. Discovery should bring hidden technology into a path for evaluation and support, not turn every unregistered experiment into an automatic offense.

Measure whether the register can support action

The total number of rows is a weak success metric. A rising count may mean discovery improved, duplication grew, or stale records accumulated.

Measure decision readiness instead:

• percentage of critical services with confirmed business and technical ownership;
• percentage with tested recovery links and mapped high-impact dependencies;
• renewals due within the planning window that have a named decision owner;
• high-impact records with unknown, inferred, or disputed fields;
• stale records by risk tier and evidence source;
• discovered assets not connected to an approved business purpose;
• retired assets with remaining cost, identities, data, or integrations;
• material changes that updated the register through the normal workflow.

Every coverage measure needs a denominator. “Ninety percent inventoried” means little unless the organization can explain ninety percent of what: detected network assets, paid SaaS vendors, production cloud accounts, critical workflows, or registered AI systems. Report coverage by evidence source and business boundary until reconciliation is strong enough to support a broader claim.

These measures lead naturally into portfolio action. The related guide on retiring legacy systems before AI sprawl grows explains the next step once ownership and dependencies are visible. Discovery does not decide what to retire, but it makes that decision less dependent on guesswork.

A useful register changes the conversation

Technology asset management is not finished when every device has a serial number or every application has a vendor name. Those facts matter, but leadership decisions depend on a richer chain: this asset supports this outcome, these people hold these responsibilities, these systems and data depend on it, this evidence is current, and this decision is due next.

Start with one boundary and one decision. Create the minimum viable fields. Reconcile multiple evidence sources. Record uncertainty honestly. Trace the important dependencies. Attach updates to normal change. Measure whether the register helps teams act.

The result will never be perfectly complete. It can still be dependable enough to answer the questions that matter: what exists, why it exists, who can decide, what it depends on, what happens when it fails, what it costs to keep, and how it can leave safely.