Software Asset Register: Licenses, Owners, Vendors, and Renewal Evidence

A software asset register should track six things for every licensed or installed application: identity (name, category, version), vendor, owner (who is responsible for it), license (type and status), renewal date, and safe key handling (whether a key exists and a masked hint — never the full key). Get those right and a scattered set of licenses becomes a record you can answer questions from: what do we run, who owns it, what does it cost to renew, and is it still in use?

This is the software companion to what an IT assets register is and the hardware field guide. It is deliberately manual-first: a record you keep, not a tool that watches your software. It records license context — it does not measure SaaS usage, detect waste, or guarantee compliance.

What to Track in a Software Asset Register

The short version before the detail: track enough to identify the software, know who is responsible for it, what license it has and its status, when it renews, and whether a key exists without storing the key itself. Everything below maps to fields CertPilot's Assets Register holds today, so the list is grounded in a real register.

| Field group | Example fields | Why it matters | Review use | |---|---|---|---| | Identity | Software name, category, version | Distinguishes one product from another | Find a product; confirm the right edition | | Vendor | Vendor name | Ties the record to who you buy from and renew with | Vendor queries; renewal contact | | Owner & custody | Assigned person, linked hardware | Answers "who is responsible?" and "where does it run?" | Offboarding; reassignment | | License | License type, license status | Captures what you hold and whether it is current | Spot expired or unassigned licenses | | Renewal & purchase | Renewal date, purchase date, invoice reference | Makes cost and timing traceable | Renewal planning; finance queries | | Key safety | key_present, masked key_hint | Confirms a key exists without exposing it | Verify a license is recoverable |

Why Software Evidence Gets Messy

Software records decay for reasons hardware records do not. Licenses are bought by whoever needs the tool, often on a card, and the details land in an inbox rather than a list. Versions change silently. A subscription auto-renews because nobody owned the decision. A seat is freed when someone leaves but never reassigned. The result is the familiar state where the company is plainly paying for software, but no single list says what, for whom, or until when.

The fix is not to watch every install — it is one owned record where adding a license takes a minute and answers the questions that come up later.

Software Identity Fields to Track

Identity makes a record point at one product:

• Software name — the product, named one consistent way so duplicates don't creep in.
• Category — operating system, office, antivirus, design, development, SaaS, utility, or other. Categorizing is what lets you answer "show me all our design tools" without reading every row.
• Version — the edition or release you hold, which matters for support and for knowing whether a renewal is an upgrade.

Consistent naming is the unglamorous habit that keeps a software register usable: "Adobe Photoshop" and "Photoshop CC" in the same list quietly become two products that are really one.

Vendor, Owner, and Renewal Fields to Track

These three fields turn a name into something you can act on:

• Vendor — who you buy and renew with. The vendor field is the bridge to your Renewals & Vendor Register, where the renewal workflow itself lives.
• Owner — the person responsible for the software, linked to your People & Accounts register or recorded as a name. This is the same accountability idea as asset ownership and custody: every license points at a responsible person, and a software asset can also be linked to the hardware it runs on.
• Renewal date — when the license next comes due. In the software register this is context; the active job of tracking what renews when belongs to the Renewals & Vendor Register.

License and Key-Safety Fields to Track

The license fields record what you hold; the key fields record that a key exists without ever becoming a place secrets live:

• License type — perpetual, subscription, per-seat, site, and so on — recorded as you describe it.
• License reference — an order or entitlement reference that points back to the purchase.
• key_present — a simple yes/no that a license key exists.
• key_hint — a short masked reference (a handful of visible characters at most) so you can recognise the right key without revealing it.

The rule that matters: never put a full license key, password, recovery code, or API token in the register. The actual key belongs in a password manager or secure vault; the register records only that a key exists and a masked hint, and you can note in the license reference where the real key is stored. CertPilot is not a password manager or a secrets vault, and the masked-hint design is deliberate so the register never becomes one.

Status and Lifecycle Fields to Track

Status is what keeps the register honest about what is actually live. CertPilot's software license status options are active, expired, replaced, unassigned, and cancelled:

• Active — in use and current.
• Expired — past its term and not renewed.
• Replaced — superseded by a different product or license.
• Unassigned — a paid seat with no current holder, freed (often when someone left) and available to reassign rather than quietly wasted.
• Cancelled — deliberately ended.

The non-active states are the valuable ones. An unassigned seat is the software equivalent of an unassigned device: visible, deliberate, and ready to reuse instead of forgotten. A register full of "active" rows proves little; one that honestly shows expired and unassigned licenses is the one being managed.

How Software Assets Connect to Renewals and Vendors

The software register and the Renewals & Vendor Register are complementary, not duplicates. The software register answers what we run and who owns it; the renewals register answers what renews when, at what cost, and who handles it. The vendor and renewal-date fields are the link between them — record the license as an owned software asset, and track its renewal as a dated commitment in the renewals register, where reminders and cost context belong.

What Not to Track

A software register earns trust by staying narrow. Never record:

• Full keys or secrets. No complete license keys, passwords, recovery codes, API tokens, OAuth secrets, or private keys. key_present plus a masked hint is the whole of it.
• Usage or behaviour. The register does not know how often an app is opened or by whom, and should not pretend to — there is no usage data here, by design.
• Sensitive HR or financial detail. An owner's name is enough; the register is not an HR file or an accounting ledger.

These limits keep the register on the right side of the line drawn in what CertPilot is and is not.

How This Supports Management-Ready Evidence

A maintained software register is the internal-register input to IT governance evidence — the register half of the checks + registers → evidence reports model. Software data rolls up as summary counts into the cross-module evidence reports — how many licenses, how many expired or unassigned — feeding a management-ready evidence report a non-technical reader can use; the sample reports gallery shows the finished artifact. There is no dedicated Assets PDF today; software evidence surfaces as Governance Evidence Pack counts, plus the register and a CSV export.

How CertPilot Fits — With Strict Boundaries

CertPilot's Assets Register holds the software fields above as a customer-maintained, manual-first record with CSV import and export. The boundaries are deliberate:

• It records operational software and license evidence; it does not discover software automatically or discover SaaS in your environment.
• It does not monitor app usage, score license utilization, or detect license waste — there is no usage data behind it.
• It does not guarantee license compliance and is not a certification or an audit guarantee.
• It does not scan devices or networks and does not perform vulnerability scanning.
• It is not a procurement system, not an accounting or depreciation system, and not a CMDB replacement.
• It is not a password manager or secrets vault — keys live elsewhere; the register notes only that one exists.

Every field is something you enter or import. It supports internal governance routines and evidence preparation — not a tool inferring your software for you.

A Practical First Version for a Lean IT Team

You can stand up a useful software register in an afternoon:

1. Import what you have. Export your license or subscription spreadsheet to CSV and import it — gaps and all.
2. Name a vendor and an owner for each. If you cannot name an owner, that is the finding; record it as a gap.
3. Set the license status. Mark expired, unassigned, replaced, or cancelled honestly — the exceptions are the point.
4. Record key_present and a masked hint for anything with a key, and put the real key in your password manager.
5. Send renewal dates to the renewals register and set a monthly upkeep slot, so the record stays current. The prove-it-without-spreadsheets routine shows how this becomes a habit.

In Short

• Track identity, vendor, owner, license type and status, renewal date, and safe key handling for each software asset.
• License status (active, expired, replaced, unassigned, cancelled) is the highest-value field; unassigned seats are recoverable, not lost.
• Never store a full key — record key_present and a masked hint, keep the real key in a password manager.
• Renewals belong in the Renewals & Vendor Register; the software register holds the renewal date as context.
• CertPilot's register is manual-first — no SaaS discovery, no usage monitoring, no license-waste scoring, no compliance guarantee.

Frequently Asked Questions

Does CertPilot store my license keys?

No. The software register records only whether a key exists (key_present) and a short masked hint (key_hint) so you can recognise it. The full key — like passwords and other secrets — belongs in a password manager or secure vault, never in the register. CertPilot is not a password manager or secrets vault.

Does it discover installed software or SaaS automatically?

No. The register is manual-first. You add software by hand or by CSV import; CertPilot does not scan devices, discover SaaS in your environment, or detect shadow IT. The register is as complete as you keep it — which is also what keeps it accurate.

Can it tell me which licenses are wasted or unused?

No. There is no usage data behind the register, so it cannot score utilization or flag waste. What it can do is make recorded states visible — an expired license or an unassigned seat you have marked — so you act on what you know, not on inferred usage.

How does this relate to the Renewals & Vendor Register?

They are complementary. The software register records what you run and who owns it; the Renewals & Vendor Register tracks what renews when, at what cost, with reminders. The vendor and renewal-date fields connect the two, so a license is an owned asset and its renewal is a tracked commitment.

Does a software register prove we are license-compliant?

No. It is operational evidence — a record of what you hold and its status — that supports vendor audits, questionnaires, and management reviews. It is not a license-compliance guarantee, a certification, or legal advice, and CertPilot does not measure usage to assert compliance.