TL;DR
- Auditors ask for far less than teams prepare. Five artefacts cover almost every equipment question in a SOC 2 or ISO 27001 assessment.
- The hard one is not the asset list. It is proving that a specific device was wiped or recovered when a specific person left.
- A register that cannot show a date and a person for each event is a list, not evidence.
- Most teams fail on the leaver path rather than on inventory, because nothing records what happened to the laptop.
- Declare your scope. A register covering laptops completely beats one covering five categories at partial coverage.
- Start producing the evidence monthly before anybody asks for it. Retrofitting twelve months of history is the expensive version.
The Audit That Turned on One Laptop
The inventory was fine. Three hundred and eleven devices, serials, models, assigned holders, all exported neatly into a spreadsheet the auditor accepted without comment.
Then she asked about a single row. A developer who had left in March. What happened to her MacBook. The honest answer, assembled over two days from a Slack thread, an expense claim and somebody's memory, was that it had been posted back, received by an office manager who had since left, and either reissued to a contractor or put in a cupboard. Nobody could say which, and there was no record that it had been wiped.
That one row was the finding. Not the inventory, which was excellent. The inability to produce a date, a person and an action for one device at one moment, which is precisely what the control required and precisely what no asset register had been designed to hold.
Best tools for Device Management
The real issue is not whether you know what you own. It is whether you can show what happened to it.
The Five Artefacts Auditors Actually Ask For
Narrower than most teams prepare for, and worth knowing before you build anything.
A scoped asset inventory. What you own, within a stated scope, with serials and assigned holders. Almost everyone has this and it is rarely where findings come from.
Evidence of assignment. That a named person received a named device on a date, and acknowledged responsibility for it. Usually a signed acceptance or an equivalent record.
Evidence of recovery or disposal on exit. That when somebody left, their device was returned, wiped, reissued or disposed of, with a date and a responsible person. This is where findings happen.
Evidence of encryption and device state. That devices holding company data meet your stated baseline. Normally from your management platform rather than your asset register.
A policy and evidence that people saw it. The equipment policy itself, plus records that staff acknowledged it. We have written separately about acknowledgement tracking, and the mechanics are the same here.
That is the list. Notice that three of the five are about events rather than about state, and that most asset tooling is built for state.
When You Don't Need Any of This
No audit, no customer asking, no regulatory driver. Then equipment compliance evidence is insurance against an event with no date attached. That can be a reasonable purchase and it should be described honestly in the business case rather than as efficiency.
Under about 40 people in one place. At that size the knowledge genuinely is in somebody's head and retrieving it takes an afternoon. The artefacts matter once nobody can hold the whole picture.
You are mid-way through changing systems. Do not build evidence pipelines out of a platform you are leaving. Fix the destination first.
Your inventory is wrong. Evidence built on an inaccurate register is worse than no evidence, because you will attest to figures you cannot defend. Measure accuracy first; we cover the method in why asset registers go wrong.
What Teams Actually Need to Answer
Who had this device on this date? Not who has it now. Auditors pick a date in the past and ask. A register that only holds current state cannot answer, and overwriting the holder field on reassignment destroys exactly the history you need.
What happened to it when they left? Returned, wiped, reissued, destroyed, or still outstanding. With a date and a name against each.
How do you know it was wiped? A claim is not evidence. A certificate, a platform log, or a signed confirmation is.
What is in scope, and what is deliberately not? Auditors are entirely comfortable with a narrow scope, clearly stated. They are not comfortable with an unstated one, because then nothing can be tested.
Who is accountable for this process? A named role. Unowned processes produce exactly the gap in the opening story.
The Three Shapes of Equipment Compliance Evidence
A register plus manual evidence. The asset list lives in one system and the proof lives in tickets, emails and signed forms somewhere else. Works, and assembling evidence for an audit is a project every time, because nothing is linked.
A register that records events. Assignment, reassignment, return and disposal are entries with dates and actors rather than fields that get overwritten. Much better, and depends on somebody performing those entries reliably.
A platform where the evidence is a by-product. The record exists because the action happened: the device was shipped, received, wiped and recovered through the system, so the audit trail is a side effect rather than an obligation. Strongest for the leaver path, and blind to anything handled outside it.
| Shape | Produces inventory | Produces event history | Audit effort |
|---|---|---|---|
| Register plus manual evidence | Yes | Scattered | A project each time |
| Event-recording register | Yes | Yes, if maintained | Moderate, depends on discipline |
| Lifecycle platform | For devices it handles | Automatically | Low for in-scope devices |
How to Choose: Five Questions Before You Talk to a Vendor
Has anybody actually asked you for this? If yes, you need the leaver path solved and the rest is secondary. If no, price this as insurance.
Can your current register show history, or only current state? Test it. Pick a device reassigned six months ago and try to establish who held it in April. If the answer is no, that is the gap and it is architectural rather than a configuration problem.
Where does wipe confirmation come from today? Your management platform, a disposal vendor's certificate, or somebody's word. The third is not evidence.
What is your real scope? Write down what is excluded, get it agreed, and stop apologising for it. Narrow and complete is the goal.
Who owns the monthly production of this? Half a day a month, named. Evidence produced only when requested is evidence assembled under pressure from incomplete sources.
Building the Leaver Path, Which Is Where Findings Come From
This is the specific work that would have prevented the opening story, and it is a fortnight rather than a quarter.
Define the states a device can be in on exit. Returned and wiped. Returned and reissued. Returned and disposed of, with a certificate. Not returned, with a date and an escalation. Four states, no others, no blanks.
Attach a date and a person to every transition. Not just the final state. When it was requested, when it arrived, who confirmed the wipe. The transitions are what an auditor samples.
Decide where wipe confirmation comes from, once. A management platform log is the easiest defensible source. A disposal vendor's certificate works for destruction. A colleague saying they did it is not evidence and will be treated as none.
Make the trigger automatic. The offboarding process should create the equipment task, not rely on somebody remembering that the leaver had a laptop. Tying this to your HR system is covered in connecting the asset register to your HRIS.
Report outstanding items weekly, not at audit. A device unreturned for three weeks is recoverable. One unreturned for nine months is a finding and usually a write-off.
What Each Option Gives You
Every figure below was read from the vendor's own page on 16 October 2026, with script and style blocks stripped first.
| Option | Published pricing | Event history | Wipe evidence |
|---|---|---|---|
| AssetTiger | $15 a month unlimited items, $20 a month to 500 assets, then $40, $75, $140 and $275 | Limited | No |
| Snipe-IT | Free self-hosted; hosting from $399.99 a year | Check-in and check-out log | No |
| Lansweeper | No figure published; free tier available | Discovery snapshots | No |
| Jamf | Jamf for Mac $12.50 per macOS device per month | Device state over time | Yes, from the platform |
| Hexnode | $2.20, $3.20 and $4.70 per device per month | Device state over time | Yes, from the platform |
| RemoAsset | No figure published, quote-based with a demo required | Shipping and retrieval events | Via its own process |
Two cautions on that table. The Jamf figure covers a bundle of several products rather than its standalone management tool, so attaching it to the wrong product name overstates what the money buys. And the published Hexnode figures are per device per month, which at a few hundred devices is a materially different number from a flat platform fee.
Six Options Worth Knowing
Snipe-IT. Best for teams who need a defensible check-in and check-out history on a small budget, since the self-hosted edition is free and open source and the log is genuinely usable as evidence. Where it struggles: it holds no wipe confirmation, so half your leaver evidence comes from elsewhere, and self-hosting becomes a dependency on one person.
AssetTiger. Best where you need a cheap inventory with readable pricing from $15 a month. Where it struggles: history is thin, so answering who held a device last April is difficult, and that is exactly the question auditors ask.
Lansweeper. Best for office estates where discovery genuinely contributes to inventory completeness. Where it struggles: it depends on reaching devices, so a remote fleet produces a register that looks complete and is substantially stale, which is the worst possible input to an attestation.
Jamf. Best for Apple estates needing device-state and encryption evidence, which is the artefact your asset register cannot produce. Where it struggles: it is a management platform rather than an asset register, so assignment history and retrieval records still live elsewhere.
Hexnode. Best for mixed estates wanting published per-device pricing and device-state evidence in one place. Where it struggles: same boundary, in that it evidences the device rather than the custody chain.
RemoAsset. Best specifically for the leaver path, which is where findings come from. Disclosure that should shape how you read this: RemoAsset is owned by the same people who publish this site. Because it ships, recovers and wipes devices itself, the dates and actors an auditor samples are produced as a consequence of the work rather than recorded afterwards by somebody who has to remember. Where it struggles, stated plainly: pricing is quote-based and requires a demo, so it cannot be benchmarked against the published options above without a call; and it is a newer platform with a smaller footprint than the legacy global resellers, which matters if your estate spans unusual markets. It also evidences only devices it handles, so anything bought or retrieved outside it needs separate records, and it is not a management platform, so encryption and device-state evidence still comes from one of the tools above.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| No audit, no customer asking | Any | Spreadsheet | None yet | Buy nothing, state the scope |
| First SOC 2, inventory sound | 100 to 500 | Register exists | Leaver evidence missing | Build the four-state leaver path |
| Auditor sampled a past date | Any | Current-state register | No history | A register that logs events |
| Need encryption evidence | Any | Asset register only | Device state unprovable | A management platform |
| Remote fleet, register stale | 150 plus | Discovery tool | Attesting to stale data | Lifecycle events, not scanning |
| Devices disposed of informally | Any | No certificates | Cannot prove destruction | A disposal route that certifies |
| Inventory itself is wrong | Any | Any | Evidence built on sand | Measure accuracy first |
What the Vendor Demo Will Not Show You
Whether history survives a reassignment. Ask them to reassign a device and then show you who held it previously, with dates. Several products overwrite the field, which quietly destroys the evidence you are buying the system for.
What the export looks like to somebody outside IT. Your auditor will read a spreadsheet, not your dashboard. Ask for the actual export and look at whether the columns mean anything without explanation.
How it handles a device nobody can find. The honest answer is a state called outstanding with an escalation date. Products that force every record into a tidy status push the awkward cases into a blank field, and blank fields are what auditors find.
Retention. Evidence is only useful for as long as it exists. Ask how long event history is kept and whether you can export it, because an audit may reach back further than your subscription.
The Acknowledgement Artefact, Which Is Easy and Gets Forgotten
Of the five pieces of equipment compliance evidence, this is the cheapest to produce and the one most often missing, because it belongs to nobody in particular.
The control is simple: staff were told the rules about company equipment and confirmed they understood. The artefact is equally simple: a record that a named person acknowledged a named version of the policy on a date.
Where it goes wrong is version control. An acknowledgement against "the equipment policy" is close to worthless, because the policy has been edited twice since. What you need is an acknowledgement against a specific version, with the text of that version still retrievable. If your policy lives in a document that gets edited in place, the version somebody agreed to no longer exists, and the record points at nothing.
The second failure is coverage. Acknowledgement is usually captured at induction and never again, so anybody who joined before you started capturing it has no record, and everybody has acknowledged a version that predates the last two changes. A one-off re-acknowledgement exercise fixes the backlog in a fortnight.
What to do: three things, none of them large. Version the policy so each release has an identifier and the text is preserved. Capture acknowledgement against that identifier rather than against the policy generally. And re-run acknowledgement whenever the policy materially changes, rather than only at induction.
That is the whole artefact. It is perhaps two days of setup and it removes an entire category of finding, which makes it the best return available in this area.
What Differs Between SOC 2 and ISO 27001
The equipment compliance evidence overlaps heavily, and the differences are worth knowing because they change what you prioritise.
SOC 2 tests your own stated controls. You write what you do, and the assessment checks whether you did it over a period. That makes the wording of your control description the thing that determines your workload. A control saying all devices are wiped within five working days of departure creates a far heavier evidence burden than one saying devices are recovered and wiped as part of offboarding, with exceptions documented. Both are honest. One is much easier to evidence.
ISO 27001 tests against a defined set of controls and expects a risk-based justification for how you treat each. The equipment questions sit mostly around asset management and secure disposal, and the emphasis is on having a documented approach and evidence that you follow it rather than on a specific interval.
The practical consequence is about drafting. For SOC 2, the highest-value hour you will spend is reviewing your own control language before the observation period starts, because that language sets the bar you will be held to. Teams routinely write ambitious wording in year one and then spend the assessment explaining exceptions against a standard they set themselves.
Both care more about consistency than completeness. An organisation that applies a narrow, clearly stated process reliably will do better than one with a broad policy applied unevenly. That is the single most useful thing to understand about either framework, and it is why declaring your scope is worth more than extending it.
What to do: read your own control descriptions as though you were the person who has to produce the evidence, because you are. Where the wording commits you to an interval, a percentage or an absolute, ask whether you can show it for every instance across the whole period. If not, change the wording now rather than explaining it later.
How Auditors Actually Sample
Understanding the sampling method changes what you prepare, and most teams prepare for the wrong thing.
Auditors do not read your inventory. They take your population, pick a small number of items from it, and test each one against the control you claimed. For equipment that usually means somewhere between five and twenty-five devices depending on population size and the assessment type, chosen by them rather than offered by you.
The selection is deliberately awkward. They will favour devices belonging to people who have left, because that tests the exit control rather than the easy one. They will favour older records, because those test whether your process held a year ago rather than last month. And they will sometimes pick a device that appears in one system and not another, because inconsistency between sources is the most productive thing to pull.
What to do: sample yourself, first, using their method. Take your own leaver list for the last twelve months, pick eight at random, and try to produce the four artefacts for each: assignment record, return date, wipe confirmation, final disposition. Time how long it takes you.
If eight records take a day, your evidence is in reasonable shape and the audit will be uneventful. If they take a week and two come back unresolvable, you have found your finding before somebody else did, which is the entire point of doing it.
The other benefit is that it tells you which source is unreliable. Teams usually discover that assignment is well recorded, returns are patchy, and wipe confirmation exists for some devices and not others depending on who handled them. That is a much more actionable conclusion than a general sense that the records could be better.
One more thing worth knowing: an auditor finding a gap you have already documented and are remediating is a very different conversation from one finding a gap you did not know about. Self-identified issues with a plan attached are treated as evidence that the control environment works. The same issue found cold is a deficiency.
The Encryption Artefact, Which Comes From Somewhere Else
Of the five artefacts, this is the one your asset register cannot produce, and teams routinely discover that two weeks before an assessment.
The control usually reads something like: devices storing company data are encrypted at rest. Proving it requires a source that can see the device's actual configuration, which means a management platform rather than an inventory. An asset register knows a laptop exists and who has it. It has no idea whether disk encryption is on.
What the evidence looks like. A report from your management platform listing devices and their encryption state, dated, covering the population you claimed. Not a screenshot of one machine. Not a policy saying encryption is required. A list, with a date, that an auditor can compare against your inventory.
The reconciliation is the real work. Your management platform knows about devices it manages. Your asset register knows about devices you own. Those two populations are never identical, and the difference is the interesting part. Devices in the register but not the platform are unmanaged and therefore unevidenced. Devices in the platform but not the register are a different problem, usually something bought outside the process.
What to do: run both exports monthly and compare the counts. Report three numbers rather than one: devices owned, devices managed, devices confirmed encrypted. If the first and second differ by more than a few per cent, that gap is the thing to fix before the assessment, because it is the question an auditor will ask as soon as they see both lists.
Jamf publishes Jamf for Mac at $12.50 per macOS device per month, and that figure covers a bundle of several products rather than its standalone management tool, so attach it carefully. Hexnode publishes $2.20, $3.20 and $4.70 per device per month across its tiers. Either will produce the artefact; the choice depends on your platform mix rather than on compliance capability.
Contractor and BYOD Devices, Which Break the Model
Every framework assumes you own the device. A meaningful share of real estates include machines you do not own, and the evidence model has to be different rather than absent.
You cannot wipe what you do not own. A contractor's own laptop cannot be remotely wiped on exit, so a control promising that is a control you will fail. The honest version is narrower: company data is removed from the device, or the device never held company data because access was through a browser session you can revoke.
The evidence shifts from the device to the access. For owned hardware, you evidence the device. For personal hardware, you evidence that access was granted, scoped and withdrawn, with dates. That is an identity artefact rather than an equipment one, and it usually comes from your directory rather than your asset register.
Scope it out explicitly, with a reason. The strongest position is a stated scope that excludes personal devices, paired with a compensating control about access and data handling. The weakest is silence, because an auditor who finds contractors using personal machines inside an unstated scope will ask what else the scope excluded.
What to do: list every population separately. Company-owned and managed. Company-owned and unmanaged. Contractor-owned with access. Each needs its own evidence story, and writing them as three lines prevents the assessment conversation where somebody realises a fifth of the workforce was never in scope. We have covered the policy side in BYOD policy, and the compliance angle is narrower: you are evidencing access rather than hardware.
What to Do When Preparation Finds a Gap
It will, and how you respond matters more to the outcome than the gap itself.
Write it down the day you find it. A dated note describing the gap, its cause and its remediation plan converts a deficiency into a self-identified issue. That distinction is not cosmetic; it changes how the finding is characterised.
Do not retrospectively create records. The temptation to backfill a wipe confirmation from memory is understandable and it is the one thing that turns a minor gap into a serious one. An absent record is a gap. A fabricated record is a misrepresentation, and auditors are experienced at spotting documents created in a batch after the fact.
Fix forward, and say so. The defensible position is that the process changed on a stated date, evidence exists from that date onward, and the prior period has a documented gap. Assessors see this constantly and handle it routinely.
Prioritise by what gets sampled. Leaver records from the last twelve months matter most, because that is the population auditors draw from. Perfecting your current-state inventory while the leaver history stays patchy is effort spent in the wrong place.
Fix the trigger, not the instance. If three leavers had no equipment task raised, the fix is tying the task to the offboarding process rather than chasing three laptops. Otherwise the same gap reappears next quarter with different names.
The Outstanding-Equipment Number, and Why It Should Be Visible
One figure does more to keep equipment compliance evidence honest than any system: the count of devices that should have come back and have not.
Most teams do not have it. They have a list of leavers and a register of devices, and the intersection is something nobody computes until an auditor asks. The result is that unreturned equipment accumulates invisibly, and the longer it accumulates the less recoverable it becomes.
Compute it weekly and age it. Devices outstanding under two weeks are in transit and uninteresting. Two to six weeks is a chase. Beyond six weeks the realistic outcome is a write-off, and the number you report should say so rather than implying recovery is still likely.
Give it an owner who is not IT. This matters more than it sounds. IT can raise the task and post the label; it cannot compel a former employee to return hardware. The escalation that works runs through the person's former manager and, past a threshold, through whoever handles final pay, subject to whatever your local rules allow. Deciding that chain in advance, rather than per incident, is what turns a six-week chase into a two-week one.
Report it alongside the inventory, always. A register of 311 devices means something different if 14 of them are outstanding and nine have been outstanding for four months. Publishing both numbers together is the same discipline as reporting devices known alongside devices confirmed, and for the same reason: a single figure invites a conclusion the data does not support.
Write off deliberately, with a date and an approver. Devices that will not come back should leave the register through a decision rather than by being quietly deleted. An auditor seeing a device disappear from one export to the next will ask what happened, and "it was written off on this date by this person" is a complete answer where silence is not.
The teams who handle this well treat the outstanding number as an operational metric rather than a compliance artefact, and the compliance benefit arrives as a side effect. The teams who struggle compute it once a year, under pressure, and discover a figure nobody wants to put in a report.
Producing the Monthly Pack
The habit is the control. Five artefacts, half a day, same time each month.
Checklist:
- Inventory export, with the scope statement attached
- Management platform export, with encryption state
- Reconciliation of the two, with the difference explained
- Leaver list for the month, with disposition against each device
- Outstanding items, with age and escalation status
- Any new policy acknowledgements
File it somewhere a successor will find it. The characteristic failure is a year of excellent evidence in the personal drive of somebody who has since changed role. A dated folder in shared storage, with a one-page note saying what each file is and where it came from.
Keep the exports, not just the dashboards. A dashboard shows you today. An auditor asks about March. Only a stored export answers that, and regenerating a historical view is usually impossible.
Do this for two quarters and the assessment becomes a matter of handing over files that already exist. That is the entire objective, and it is considerably less work than the alternative.
What Getting This Wrong Costs
The visible cost is audit remediation, which is a few weeks of somebody assembling history from Slack and memory. That is annoying and survivable.
The expensive version is attesting to something you cannot support. A control that says devices are wiped on exit, signed off on the strength of a process nobody evidenced, is a materially different problem from a gap you declared. Auditors are reasonable about scope and unreasonable about claims that do not hold, and rightly so. The teams who come through these assessments well are not the ones with the most complete records. They are the ones whose records match exactly what they said their records were.
The second cost is slower. An organisation that treats equipment compliance evidence as an annual scramble never builds the monthly habit, so each audit costs the same again, and the gaps found are the same gaps. Producing five artefacts monthly is less work in total than producing twelve months of them once a year under pressure.
So the question is not whether your inventory is good. It is whether you can show a date, a person and an action for one device at one moment, chosen by somebody else.
When You're Ready to Build It
Start with the leaver path, because that is where findings come from and because it is a fortnight of work rather than a platform migration. Four states, a date and a person on every transition, and a defensible source for wipe confirmation.
Then test your own register the way an auditor will. Pick a device reassigned six months ago and establish who held it in April. If you cannot, you have an architectural gap rather than a data-entry problem, and no amount of tidying will close it.
And write down your scope. The single most common unforced error in this area is apologising for a narrow scope instead of stating it, because a declared boundary is testable and an undeclared one makes every number untrustworthy.
One closing note on sequencing, because it determines how much of this costs. Everything above is cheaper before an assessment is booked than after. The leaver path, the version-controlled acknowledgement, the monthly reconciliation and the outstanding-equipment number are each a fortnight of unhurried work in a normal quarter, and each becomes a scramble once a date is in the diary and an assessor is asking for a population. Teams who build equipment compliance evidence as an operational habit find the assessment is a matter of handing over files that already exist. Teams who build it in response to an assessment produce the same artefacts at three times the cost, under pressure, with the gaps found by somebody else rather than by themselves. The work is identical. Only the order changes, and the order is the entire difference between a clean report and a list of findings.
Frequently Asked Questions
What equipment compliance evidence do auditors actually ask for?
Five artefacts cover almost everything: a scoped asset inventory, evidence that a named person received a named device on a date, evidence of what happened to that device when they left, evidence that devices meet your encryption baseline, and the policy plus acknowledgement records. Three of those five are about events rather than current state, which is the mismatch that catches teams out, because most asset tooling is built to hold state.
Why does the leaver path cause most findings?
Because it is the one artefact nothing records automatically. An inventory is easy to produce and a policy is easy to show, but establishing that a specific laptop was returned, wiped and either reissued or destroyed, with a date and a responsible person, requires that somebody captured those events at the time. When nobody did, the answer gets assembled months later from chat threads and memory, and that assembly is itself the finding.
Is a spreadsheet enough?
For inventory, often yes, provided it is accurate and its scope is stated. For event history it usually is not, because spreadsheets get overwritten rather than appended, so the previous holder disappears the moment a device is reassigned. Test yours by picking a device reassigned six months ago and trying to establish who held it before. If you cannot, the gap is structural rather than a matter of tidiness.
How do we prove a device was wiped?
From a defensible source rather than an assertion. A management platform log showing the wipe command and its result is the easiest, a disposal vendor's certificate of destruction works where the device was destroyed, and a signed confirmation from a named person is acceptable if nothing better exists. A colleague recalling that they did it is not evidence and will be treated as none.
Can we limit the scope?
Yes, and you should. Auditors are entirely comfortable with a narrow scope that is clearly stated and consistently applied, which is why a register covering laptops completely is stronger than one covering five categories at partial coverage. What causes problems is an unstated scope, because then nothing is testable and every figure invites a question about what it excludes.
Does a management platform replace an asset register?
No, and the two cover different artefacts. A management platform evidences the state of a device, including encryption and configuration, which an asset register cannot. An asset register evidences custody, meaning who had what and when, which a management platform generally does not hold properly. Most teams need both, with one designated as authoritative for each fact so nobody has to reconcile them.
How often should we produce this evidence?
Monthly, and before anybody asks. The total effort of producing five artefacts each month is lower than assembling twelve months of history once a year under audit pressure, and the monthly rhythm surfaces gaps while they are still fixable. A device unreturned for three weeks is recoverable; the same device at nine months is a finding and usually a write-off.
What should we check before buying anything for this?
Whether assignment history survives a reassignment, what the raw export looks like to somebody outside IT, how the system represents a device nobody can locate, and how long event history is retained. That last one matters more than it sounds, because an audit can reach back further than your subscription has existed, and evidence you can no longer export is evidence you no longer have.