Assets, processes, data and dependencies: the scope of a security decision

Security decisions begin by naming what is in scope, and the obvious answer is usually wrong. The NIST Cybersecurity Framework 2.0 defines an asset as anything that enables the organization’s business purposes — data, hardware, software, systems, facilities, services, people; CIS Control 1 counts end-user, network, IoT and cloud devices, and Control 2 adds software. An asset matters for the process it serves and the data it handles, so an inventory maps data to the components where it is processed, stored or transmitted (NIST SP 800-53, RA-2). Each asset also depends on suppliers and providers, which decide what a failure takes with it. This sheet fixes that scope and the two properties that make an inventory usable: coverage and freshness.

The model: process, data, asset, dependency

a purpose (what the organisation must keep doing)
      ↓
process — the activity that delivers it
      ↓
data — what the process reads, changes, stores, transmits
      ↓
asset — the component the data lives on and the process runs on
      ↓
dependency — the service, supplier or provider the asset relies on
      ↓
what fails with it — the consequence the decision is about

Read from the top, the chain answers one question: what is the scope of this decision? Each line widens it. An asset is the third item, not the first — in scope because a process needs it and data rests on it. A dependency is anything the asset needs to work, including what the organization does not own. What fails with it is what the decision protects: scope is never a device list.

What counts as an asset

Three authoritative definitions overlap, and the boundary is wider than hardware:

• CIS Control 1 — enterprise assets are end-user devices, network devices, non-computing/Internet of Things (IoT) devices and servers, connected physically, virtually, remotely or within cloud environments.
• CIS Control 2 — a second class, software: “operating systems and applications”.
• NIST SP 800-53, CM-8 — a system component is a “discrete, identifiable information technology asset” including “hardware, software, and firmware”.

An asset, then, is defined by what the organization depends on, not by where it sits. The framework opens the list furthest: data, hardware, software, systems, facilities, services, people. Scope is built in one direction:

1. name the purpose the organization must keep delivering;
2. name the process that delivers it;
3. name the data that process handles;
4. name the components that data touches;
5. name what each depends on.

Data and process lead for a reason: CIS Control 3, Data Protection, asks for controls to identify, classify, securely handle, retain and dispose of data — a lifecycle belonging to the data, not the device, since a server can be decommissioned while its data is still required. RA-2 in NIST SP 800-53 maps that information to the components where it is processed, stored or transmitted.

Assets are not isolated: dependencies set what a failure takes with it

A component that works is not a process that works. CIS Control 15, Service Provider Management, asks the organization to evaluate providers “who hold sensitive data, or are responsible for an enterprise’s critical IT platforms or processes” — a provider is in scope even when it owns no hardware of yours. CSF GV.SC agrees: suppliers “are known and prioritized by criticality” (GV.SC-04), and their risks are monitored over time (GV.SC-07). Dependencies decide propagation: when a critical supplier fails, the failure reaches the process even if every owned component is healthy.

The inventory is a governance instrument, not a list

An inventory earns its place by being usable, and CM-8 says what that means: it must accurately reflect the system, include all components, avoid duplicate accounting, and be reviewed and updated at an organization-defined frequency. CM-8(1) updates it on installations and removals, because otherwise there is “a greater likelihood that the information will not be appropriately captured”; CM-8(2) maintains its “currency, completeness, accuracy, and availability”. Two properties follow: coverage, how much of the in-scope estate is listed, and freshness, how recently each entry was confirmed. An inventory written once and never revised fails both, which is why CIS Control 1 defines its purpose as knowing “the totality of assets that need to be monitored and protected”.

A common misconception: “the asset inventory is the list of servers in the rack”

The rack is a location, not a scope: two errors follow. The first is to stop at hardware: a list of servers and switches omits software (CIS Control 2), the data itself (Control 3) and provider-held services that own no device (Control 15). The second is to read scope off the perimeter, assuming “in scope” means “inside the network”. The framework asks instead for “internal and external network data flows” (ID.AM-03) and “inventories of services provided by suppliers” (ID.AM-04): a cloud service holding the data is in scope though no device of yours stands in that rack. Scope follows the chain, not the wall.

What to remember

• An asset is anything the business purposes depend on, because a process uses it and data rests on it.
• Scope is the chain — process, data, asset, dependency — not the perimeter, and dependencies set what a failure propagates to.
• Inventory quality is coverage and freshness, not existence; the inventory is evidence for a decision, not a shelf list.

Level and prerequisites

L1 — fundamentals: what is in scope and why, with no procedure or tooling. Prerequisites: none; the preceding sheet (confidentiality, integrity and availability) supplies the loss vocabulary used here.

Where to go next

• Cybersecurity Governance — the area this sheet belongs to.
• The technical side lives elsewhere: Networking (segmentation), Server & Virtualization (hardening, backup).

References

• Center for Internet Security, CIS Critical Security Controls v8.1 — Control 1 (enterprise assets), Control 2 (software assets), Control 3 (data protection) and Control 15 (service providers), with their stated purposes.
• NIST, The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29, February 2024) — the Asset Management category ID.AM (ID.AM-01, -02, -03, -04, -05, -07, -08) and the supply chain category GV.SC.
• NIST, Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5) — CM-8 System Component Inventory and enhancements CM-8(1), CM-8(2); RA-2 Security Categorization.