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

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:

1. The organisation expects the device to exist.
2. The device is assigned to an accountable owner or lifecycle state.
3. A management or monitoring control is actively reporting from it.
4. 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:

1. Scope statement

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

2. Expected population

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

3. Reconciled inventory

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

4. Security and update exceptions

   Unknown, failed, stale, unsupported, or non-compliant states with accountable owners.

5. Change and action history

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

6. 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:

1. Collect endpoint state
2. Identify the exception
3. Permit controlled action
4. 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

• NIST Cybersecurity Framework 2.0
• Australian Signals Directorate: Guidelines for system management
• Microsoft Learn: See device details in Intune
• Microsoft Learn: App inventory for Windows devices

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.