The information asset register is the document most often built and least often maintained. The first pass gets filled in by sheer effort — a few hundred rows. The problem shows up six months later: systems have been added, SaaS swapped, departments reorganised, and the register still says what it said on day one. Internal audit flags it as stale, and someone patches it in a panic before the certification audit. Once that cycle starts, the register stops functioning as the foundation of the risk assessment.
Almost always the cause is the granularity chosen at the start. Too fine and it cannot be maintained; too coarse and it cannot feed a risk assessment. Between those failures sits a granularity that is both sustainable and meaningful as a unit of risk.
This article covers four things: granularity, coverage, scoring and update. For the prerequisite see Defining the Scope of Your ISMS; for what consumes the register, Clause 6: Planning; for the standard overall, What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
Why This Is Where People Get Stuck
1. "Asset" gets read as "thing"
The word suggests laptops, servers, USB drives — and the register becomes a fixed-asset inventory. But what an ISMS protects is the information; the device is only where it sits. "47 laptops" yields no risk at all. What matters is what is on them.
2. Chasing completeness first
Fear of a finding for omission drives an attempt to list everything. Rows multiply, each row thins out, and maintenance cost explodes. The register exists to set the unit of risk assessment, not to be a complete inventory.
3. Scoring before the scale is defined
Deciding only that confidentiality, integrity and availability get 1–3 and then filling in the sheet guarantees divergence between assessors. Sales rates "customer data" a 3 for confidentiality; engineering rates it a 2. Risk values derived from that register are not comparable.
4. No update mechanism
A register whose only rule is "review annually" belongs to nobody and is not reviewed. Updates must be tied to events, not dates.
What You Are Actually Deciding
| Decision | Options | Recommended |
|---|---|---|
| Granularity (what one row is) | Individual items / information type × location / business process | Information type × storage location (system) |
| Coverage | Electronic only / plus paper / plus human knowledge | Electronic, paper and undocumented know-how |
| Scoring axes | C, I and A separately / one importance score | C, I and A separately, each scale defined in words |
| Update trigger | Periodic only / event-driven | Event-driven plus an annual stocktake |
The granularity principle is: group by shared controls. Twelve laptops managed under the same device policy, encryption setting and removal rule are one row. Conversely, "customer data" in the production database and the same data in a CSV a support engineer downloaded are governed by entirely different controls — those are two rows.
| Register row | Verdict | Why |
|---|---|---|
| "Laptops (Sales, 12)" | OK | One control set; one row suffices |
| "Laptop-0047 (Yamada)" | No | Per-item rows produce hundreds and need editing on every transfer |
| "Customer data" | No | Too coarse; no location, so no control follows |
| "Patient data (production DB / cloud)" | Good | Type and location identified; controls follow |
| "Patient data (support file share)" | Good | Same data, different location, different risk |
| "Source code (GitHub organisation)" | Good | An asset held in SaaS; access rights and public-visibility settings are the issue |
| "Outsourcing contracts (originals / head office safe)" | Good | Paper asset; subject to physical controls |
Coverage is easiest to get right by thinking in five classes.
| Class | Examples | Commonly missed |
|---|---|---|
| Electronic data | Production DB, backups, logs, design documents, source code | Logs and backups — the original is listed, the copies are not |
| Data held in SaaS | Ticketing, CRM, chat, file sharing | Customer data pasted into chat — where uncontrolled data accumulates fastest |
| Paper | Contract originals, sealed applications, receipts | Originals still held after digitisation |
| Software and services | OS, middleware, your own applications | Needed for the availability view |
| People and knowledge | Tacit operational know-how, incident-handling experience | Know-how held by one person — a genuine availability risk |
The last class is routinely omitted, yet "if that person leaves, nobody can restore production" is a real availability risk. One row in the register makes "document the procedure" fall out naturally as risk treatment.
How to Do It
Step 1 — Define the scales before writing a single row
Define C, I and A in words. This decides the quality of everything downstream. Numbers alone always drift; attach decidable wording.
| Score | Confidentiality (if disclosed) | Integrity (if altered or lost) | Availability (if unavailable) |
|---|---|---|---|
| 3 (high) | Irreversible harm to a patient or user; regulator notification or public disclosure required | Could cause a wrong clinical decision; no longer valid as an audit trail | Customer operations halt; even hours of downtime unacceptable |
| 2 (medium) | Customer notification required; contractual consequences | Work must be redone; recoverable by correction | Internal disruption; a workaround exists for about a business day |
| 1 (low) | Public information, or no real harm | Errors have limited effect | Downtime causes no significant disruption |
For healthcare companies, designing the integrity scale separately from confidentiality matters. Generic IT registers weight confidentiality, but for clinical and trial data, "not altered" and "not missing" carry consequence equal to or greater than disclosure.
Step 2 — Ask each department what information they handle
Start from information, not devices. Ask what information they work with daily, then ask where it is stored. That order surfaces what has accumulated in SaaS and chat.
Step 3 — Split by location, merge by control
Same information in several places becomes several rows. Different information under one control set merges. Row counts rise, then fall.
Step 4 — Assign a responsible role to every row
Record the department and role responsible — never a person's name. These become candidate risk owners, and role-based entries survive staff transfers without edits.
Step 5 — Score and derive importance
Score C, I and A and derive importance as the maximum or the sum. Either works, but taking the maximum usually fits healthcare better: if any one of the three is high, the asset needs high control.
Step 6 — Write the update triggers into a procedure
This step decides maintainability. Tie updates to events.
| Trigger | Who raises it | How the register is updated |
|---|---|---|
| A new SaaS or cloud service is adopted | The requesting department | Build a register entry into the adoption approval flow |
| A new service or feature ships | Engineering lead | Add it to the release checklist |
| A department is created or merged | HR / General Affairs | Include it in the reorganisation procedure |
| A supplier is added or changed | The contracting department | Link it to supplier management |
| Joiners, leavers and transfers | HR | Not needed if rows name roles |
| Annual stocktake | ISMS office | Ask departments to confirm; update only the deltas |
The point is not to make "update the register" a standalone task. Embedded as one line item in flows that already exist — SaaS adoption requests, release gates, contract signing — updates happen by themselves. The annual stocktake is the safety net that catches what slipped through.
A workable minimum column set: asset ID; asset name; storage location and medium; responsible department and role; form (electronic / paper / knowledge); C, I, A; importance; whether it constitutes personal information (including special-care-required personal information); retention period and disposal method; last confirmed date.
That personal-information column is worth adding: medical information can constitute special-care-required personal information, so flagging it here means you do not have to run a separate stocktake for data protection compliance.
Where It Goes Wrong
One row per laptop, and hundreds of rows
The most common failure. As rows multiply each one thins, and nobody reads the register. Merge groups sharing a control set.
A single row saying "customer data"
The opposite failure. With no location, no concrete control follows, and the risk assessment yields nothing but "strengthen access control" — a treatment plan that cannot be executed.
Logs and backups missing
The production database is listed; its backups and access logs are not. Backups carry the same confidentiality as the original, and logs are the backbone of integrity. Both need their own rows.
Chat and file shares omitted
The customer CSV pasted into a Slack channel; the "temp" folder on the shared drive. Where uncontrolled data accumulates most, and where registers are silent. Step 2 surfaces them.
Everything scores 2
Happens whenever the scale lacks wording. Step 1 is the only cure.
Rows naming individuals
Every transfer and resignation then requires editing the whole register, so editing stops. Use roles.
Drift between register and reality goes unnoticed
Guaranteed when updates are periodic only. It surfaces at audit as a system running on the floor that appears nowhere in the register.
A register that is written once and never used
Its value comes from feeding the risk assessment. A register that exists while the risk table runs off a different asset list reads as formalistic. Connect it to How to Run a Risk Assessment.
Healthcare Examples
A SaaS provider for healthcare institutions
Patient data is the core, but splitting by location is decisive.
| Asset | Location | C | I | A | Issue |
|---|---|---|---|---|---|
| Patient data | Production DB (cloud) | 3 | 3 | 3 | Multi-tenant data separation |
| Patient data | Production backups | 3 | 3 | 2 | Encryption at rest, retention period |
| Patient data (extracts) | Support file share | 3 | 2 | 1 | Request, approval, deletion deadline |
| Patient data (defect investigation) | Developer workstation | 3 | 2 | 1 | Should not be there. Treatment is prohibition plus an alternative |
| Access logs | Logging platform | 2 | 3 | 2 | Tamper resistance and retention |
| Source code | GitHub organisation | 2 | 3 | 2 | Visibility settings, revoking leavers' access |
| Customer contracts | Head office safe (paper) | 2 | 3 | 1 | Physical locking, removal records |
| Production recovery procedure | One engineer's head | 1 | 2 | 3 | Single point of knowledge. Documenting it is the treatment |
Row four is the most valuable kind of entry: record honestly the assets sitting where they should not be. Deleting the row hides it without changing reality. Recording it and then designing treatment — "investigation happens in a masked environment" — reads far better at audit.
A PHR operator
Alongside the data entrusted by users, make the consent record its own asset. Grant, withdrawal and scope-change history carries an extremely high integrity requirement. See ISMS for PHR Operators.
A clinical trial systems company
Register the audit trail as a top-tier asset in its own right. Its integrity score is maximal, and "no gaps" and "no retrospective alteration" become the focus of treatment. Listing only the primary data leaves this sector's core risk outside the assessment.
Common ground when hospitals are your customers
Hospitals, under the three-ministry guidelines, will ask where the information they entrust to you resides. A register that can answer "which information is where" doubles as your check-sheet response. Adding columns for what those sheets ask — country of storage, whether sub-contracting occurs — avoids duplicated work. See Three-Ministry Guidelines and Cloud Security for Healthcare Institutions.
Conclusion
- The register exists to set the unit of risk assessment, not to be a complete inventory
- Granularity is information type × storage location. Merge groups sharing a control set
- Cover SaaS, paper and tacit know-how, not just electronic data. Logs and backups are the most common omission
- Define the C/I/A scales in words before writing rows. Numeric-only scales always drift
- Tie updates to events, not dates — embed one line item into SaaS adoption, release gates and contracting
- Record assets that are where they should not be, then design the correction as risk treatment
The completed register feeds the next stages: How to Run a Risk Assessment and Risk Treatment Plans and Acceptance. If scope is still open, start with Defining the Scope of Your ISMS.
Pottech supports ISMS certification with a focus on healthcare, including register templates and the healthcare-specific asset entries that generic templates miss. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee (JISC)
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Personal Information Protection Commission, Japan
Note: interpretation of requirements and the handling of accreditation and certification are governed by the standard itself and by the publications of the accreditation and certification bodies, and may change with revisions.