Start free trial

By Yair Knijn · March 3, 2026

Your SOC 2 asset inventory can't account for half your IP space, and the auditor noticed

The audit lead pulls together the asset inventory the week before fieldwork. Servers from the CMDB, laptops from the MDM, cloud instances from the tagging export, SaaS from the SSO app catalog. It reconciles, owners are assigned, and it looks complete. Then the auditor asks a question that isn't on the checklist: which team owns 10.40.0.0/14, and where is it recorded as an asset.

There is no answer, because address space was never treated as inventoried. The assumption was that an asset is a thing you can boot or open a console to. Allocations, subnets, and the public ranges announced under the org's ASN were left out, and that is the gap the control was written to catch.

Why IP address space is an asset your controls already cover

ISO 27001:2022 Annex A 5.9 asks for an inventory of information and other associated assets, each with an assigned owner. The phrasing is deliberate. "Other associated assets" pulls in the supporting infrastructure that information rides on, and an allocated range that routes production traffic qualifies as squarely as the host plugged into it. On the SOC 2 side, the AICPA points of focus under CC6.1 expect accurate network and data-flow diagrams, and a diagram you can't tie back to an authoritative allocation record is a drawing, not evidence.

So this is not a new control you have to invent. It's the inventory and ownership control you already attested to, applied to a class of asset most inventories silently skip. The address space is in scope whether or not anyone wrote it down.

The gap between an endpoint inventory and a network inventory

An endpoint inventory answers "what machines do we have." A network inventory answers "what address space do we hold, how is it carved, and what is live." Those are different questions, and the first does not roll up into the second. You can have every server in the CMDB and still not know that a /20 was sub-allocated to a since-dissolved project, or that a lab range bridged into a routed VLAN two reorgs ago.

Auditors test inventories with floor-to-list and list-to-floor walks. List-to-floor on address space is brutal: pick ten allocations from the register and prove what's actually announced or served on each. If the register is a wiki page last edited fourteen months ago, that walk produces a finding before lunch.

Ownership and accountability as auditable allocation metadata

Ownership is the part teams underestimate. Annex A 5.9 doesn't just want a list, it wants a named owner per asset, and an owner who can be asked to attest. For a subnet that means the allocation record itself carries the accountable team, the purpose, the date it was assigned, and the change that last touched it. When an auditor asks who is responsible for 192.0.2.0/24, "networking, probably" is not an owner.

Producing an authoritative allocation register on demand

The thing that converts a finding into a clean control is the ability to export, during fieldwork, a register that is current rather than reconstructed. Reconstructed means someone spent a panicked week diffing routing tables against a spreadsheet, and the auditor can usually tell, because the dates all cluster around the request. An authoritative register is one that was already right because allocations were recorded as they happened and reconciled against what DHCP and DNS actually serve.

This is the same discipline good IPAM enforces day to day: every prefix has an owner, overlaps are flagged before they route, and reclaim is gated on knowing who holds an address. Spot IPAM keeps that register inside the Environment that maps to your audited tenant, so the ownership metadata an auditor asks for is the same record your network team works from. When the request lands, you export the allocations rather than rebuild them. See how the allocation and ownership model holds up under that kind of walk.