Is an IT asset register itself personal data under GDPR?

Partly, yes. The moment a row says which employee holds which laptop, that row is personal data about the employee: it reveals their equipment, and the history reveals dates of joining, moving, and leaving. The register needs a lawful basis (legitimate interest in managing company property is the usual one), a retention position, and discipline about what never belongs in it.

Does GDPR require an asset inventory?

Not by name. But Article 30 requires a record of processing activities, which is hard to write honestly without knowing what systems exist; Article 32 requires security appropriate to the risk, which presumes you know what processes personal data; and a defensible breach notification within 72 hours presumes you know what a lost device held. The inventory is the artifact underneath all three.

What should we never put in the asset register?

Anything sensitive that the register does not need: health information explaining an equipment accommodation, disciplinary context around a device withdrawal, personal phone numbers when a work contact exists. The register needs who holds what, since when, and in what state. Data minimisation applies to IT's own records, not just to product databases.

How does OnTrackio handle the register's own GDPR duties?

The register lives in your workspace's own region (EU workspaces in Frankfurt), each workspace is an isolated database, a DSAR export and right-to-erasure pipeline are built in, the agent's collected-data list is public and deliberately narrow, and disposal generates wipe certificates tied to the asset entry. None of that makes you GDPR compliant; it makes the register a defensible part of your story.

GDPR and the IT asset register: it cuts both ways

2026-07-18

Most GDPR-and-ITAM articles get one direction and miss the other. The familiar direction: your asset register helps with GDPR, because it knows where data lives. The forgotten direction: the register is itself a personal-data processing activity, with everything that implies. If you run IT for a European company, you own both, and the second one is where audits get awkward.

The register is personal data

A hardware register that tracks assignment says, for every row: this person holds this machine, since this date, at this location. That is personal data about your employees, plainly within GDPR’s scope. The assignment history doubles as an employment timeline. The usage data an endpoint agent reports says when a machine was active. None of this is exotic or forbidden; managing company property is a textbook legitimate interest. But legitimate interest is a basis, not a blank cheque, and three disciplines follow from it.

First, minimisation. The register needs custody facts: who, what, since when, what state. It does not need the story around them. The note field that says why a device was withdrawn from someone, the health context behind an ergonomic keyboard, the personal mobile number when a work address exists: leave them out. IT departments write things in notes fields that would look terrible in a subject access response, and everything in the register is in scope for one.

Second, retention. A leaver’s assignment history has a legitimate life after their departure: warranty claims, audit trails, dispute windows. It does not have an indefinite life. Decide a retention period for person-linked records, write it down, and make the system able to honour it. A register that cannot delete is a liability with a search function.

Third, transparency. Your employees should be able to learn what the register holds about them without filing a formal request. If an endpoint agent is part of the picture, its collected-data list should be public and boring. The agent we ship reports hardware specification, installed software, and usage sessions, and the exhaustive list is published; no browsing history, no file contents. Whatever tool you use, insist on that document existing.

The register is evidence

Now the direction most articles start with, made concrete. Four GDPR obligations lean on the asset inventory:

Article 30, the record of processing activities. A RoPA describes what processing happens on what systems. Writing one without a systems inventory is creative fiction; auditors and supervisory authorities can tell. The software register, with owners and data classifications per application, is the honest input. When someone adds a SaaS tool nobody procured, your RoPA is out of date, which is why shadow-IT discovery belongs in the same conversation.

Article 32, security of processing. “Appropriate technical and organisational measures” presumes you know which assets process personal data at all. A classification column that flags what holds personal or customer data is the sorting hat: it decides which machines get the encryption checks, the patch priority, and the restricted access. Without it, Article 32 programmes protect everything vaguely and nothing demonstrably.

Subject access and erasure. A DSAR asks: what do you hold about this person, where? The register answers the where for devices and systems, and the holder history answers which machines a person’s working files may have touched. Erasure requests inherit the same dependency, plus the register’s own rows about the requester.

Storage limitation and disposal. Personal data on a laptop does not stop being personal data because the laptop is old. Disposal needs evidence: this device was wiped, on this date, by this method, or physically destroyed with a certificate. Tying wipe and destruction certificates to the specific asset entry closes the loop; a drawer of dead laptops with no paper trail is an Article 5(1)(f) finding waiting for its moment. This is the same discipline that the offboarding evidence guide covers from the SOC 2 angle: frameworks differ, the leaver’s laptop does not.

And the 72-hour clock. When a laptop goes missing, the breach assessment starts with what was on it, who it belonged to, whether it was encrypted. A current register answers in minutes. An outdated one turns the first day of your 72 hours into archaeology.

Where the register lives matters too

If the register is personal data, its own hosting is a GDPR question. A register of EU employees sitting in a US-region SaaS with no transfer mechanism is a quiet irony: the compliance tool as the compliance problem. Ask any vendor, including us, three questions: where does the data live, who are the sub-processors, and is there a DPA on the table without negotiation theatre. Our answers are on the security page: EU workspaces in Frankfurt, US workspaces in the US, sub-processors listed publicly, DPA on request.

The honest summary

The register helps you with GDPR and is regulated by it at the same time. Treat both directions deliberately: minimise and retire the person-linked rows, and let the inventory carry the Article 30 and 32 evidence it is uniquely positioned to carry. If you want the register columns as a starting point, the free NIS2 asset register template carries the same ownership and classification spine, and a 30-minute demo shows how OnTrackio runs both directions on live data. What no tool provides, ours included, is GDPR compliance itself: that remains a property of your whole programme, not a purchase.