Skip to main content

    An audit trail for company devices proves every step

    Data security
    October 14, 20267 min read
    An audit trail for company devices proves every step

    An audit trail for company devices records, without gaps, who received a device when, how it was changed and when it was returned, down to the proof of erasure. No law requires it as a document of its own. But GDPR and NIS2 demand evidence that is hard to produce without one. A device-as-a-service provider such as Everphone delivers a key part of it.

    A device list in Excel shows what is true today. An audit trail shows how it got there. That is exactly what data protection officers, auditors and insurers ask for once something has gone wrong.

    Our position: document what is necessary, but document it without gaps. Proving five events cleanly is worth more than fifty half-proven ones.

    What is the difference between a device inventory and an audit trail?

    The inventory is a snapshot: device, serial number, owner, status. The audit trail is the history behind it. Every change to the inventory appears there as an entry with a timestamp, a trigger and a result.

    You need both. The inventory answers "Where is the device right now?". The trail answers "Who had it on March 14, and what has changed since?". Without an inventory you have no starting point. Without a trail you have no proof.

    ISO 27001 separates the two as well. Control 5.9 requires an inventory of information assets with named owners. Control 8.15 requires that relevant events are logged, protected and evaluated. Both can be applied to devices, even though the standard does not name end-user devices explicitly.

    Who requires proof about company devices?

    No law prescribes an "audit trail for end-user devices". Several rules do demand evidence that, in practice, you can only produce with a device history.

    Rule set What it requires What it means for devices
    GDPR, Art. 5(2) and Art. 32 You must be able to demonstrate compliance with the principles and protect data with appropriate measures You must be able to prove access to, loss of and erasure of any device that holds personal data
    NIS2 Directive (EU) 2022/2555, Art. 21(2) Risk management includes access control and asset management Every device on the network must be recorded, assigned and controlled
    German BSI Act after the national NIS2 implementation, Section 30 Affected entities must implement and document risk management measures Germany's Federal Office for Information Security (BSI) can request evidence
    ISO 27001:2022, Controls 5.9 and 8.15 Inventory with owners, logging of relevant events A typical audit question: "Show me the history of this device"

    Not every company falls under NIS2. Whether yours does depends on its sector and size. GDPR, by contrast, applies to every company that holds personal data on devices, so to almost all of them.

    Which events belong in the audit trail?

    Everything that changes a device's state or assignment, and everything that can put data on it at risk. Nothing more. A trail that logs every app launch is not evidence, it is surveillance.

    Event What you record What you need it for later
    Procurement Device, serial number, order date, who triggered the order Proof that the device was approved
    Assignment Employee, time, who assigned it Establishing who was responsible during an incident
    Configuration MDM profile, encryption, updates, who triggered the change Evidence of "appropriate measures" under Art. 32 GDPR
    Status change Locked, reported lost, replacement issued Timeline for the data breach notification
    Remote actions Lock, wipe, locate, with timestamp and who executed them Proof that the data was protected in time
    Return and erasure Return date, erasure method, certificate Proof that no data left the building

    Two entries are missing most often in practice: who triggered a change and when the device was erased. Those are the first two questions after an incident.

    What an audit trail does when a device is lost

    Take a company with 120 employees. On a Friday evening, a sales manager reports her laptop as stolen. On Monday, the data protection officer asks three things: Since when did she have the device, was it encrypted, and when was it locked remotely?

    Without a trail, you search tickets, emails and an Excel sheet. With a trail, you read off three entries: assigned in January, encryption active since delivery, remote lock on Friday at 7:42 pm. On that basis you decide whether a report to the supervisory authority is necessary. We describe the 72-hour deadline in Lost company phone: the first 72 hours.

    The trail cuts the investigation from days to minutes and replaces assumptions with evidence.

    How to set up an audit trail for company devices

    1. Decide on the leading source. Ideally it is one system that knows ordering, assignment and management, instead of reconciling three systems after the fact.
    2. Define the events. Use the table above as a starting point and strike what you do not need.
    3. Assign every entry to a person or a system. "Status changed" is not enough. It has to say who or what triggered it.
    4. Protect the entries. Nobody should be able to change them afterwards. ISO 27001 calls for immutability and separate storage.
    5. Set retention periods. GDPR requires storage limitation, so not forever. You base the period on risk and legal requirements, and you put it in writing.
    6. Regulate access. The trail contains personal data, namely who had which device. Who may read it belongs in a policy, ideally agreed with data protection and the works council.

    The last point is easily forgotten. An audit trail must not turn into performance monitoring. What is permitted is explained in Company phone monitoring: what employers may do.

    Audit trail with device as a service

    With device as a service, the provider takes over tasks that would otherwise land in your IT team. Asset management is included, as are certified erasure and refurbishment after return, at no extra cost.

    That way, you do not have to build two of the most sensitive points in the device lifecycle yourself: the inventory and the proof of erasure.

    The Everphone portal and the API work on the same data. What is ordered via the API appears in the portal, and the other way round. The trail therefore arises in one place instead of two.

    Erasure certificates at Everphone are clearly documented and linked to each device with a date. They can be exported as a PDF, as an annual ZIP or via the API. For a single case, admins find it as a PDF on the return case detail page under "Data Erasure". Each certificate has a report UUID and is linked to the serial number, IMEI, stocklist item and return case.

    A provider does not replace your own responsibility. The accountability duty under GDPR stays with you. How to regulate this cleanly in the contract is covered in Is device as a service GDPR compliant?.

    Who should invest the effort

    Start now if you are aiming for ISO 27001, might fall under NIS2 or issue devices that hold customer data. That applies to most companies whose employees use laptops or smartphones for work.

    Leave it alone as long as you have no clean inventory. A trail without an inventory logs devices nobody knows about. Start with the inventory, then assignment and erasure, then the rest.

    If you are short on time, put two things in place first: who has which device, and when was it erased? That lets you answer most of the questions that come after an incident.

    Frequently asked questions

    Is an audit trail for company devices mandatory?

    No rule requires exactly this document. GDPR does require you to be able to demonstrate compliance with data protection. NIS2 and ISO 27001 require an inventory and logging. In practice, you only meet that with a traceable device history.

    What is the difference between an audit trail and a log file?

    A log file records the technical events of a system. An audit trail assigns events to a person or a trigger, is protected against later changes and is meant for audits. Logs are often the raw data from which a trail is built.

    How long do I have to keep audit trail data?

    There is no general retention period for device histories. You set it based on a risk assessment, legal requirements and internal policies. GDPR requires storage limitation here: personal data may not be kept longer than the purpose requires.

    Is an MDM enough as an audit trail?

    An MDM logs configuration and remote actions, but often knows nothing about procurement, return or proof of erasure. For a complete trail you need the history across the whole lifecycle. How the functions of an MDM fit together is explained in the article MDM features.

    Who may view the audit trail?

    Only a clearly defined group, such as IT management, data protection officers and internal audit. The trail contains personal data and must not be used for performance monitoring. Define access in writing and agree it with the works council, if you have one.