A spreadsheet containing laptop serial numbers is not proof that every endpoint is managed. It proves only that someone created a spreadsheet.
Defensible endpoint evidence has 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.
This distinction matters during security reviews, customer questionnaires, internal audits, onboarding, offboarding, and incident response. 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.
Maintain a current, reconciled inventory of expected endpoints, managed endpoints, owners, security state, and unresolved exceptions.
01
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 company-owned laptops, a practical definition normally requires all of the following:
Uniquely identifiable
Hostname, serial number, hardware identifier, operating system, and management record can be tied to one physical or virtual device.
Assigned or classified
The device has a named user, department, custodian, stock status, repair status, or retirement state.
Actively enrolled
The expected MDM, RMM, EDR, or other endpoint control is installed and associated with the correct organisation.
Recently reporting
The last check-in and evidence timestamps fall within a documented threshold appropriate to the fleet.
Security state known
Update, encryption, firewall, antimalware, restart, and other required controls have known states rather than blank values.
Exceptions owned
Any deviation has 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.
02
Reconcile three sources of truth
No single system usually proves complete fleet coverage. Reconciliation is necessary because each system answers a different question.
HR or identity roster
Who currently works for the organisation, which employment state applies, and which users should possess company equipment?
Procurement or asset register
Which laptops were purchased, received, assigned, stored, repaired, lost, returned, or retired?
Endpoint platforms
Which devices are currently enrolled, checking in, reporting posture, and available for approved administration?
Match records using stable identifiers
Names and email addresses change. Hostnames can be reused. Use the most stable combination available:
- Manufacturer serial number
- Hardware UUID or platform identifier
- Agent or enrolment identifier
- Primary user or custodian
- Asset tag
- Hostname and domain or tenant
Classify every mismatch
| Mismatch | Likely meaning | Required action |
|---|---|---|
| Employee exists, no assigned endpoint | New starter, shared device, missing asset assignment, or incomplete onboarding | Confirm whether a company device is required 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 record, 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 |
03
Collect the minimum evidence needed to support the control
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 proves |
|---|---|---|
| Device identity | Hostname, serial number, manufacturer, model, hardware identifier | The endpoint record refers to a specific device |
| Ownership | Assigned user, department, custodian, asset tag, lifecycle state | The organisation knows who is accountable for the asset |
| 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 | The software platform and support context are known |
| Update evidence | Last scan, last successful install, pending updates, failures, restart state | Patch status is based on current endpoint 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, detected date | Installed software can be reviewed and investigated |
| Change history | Ownership, software, update, posture, enrolment, and administrator events | The reviewer can distinguish current state from historical changes |
NIST Cybersecurity Framework 2.0 includes outcomes for maintaining inventories of managed hardware and of managed software, services, and systems. Australian Signals Directorate guidance also calls for regularly verified software registers containing versions and patch histories for applications, drivers, operating systems, and firmware.
An empty encryption field is not the same as "not encrypted". It may mean the collection method failed, the platform is unsupported, or the device has not reported recently. Use explicit states such as compliant, non-compliant, unknown, unsupported, and stale.
04
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:
Evidence is recent enough for normal operational and audit use.
The device may be travelling, on leave, or intermittently connected. Confirm context.
The reported state can no longer support a current compliance or security conclusion.
The reason, owner, compensating control, and review date are documented.
Do not use one threshold for every field. A serial number changes rarely. Installed software, update state, and restart requirements can change quickly. Store collection timestamps at the evidence level where possible.
05
Treat exceptions as controlled work, not hidden rows
The point of an audit-ready inventory is not to produce a perfect green dashboard. It is to expose gaps and show that each gap is understood and controlled.
Each exception record should contain:
- The affected device and control
- The 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 device travelling in an area with limited connectivity, a known update block, an approved legacy application, or a machine awaiting replacement. The exception should remain visible until it is resolved or formally retired.
06
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.
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, control 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.
07
Where Snipe RMM fits
Snipe RMM is being developed around the evidence lifecycle used in this guide: collect endpoint state, identify exceptions, permit controlled action, and 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.
- 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
- Automatic certification against a framework
- Replacement of organisational policies and procedures
- Proof for data the agent or integration did not collect
- Removal of the need for human exception review
Snipe RMM Early Access
Inspect the evidence model in the interactive demo.
Open device records, review posture evidence, inspect alerts, and see how administrative history is organised.
Checklist
Endpoint audit evidence checklist
Sources
Authoritative references
- National Institute of Standards and Technology, Cybersecurity Framework 2.0See the Asset Management outcomes, including inventories of managed hardware and software.
- Australian Signals Directorate, Guidelines for system managementSee the software register and patch-management guidance.
- Microsoft Learn, See device details in IntuneExample of device identity, ownership, hardware, application, compliance, and configuration records in a management platform.
- Microsoft Learn, App inventory for Windows devicesExample of richer application inventory and delta-based collection.
This guide describes an operational evidence workflow. It is not legal advice, audit certification, or a guarantee that any specific framework requirement has been met.