SOC 2 Device Inventory: What Auditors Actually Check
A device list is not an inventory. What a SOC 2 auditor tests: completeness, discovery method, owners, reconciliation, and proof it held all period.
By SAUTERA
A device list is not an inventory. Every control percentage you show an auditor assumes you know which devices exist. If the list is wrong, every number built on it is too. Here is what auditors test.
What do SOC 2 auditors check in a device inventory?
They check five things. The list is complete, built by discovery rather than self-reporting, and tied to owners and security state. It was reconciled against other records and maintained for the whole period. A spreadsheet exported the week before fieldwork usually fails at least three of them.
SOC 2 does not publish one canonical control checklist, so the exact tests vary by firm and by how you scoped your system. One practitioner guide summarizes the direction of the updated criteria this way: service organisations must maintain accurate hardware and software inventories. Confirm the specifics with your auditor early.
Is a spreadsheet a valid SOC 2 device inventory?
It can be, but it is weak evidence. A spreadsheet records what is true right now, and when someone edits a cell the previous value disappears. An auditor testing a period needs to see how the inventory changed over that period, not only where it ended up.
Reftab's SOC 2 guidance makes this point directly: spreadsheets show what is true right now, and auditors want immutable audit logs of asset state changes with timestamps and user attribution. If you keep a spreadsheet, keep dated snapshots and a change history. Better, generate the list from a system that records changes itself.
How should the inventory be built: discovery or self-reporting?
Build it by discovery. A list assembled from employees telling you which machines they use is an honor system, and auditors tend to say so. The same Reftab guide warns that if self-reporting is your only discovery method, auditors will note that the inventory relies on an honor system rather than active discovery.
Discovery means something outside the person's own claim finds the device: an identity provider sign-in, a management enrollment, a network observation, a sensor on the host. The goal is to surface machines nobody told you about. Contractors on personal laptops, spare machines, and test hardware are the usual blind spots.
What fields does a device record need?
At minimum, enough to answer "whose is this, what is it, and what state is it in." The Konfirmity guide recommends a common core of unique ID, category, owner, department, location, lifecycle stage, acquisition date, last update, and status. For hardware it adds:
- Identity: serial number, model, and network identifiers.
- Software state: operating system.
- Assignment: the user the device is assigned to.
- Security state: encryption status.
The last item is the one most inventories lack. A register that says who has a laptop but not whether its disk is encrypted can answer a scoping question and nothing else. Joining the register to posture is what turns a list into evidence. We cover that for disk encryption and for patch status.
What does reconciliation mean to an auditor?
It means comparing the inventory with at least one independent source and recording what you found. Konfirmity suggests syncing with cloud accounts, HR, and procurement systems, and reconciling quarterly to catch orphaned assets and misclassifications. Reftab goes further on proof: auditors want evidence that reconciliation happened and that issues were addressed, not just that reviews were scheduled.
The payoff shows up in access control. The Konfirmity guide notes that auditors use the register to verify that controls cover all systems and that access is revoked for terminated staff. If a departed employee's laptop is still listed as active, or an active employee has no laptop on the list, the mismatch is the finding.
Run the comparison monthly if you can, and keep each result. A dated exception list with closure notes reads better than a clean report nobody can verify.
What if the management tool and the inventory disagree?
Expect questions. Reftab's guidance on completeness is blunt: if your device-management count and your inventory count differ, auditors will not assume the missing devices are unimportant. Each unmatched device needs a status and an explanation.
Typical reasons are benign: a laptop in a drawer, a device pending disposal, a machine reimaged and enrolled twice. Write the reason down. The ones that are not benign are the unmanaged machines that touch company data, and those are exactly what the reconciliation exists to find.
How do auditors treat personal and unmanaged devices?
They still expect proof. Drata's help article on personal devices says most companies will still be required to prove that devices used for business are configured securely, using management enrollment, the vendor's own device software, or screenshots from the workstation. If settings cannot be enforced, alternative controls may be used, but whether they are accepted is up to your auditor.
Decide your position before the audit. Either enroll the device, or document the compensating control and get the auditor's view on it. Leaving personal devices out of the register does not remove them from scope. It just means the register is incomplete.
Do remote workers' devices belong in the inventory?
Yes, where they are in scope. KirkpatrickPrice's SOC 2 guidance on inventorying physical devices tells organizations to consider remote locations and third parties, and names home offices among the places to include when scoping physical security under CC6.4. A laptop that sits in a kitchen is still a laptop that holds your data.
That also affects the loss scenario auditors like to probe. If you claim you can remotely lock or wipe a stolen laptop, the inventory is how you prove you know which laptop it was.
How do you prove the inventory held all period?
Keep periodic, system-timestamped exports across the whole audit window, plus the reconciliation records and exception trail. A single export from the audit month proves the present. The period is what the opinion covers.
Auditors usually sample. They select a device from your population and trace it: is it in the inventory, who owns it, what was its state in a given month, and is every gap explained? Rehearse that yourself. Pick ten devices at random and try to produce the same trail for each. Where you cannot, expect the auditor to notice. The same pattern applies to endpoint protection evidence, where the console alone cannot prove the population is complete.
Where does a continuous device record fit?
Manual exports are a stopgap. The durable approach is an inventory that the devices help produce: a sensor on each host reports what it is and what state it is in, continuously, and the history is kept. SAUTERA is an infrastructure-trust platform built around this idea. It scores device posture from observed telemetry and reports "Unknown" when it cannot prove a state, instead of rounding a missing signal up to a pass.
That honesty matters for inventory too. A device that has not checked in belongs on the exception list, not in the compliant count. The same discipline underlies continuous monitoring on devices. When a fix is needed, a person approves it and the action is recorded.
What does a defensible inventory package contain?
Five parts survive sampling:
- Scope statement. What counts as an in-scope device and who owns the list.
- Discovery method. How devices get onto the list without anyone self-reporting.
- Periodic exports. Owner, identifiers, and security state, system-timestamped across the period.
- Reconciliation records. The list compared with HR, identity, and procurement, with unmatched devices explained.
- Exception trail. Each gap, when it was found, what was done, and when it closed.
Takeaway
A device inventory is evidence of the population every other control depends on. Build it by discovery, record owner and security state, reconcile it against independent sources, and keep dated history for the whole period. An auditor will forgive an exception that was found and closed far sooner than a gap nobody knew existed.
Not sure your device list is complete? Start free with SAUTERA and see which devices your current tools have never seen.
Written by
SAUTERA
Author of the Infrastructure Trust Architecture (ITA) and the Infrastructure Trust Conveyance Mechanism (ITCM) — the standard organizations use to decide whether infrastructure can be trusted.
Follow the work
Read the next one
New perspectives on infrastructure trust and updates to the ITA / ITCM framework, by email.
Occasional. No spam. Unsubscribe anytime.