A.5.9 Organizational
Inventory of information and other associated assets
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (15)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- CM-8mostlyaligns with — Both controls require maintaining an accurate, up-to-date inventory of organizational assets with assigned ownership and sufficient granularity to support security management.
- AC-2partialaligns with — Reassigning asset ownership when personnel change roles or leave supports the account management lifecycle and removal of unnecessary access.
- CM-2partialaligns with — The ISO requirement to keep asset inventories accurate and aligned with other inventories supports the maintenance of approved baseline configurations.
- CM-3partialaligns with — Requiring inventory updates when assets are installed, changed, or removed provides the visibility needed to control configuration changes.
- CM-8partialcovers — A.5.9's broad asset inventory requirement (information + associated assets, with ownership) accounts for the bulk of CM-8's system component inventory but leaves a residual: CM-8's system-specific, non-duplicative, granularity, and accountability details are narrower and more prescriptive than the general asset inventory in A.5.9.
- PM-5partialaligns with — Assigning ownership and maintaining asset inventories at an organizational level contributes to the system inventory used for security program management.
- CM-2covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PM-5implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Aligned NIST CSF 2.0 outcomes (21)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- ID.AM-01mostlyaligns with — The ISO control's requirement to maintain accurate, up-to-date inventories of hardware and other assets directly supports the CSF outcome of keeping hardware inventories current.
- ID.AM-02mostlyaligns with — Requiring inventories of software, services, and systems to be maintained and kept consistent mirrors the CSF outcome for software and system inventories.
- ID.AM-05mostlyaligns with — Assigning ownership and classifying assets according to their importance provides the prioritization and criticality assessment the CSF outcome expects.
- ID.AM-08mostlyaligns with — The ISO control's emphasis on managing assets throughout their entire life cycle, including secure disposal and removal from inventory, fulfills the CSF outcome for life-cycle management.
- ID.AM-07partialaligns with — By requiring information assets to be inventoried and classified, the ISO control contributes to the CSF outcome of maintaining data inventories and associated metadata.
- ID.RA-05partialaligns with — The ISO control's requirement that asset owners participate in risk identification and management for their assets supports the CSF outcome of using asset information to inform risk response.
- ID.AM-01implements — A.5.9 directly operationalizes the maintenance of asset inventories that ID.AM-01 requires (hardware is a core subclass of the assets A.5.9 names and owns)
- ID.AM-02implements — A.5.9's defined purpose is to maintain an inventory of information and associated assets (including systems/services/software); this directly operationalizes the exact outcome named in ID.AM-02
- ID.AM-05implements — A.5.9's inventory+ownership process directly operationalizes the asset-prioritization outcome in ID.AM-05; classification/criticality/impact are assigned and used during that inventory, making the technical control the primary means that gives effect to the governance outcome within the asset-management domain
- ID.AM-07implements — A.5.9's defined purpose is exactly to maintain asset inventories (including data) and assign ownership; this directly operationalizes the CSF outcome that inventories of data and metadata are maintained.
- ID.AM-08implements — A.5.9's inventory process directly operationalizes the asset life-cycle management outcome named in ID.AM-08 (identification and ownership are core early phases of any asset life cycle); the link is within the shared asset-management domain but not by explicit citation of life-cycle stages.
- ID.RA-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Related OWASP ASVS 5.0 requirements (8)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V15.1.2mostlyaligns with — Maintaining an accurate, up-to-date inventory of software components and their versions directly supports the ISO requirement to keep asset inventories current and consistent.
- V11.1.2partialaligns with — The ISO control's mandate to inventory cryptographic keys, algorithms, and certificates aligns with the ASVS requirement for a maintained cryptographic inventory.
- V13.1.4partialaligns with — Assigning ownership and tracking critical security secrets in the asset inventory corresponds to the ASVS requirement for documenting and rotating important secrets.
- V13.4.1partialaligns with — Including source-control metadata and other assets in the inventory helps ensure they are either removed or properly managed, aligning with the ASVS control on preventing unintended exposure of such metadata.
Related weaknesses / CWE (3)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- CWE-284nonemitigates — Assigning explicit owners and maintaining an accurate inventory of assets enables consistent enforcement of access restrictions that match asset classification, reducing the chance that sensitive resources remain accessible without proper authorization.
- CWE-200prevents — By requiring owners to classify assets and periodically review access restrictions, the control limits the likelihood that sensitive information will be exposed to unauthorized actors through misclassified or forgotten resources.
- CWE-552mitigates — Including asset location and ownership in the inventory, combined with secure disposal procedures, decreases the chance that files or directories remain accessible to external parties after they should have been removed or restricted.
Mitigated MITRE ATT&CK techniques (219)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
T1001←MT1001.002←MT1001.003←MT1006←MT1014←MT1027.001←MT1027.002←MT1027.005←MT1027.008←MT1027.009←MT1027.011←MT1027.014←MT1027.016←MT1027.018←MT1030←MT1036←MT1036.002←MT1036.003←MT1036.004←MT1036.005←MT1036.008←MT1036.009←MT1036.011←MT1036.012←MT1055←MT1055.001←MT1055.002←MT1055.003←MT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1070←MT1070.004←MT1070.006←MT1070.008←MT1070.009←MT1070.010←MT1071.001←MT1071.004←MT1074.002←PT1078→PT1090.003←MT1098.005←MT1102←MT1102.001←MT1110.001→PT1112←PT1127←MT1127.001←MT1132.002←MT1133←MT1134←MT1134.001←MT1134.003←MT1134.004←MT1136.001←PT1137.001→PT1137.006→PT1202←MT1204.004←MT1207←MT1211←PT1216←MT1218←MT1218.005←M →PT1218.007←MT1218.008←MT1218.010←MT1218.011←MT1218.013←MT1221←MT1222←MT1222.001←MT1222.002←MT1480.001←MT1484←MT1484.002←MT1485←P →PT1485.001←MT1486→MT1490←M →MT1496→PT1497←MT1499←FT1530→PT1537←MT1539←MT1542←MT1542.002←MT1543.003←PT1546.003→PT1546.007→PT1546.012←PT1547.006←PT1548.006←MT1550←MT1550.001←FT1550.002←FT1550.003←FT1550.004←FT1553.001←MT1553.002←PT1553.003←MT1553.004←MT1553.005←MT1553.006←MT1556←MT1556.003←PT1556.006←PT1556.007←MT1556.009←MT1561←M →PT1561.001←P →MT1561.002→MT1564←MT1564.001←MT1564.004←MT1571←MT1572←MT1574←MT1574.001←MT1574.004←MT1574.013←MT1578←MT1578.001←MT1578.002←MT1578.003←M →PT1578.004←MT1578.005←MT1584.001←P →PT1599←MT1599.001←MT1600←MT1601.001←MT1601.002←MT1606.001←FT1610←PT1612←MT1620←MT1621←PT1647←PT1653←PT1665←MT1666←MT1678←MT1685←MT1685.001←MT1685.002←MT1685.003←MT1685.004←MT1685.005←MT1685.006←MT1686←FT1686.001←MT1686.002←MT1686.003←MT1687←PT1688←MT1689←PT1690←M
Why these map — AI rationale (under review)
- T1078prevents — A.5.9's inventory, ownership assignment, timely reassignment on departure/role change, and secure removal of disposed assets directly prevent abuse of inactive/orphaned accounts (a named slice of T1078), but do not stop credential compromise, permission overlap, or abuse of active accounts.
- T1110.001prevents — maintaining an accurate asset inventory with assigned owners and classification enables timely ownership-driven decisions on hardening authentication (e.g. disabling default accounts, enforcing MFA, removing unused services) on the inventoried management ports and accounts the technique targets, but the control stops at identification/ownership and does not mandate those protective configurations
- T1137.001prevents — A.5.9's inventory, ownership assignment, classification, and owner duties to protect/securely delete assets (including software/components) can constrain abuse of Office template files as assets, but does not stop macro insertion, search-order hijacking, or registry modification that enables the persistence technique.
- T1137.006detects — A.5.9 requires maintaining accurate asset inventories (including software/components) and periodic reviews that can surface unauthorized add-ins as inventory discrepancies, but this is indirect, scope-limited to inventoried items, and does not mandate detection mechanisms or real-time identification of the persistence technique.
- T1137.006prevents — A.5.9 requires identifying, inventorying, classifying, and assigning ownership to assets (including software/components like Office add-ins) across their lifecycle, which constrains untracked/persistent add-ins from being introduced or surviving; this reaches only a slice of the technique since the control is governance-oriented and does not mandate technical blocks on add-in registration or execution.
- T1218.005detects — asset inventory (with location, classification, ownership and lifecycle tracking) can surface anomalous or unauthorized mshta.exe usage or .hta payloads when they deviate from approved/known assets, but this is indirect, post-facto, and limited to monitored assets rather than reliably catching the technique in flight or in custom/untracked locations
- T1485recovers — A.5.9 requires maintaining accurate asset inventories (including VMs, storage, databases) and secure deletion from the inventory upon disposal, which enables recovery of known assets via backups or reconstitution after T1485 destruction; however, it does not itself perform or mandate backup/recovery mechanisms and leaves many short-lived or un-inventoried assets outside its scope.
- T1486recovers — A.5.9 requires maintaining accurate asset inventories (including location, ownership, classification, and lifecycle handling) that explicitly cover secure deletion/disposal and removal from the inventory; this directly enables post-encryption recovery of known, inventoried data/assets (as in the event-lane backup/recovery anchors), though it stops short of mandating the actual backup or restoration mechanisms themselves.
- T1490recovers — A.5.9 requires maintaining accurate asset inventories (including backups, snapshots, VMs, and recovery-related items), assigning ownership, ensuring secure deletion from the inventory, and linking components; this directly supports post-attack recovery by preserving knowledge of and access to remaining recovery assets, though the control stops short of mandating actual backup creation or restoration mechanisms.
- T1496detects — A.5.9 requires maintaining accurate asset inventories (with reviews, ownership, classification, and lifecycle tracking) that can surface unexpected or unauthorized resource-consuming assets post-compromise, but this is indirect governance rather than active detection of the hijacking technique itself.
- T1530prevents — A.5.9's inventory, ownership assignment, classification, access-restriction duties, and secure-deletion rules directly close the misconfiguration vector that leaves cloud storage objects openly accessible or untracked, but do not address credential theft/abuse or all runtime access paths.
- T1546.003detects — A.5.9 requires maintaining accurate asset inventories (including hardware, software, VMs, components) and periodic reviews that can surface anomalous or unauthorized WMI subscriptions, MOF files, or event consumers as inventory discrepancies, but this is indirect, scope-limited to inventoried items, and does not mandate detection of the technique in execution.
- T1546.007detects — A.5.9 requires maintaining accurate asset inventories (including software/components) and periodic reviews that can surface unauthorized registry entries or helper DLLs as anomalies, but this is indirect, scope-limited to inventoried assets, and does not mandate monitoring for the persistence technique itself.
- T1561recovers — A.5.9 requires maintaining accurate asset inventories (including location, ownership, classification, and secure deletion handling) and explicitly mandates that deleted/disposed assets be removed from the inventory while owners ensure proper lifecycle management; this supports post-wipe recovery planning for known assets but does not itself restore wiped data or configurations.
- T1561.001recovers — A.5.9 requires secure deletion handling that removes wiped assets from the inventory and assigns ownership duties spanning the full asset life cycle (including recovery-oriented classification, protection, and risk management of storage assets), directly enabling post-wipe restoration of availability for inventoried assets; the bounded remainder is that it does not itself perform the data restore.
- T1561.002recovers — A.5.9 requires maintaining accurate asset inventories (including hardware, VMs, facilities) plus secure deletion/disposal procedures that remove wiped assets from the inventory and support recovery of state via owner-driven lifecycle management; this restores availability after T1561.002 but leaves a named remainder for assets whose short-lived or wiped state makes full inventory restoration infeasible.
- T1578.003detects — A.5.9 requires maintaining accurate, up-to-date asset inventories (including VMs/instances) with location and ownership, plus periodic reviews and removal only via secure documented processes; this surfaces unauthorized deletions or inventory discrepancies as anomalies but does not instrument runtime detection of the deletion technique itself.
- T1578.003recovers — A.5.9 requires secure deletion handling plus removal from the inventory and mandates that inventories remain accurate/up-to-date; this directly enables recovery of the pre-deletion inventory state (what existed, who owned it, its classification) after the adversary's deletion, but does not restore the lost instance itself or its forensic artifacts.
- T1584.001prevents — A.5.9's inventory, ownership assignment, classification, and owner duties over the asset life cycle (including secure deletion/removal from inventory) directly prevent subdomain hijacking from deprovisioned resources and reduce domain registration hijacking via accurate ownership tracking, but leave renewal gaps, social engineering of registrars, and cloud compromise vectors untouched.
Prevented OWASP Web Top 10 (2025) risks (3)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.