Information asset register: what you hold, where it is, and who owns it

An information asset register lists the information a business holds and depends on — customer records, contracts, source code, financial data, HR files — with an owner, a location, a sensitivity classification and a retention period for each. It is not an inventory of laptops and servers; those belong in a different register, and confusing the two produces a list that answers neither question.

Its usefulness comes from being the first thing you reach for in three different situations: an information security assessment, a privacy question about what is held and why, and an incident where the first thing anyone needs to know is what was affected.

What an information asset register records

• The asset: a named body of information, at a level someone can act on — "customer contract files", not "documents".
• Owner: a named role accountable for decisions about it, not the IT team that stores it.
• Where it lives, including any copies and the systems that hold them.
• Classification: how sensitive it is, using the scheme your policies already use.
• Whether it contains personal data, and the lawful basis if so.
• Retention period and the disposal method.
• Dependencies: what the business cannot do if it is lost or unavailable.

The dependency column is what turns a list into a risk tool. It is also the column that reveals the assets nobody had thought about — the spreadsheet that reconciles two systems, the mailbox that holds the only copy of supplier agreements.

Where it is required, and where it just helps

ISO 27001 expects an inventory of assets with owners; privacy regimes require a record of processing activities that overlaps heavily with it; and customer security questionnaires ask for it directly. Keeping one register and deriving those views is far cheaper than maintaining three lists that quietly diverge.

Build it at the level of business processes rather than files. A register with four hundred entries will not be maintained; one with thirty, each owned by a named role and reviewed annually, survives contact with a real organisation and answers the same questions. Keep it separate from the fixed asset register: different owners, different review cycles.

Keeping it true

1. Populate it from interviews with process owners, not from a systems scan — the scan finds storage, not meaning.
2. Give every entry an owner who would notice if it were wrong.
3. Review on change: new system, new supplier, new category of data, or a change in retention.
4. Reconcile annually against the record of processing activities so the two agree.
5. Use it when an incident happens; a register nobody opens during an incident is a register that will not be maintained after it.

Because the register is a table with owners, dates and links to evidence, it belongs somewhere versioned rather than in a shared file. Ettex Records keeps entries with their owners, classifications and review dates, so the state of the register on a given date can be shown — which is what an assessment asks for. What the classifications mean, and which retention applies, remain policy decisions the organisation has to make.