Software Asset Management (SAM)
1. Overview
Definition: Software Asset Management (SAM) is a management system that identifies the entire lifecycle of software assets an organization holds and uses — acquisition, deployment, maintenance, utilization, and retirement — and continuously reconciles entitlements (rights held) against actual installation and usage (the real state), so as to control legal compliance, cost optimization, and security risk at the same time. The essence of SAM is to keep the organization always aware of "what, how much, and under which rights" software is being used, and internationally the ISO/IEC 19770 family of standards defines its processes and data model.
Software has no physical substance and copies freely, so the boundary of "ownership" is blurred. What is purchased is not the software itself but the right to use it (a license), and that right is bound to contractual conditions such as number of users, number of CPU cores, or number of concurrent connections. Yet installation takes only a few clicks, instances scale up and down constantly through virtualization and the cloud, and each department brings in software on its own. As a result, an organization easily falls into a state where it does not even know what it is using, how much, or whether it legitimately holds the matching rights. SAM emerged precisely as the management activity that seeks to make this "invisible asset" visible.
This opacity is not merely an inconvenience; it returns to the organization as real loss. A single audit can produce a settlement bill that exceeds the budget; conversely, maintenance fees drain away every year on licenses no one uses; and software absent from the inventory becomes an entry point for security incidents. All three losses stem from a single root — "not knowing what one holds and how it is used" — so a systematic activity to secure that visibility becomes a common demand of the finance, legal, and security functions alike.
Three pressures lie behind the need for SAM. The first is compliance pressure. Software vendors conduct license audits periodically, and if under-licensing is detected, the retroactive settlement amount is topped with fines and penalties, leading to an unexpectedly large bill. Piracy-reporting schemes run by bodies such as the BSA (Software Alliance) are an ever-present risk too. The second is cost pressure. Conversely, over-licensing — holding licenses that are not actually used — wastes maintenance fees (typically 15–25% per year) year after year. Trimming both under- and over-licensing to "exactly as much as needed" is the heart of cost optimization. The third is security pressure. Unauthorized software absent from the inventory (shadow IT) and end-of-life (EOL) old versions become breeding grounds for unpatched vulnerabilities, so asset visibility is a precondition for attack-surface management.
In particular, the spread of generative AI and large-scale services is again reshaping the structure of software spending. As AI-platform subscriptions tied to GPU usage, token- and API-call-based charging, and copilot-style tools with surging usage proliferate, the share of consumption-based "pay as you use" cost in an organization's IT budget is growing rapidly. Asset management centered on traditional perpetual licenses alone cannot control this volatility, so SAM's focus is shifting from "how many were installed" to "what is consumed and how much." This current is the fundamental driver accelerating the convergence of SAM and FinOps.
The nature of software assets is the intrinsic characteristic that determines SAM's difficulty. First, intangibility means they cannot be managed by "counting" like physical assets and must be measured indirectly through discovery tools. Second, ease of duplication makes install counts easy to grow without control, and the moment a single installation medium is deployed to thousands of machines, license violations can occur en masse. Third, conditionality of rights: what is purchased is not a product but a right to use under specific conditions (edition, version, user, region, purpose), so even the same installed copy may be lawful or unlawful depending on the contract terms. Fourth, dynamic variability: with virtualization and auto-scaling, instances are created and destroyed by the minute, so continuous tracking is required rather than a point-in-time snapshot. These four traits inevitably make an always-on reconciliation system, not a "count once and done" exercise.
From the perspective of a Professional Engineer of Information Management, SAM is not mere license accounting but an operational discipline linking IT governance, ITSM, and information security. ISO/IEC 19770-1 defines SAM as a management system aligned with ISO/IEC 20000 (ITSM) and 27001 (information security), and recently, with the spread of the cloud and SaaS, its scope is converging with ITAM (IT Asset Management) and FinOps. Below, we address SAM's components and processes, license measurement models, comparisons and cases, recent trends, and implications from the Professional Engineer's perspective in turn.
2. SAM's Conceptual Structure and Components
A SAM system runs with three layers interlocking: data (what is held and how it is used) → process (lifecycle management) → governance (policy, organization, roles). At the bottom sit discovery/inventory that collects the installation state, license entitlement that organizes the rights held, and a reconciliation engine that compares the two; above them run the procurement, deployment, and reclaim processes; and at the top, policy and an accountability structure (governance) control the whole.
graph TD
POL["SAM policy/governance<br/>(policy, org, roles, KPIs)"] --> PROC["SAM process<br/>(acquire→deploy→use→reclaim→retire)"]
PROC --> DISC["① Discovery/inventory<br/>(install/usage state)"]
PROC --> ENT["② Entitlement<br/>(contracts, license rights)"]
DISC --> REC["③ License position reconciliation<br/>(ELP: held vs used)"]
ENT --> REC
REC --> OPT["④ Optimize/remediate<br/>(reharvest, reclaim, extra purchase)"]
OPT -. feedback .-> PROC
SWID["SWID tag(19770-2)"] -.identify.-> DISC
ENTS["ENT schema(19770-3)"] -.rights.-> ENT
RUM["RUM(19770-4)"] -.usage.-> DISC
Among the three layers, the governance layer is most often overlooked, but in reality it determines success or failure. However sophisticated the discovery tool, if policies such as "no installation of unauthorized software," "procurement must go through a central window," and "mandatory quarterly reconciliation" are not effectively enforced, the data quickly diverges from reality. The governance layer not only sets policy but also defines the roles (RACI) of the SAM manager, procurement, security, and the business units, measures performance through KPIs such as compliance rate and savings, and turns executive sponsorship into a compliance incentive across the organization. In short, SAM becomes sustainable only when the data and process below are controlled by the governance above.
The core of this structure diagram is the cycle that continuously reconciles what is held (rights) and what is used (the real state) to produce the Effective License Position (ELP) and feeds the result back into the process. If the ELP is positive (+), surplus licenses are reclaimed and redeployed; if negative (−), the gap is filled by purchasing more or reducing usage. When this cycle breaks, SAM degenerates into a one-off audit.
The expected benefits SAM brings to an organization sort into three axes. The first is the financial benefit: reclaiming and redeploying over-licenses, cutting maintenance fees, and strengthening negotiating power reduce direct cost. The second is the risk benefit: it preemptively lowers the audit-penalty and litigation risk of under-licensing and the security risk of EOL and shadow software. The third is the operational benefit: accurate asset data becomes the basis for budgeting, capacity planning, and technology standardization, raising the quality of IT decisions. These three benefits interlock, so securing visibility creates a virtuous cycle that improves cost, risk, and operations at once. To prove the benefits in numbers, however, KPIs such as ELP, savings, and reclaim rate must be defined and tracked from the start.
Unpacking the components a little further: discovery/inventory collects, through agents or network scans, the software installed on enterprise endpoints, servers, and virtual machines along with its version, edition, and usage frequency. Here the SWID tag of ISO/IEC 19770-2 (a standard metadata file in which the software describes itself) is important, providing product name, version, and publisher in a standard format so that "exactly which product this executable is" can be identified without ambiguity. Entitlement digitizes purchase contracts, orders, and license certificates to organize "under what conditions and how many rights we hold," and the ENT (entitlement) schema of 19770-3 provides its data standard. The reconciliation engine pits the installation state against the rights, product by product and metric by metric, to compute the ELP. Here the RUM (Resource Utilization Measurement) of 19770-4 measures charging-basis values such as cores, users, and concurrency in a standard way, raising reconciliation accuracy.
The hardest practical problem in this reconciliation process is normalization. Discovery spews out raw install names that vary wildly, such as "Acme DB Server 19c Enterprise (x64)," and comparison becomes possible only once these are accurately mapped to the standard product names and editions on the entitlement side. Mapping a single product name wrong can count a right you actually hold as a violation, or the reverse, collapsing the credibility of the entire reconciliation result. The more SWID tags spread, the more this mapping is standardized, but in reality it still depends heavily on the tool's product catalog and human verification. Thus, data-quality management and the ongoing upkeep of normalization rules become a hidden core capability of SAM operation.
Summarizing the role of these components and their corresponding standards gives the following. The table is merely an aid to distinction, however; in reality the data references one another and integrates into a single asset knowledge base.
| Component | Core question | Main data | Corresponding standard |
|---|---|---|---|
| Discovery/inventory | What is installed/used | Product, version, usage frequency | ISO/IEC 19770-2 (SWID) |
| Entitlement | Which rights are held | Contract, quantity, metric | ISO/IEC 19770-3 (ENT) |
| Usage measurement | How much is used (cores, users) | Resource consumption | ISO/IEC 19770-4 (RUM) |
| Reconcile/optimize | How large is the gap | ELP, compliance state | ISO/IEC 19770-1 (process) |
For example, if a manufacturer discovers 1,000 installations of a design tool but holds entitlement for only 700, the ELP is −300, an under-licensed state. If RUM then confirms that "the users who actually ran it at least once a month number 650," the organization can, instead of buying all 300 more, reclaim and redeploy the 350 idle ones to match the real demand of 650 and reinforce only part of the shortfall.
What must be especially guarded against here is shadow IT (unauthorized software). When a business unit installs free, trial, or personally purchased copies at will without going through central procurement, they are caught by the inventory but have no basis in the entitlement and are immediately deemed violations in an audit. The bigger problem is that such software falls outside the scope of security patches and support and remains a vulnerability. Therefore SAM's data layer must function not as a mere list but as an asset knowledge base that classifies every discovered installation as "approved and rights-held / approved but rights-short / unauthorized" and prioritizes action accordingly. Only when this classification is shared with ITSM's configuration management (CMDB) and security's vulnerability management does asset visibility convert into control power across the whole organization.
3. The SAM Lifecycle and Core Processes
SAM runs along the lifecycle of a software asset — acquire → deploy/install → operate/use → reclaim/redeploy → retire — with policy verification and record updates accompanying each stage. This flow is not built once and done; it repeats continuously through regular quarterly or semi-annual reconciliation and vendor-audit response.
flowchart LR
A["Acquire (Request/Acquire)<br/>demand check, contract, register rights"] --> B["Deploy/install (Deploy)<br/>install only approved SW"]
B --> C["Operate/use (Operate)<br/>usage monitoring"]
C --> D["Reconcile/optimize (Reconcile)<br/>compute ELP, remediate"]
D --> E["Reclaim/redeploy (Reclaim)<br/>harvest idle licenses"]
E --> F["Retire (Retire)<br/>terminate rights, retain records"]
E -. redeploy .-> B
D -. extra purchase .-> A
C -. audit response .-> D
The level of SAM is not completed at a stroke but develops through maturity stages. Early on it stays at a reactive level that barely grasps "what we have now" through periodic manual audits; once automatic discovery and contract digitization are in place, it rises to a proactive level where always-on reconciliation is possible; and finally it reaches an optimized level that strategically links demand forecasting, automatic optimization, and procurement negotiation. If a low-maturity organization introduces expensive tools first, data quality cannot support them and the return on investment fails to materialize, so a staged roadmap that raises process, data, and governance together is desirable.
In the acquisition stage, software requests from the business are received centrally to block duplicate purchases and shadow IT. If idle licenses are already held, they are redeployed instead of buying new; if a purchase is truly needed, optimal terms such as volume discounts or subscription conversion are negotiated, and then the rights are immediately registered in the entitlement repository. When registration is omitted, an accident commonly occurs later where "the right exists but there is no evidence," so an audit misjudges it as under-licensing.
Another benefit of the acquisition stage is negotiating leverage. Aggregating enterprise-wide demand and buying in bulk can secure volume discounts, and presenting ahead of renewal, on the basis of utilization data, that "only 60% of seats are actually used" can drive quantity reductions or unit-price cuts. This economy of scale and data-based negotiation, unobtainable through scattered purchasing, is the direct financial benefit of SAM's procurement consolidation.
The core discipline of the deployment/operation stage is to control installation so that only "approved software, in approved quantities" is installed, and after installation to monitor actual usage frequency. A license not run even once in 90 days is classified as idle and made a reclaim candidate. This usage-based visibility is the source of cost optimization. For instance, expensive professional design tools or BI tools commonly have users who "were allocated but barely use it," so downgrading from a higher to a lower edition or reclaiming seats on the basis of usage yields immediate cost savings.
In the reconcile/reclaim/retire stage, the installation state is pitted against the rights to compute the ELP; shortfalls are reinforced and surpluses reclaimed. Reclaimed licenses are not retired but put into a redeployment pool and reused for the next demand, curbing new purchases. When a device is retired or an employee leaves, the installation is removed and the right is returned, while contracts and evidence are retained for the statutory period in preparation for audits. When this lifecycle interlocks with ITSM's change and configuration management (CMDB), asset changes are recorded in real time and the freshness of reconciliation is maintained.
Vendor-audit response is the real-world arena that tests the maturity of a SAM process. Large vendors place an audit clause in the contract and give notice of a license inspection every few years; at that point, an organization that has routinely managed its ELP seizes the negotiating initiative with its own figures, whereas one that is unprepared accepts the results of the vendor-supplied script as is and is exposed to unfavorable interpretations (full-capacity, maximum-install-count basis). In practice the standard move is, immediately upon audit notice, to run an internal reconciliation first to grasp the gap oneself and to use the scope of voluntary true-up as a negotiating card. For example, in one financial-sector case, the license boundary of a database virtualization cluster had not been isolated in advance, so during the audit the organization faced a threat of additional billing in the tens of billions of won on a full-host basis, which it then largely mitigated through retroactive architectural isolation and negotiation — an instructive case showing that SAM should have been reflected from the design stage rather than after the fact.
4. License Measurement Models and Comparison
SAM's difficulty ultimately arises from the diversity of license metrics (charging bases). Even for the same product, the charging unit differs by vendor and contract — per device, per user, per core, per concurrent connection — so counting them accurately itself demands a high level of expertise. The table below organizes representative metrics, but why each model is designed the way it is and what traps it holds are explained in the prose that follows.
| Metric | Charging basis | Suitable situation | Caution |
|---|---|---|---|
| Per Device | Number of installed devices | One device per person | Instance explosion under virtualization |
| Named User | Number of designated users | Multi-device users | Missed seat reclaim for leavers |
| Concurrent | Peak simultaneous connections | Intermittent shared tools | Peak-measurement accuracy |
| Per core/processor | Number of physical/virtual cores | Server SW (DB, etc.) | Core factor, sub-capacity |
| Subscription | Term, usage | SaaS, cloud | Accumulation of unused seats |
Core/processor-based licensing is the thorniest in server software, especially databases. Each vendor counts cores differently: Oracle, for instance, computes by multiplying the number of processor cores by a Core Factor that varies by CPU type, while IBM charges in PVU (Processor Value Unit) units and, to gain sub-capacity (partial-capacity) recognition in a virtual environment, mandates the installation and measurement of the ILMT (IBM License Metric Tool). Not knowing these rules and leaving an environment where virtual machines roam freely unattended can, at audit time, turn into a full-capacity demand to "license on the basis of all physical cores," bringing additional billing in the hundreds of millions of won. This is precisely a representative case where SAM expertise translates directly into cost.
Because of this complexity, in server-software licensing a design that closes the gap between "the technically possible maximum" and "actual use" becomes cost itself. For example, when licensing a database cluster made of two 24-core servers on a core basis, if the core factor is 0.5 it ends at 48 cores × 0.5 = 24 licenses, but applying the factor wrong or targeting the whole virtual environment leads to overspending by several times the demand or, conversely, to a serious violation. A misunderstanding of a single digit can split hundreds of millions of won, so accurate metric calculation remains a core area of SAM expertise.
Virtualization and the cloud fundamentally shake metric calculation. A virtual machine can move between hosts (via vMotion and the like), so the boundary of "on which physical cores this software can run" blurs, and vendors often apply a conservative interpretation that "all hosts it can move to must be licensed." Therefore an architecture design that physically isolates the license-target cluster (pinning affinity) becomes central to cost control. This shows that SAM is not mere clerical administration but a technical activity interlocked with infrastructure design.
The change in the license-procurement model itself also warrants comparison. The old perpetual license is a capital-expenditure (CAPEX) structure where one buys up front, uses it forever, and pays only maintenance fees annually, characterized by under-licensing risk and a large up-front-investment burden. By contrast, a subscription is an operating-expenditure (OPEX) structure where cost is paid according to term, seats, and usage; the up-front burden and under-licensing risk are low, but if unused seats accumulate, total cost of ownership (TCO) can actually exceed that of a perpetual license. Add the cloud's consumption-based charging and cost links to usage in real time, lowering predictability further. Thus SAM is not a matter of choosing a single model but takes on the character of portfolio management that combines the three models according to each product's usage pattern and continuously compares and adjusts their total cost.
The Named User and Concurrent models look like the same "number of users" charging but are entirely different in nature. Named User allocates a license to each designated individual, which favors users with multiple devices, but if seats are not reclaimed on departure or transfer, ghost seats pile up. Concurrent charges by "how many use it at most at the same time," which is economical for intermittently used shared tools (e.g., 100 people take turns but peak concurrent use is 20), but if peak measurement is inaccurate it leads to access denials or over-purchasing. The choice between the two models must be premised on usage-pattern analysis, and this is exactly the point where RUM and utilization data become weapons in negotiation.
Conversion to the subscription model (SaaS) reduces under-licensing risk but gives rise to a new problem of unused-seat waste. A perpetual license (CAPEX) is done once bought, but a subscription (OPEX) is charged every month even when unused, so utilization management that finds and cancels "seats that were allocated but never logged into" becomes a standing task. One global analysis cites a vendor report that systematic SaaS management cut spending by 20–35% in the first year; this should be taken conservatively as a marketing figure, but the direction itself — that "unused seats are substantial" — is widely confirmed in practice. In fact, many organizations run a procedure that automatically identifies and reclaims accounts with no login for 90 days through quarterly seat audits, which again shows that SAM is a continuous operational discipline, not one-off purchase management.
5. Deep Dive — Standards, Cloud Convergence, and Recent Trends
The ISO/IEC 19770 family of standards is SAM's international reference. Part 1 used to follow a maturity-tier approach, but the current ISO/IEC 19770-1:2017 is established as the requirements for an IT Asset Management management system (ITAM MS), sharing the same management-system framework (Plan-Do-Check-Act) as ISO/IEC 20000 (ITSM) and 27001 (information security). Part 2 (19770-2:2015, reconfirmed valid in 2021) defines the SWID tag by which software identifies itself, Part 3 (19770-3) the ENT schema describing rights held, Part 4 (19770-4) the RUM that measures usage in a standard way, and Part 5 (19770-5) terminology and overview. The more these data standards are in place, the more license-information exchange among vendors, customers, and tools is automated, reducing the manual burden of reconciliation. That said, SWID-tag adoption has been slow, so a reality that still relies on discovery heuristics coexists. The meaning of Part 1's reshaping into a management system is a call to view SAM as "a continuously operated system" rather than "a project." That is, by institutionalizing a PDCA cycle — setting policy and objectives (Plan), running the process (Do), checking through internal audit and reconciliation (Check), and remediating the gaps found to improve (Act) — an organization can operate SAM in an integrated way on the same operational rhythm as the ISO/IEC 20000 and 27001 certification frameworks.
The convergence of SAM, ITAM, SaaS management, and FinOps is the most prominent recent current. Traditional SAM focused on the compliance of on-premises perpetual licenses, but as consumption-based cloud spreads, the boundary with FinOps (cloud cost optimization) and its "pay as you use" is blurring. Forrester, Flexera, and others point to an integration toward a single Technology Business Management in which FinOps tools also encompass on-premises licenses and SAM expands into SaaS spend and shadow-SaaS governance. In practice, "usage-based optimization" is cited as the most effective approach, and tools that use AI/ML telemetry to track user activity and license utilization and automatically suggest downgrade and reclaim opportunities are increasing.
The SAM tool ecosystem is also developing fast. Specialized tools such as Flexera, ServiceNow (SAM Pro), and Snow Software integrate agent-based discovery, a knowledge library (PURL/product catalog) holding the license rules of hundreds of vendors, automatic calculation of virtualization and cloud metrics, and utilization analysis. Their core value lies in embedding the arcane per-vendor rules — "Oracle by core factor, IBM by PVU, Microsoft by core and CAL" — so that people do not have to calculate each one by hand. Still, a tool is not a panacea: judgment areas such as contract interpretation and negotiation remain the province of specialist staff, and the expectation that introducing a tool alone completes SAM should be guarded against.
The domestic and public-sector context is also worth noting. In Korea, copyright law attaches civil and criminal liability to the illegal copying of business software, and the public sector manages licenses within a procurement framework such as the maintenance-fee rate for commercial software (typically a fixed annual percentage of the purchase price) and the Multiple Award Schedule (MAS). As public-sector SaaS use grows with digital transformation, the importance of seat- and usage-based charge management is rising, and, as in the private sector, a current of linking the asset inventory with information-security (ISMS-P) checks to identify unauthorized and EOL software is spreading.
Linkage with security and the supply chain is also a deep-dive point. Since the asset inventory is a precondition for vulnerability management, linking SWID tags with an SBOM (Software Bill of Materials) makes it possible to track, from an asset perspective, "which component is installed where and exposed to which vulnerability (CVE)." As open-source use grows, the focus of license compliance is also expanding from commercial licenses to compliance with open-source license obligations (GPL copyleft, notice obligations, etc.). In this way SAM is broadening its points of contact with security (vulnerabilities, supply chain) and development (OSS governance).
Ultimately, on the single foundation of asset visibility, compliance, cost, security, and the supply chain are managed together, and SAM is evolving into a common data hub that links them. From this viewpoint, SAM should be redefined not as a collection of individual license-management techniques but as a foundational capability for strategically operating software — a core resource — in the age of digital transformation.
6. Considerations and Implications
From the Professional Engineer's perspective, SAM should be understood, beyond a cost-cutting tool, as a governance discipline that places software — an intangible asset — under the organization's control. The following should be considered comprehensively when adopting and operating it.
Data freshness decides success or failure: SAM stands on the data quality of "accurate inventory and entitlement," and unless this interlocks with ITSM's change and configuration management (CMDB) and is updated in real time, reconciliation results quickly go stale and lose trust. Investing up front in automatic discovery and contract digitization, and clarifying data ownership and update responsibility, comes first.
The trade-off between compliance and optimization: Under-licensing invites legal and financial risk (audit penalties), while over-licensing invites cost waste. Avoiding risk through excessively conservative over-purchasing loses cost efficiency, and excessive cost-cutting raises audit risk. On the basis of the ELP, the balance point of "minimizing cost within the tolerance for risk" must be managed quantitatively.
Consistency with the cloud-transition strategy: In virtualized and SaaS environments, license rules link directly to architecture design (cluster isolation, instance placement), so treating SAM as after-the-fact management separate from the infrastructure and cloud-transition plan will fail at cost control. SAM specialists should be involved from the design stage, and operation should be integrated with FinOps and the tagging scheme.
Institutionalizing governance, organization, and roles: SAM is not completed by tools alone; it needs governance involving the SAM manager (owner), procurement, security, and business units, and the effective enforcement of policies such as "no unauthorized installation." Roles and KPIs (compliance rate, savings, reclaim rate) must be defined and executive sponsorship secured for it to be sustainable.
Staged adoption and change management: SAM is not a one-time introduction of an expensive tool but a maturity journey that raises data, process, and governance together. A roadmap through the reactive → proactive → optimized stages should be set, and change management and education that draw out the behavioral change of "following the approval procedure" in the business must accompany it for the investment to pay off.
Outlook and related technologies: SAM is expected to converge with ITAM, SaaS management, and FinOps and to advance through AI-based usage analysis and automatic optimization. Broadening its reach into SBOM and vulnerability management (security) and open-source governance (development), it will establish itself, beyond simple cost control, as a discipline encompassing the finance, risk, and security of digital assets as a whole.
References
- ISO/IEC 19770 (Wikipedia overview): https://en.wikipedia.org/wiki/ISO/IEC_19770
- ISO/IEC 19770-2:2015 (SWID tags, ISO catalog): https://www.iso.org/standard/65666.html
- Forrester, The Convergence of Software Asset Management and SaaS Management: https://www.forrester.com/blogs/the-convergence-of-software-asset-management-and-saas-management/
- Flexera, Aligning FinOps with SaaS Management: https://www.flexera.com/blog/finops/how-does-your-organization-align-finops-with-saas-management/
In one line: Software Asset Management (SAM) is a management system that, across the entire lifecycle of software assets, continuously reconciles rights held (entitlement) against actual use (inventory) to produce the Effective License Position (ELP), thereby controlling compliance, cost, and security at once, and — taking ISO/IEC 19770 as its reference — is converging with ITAM and FinOps in the cloud and SaaS era.