The software asset register auditors ask for (ISO 27001 and Cyber Essentials)

Every security certification eventually asks the same two questions: what software do you run, and who is responsible for each piece of it. Most teams answer with a spreadsheet built in the fortnight before the audit, signed off, and then left to rot until the next one. It passes. It also does nothing for you for the remaining eleven months of the year.

A software asset register that is genuinely maintained is cheaper than the annual scramble and more useful. Here is what the two frameworks UK teams meet most often actually require, and what a register needs to hold to serve both the auditor and the business.

What ISO 27001 requires

ISO/IEC 27001:2022 covers this in Annex A control 5.9, "Inventory of information and other associated assets". The control asks you to develop and maintain an inventory of information and its associated assets, including owners. Software is an associated asset, so your applications and subscriptions belong in scope alongside hardware and data.

Two words in that control do most of the work. "Maintain" means a point-in-time snapshot is not enough: an auditor will look for evidence the register is kept current, not simply that it exists. "Owners" means every asset needs a named accountable person, because ownership is what the rest of the standard hangs off. Access reviews, risk assessment, classification and incident response all assume somebody can be asked about a given system.

Where Cyber Essentials fits

Cyber Essentials is narrower. Its five technical controls are firewalls, secure configuration, security update management, user access control and malware protection. An asset register is not one of them, so strictly speaking the scheme does not require you to hold one.

In practice you cannot answer the question set without one. The NCSC publishes asset management guidance separately and treats it as foundational rather than optional, for the obvious reason: security update management and user access control are both claims about every piece of software in scope, and you cannot make a claim about a set you have not enumerated.

The requirement that bites hardest is unsupported software. Anything the vendor no longer issues updates for has to be removed, upgraded, or taken out of scope entirely. Finding those tools is a register problem before it is a security problem, and the ones that catch people out are rarely the obvious platforms. They are the small utilities bought on a card years ago by someone who has since left, which is the same gap covered in our guide on finding software nobody owns.

The fields that make a register auditable

Neither framework hands you a schema, which is why registers vary so wildly. A practical set that satisfies both, and stays useful outside audit season:

• Identity: the product name, the vendor behind it, and the product domain so two similarly named tools cannot be confused
• A named owner, plus the business unit that uses the tool - a person, never a shared inbox
• Status: whether the tool is on trial, live, in notice, cancelled or expired
• Criticality, so the register can be sorted by what would actually hurt if it went down
• Licence type and seat count, which is what user access control questions are really about
• Cost, currency and billing cycle, so the same record serves finance
• Renewal or expiry date, the notice period, and whether the contract auto-renews
• The supporting documents - contract, terms, invoices - attached to the record rather than filed somewhere else

Those are the fields StackTrackr holds on every tool. Our guide on the register fields that matter goes through the reasoning behind each one in more depth, and the features overview shows how they sit together on a record.

Owner is the field people skip

It is also the one the standard names explicitly. A register with perfect commercial detail and a blank owner column fails the part of 5.9 that matters, because there is nobody to ask when a question arrives. Assign an owner at the moment a tool is added, not in a backfill exercise later.

Keeping it current between audits

A register decays for one reason: nothing in the working week forces anyone to open it. The fix is to attach maintenance to events that already happen rather than to a review meeting that will be skipped.

1. 1A new tool is bought: it goes in the register before the first invoice is paid, with an owner assigned
2. 2Someone leaves: their owned tools are reassigned as part of offboarding, and any personal-seat tools are cancelled
3. 3A renewal approaches: the owner reviews cost, seats and whether the tool is still needed, and the record is corrected at the same time
4. 4A tool is dropped: the record is marked cancelled rather than deleted, so the estate keeps its history

The second of those is the one that fails most often. Our software offboarding checklist covers the reassignment step properly. The third is where a register that already tracks renewal dates and notice periods pays for itself, because the review is prompted rather than remembered.

What evidence actually looks like

Auditors ask how you know the register is accurate. Useful answers are concrete: records carry a last-updated timestamp, every tool has an owner, contracts are attached to the record they belong to, and there is a trail showing renewals were reviewed before they happened rather than after. A living system produces that evidence as a by-product. A spreadsheet rebuilt each year cannot produce it at all.

One register, two audiences

The strongest argument for doing this properly is that security is not the only department that wants this data. Finance needs the same records to forecast spend and to answer what the business is contractually committed to. IT needs them to know what to patch and what to switch off. Keeping one register that serves all three is what makes it survive, because then somebody has a reason to open it in a month with no audit in it.

If your current answer is a spreadsheet, start by getting the identity, owner and renewal date right for every tool, and let the rest fill in over time. The free Starter plan covers up to ten tools, which is enough to move your most significant systems off the spreadsheet and see whether a maintained register holds up. When it does, create an account and bring the rest across.