License Registry Without a CMDB: Field Template and Update Rules

Purpose of the registry: order in licenses without a CMDB

A license registry is needed when there is no CMDB, it is not maintained, or its data is outdated. In that situation, licenses "live" in emails, contracts, with accounting, and in admins' heads. A license registry without a CMDB provides one clear source of truth: what was purchased, where it is used, and under what conditions.

Without a registry the risks are usually the same. You pay for software that is no longer used, or you don't notice a shortage of licenses until an audit. Renewals are missed because "it was somewhere in the calendar." Extra installations appear: an employee installs software on a second laptop, and the rule "one license per device" is not enforced. And at the worst possible moment — a request from security, audit, or management — you can't quickly answer who and why is using a specific product.

Agree in advance what you consider a license and record it in the registry. Typically this includes subscriptions (monthly or yearly), perpetual licenses, OEM licenses tied to hardware, CAL and server access rights, and also packages and license pools that are distributed as needed.

The minimal useful outcome of the registry is simple: in 2–3 minutes answer four questions about any software — who uses it, on which host or for which user, under what right (type and conditions), and until what date that right is valid. If you can do that, you can later improve accuracy and add automation.

What makes a registry workable: 4 simple principles

A working registry doesn't have to be pretty or "perfect." It must answer two questions on any day: how many rights do we have and what are they currently assigned to. If you build a license registry without a CMDB, discipline and consistent rules are more important than complex spreadsheets.

1) The 80/20 principle: start with the critical

First enter what carries the most risk and cost: office suites, OS, server products, VDI, CAD, antivirus, expensive subscriptions. In practice 10–20 items often cover 80% of the budget and almost all audit questions.

2) One source of truth

The registry should live in one place: one file or one list in the chosen system. Do not allow parallel copies "for security," "for procurement," and "for admins." If needed, create views and exports, but edits must be made only in the primary source.

3) Common definitions

Same words — same numbers. Fix simple definitions and use them in every disagreement: what counts as a "right," what counts as an "installation," who is a "user," what is a "host," how you count a pool and virtual machines. Otherwise one person counts by devices, another by people, and figures won't match in meetings.

4) Versioning and responsibility

Assign an owner of the registry (usually IT assets or IT operations) and someone who approves changes (for example, IT or procurement head). Every edit should leave a trace: date, who changed it, what changed and on what basis.

A practical goal: if an employee asks "how many licenses do we have and when is the renewal," you answer within 2 minutes and can show where the number came from.

Field template: the "Right" block (what was bought and under what conditions)

The "Right" block is the core of a registry entry. If it is filled in carefully, a license registry without a CMDB already answers the main question: what you have on paper and under what conditions it can be used.

Start with the formulation of the "level of right." Record not just the name, but a combination: product + edition/package + license type + metric. Otherwise in six months "Office" will turn into a dispute: is it Pro or Standard, subscription or perpetual, user-based or device-based.

To make records easy to verify against purchases and vendor emails, add identifiers: vendor and SKU/Part Number (if present on the invoice or order), contract number, order number or request number. This saves hours during audits and internal checks.

Finance fields depend on the situation but are often useful: cost, currency, cost center or department. Even if exact amounts are stored in accounting, the registry should include the cost center and purchase number.

Specify where the proof of right is stored: invoice, act, certificate, license letter, extract from a vendor account. It's important to record a specific storage location (for example, folder and file name) so the document can be found in a minute.

Minimal set of fields that usually suffices:

• Product, edition/package, license type, metric
• Vendor, SKU/Part Number, contract/order number
• Department (cost center), currency (and amount if needed)
• Document type and location of proof

Example entry: "Windows Server, Standard, perpetual, per core; Vendor: Microsoft; Part Number from invoice; contract No...; Cost Center: IT; proof: act + letter, stored in procurement folder."

Metric and counting rules: so everyone counts the same

When there's no CMDB, the biggest disagreements are not about "what was bought" but "how to count." So for each item fix the metric so two different people get the same result. This is especially important when you reconcile the registry with purchases and actual use.

Typical metrics look simple until they are mixed in one field: "per device," "per user," "per server," "per core/processor," "per instance/VM" or subscription "for a period" (month, year). A common mistake is describing the metric in comments and everyone interprets it differently.

Make the "Licensing Metric" a required field with strictly defined values (picklist). Next to it add "Unit of Account" (user, device, core, VM, server) and "Quantity per contract." Then the model becomes transparent: "how many were bought" plus "how many are assigned."

To avoid confusion about constraints, create a short "Restrictions" field and fill it in a consistent format. Usually note region/country of use, organization type (e.g., public, education), purpose (test, development, production), and transfer restrictions (if any).

If a metric is complex and depends on hardware, cluster, or a combination like "server + cores," don't try to pack it into a single name. Add a field "Counting rule (in plain words)" (for example: "count by physical server cores, do not count VMs separately") and a field "Source of rule" (document or contract clause) to avoid disputes during checks.

Assignment of a license: to a user, to a host, or to a pool

Even a tidy license registry without a CMDB quickly falls apart if you don't agree on one thing: what you attach the usage right to. Usually there are three options — to a user, to a specific device (host), or to a shared pool.

How to choose the assignment type

Assignment to a user fits when an employee can work from one or more devices and the license "follows" them. Assignment to a host is needed when the right is tightly tied to a PC or server (or you want to control installation by inventory data). A pool is useful for temporary tasks and floating licenses when it's important to know how many rights are free right now.

A practical rule:

• User — "license for a person": devices may change, owner is one person.
• Host — "license for hardware": inventory number and installation location matter.
• Pool — "license in stock": issued and returned by request.

Minimal fields to avoid disputes during checks

For user assignment it is enough to identify the person and their current status. Usually display name, a unique identifier (personnel number or stable HR system ID), department and status (active or dismissed) suffice. Status is important: it immediately shows that the license can be returned to the pool or reassigned.

For host assignment record data that doesn't change with renaming on the network: PC/server name (as seen by IT), inventory number, serial number and location (office, room, rack). This helps when a device moved to another branch or was replaced under warranty.

If a license is in a pool, don't leave the owner field empty. Mark status as "Available" and add an "Expected owner" field (for example, "new accountant, start 15.02" or "project team, March"). This prevents the pool from becoming a heap of unassigned rights.

Example: a designer left and their license was user-assigned. You change status to "dismissed," clear the owner, move the entry to "Available," and put the new employee in "Expected owner." In a minute it's clear that the right wasn't lost or left on an old laptop.

Dates and documents: how not to miss renewals and checks

When there is no CMDB, the registry often breaks not on the "right" but on small details: term expired, vendor email was lost, or purchase proof is searched for in chats. Therefore deadlines and documents must have simple, consistent rules.

Date fields that actually work

The minimal set of time fields should be the same for all license types: start date, end date, renewal period and "notify N days before." If the license is perpetual, end date stays empty or marked "perpetual," but support term (if any) should be tracked separately — as a separate field or a separate entry.

To know when to raise the issue, fix one rule: N days depends on procurement complexity. For example, standard subscriptions — 30 days; purchases through tender or long approvals — 60–90 days.

Add lifecycle statuses so delays don't look like incidents. A working scale: "purchased" (right exists but not assigned), "assigned" (has an assignment), "active" (in use), "suspended" (temporarily not used but right retained), "terminated" (term expired or right ended).

Documents: how to quickly prove a right

In the "Document" field indicate type and details: invoice, contract, act, certificate, confirmation letter, vendor account order number. It should be possible to quickly find the primary source from one registry line: "Contract No..., dated..., counterparty..."

Store files separately (in a secure folder or storage with access controls) and keep only identifiers and storage location in the registry. Put scans, letters and certificates there too. Do not write keys and tokens in the registry: note their existence and where they are stored, otherwise the registry becomes a leakage source.

Example: a 100-seat subscription expires June 30. The registry has "notify 60 days," status "active," and invoice and vendor letter references. In early May you already have a renewal task and during a check you can show references without searching old chats.

Step-by-step: how to build the registry in 1–2 weeks

A license registry without a CMDB can be assembled quickly if you don't try to document the whole world at once. Start with a clear scope: software purchased or renewed in the last 12–24 months plus what is already installed at workplaces and most likely to come up in checks.

1–2 week plan

Work in short iterations: first record rights, then assignments, and only then verify actual installations.

1. Gather sources: invoices, contracts, acts, license letters, exports from vendor accounts, and also a list of installed software (at least from OS inventory or manual checks of critical departments).

2. Create reference lists to avoid variant spellings: vendor, product, edition, department, metric type, record status.

3. Enter rights: what was bought, in what quantity, under what conditions and which documents support it. This is your "point of truth."

4. Add assignments: who or what the license is assigned to (user, host, server cluster, shared pool). Then reconcile with actual installations and note discrepancies.

5. Set up a basic routine: who updates the registry, how often it is reconciled, and which reports are reviewed weekly.

How not to drown in details

Keep an input order: one rights row per purchase or package, and maintain assignments separately (a second sheet or a separate table). If you bought 50 user subscriptions, the right is one row and there may be up to 50 assignment rows. This makes it easier to see the balance and reallocate.

At the finish add three control reports (even as simple filters):

• what expires in the next 60–90 days;
• where assigned exceeds purchased quantity;
• where there are installations without assignment (or vice versa).

The benefit appears immediately, without waiting for perfect accuracy.

Update rules: trigger events and reconciliation frequency

A registry breaks not because it lacks fields, but because people forget to update it. So agree in advance on two things: which events must trigger a change and how often you perform scheduled reconciliations even if "nothing changed."

Trigger events: what should be recorded immediately

The most reliable approach is to record changes the day they occur, not "when there's time." Usually four groups of triggers are enough.

Purchase or renewal: create the entry on the order/request date and then confirm it by invoice, act and closing documents. If contract documents differ, update the entry to reflect the facts.

HR changes: dismissal, transfer, long-term leave. This is a reason to remove assignment, reassign the license, or return it to the pool.

IT changes: issuance of a new PC, replacement of key components, OS reinstall, moving a user to another host. After such work check which licenses should "move" and which should cease to be valid on the old machine.

External checks: requests from procurement, security or an auditor. It is useful to record the check itself and the result (who reviewed and what was confirmed).

Reconciliation frequency: so errors don't accumulate

Scheduled checks catch silent discrepancies: a forgotten user, a missing document, a license lingering on an old host.

A practical regimen: weekly — quick edits for recent events; monthly — reconcile registry with procurement and HR changes; quarterly — mini-audit for critical products (expensive licenses and those frequently audited).

Example: an employee was transferred to another department and given a new PC. On the same day you remove the assignment from the old machine, move the assignment to the new one, verify the metric (by user or by device) and attach the basis: request, handover act, transfer order. This keeps the registry alive rather than an annual archive.

Common mistakes and how to avoid them

A license registry without a CMDB usually breaks due to small inaccuracies that accumulate. As a result numbers don't match and it's hard to prove rights during checks.

A common problem is mixing metrics in one row without clarification. For example, one entry shows "10 users / 10 devices" or lists "16 cores" and "1 server" together. In a month no one remembers how to count consumption. The fix is simple: one row — one metric and one counting rule. If details are needed, put them in separate fields.

Second pain: storing only keys and serial numbers without documents. A key proves activation but not the right. You need contract numbers, invoices, acts, transfer letters and terms (period, territory, permitted use). If documents are missing, create a "document basis" field and a status "awaiting confirmation" so such records don't count as confirmed balance.

Third mistake: assigning to user names ("Ivanov I.I.") without a unique identifier. People leave, change names, or share surnames. Better keep a personnel number or stable HR ID and use the name only as display. For hosts likewise: not just "PC-OLGA," but an inventory or serial number.

Fourth mistake: no statuses and dates, causing double counting. For example, an entry "bought 50" and entries "issued 50" later sum to 100. You need statuses (e.g., "in pool," "assigned," "expired," "written off," "for review") and dates: purchase, start, end, assignment date, return date.

Quick way to find these problems:

• ensure each row has exactly one metric and a clear counting rule;
• check that each purchase has a document basis or an explicit status "no proof";
• sample 10 assignments: does each user have a unique ID and each device an inventory mark;
• verify statuses and dates: "purchase" and "assignment" should not be counted as two separate rights;
• find duplicates by key fields (product, version, metric, contract, period) and determine the main record.

Fixing these immediately turns the registry from a "list of keys" into a working source of truth for renewals and checks.

Quick registry check: a 10-minute checklist

If multiple people maintain the registry it drifts in the details. This short check helps quickly understand whether you can trust the numbers and dates in a license registry without a CMDB.

10 minutes: what to check

Answer yes/no for each item. If "no" anywhere, mark the row and return to it later.

• Each license has basic fields filled: product (and edition), license type, metric, quantity, document number and date (invoice, contract, act, certificate).
• Each assignment has a clear binding: user or host, assignment date, and current status (active, removed, reserved).
• Dates are under control: there is an end date or next payment date, and a separate report for the coming 30–60–90 days.
• Totals reconcile: "rights" minus "assigned" plus "pool available" equals the balance without unexplained gaps.
• No obvious duplicates: the same key/serial doesn't appear twice and identical products aren't spread under different names.

A small example: you bought 120 seats for product X. Assigned 95 (to users), pool available 25. If the registry shows 120 - 95 - 20 = 5, five licenses are "lost": an assignment was missed, the pool count is wrong, or the purchase quantity is recorded incorrectly.

If you find a gap, don't try to fix everything at once. First make minimal edits to make the registry reconcile: unify names and metric, restore the link "document -> quantity -> assignments," mark disputed rows as "requires review" and assign an owner.

Practical example: a registry for a 200-seat organization

Imagine a school or clinic: about 200 PCs in offices, reception and classrooms, plus several servers with critical applications. There's no CMDB, but a license registry in a simple spreadsheet works well if rules are agreed in advance.

It's convenient to split accounting into three categories:

• Office suite — track by user (account/ID) because people change workstations.
• Antivirus — track by host (inventory/serial) because protection is installed on specific machines.
• Server licenses — track by server and role (OS, DBMS, access), one row per server.

Decide what you keep in a pool. For example, keep 10–15 office licenses as reserve for new hires and short-term projects. Antivirus pool is usually unnecessary since it's device-tied.

To keep things consistent, lock a few key registry fields: "Right/edition", "Metric", "Assignment (user/host/pool)", "Validity", "Document".

Monthly reconciliation takes 20–30 minutes with responsible parties: HR provides personnel changes, IT records issuance/retirement of PCs and server changes, procurement confirms upcoming renewals and document locations, and the registry owner logs changes and flags disputed rows.

Next steps: evolve the registry and prepare for growth

Once the registry is built, the main challenge is preventing it from becoming outdated. You need a process owner (often IT manager or procurement) and a short regimen: who makes changes, in what timeframe, and which documents provide the data.

Develop the registry gradually without complexity. Four things help most: record installation source and evidence, produce department reports, keep change history (date, who changed what and why), and maintain a separate "risks" list (unclear metric, missing document, disputed assignment).

If a CMDB or SAM tool appears later, you won't want to rewrite data. Therefore use stable identifiers now: personnel number, PC/server inventory number, unified department directory, and for licenses one naming and version format.

A good moment to reconcile the registry is during hardware refresh: when replacing workstations you can update inventory numbers, verify assignments and close document gaps. If you plan infrastructure modernization and want to link equipment delivery, commissioning and ongoing support into one process, discuss it with GSE.kz as manufacturer and system integrator.

The goal is simple: the registry should survive company growth and IT changes without an annual manual "heroic" effort.