Risk Identification and Asset Classification

ISO/IEC 27005 divides information assets into two broad categories: primary assets and supporting assets. Primary assets are the information itself and the business processes that use it. Supporting assets are the infrastructure elements that hold or process primary assets: hardware, software, networks, facilities, and people with specialist roles. The distinction matters because risk identification starts with primary assets and then traces the dependencies to supporting assets.

In practice, auditors build their inventory starting from primary assets: what information does this organisation create, process, store, or transmit? They then trace each primary asset to its supporting assets. A customer database (primary) depends on a database management system (software), a set of virtual machines (hardware), a network segment (network), a data centre (facility), and a team of DBAs with admin credentials (people). Each link in that dependency chain is itself an attack surface.

Cloud environments complicate this picture. Infrastructure that was once owned, racked, and managed by the organisation is now owned by a cloud provider. The asset inventory must still capture the virtual equivalents: cloud storage buckets, managed database instances, serverless functions, API gateways. The shared responsibility model determines which supporting assets the organisation controls and which the provider controls, but the primary asset, the data, remains the organisation's responsibility regardless of where it sits.

A usable asset inventory has consistent fields across all entries. The minimum viable set includes: asset name and description, asset type (from the primary or supporting taxonomy), owner (named individual or role), custodian, physical or logical location, classification level, criticality to business operations, any dependencies on other listed assets, and a last-reviewed date. Entries without a named owner and without a classification level are incomplete and should not be treated as reviewed.

Criticality is separate from classification. Classification reflects sensitivity: how much harm disclosure would cause. Criticality reflects availability dependency: how much harm loss or downtime would cause. A publicly available marketing website may have a low classification (public data) but a high criticality (revenue-generating). An archived research dataset may have a high classification (sensitive personal data) but low criticality (not needed for daily operations). Both dimensions drive different control requirements, so the inventory must record both.

Discovery techniques for populating the initial inventory include network scanning (to find connected hardware and services), configuration management database (CMDB) exports (for IT-tracked assets), data flow mapping (to trace where information moves), and interviews with process owners (to surface shadow IT, cloud services procured without IT involvement, and manual processes that hold sensitive data outside any system). No single technique captures everything; the full inventory requires all of them.

Classification schemes assign each asset or data type to a tier that determines how it must be handled. A four-tier model is common in private sector organisations. The tiers, working from least to most sensitive, are typically labelled Public, Internal, Confidential, and Restricted (or Highly Confidential). Each tier must come with concrete handling rules, not just a label; a classification policy that tells staff an asset is Confidential without specifying what that means for storage, transmission, printing, and disposal is not actionable.

Regulatory frameworks impose their own category definitions that must map onto the organisational classification scheme. Under the EU General Data Protection Regulation and India's Digital Personal Data Protection Act 2023, personal data and sensitive personal data require specific technical and organisational measures. Under PCI-DSS, cardholder data (primary account numbers, card verification values, PINs) must be protected with a defined set of controls regardless of what the organisation calls its internal tiers. Under HIPAA in the United States, protected health information carries its own handling requirements. The asset inventory must record which regulatory category applies to each entry, so that the correct compliance obligations can be traced from the asset to the control.

Government classification schemes differ by country. The UK Government Security Classifications use Official, Secret, and Top Secret. The US federal framework uses Confidential, Secret, and Top Secret with additional compartmented handling at the highest levels. Organisations that process government data must align their internal schemes to the applicable statutory scheme, which may impose additional requirements beyond their standard policy.

Once the asset inventory is populated and classified, the next step is to identify what could go wrong for each asset. This requires two lists per asset: the threats that are credible given the asset type and the organisation's environment, and the vulnerabilities in the asset or its controls that those threats could exploit. The unit of risk analysis is the threat-vulnerability pair applied to a specific asset: not 'ransomware is a threat' in the abstract, but 'ransomware actors (threat) exploiting unpatched remote desktop services (vulnerability) on the HR payroll server (asset)'.

Threat identification draws on several sources. Internal incident history shows what has actually happened before. Industry threat intelligence (from sector-specific ISACs, national cybersecurity agencies such as CISA in the US, the NCSC in the UK, or CERT-In in India) shows what is currently active in the sector. Structured threat catalogues such as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) or the MITRE ATT&CK framework provide systematic checklists against which assets can be reviewed. See Threat Actors and the Threat Environment for a full treatment of threat actor categories and techniques.

Vulnerability identification uses a different set of techniques. Technical scanning (vulnerability scanners, penetration testing, configuration audits) identifies weaknesses in hardware and software. Process review (control interviews, walkthroughs, document reviews) identifies gaps in procedures, segregation of duties, and access management. Physical inspection identifies facility vulnerabilities: unlocked server rooms, missing CCTV coverage, accessible cable runs. The output for each asset is a list of vulnerabilities, each linked to the threats that could exploit it and the potential impact if exploitation succeeded.

Auditors use the asset inventory in several ways during an information security audit. First, it defines scope: the audit covers the assets in the register, and any asset not in the register is outside scope by default. This makes the completeness of the inventory itself an audit finding: an incomplete register is a control gap because it means the organisation does not know what it is protecting. Second, the inventory drives control sampling: auditors select a subset of assets from the register and test whether the controls claimed for each asset tier are actually in place and operating. Third, the inventory provides the baseline for exceptions: if an asset is classified Confidential but stored without encryption, that is a direct violation of the classification policy's handling rule.

ISO/IEC 27001 Annex A 5.9 requires organisations to identify information assets associated with the ISMS in scope and to document these in an inventory. External certification auditors check for this inventory, verify that it has a named owner for each entry, and test whether classification levels and handling rules are being applied in practice. An inventory that exists only as a document and is not linked to actual control enforcement will not satisfy an ISO 27001 Stage 2 audit.

The inventory also anchors risk treatment decisions. Once risks are assessed for each asset, treatment options (accept, mitigate, transfer, avoid) are chosen and the resulting controls are recorded in the risk register. The risk register references the asset by its inventory identifier, creating a traceable link from asset through risk through treatment to control. Auditors follow this chain in both directions: from a control back to the risk it addresses, and from a risk forward to the treatment that was selected. Without the asset inventory as the anchor, the chain breaks and the audit cannot verify that controls match risks.

For the connection between asset classification and the treatment decisions that follow from it, see Risk Treatment and the Risk Register.

A newly built inventory degrades unless governance processes keep it current. The minimum requirements are: a defined review cycle (annually is the ISO 27001 minimum, but quarterly is more practical for organisations with frequent IT change), a change management trigger that requires asset register updates whenever systems are deployed, decommissioned, or significantly reconfigured, and an owner attestation process in which named asset owners formally confirm their entries remain accurate.

In organisations with a functioning CMDB, the asset inventory and CMDB should be synchronised, but they are not the same thing. A CMDB tracks configuration items and their relationships for IT service management purposes; it is not typically structured to record classification levels, business owners, or regulatory mappings. Most organisations maintain the security asset inventory as a separate document or tool and synchronise it with the CMDB on a defined schedule rather than treating one as a substitute for the other.

Decommissioning triggers are particularly important. An asset that has been retired but not removed from the inventory occupies audit scope unnecessarily and may lead auditors to test controls on systems that no longer exist. More seriously, an asset that has been retired from the business but has not had its data properly disposed of, and is therefore not removed from the register because the data is still held somewhere, is a disclosure risk. The decommissioning process must include data disposition confirmation before the inventory entry is closed.