How do security and IT teams decide whether software asset management should sit with operations, procurement, or governance?

The right model is shared accountability with clear ownership. Operations usually handles discovery and usage data, procurement manages contracts and renewals, and governance sets policy, controls, and reporting standards. When these functions work separately without a common process, asset data fragments and compliance decisions weaken. A coordinated model gives teams one view of entitlement, usage, and risk.

Why This Matters for Security Teams

software asset management looks like a tooling question, but it quickly becomes a control-ownership question when security incidents, audits, and renewals depend on the same data. If operations, procurement, and governance each keep a partial record, the organisation can end up with overlapping licenses, unknown software sprawl, and weak accountability for risk decisions. The right operating model is less about who “owns” everything and more about who owns each decision point.

That distinction matters because modern asset oversight is tied to exposure, compliance, and identity. NIST’s Cybersecurity Framework 2.0 treats governance, identification, and monitoring as connected functions, not isolated tasks. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs makes the same point in the identity context: lifecycle control fails when no single process connects discovery, approval, and retirement.

For security and IT teams, the real issue is that software assets behave like living dependencies, not static inventory records. In practice, many teams discover ownership gaps only after a renewal, audit finding, or exposed secret has already made the problem visible.

How It Works in Practice

A workable model assigns different accountability by decision type. Operations should own discovery, installed base data, usage telemetry, and day-to-day reconciliation. Procurement should own vendor records, contract terms, renewals, and commercial exceptions. Governance should own policy, reporting standards, control thresholds, and escalation rules. This split prevents duplicate effort while preserving a single source of truth for each business decision.

The implementation challenge is coordination. Asset data has to flow between systems, not sit in separate spreadsheets or ticket queues. That usually means standardising identifiers, defining mandatory fields, and enforcing review points at onboarding, renewal, and offboarding. NIST SP 800-53 Rev. 5 is useful here because it reinforces inventory, configuration, and accountability controls that support shared oversight. For NHI-heavy environments, the same logic appears in the NHI Lifecycle Management Guide: discovery is not enough unless it connects to ownership and decommissioning.

• Operations validates what is actually deployed and in use.
• Procurement validates what is contractually approved and financially committed.
• Governance validates whether usage meets policy and risk appetite.
• All three share escalation for exceptions, shadow IT, and renewal disputes.

This model works best when there is a named control owner for the process and named data owners for the records, because asset management fails when “everyone is responsible” but nobody can approve a change. These controls tend to break down in decentralised environments with frequent tool sprawl and weak integration between procurement and endpoint or SaaS discovery systems.

Common Variations and Edge Cases

Tighter ownership often increases administrative overhead, so organisations have to balance control quality against speed and usability. The right design depends on whether the primary risk is compliance drift, budget leakage, or security exposure.

Best practice is evolving for highly distributed software estates. In smaller teams, procurement may act as the process coordinator if operations is thinly staffed. In highly regulated environments, governance often becomes the final approver for policy exceptions and exception reporting. For SaaS-heavy or identity-heavy estates, some organisations elevate security to define the control framework, while leaving procurement and operations to execute it. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a useful analogue: auditability depends on clear accountability, even when operational tasks are shared.

The key edge case is shadow IT or untracked subscriptions, where procurement never sees the purchase and governance never sees the risk. In those environments, the control model should prioritise discovery and exception reporting before trying to perfect approval workflows. Security teams should also watch for NHI-linked software assets such as API-enabled tools or integrations, because credential exposure and ownership ambiguity often travel together. NHIMG has documented this pattern repeatedly in incidents like JetBrains GitHub plugin token exposure and the Hard-Coded Secrets in VSCode Extensions.

Related resources from NHI Mgmt Group

• How should teams decide whether AI procurement belongs in security governance review?
• How should security teams use IAST and RASP in NHI governance?
• How should security teams connect IT asset management to identity governance?
• How do teams decide whether ITAM should sit inside IAM governance?