Information Asset Identification — Standard Definition

Information Asset Identification — Standard Definition

Status: Draft v0.2.12 | Author: Security Director | Date: 2026-02-25

Applicable Standard: ISO/IEC 27002:2022 Control 5.9

1. Purpose

This document defines the criteria for identifying information assets at Cybercraft. It establishes consistent and verifiable criteria for determining what to register in the Asset Register and what not to register.

By referencing this document, any person or AI making a determination should arrive at the same classification result.

2. Normative References

This document is based on the following standards and documents:

2.1. ISO 27001:2022 Annex A 5.9 — Standard Text

"An inventory of information and other associated assets, including owners, should be developed and maintained."

— ISO 27001:2022 Annex A 5.9

2.2. ISO 27002:2022 Control 5.9 — Key Implementation Guidance

Asset Identification and Documentation Requirements:

• Identify information and assets
• Determine the importance of information and assets
• Document and maintain accuracy, currency, and consistency
• Record the location of assets
• Classify assets
• Allocate ownership of assets

Component Documentation Requirements (2022 Revision Addition):

"Components that sustain technology assets are recorded and interrelated, including databases, storage, software components and sub-components."

— ISO 27002:2022 Control 5.9, Implementation Guidance

This clause is the normative basis for the Component and Resource concepts defined in this document.

Asset Inventory Record Items (ISO 27002:2022 5.9):

Separately from the asset types above, the standard requires the following to be recorded in the inventory for each asset: unique identifier, location, classification, owner, version (where applicable), and licence expiry date (where applicable). These are attributes of the asset, not examples of asset types.

Asset Types Defined by the Standard for Inventory Inclusion:

2.3. Asset Owner Responsibilities (ISO 27002:2022 Control 5.9)

Asset Owner responsibilities as defined by the standard:

1. Ensure all data and related resources are registered and documented in the inventory
2. Ensure all assets are correctly classified and protected
3. Periodically review classifications to maintain accuracy
4. Ensure components sustaining technology assets are recorded and interrelated
5. Establish acceptable use requirements for assets (→ linked to A.5.10)
6. Periodically review that access restrictions align with classification and remain effective
7. Ensure assets are safely handled and removed from the inventory upon deletion or disposal
8. Identify and manage risks associated with assets
9. Support roles and responsibilities for personnel managing information

2.4. Information Classification Requirements (ISO 27001:2022 Annex A 5.12)

Each asset in the Asset Register must be classified according to the information classification scheme:

This classification scheme is implemented as the Classification property in the Asset Register.

3. Scope

• All information assets within the Cybercraft ISMS scope
• All items registered in the Information Asset Register (L1) and License Inventory (L2)
• Components and Resources documented in asset page bodies

3.1. Key Terms

Key concepts used from §4 onwards are defined here. For the full glossary, see Appendix A.

4. Core Principle

This document identifies assets through two tracks:

4.1. Track A — Technology Asset Identification: 3-Question Test

This principle is verified through the following questions:

1. Did we create or contract it? (tenant, organisation, account, domain registration, subscription agreement)
2. Do we control it? (we manage configuration, users, data, and access controls)
3. Can it be independently terminated? (terminating it independently would stop only that service)

All three questions Yes → Register as an asset

Asset Discovery Methodology

4.2. Track B — Information Asset Identification: 3-Question Test

Determined by different questions from technology assets:

1. Is it an identifiable dataset? — A logical unit that can be named ("customer data", "financial data", "source code")
2. Does it require Confidential or Internal classification? — Would disclosure or tampering cause harm to the organisation?
3. Does it require separate ownership, access controls, and risk assessment? — Does it need a different level of protection from general business documents?

All three Yes → Register in Asset Register as Information type

Otherwise → Registration not required. It is ordinary content naturally residing in its storage location.

Registration Unit

On a customs declaration form, you write "diamond necklace", not "left pocket of the suitcase". The left pocket is what you write in the "storage location" field.

Likewise, what you register in the Asset Register is the logical dataset called "Customer Data".

• Not a folder (folder = storage path)
• Not a file (file = physical unit. Updating asset registration every time a file is added is file management, not asset management)
• Not a site/URL (site = storage = a resource of a technology asset)

Registration Example:

In this example:

• "Customer Data" is the registration unit (logical dataset)
• SharePoint HR Portal site is the storage location (attribute)
• Power BI dashboard is the access path (attribute)
• Neither the SharePoint site, the Power BI dashboard, folders, nor files are registration units

Storage Location Recording Guide

Distinguishing Source and Viewer

Where data is stored and where data is displayed are different:

Recording Rules:

• Storage Location = Record only the source. Where the data actually exists.
• Access Path = Record if a viewer exists. Optional, but useful for understanding who accesses data via which path.
• If the viewer is within the same system as the source (e.g., a different view of a SharePoint list), separate recording is unnecessary.
• If the viewer is in a different system (e.g., SQL DB → Power BI), record it as an access path.

Decision Examples:

What Not to Register — General Data

All data belongs to the organisation, but most general business data fails at questions 2 and 3 of the 3-Question test:

• Team meeting notes, internal announcements, project schedules, general business documents → no serious harm from disclosure → registration not required
• Test/dummy data (even if in customer data format, no actual customers) → no harm from disclosure → registration not required
• Public website content → already public information → registration not required

Only datasets classified as Confidential or Internal that require separate protection are registration targets.

Storage-Specific Application Rules — Resolving SharePoint Ambiguity

SharePoint sites appear to play different roles depending on context, but the definition is singular:

SharePoint site = A resource (storage) of the M365 Subscription. It is not an asset in itself.

If it contains data requiring protection → that data is a separate information asset.

The same principle applies uniformly to all storage types ("if it contains data requiring protection" = when 3-Question is satisfied):

5. Asset Type Taxonomy

The four standard types from ISO 27002:2022 Control 5.9 (see §2.2), specialised for the Cybercraft operational environment:

Asset Type — Layer Relationship Diagram

The diagram below shows how §5 asset types connect to the layer structure (§8) and how they are distinguished from §6 components and resources.

graph TB
    subgraph L1["L1 — Asset Register"]
        TA["Technology Assets Track A<br>Service Env · Identity<br>Cloud · Domain · Physical"]
        IA["Information Assets Track B<br>Information / Data"]
    end
    subgraph L2["L2 — License Inventory"]
        LI["License / Subscription"]
    end
    subgraph L3["L3 — Asset Page Body"]
        CO["Component<br>Independent termination ✗"]
        RE["Resource<br>Instance within subscription"]
    end
    TA -->|"Usage basis"| LI
    TA -->|"Internal feature"| CO
    TA -->|"Internal instance"| RE
    RE -.->|"If containing data<br>requiring protection<br>→ Register separately via Track B"| IA

6. What Not to Register

6.1. Components

• Does not require separate risk assessment, ownership, or classification
• Documented in the asset page body as "recorded and interrelated" (ISO 27002:2022 5.9 requirement)
• Examples: Exchange Online, SharePoint, Teams, OneDrive, Intune, Defender within an M365 Subscription

6.2. Resources

• Individual instances created and deleted within a cloud subscription (asset)
• Not a separate subscription/contract, but provisioned within an existing subscription
• Documented as a resource list in the asset page body
• Examples: Azure Static Web App instance (xxx.azurestaticapps.net) within an Azure Subscription

6.3. Distinguishing Storage and Information Assets

Principle:

Storage = A component or resource of a technology asset. The container for data.

Information Asset = The dataset inside the container that requires protection.

These two are entirely different layers:

Detailed rules for information asset registration units, storage location recording criteria, and registration decisions are covered in §4.2.

6.4. DNS Mappings / Subdomains

• A configuration element of the primary domain (asset)
• it-doc.cybercraft.net = CNAME record of cybercraft.net (asset) → mapped to Azure Static Web App (resource)
• Cross-reference must be recorded on both the domain asset page and the cloud infrastructure asset page

6.5. BYOD Devices / Personal Software / Personal Hardware

Track A Application:

• Q1: "Did we (Cybercraft) contract, register, or create it?" → No → Not an asset
• Personally owned; therefore not an organisational asset

However, they are management targets:

• BYOD devices are endpoints that access corporate data, making them subject to access control and security policies (ISO 27001 A.8.1)
• Device inventory is managed in Intune (macOS ADUE) / Entra ID Registered Devices + APP reports (Windows MAM-only)
• Management purposes: compliance monitoring, selective wipe during offboarding, audit evidence, stale device cleanup
• Detailed procedure: Device Lifecycle Procedure (ISMS-PROC-BYOD-01) §6

Personal Software:

• Discoverable via Intune Discovered Apps, etc., but not a Cybercraft asset
• Unauthorised app use is addressed in the Application & Data Governance Policy (ISMS-POL-ADG-01)
• This is security policy enforcement, not asset management

7. Decision Flowchart

When a new item is identified, apply the Track A (Technology Assets) or Track B (Information Assets) decision flow depending on the nature of the item:

flowchart TD
    A["New item identified"] --> T{"Nature of the item?"}
    T -- "Service, infrastructure,\nequipment, domain" --> A1
    T -- "Dataset" --> B1

    A1{"Track A Q1:<br>Did we contract, register,<br>or create it?"} -- No --> ZA["Not an asset<br>(Vendor/third-party owned)"]
    A1 -- Yes --> A2{"Track A Q2:<br>Do we control it?"}
    A2 -- No --> ZA
    A2 -- Yes --> A3{"Track A Q3:<br>Can it be independently<br>terminated?"}
    A3 -- No --> EA["Component/Resource<br>→ Asset page body (L3)"]
    A3 -- Yes --> FA{"Is it a licence agreement?"}
    FA -- Yes --> GA["License Inventory (L2)"]
    FA -- No --> HA["Asset Register (L1)"]

    B1{"Track B Q1:<br>Is it an identifiable<br>dataset?"} -- No --> ZB["Registration not required<br>General business data"]
    B1 -- Yes --> B2{"Track B Q2:<br>Does it require<br>Confidential/Internal<br>classification?"}
    B2 -- No --> ZB
    B2 -- Yes --> B3{"Track B Q3:<br>Does it require separate<br>ownership, access controls,<br>and risk assessment?"}
    B3 -- No --> ZB
    B3 -- Yes --> JB["Asset Register —<br>Information type (L1)"]

8. Layer Structure

• L1 ↔ L2 are connected via Relation (already implemented)
• L3 uses a free-form structure per asset type — not enforced by DB schema
• When documenting L3, cross-references between related assets are mandatory (e.g., domain ↔ hosting)

9. Microsoft Ecosystem Special Rules

Microsoft Cloud follows a structure where multiple independent subscriptions are linked under a single Entra ID Tenant.

9.1. Official Hierarchy (per Microsoft Learn)

Organization (Cybercraft)
├── Entra ID Tenant (1) — Common identity foundation
│     ├── User Accounts & Groups
│     └── Provides authentication/authorisation
│
├── M365 Subscription — Separate SaaS contract
│     ├── License: Business Premium × N
│     └── Services: Exchange, SharePoint, Teams...
│
├── Azure Subscription — Separate IaaS/PaaS contract
│     ├── Billing: Pay-as-you-go / Free tier
│     └── Resources: Static Web Apps, VMs...
│
└── (Additional subscriptions possible, e.g. Dynamics 365)

9.2. Asset Registration Rules

9.3. Component ↔ Licence Mapping

M365 provides different features per licence tier. This mapping is documented as a Component — License Mapping table in the M365 asset page body.

10. Domain and Website Rules

Cross-referencing mandatory:

• Domain asset page: "it-doc.cybercraft.net → CNAME → xxx.azurestaticapps.net"
• Azure asset page: "Static Web App (it-doc) → Custom domain: it-doc.cybercraft.net"

11. SaaS General Rules

The same principle applies to all SaaS products:

12. Asset Page Body — L3 Documentation Guide

Content to document in the page body per asset type:

Service Environment (SaaS)

• Service component list
• Component ↔ licence mapping (where applicable)
• Admin console URL
• SSO/authentication integration status

Identity Platform

• Tenant ID / Domain
• List of linked subscriptions (reference)
• Key settings: Conditional Access, MFA, App Registration, etc.

Cloud Infrastructure

• Resource list (instance name, type, status)
• Custom domain mappings
• Billing structure

Domain

• Registrar, expiry date
• DNS record list (subdomain → target)
• Linked service/resource references

Information / Data

Content to document in the information asset page body:

• Dataset description — What kind of data it is
• Storage location — Which resource (SharePoint Site, Blob, etc.) of which technology asset (M365, Azure, etc.) stores it
• Classification rationale — Reason for Confidential / Internal classification
• Access permissions — Who can access it
• Retention period — Data retention requirements (legal, business)

Information Asset Storage Location ↔ Technology Asset Cross-Reference Rules

When an information asset is stored in a resource of a technology asset, cross-references must be recorded on both sides:

Technology Asset page (M365, Azure, etc.) → In the resource list:

• If the resource contains an information asset, mark with ⚠️
• Example: "SharePoint Site: HR Portal — ⚠️ Contains HR Records (Confidential)"

Information Asset page → In the storage location:

• Specify which resource of which technology asset stores the data
• Example: "Storage Location: M365 Subscription → SharePoint Site: HR Portal"

13. Related Documents

Appendix A. Glossary

Appendix B. Decision Examples

Track A — Technology Asset Decision Examples

Track B — Information Asset Decision Examples

Change History