Skip to content
OnTrackio

SOC 2 asset inventory: what auditors actually ask for

2026-07-02

The SOC 2 criteria never say “you must keep an asset inventory.” Teams preparing for a first audit search the Trust Services Criteria for the requirement and cannot find it, then get an evidence request list with the inventory sitting in the first ten items. The obligation is real, but it lives one layer below the criteria text, in the points of focus and in how auditors test. This post walks through where the requirement actually comes from, which criteria your asset records feed, and what the evidence has to look like to survive a Type II observation window.

Where SOC 2 actually asks for an inventory

The 2017 Trust Services Criteria (with revised points of focus, 2022) are outcome statements. CC6.1, the anchor criterion for logical access, requires the entity to implement “logical access security software, infrastructure, and architectures” over its protected information assets. No artifact named.

The artifact appears in CC6.1’s points of focus, which include identifying and managing the inventory of information assets: the entity identifies, inventories, classifies, and manages information assets. Points of focus are not individually mandatory. They exist to guide the design of controls and the auditor’s tests. In practice that distinction changes little: you cannot demonstrate that access to protected information assets is restricted if you cannot produce the list of assets, so the inventory becomes the first thing an auditor asks for and the foundation every CC6 test stands on.

Two properties matter more than the list itself. First, ownership: each entry needs a person or team accountable for it. Second, classification: the auditor needs to see which assets touch customer data or production systems, because that is what defines audit scope. An inventory with blank owner and classification columns reads as a control that exists on paper.

The criteria your asset records feed

Asset data does not stop at CC6.1. Walking the common criteria, a maintained inventory feeds tests across the report:

The pattern across all seven: the auditor rarely tests a document. They test whether a record set that could only exist if the control operated does in fact exist.

The evidence request list, concretely

Fieldwork requests for the asset and access portion of a SOC 2 audit converge on the same items. Industry checklists from audit firms describe asset management testing as two questions: is the inventory complete, and are the assets on it managed? Expect to produce:

  1. The inventory export with owner, classification, status, and location or custody for hardware. Dated, so it can be tied to the period.
  2. Reconciliation evidence. Proof the inventory matches reality: a comparison against your MDM, cloud resource list, or endpoint agent data, with exceptions investigated.
  3. Joiner and leaver samples. For a sample of hires and departures across the period: when access was granted, what was granted, when it was removed, and who approved it.
  4. Offboarding proof. For departed employees: the returned device, or the remote wipe record, and the access revocation timestamp. An ex-employee still holding a laptop three months after departure is a finding. We cover this sample in depth in SOC 2 offboarding: proving the assets came back.

If you want the inventory as a working file rather than a description, we keep an ungated SOC 2 asset inventory template (XLSX): separate hardware, SaaS, and cloud sheets, the owner and classification columns auditors go to first, and a review log sheet for the Type II window. No email gate. 5. Disposal records. Sanitization or destruction certificates linked to specific asset entries, with authorization before the fact. 6. Recurring review evidence. Access reviews and inventory reviews that happened on schedule during the window, not once, the week before the audit.

Completeness is the actual test

Auditors do not take the inventory’s word for it. The standard test compares your asset register against an independent source: the MDM enrollment list, the cloud console, the identity provider’s device records. Every machine on the network that is missing from the register, and every register entry no longer on the network, is an exception you will be asked to explain.

This is where spreadsheet inventories fail audits. A spreadsheet is an assertion; discovery data is evidence. An endpoint agent that reports each device’s presence, OS version, and installed software daily gives the auditor the reconciliation directly: the register and reality are the same dataset. The same applies to seats: license records reconciled against actual installed software catch the orphaned licenses and shadow tools that turn up as CC8.1 and CC9.2 questions.

Type II means the period, not the snapshot

A Type I report evaluates control design at a point in time. Most customers, especially enterprise procurement teams, ask for Type II, which covers an observation window of 3 to 12 months. That changes what your records need to be.

For a Type II, the auditor samples across the window: a leaver from month two, an asset disposed of in month five, an access review from month seven. If your inventory was reconstructed the month before fieldwork, the samples have nothing to land on. The records that carry a Type II are timestamped change histories, activity logs with retention longer than the window, and review artifacts generated when the review happened. This is the strongest argument for making the asset register a live system rather than an audit-season document: the evidence accumulates as a side effect of operating.

If you already hold ISO 27001

European companies selling into the US market usually arrive at SOC 2 from the other direction: an ISO 27001 certificate in hand, and a US prospect’s security questionnaire asking for a SOC 2 report anyway. The two frameworks want substantially the same asset record. ISO 27001:2022 control A.5.9, inventory of information and other associated assets, maps closely to CC6.1’s inventory point of focus, and the ownership and classification you populated for ISO carry over unchanged.

What changes is the vocabulary and the artifact. A US buyer’s diligence process expects Trust Services Criteria references and, ultimately, an auditor’s report. If your estate data lives in a system that can present it in either vocabulary, the second framework is mostly packaging. That is the design behind OnTrackio’s built-in crosswalk: the same asset, user, and access records render as NIS2 Article 21 evidence for a European regulator and as CC-mapped evidence for a US auditor. The same logic applies in reverse for US-based teams: the inventory work you do for SOC 2 is the same record NIS2 asks European operations for, one dataset answering both. We wrote up the NIS2 side in NIS2 asset management evidence: what the law requires.

How OnTrackio produces this evidence

OnTrackio is an IT asset management platform, and the SOC 2 evidence above is a direct export of what it already tracks. The SOC 2 CC6 evidence pack generates from live workspace data: the classified inventory with owners, the counts an auditor circles first (users without MFA, offboarded people still holding assets, orphaned licenses), and the access trail behind them. SCIM 2.0 provisioning against Okta or Microsoft Entra writes the joiner-mover-leaver record automatically, with every grant and revoke audit-logged with its provenance. The endpoint agent supplies the reconciliation: register versus reality, daily.

Honesty about scope: this is the ITAM-shaped portion of a SOC 2 audit. Policies, security awareness, vendor management beyond your software estate, and the auditor’s own testing sit outside what an asset platform can produce. Our own SOC 2 Type II clock is a work in progress with the observation window ahead of us; our current posture is public on the security page. If you are preparing for an audit and want the asset and access portion to fall out of a system instead of a spreadsheet sprint, book a 30-minute demo and bring your auditor’s request list. US teams can start at the US overview.

Frequently asked questions

Does SOC 2 explicitly require an asset inventory? Not in the criteria text. The requirement lives in CC6.1’s points of focus, which name identifying, inventorying, classifying, and managing information assets, and in every auditor’s evidence request list in practice.

What asset evidence does a SOC 2 auditor typically request? The inventory export with ownership and classification, reconciliation against an independent source like MDM or an endpoint agent, joiner and leaver samples with grant and revocation dates, offboarding and disposal records, and recurring review evidence across the period.

What changes between a Type I and a Type II audit for asset records? Type I is a point-in-time design review; a current export can carry it. Type II samples across a 3 to 12 month window, so records need timestamps, change history, and reviews that happened on schedule during the period.

Does using OnTrackio make us SOC 2 compliant? No. A SOC 2 report is an auditor’s opinion on your whole control environment. OnTrackio produces the asset, access, and offboarding evidence feeding the CC6 family and related criteria; policies and the audit itself remain yours.

We hold ISO 27001 already. How much of this evidence do we have? Most of it: A.5.9 asks for substantially the same inventory. The remaining work is presentation, because a US buyer expects the evidence in Trust Services Criteria vocabulary and, eventually, an auditor’s report.

Doing this by hand today? The free templates carry the same structure this guide describes: NIS2 register, SOC 2 inventory, offboarding checklist. Or see the register that maintains itself: book a 30-minute demo.