How to Prove Every Company Laptop Is Managed: An Endpoint Audit Evidence Checklist

Ian Jasper Sivam — Sun, 02 Aug 2026 15:34:12 +0000

A spreadsheet containing laptop serial numbers is not proof that every endpoint is managed. It proves only that someone created a spreadsheet.

For an audit, customer security review, onboarding check, or incident investigation, the evidence needs to connect four facts:

The organisation expects the device to exist.
The device is assigned to an accountable owner or lifecycle state.
A management or monitoring control is actively reporting from it.
The reported evidence is recent enough to support the decision being made.

A device can appear in an asset register while being absent from the management platform. It can also appear in the management platform while belonging to a former employee or reporting data that is months old.

Control objective: Maintain a current, reconciled inventory of expected endpoints, managed endpoints, owners, security state, and unresolved exceptions.

1. Define what "managed" means before counting devices

Teams often use the word managed without an operational definition. That creates false confidence. An endpoint should not count as managed merely because an agent was installed once.

For a company-owned laptop, a practical definition normally requires all of the following.

Criterion	Minimum evidence
Identity	Hostname, serial number, hardware identifier, operating system, and management record can be tied to one device
Ownership	Named user, department, custodian, stock status, repair status, or retirement state
Control	Expected MDM, RMM, EDR, or other endpoint control is enrolled and associated with the correct organisation
Freshness	Last check-in and evidence timestamps fall within a documented threshold
Posture	Update, encryption, firewall, antimalware, restart, and other required states are known
Accountability	Deviations have a reason, owner, approval, target date, and review history

A device that fails one criterion should not disappear from the report. It should remain visible as an exception.

2. Reconcile three sources of truth

No single system usually proves complete fleet coverage. Each source answers a different question.

HR or identity roster

This shows who currently works for the organisation, which employment state applies, and which users should possess company equipment.

Procurement or asset register

This shows which laptops were purchased, received, assigned, stored, repaired, lost, returned, or retired.

Endpoint platforms

MDM, RMM, EDR, and similar platforms show which devices are currently enrolled, checking in, reporting posture, and available for approved administration.

Use stable identifiers wherever possible:

Manufacturer serial number
Hardware UUID or platform identifier
Agent or enrolment identifier
Asset tag
Primary user or custodian
Hostname and tenant or domain

Names and email addresses change. Hostnames can be reused. A stable identifier reduces false matches.

Classify every mismatch

Mismatch	Likely meaning	Required action
Employee exists, no assigned endpoint	New starter, shared device, incomplete onboarding, or no device required	Confirm the expected state and record the decision
Asset exists, no endpoint record	Agent missing, device offline, stored equipment, repair, or registration failure	Locate the asset and restore reporting or classify its lifecycle state
Endpoint exists, no asset record	Unrecorded purchase, duplicate, personal device, test system, or unauthorised asset	Identify ownership and approve, register, isolate, or remove it
Former user remains assigned	Incomplete offboarding or stale ownership data	Recover, wipe, reassign, store, or retire the device
Device has not checked in	Travel, leave, failure, reimage, disposal, or control removal	Investigate according to the evidence-age threshold

3. Collect the minimum evidence needed

More fields do not automatically produce better evidence. Collect fields that answer identity, ownership, control, posture, history, and accountability questions.

Evidence group	Minimum fields	What it supports
Device identity	Hostname, serial number, manufacturer, model, hardware identifier	The record refers to a specific endpoint
Ownership	Assigned user, department, custodian, asset tag, lifecycle state	The organisation knows who is accountable
Management state	Agent or enrolment ID, profile, first seen, last seen, agent version	The device is connected to the intended control plane
Operating system	Edition, version, build, architecture, install date, last boot	Platform and support context are known
Update evidence	Last scan, last successful install, pending updates, failures, restart state	Patch conclusions are based on current evidence
Security posture	Disk encryption, firewall, antimalware or EDR, Secure Boot, TPM where applicable	Required endpoint controls have known states
Software	Application name, version, publisher, install scope, detection time	Installed software can be reviewed and investigated
Change history	Ownership, software, update, posture, enrolment, and administrator events	Current state can be distinguished from historical changes

The NIST Cybersecurity Framework 2.0 includes asset-management outcomes for maintaining inventories of managed hardware and managed software, services, and systems.

The Australian Signals Directorate's Guidelines for system management state that software registers should contain versions and patch histories for applications, drivers, operating systems, and firmware.

Microsoft's current Intune documentation shows the same practical pattern at the device level: identity, ownership, hardware, installed applications, compliance, and configuration status are separate pieces of evidence rather than one generic health score.

Do not infer evidence that was not collected.

An empty encryption field is not the same as "not encrypted". It may mean collection failed, the platform is unsupported, or the device has not reported recently. Use explicit states such as compliant, non-compliant, unknown, unsupported, and stale.

4. Set evidence freshness rules

A correct inventory snapshot eventually becomes stale. The acceptable age depends on how often devices are expected to connect and how quickly the underlying state can change.

A simple operating model is:

State	Meaning
Current	Evidence is recent enough for normal operational and audit use
Review	The device is approaching the threshold and needs context
Stale	The reported state can no longer support a current conclusion
Exception	A documented reason, owner, compensating control, and review date exist

Do not use one threshold for every field.

A serial number changes rarely. Installed software, update state, restart requirements, and security posture can change quickly. Store collection timestamps at the evidence level where possible.

5. Treat exceptions as controlled work

The objective is not to produce a perfect green dashboard. It is to expose gaps and show that each gap is understood and controlled.

Each exception should include:

Affected device and control
Evidence that triggered the exception
Severity or operational priority
Assigned owner
Business or technical reason
Approved compensating control, where relevant
Target resolution or review date
Status and activity history

Examples include a laptop held in evidence, a travelling employee with limited connectivity, a known update block, an approved legacy application, or a device awaiting replacement.

The exception should remain visible until it is resolved or formally retired.

6. Build an audit package that can be reproduced

A useful audit package lets another reviewer understand the scope, collection time, population, exceptions, and responsible owners without reconstructing the process from screenshots.

Include:

Scope statement

Organisation, business unit, device types, operating systems, locations, and exclusions.
Expected population

Current employees, contractors, shared devices, stock, loan units, repair units, and other lifecycle states.
Reconciled inventory

One row per device with stable identifiers, owner, management state, and last evidence time.
Security and update exceptions

Unknown, failed, stale, unsupported, or non-compliant states with accountable owners.
Change and action history

Material inventory changes and approved administrative actions during the review period.
Method and limitations

Collection tools, refresh intervals, unsupported fields, known blind spots, and export timestamp.

Preserve the original export or report, its generation time, and any filtering criteria.

A screenshot can support a finding, but it should not be the only evidence when structured records are available.

Endpoint audit evidence checklist

Use this as a working review list:

[ ] Define the criteria an endpoint must meet to count as managed
[ ] Export the current HR or identity roster
[ ] Export the current procurement or asset register
[ ] Export all endpoint records from the relevant management platforms
[ ] Match records using serial numbers and other stable identifiers
[ ] Identify employees without expected devices
[ ] Identify assets without current endpoint records
[ ] Identify endpoint records without approved assets or owners
[ ] Identify stale devices using documented evidence-age thresholds
[ ] Review unknown, unsupported, failed, and non-compliant states separately
[ ] Assign owners and target dates to every unresolved exception
[ ] Preserve the export time, scope, filters, and collection limitations
[ ] Retain the reconciled inventory and exception history for the audit period

Where Snipe RMM fits

Snipe RMM is being developed around the evidence lifecycle used in this guide:

Collect endpoint state
Identify the exception
Permit controlled action
Preserve administrative history

The platform is intended to help lean IT and security teams inspect Windows and Linux endpoint records, review posture evidence, triage alerts, and use approved operational actions from one tenant-scoped interface.

It can support:

Endpoint identity and inventory evidence
Last-seen and evidence-age review
Security posture and operational exceptions
Controlled jobs and auditable activity
Fleet-level and device-level investigation

It does not claim to:

Automatically certify an organisation against a framework
Replace organisational policies and procedures
Prove data that the agent or integration did not collect
Remove the need for human exception review

You can inspect the current workflow in the interactive Snipe RMM demo.

Authoritative references

This article describes an operational evidence workflow. It is not legal advice, audit certification, or a guarantee that any specific framework requirement has been met.

Originally published by Snipe RMM.

DEV Community: Snipe RMM