Asset Ownership and Custody: Who Is Responsible for Each Device or Tool?

Asset ownership and custody are two different answers to "who is responsible for this?" Ownership is accountability — the named person or department answerable for a device or tool. Custody is possession — who physically holds it right now. A laptop can be owned by the engineering department, in the custody of a contractor, and used day to day by that same contractor; recording all three is what lets a lean IT team answer a responsibility question before something is lost, transferred, or questioned.

This article is about responsibility specifically — not what an assets register is (see what an IT assets register is) or which hardware fields to keep (see the hardware field guide). The focus here is the roles — owner, custodian, assigned user, department, and reviewer — and what each one confirms.

Why Unclear Asset Responsibility Becomes a Governance Problem

Responsibility rarely goes missing on purpose. It erodes through ordinary events: a laptop is handed to a new starter without a record, a phone moves between people, a spare comes out of the drawer for a contractor and never goes back.

The cost shows up at the worst moments. When a device is lost, the first question is "who had it?" — and an empty answer turns a manageable incident into a scramble. When someone leaves, "what did they have?" should be a lookup, not an investigation. When leadership or an insurer asks who is accountable for the company's equipment, "we think so-and-so" is not an answer.

Owner vs Custodian vs Assigned User vs Department vs Reviewer

"Responsibility" is really several distinct roles, and conflating them is why these conversations go in circles. A lean team does not need a formal title for each, but it should know which question each role answers.

| Responsibility role | What they are responsible for | Example question they answer | Evidence created | |---|---|---|---| | Owner | Being accountable for the asset existing and being managed | "Who answers for this device?" | A named responsible person recorded against the asset | | Custodian | Physically holding and safeguarding the asset now | "Who has it right now?" | The assigned-person link, plus a note if the holder differs from the owner | | Assigned user | Day-to-day use of the device or tool | "Who actually uses this?" | The person the asset is assigned to in the register | | Department | The team the asset belongs to | "Which team does this belong to?" | The department field on the record | | Reviewer | Periodically confirming the record is still correct | "Is this still right?" | A dated note or exported snapshot confirming the check |

In a small team one person often wears several of these hats — the owner, custodian, and user are the same employee. That is fine. The point is not to manufacture five people; it is to make sure each question has a recorded answer, especially when the holder and the owner are not the same person.

What Ownership and Custody Fields to Record

You do not need a custom schema — a few fields, filled consistently, make every asset answerable:

• Assigned person — who holds or uses the asset. In CertPilot this links to a person in your People & Accounts register, or you record a name directly for anyone not in it. This single link carries custody and day-to-day use.
• Department — the team accountable for the asset, useful when the individual owner is unclear or changes often.
• A responsible owner, where it differs — when the owner is not the holder (a shared meeting-room laptop, a contractor's loaner), record the owner in the notes so accountability does not vanish into "whoever has it."
• Status — active, spare, repair, retired, or lost, so a holder who no longer has the asset is visible against its real state.

The register has one assignment link plus a department and notes — not five separate role fields. The role distinctions above are how you use those fields: the assigned person is the custodian and user; the department and a notes line carry accountability when it sits elsewhere.

How Responsibility Changes Should Be Documented

Most asset risk appears at a handover — when one person stops being responsible and another starts. Document the change rather than overwriting it silently:

• On reassignment, update the assigned person and add a short dated note: "reassigned from A. Okafor to J. Lee, 2026-06-10." The note is what makes the history readable later.
• On a temporary loan, record the current holder and note that it is a loan and to whom it returns.
• On departure, mark the person as leaving in People & Accounts; their assigned assets become a visible list to return or reassign.
• On loss or retirement, change the status and note when and what happened, as covered in lost, retired, and unassigned asset evidence.

The discipline is small — update one field and write one line in the moment — but it is the difference between a record you can stand behind and one that only shows the present.

How Ownership Connects to People & Accounts

Asset custody and account ownership are two halves of the same accountability picture. The People & Accounts register records who works here and which system accounts they hold; the assets register records which devices and tools they hold. Linking an asset to a person ties physical custody to that same record, so when someone is marked as leaving, both their accounts and their assigned hardware surface together as one handover list.

The two are deliberately parallel: the account-side version of this topic is account ownership tracking, which asks "who owns what access?" the way this article asks "who holds what device?"

How Ownership Supports Lost, Retired, and Unassigned Asset Handling

Clear custody is what makes the exception states meaningful. When a device is lost, the recorded holder is the starting point: you know who last had it and can act, rather than guessing. When an asset is retired, the owner confirms it is genuinely out of use before its status changes. And an unassigned asset — one with no recorded holder — is only a useful signal if assignment is normally kept current; against a maintained register, a blank owner reliably means "needs attention," not "probably fine."

What Not to Track

Responsibility tracking earns trust by staying narrow. Never record:

• Credentials or secrets. Responsibility means who is accountable, never how to log in. Passwords and full keys belong in a password manager, not an asset record.
• Employee behaviour. The record says who holds a device — not what they did on it. There is no usage history, location trail, or activity log here, and that is deliberate.
• Sensitive HR detail. A name and department are enough; the register is not an HR file, a line the register vs HRIS, MDM, and spreadsheets comparison draws for people records and that holds for assets too.

These limits keep responsibility tracking on the right side of the boundary set out in what CertPilot is and is not.

How This Supports Management-Ready Evidence

Clear responsibility lets a team answer leadership credibly: not "we think someone has it," but "every device has a holder, departments are recorded, and handovers are dated." That is real IT governance evidence — the internal-register half of the checks + registers → evidence reports model. Asset data rolls up as summary counts into the cross-module evidence reports, feeding a management-ready evidence report a non-technical stakeholder can read; the sample reports gallery shows the finished artifact. There is no dedicated Assets PDF today — responsibility surfaces as counts in the Governance Evidence Pack, plus the register and a CSV export as the detailed record.

How CertPilot Fits — With Strict Boundaries

CertPilot's Assets Register records ownership and custody as a customer-maintained, manual-first register with CSV import and export, each asset linkable to a person in People & Accounts. Responsibility tracking records who is accountable and operational evidence — and the boundaries are as important as the capability:

• It does not prove an asset is secure on its own — responsibility is one fact, not a security verdict.
• It does not discover devices automatically or locate them; it records the custody you enter.
• It is not MDM and runs no endpoint agent; it does not monitor endpoints, scan the network, run vulnerability scanning, or patch devices.
• It cannot remote wipe, lock, or control a device — those actions, if taken, happen in another tool.
• It is not a CMDB replacement and not an accounting or depreciation system.
• It is not a certification or an audit guarantee — it supports internal governance routines and evidence preparation.

A Practical First Version for a Lean IT Team

You can establish responsibility this week without a project:

1. Start with the assets that would hurt most if unowned — laptops, phones, and anything holding company data.
2. Give every one a holder. If you cannot name who has it, that is the finding; record it as a gap, not a blank.
3. Record the department for each, so accountability has a home even when the individual changes.
4. Note the exceptions — loaners, shared devices, anything where the owner is not the holder.
5. Set a review cadence. Monthly or quarterly, confirm holders are current and resolve anything unassigned; the prove-it-without-spreadsheets routine shows how this becomes a habit.

The first pass will expose more gaps than expected — which is the point.

In Short

• Ownership is accountability; custody is possession — record both, because they are often not the same person.
• Five roles differ — owner, custodian, assigned user, department, reviewer — and in a small team one person may hold several; each question just needs a recorded answer.
• Record responsibility with the assigned-person link, the department, and a note when the owner is not the holder; document every handover with a date.
• It connects to People & Accounts so a leaver's devices and accounts surface together, and it makes lost, retired, and unassigned states meaningful.
• CertPilot records responsibility; it does not discover, locate, monitor, or control devices, and it is not a certification.

Frequently Asked Questions

What is the difference between asset ownership and custody?

Ownership is accountability — who answers for the asset existing and being managed. Custody is possession — who physically holds it. They are often the same person, but not always: a department can own a shared laptop that is in a contractor's custody. Recording both means a responsibility question has a clear answer regardless of who happens to be holding the device.

Does CertPilot track who has a device automatically?

No. CertPilot does not discover devices, locate them, or detect possession. The assigned person is recorded by you, by hand or by CSV import — the register is as current as you keep it, which is also what keeps it under your control.

How do I record an asset where the owner is not the user?

Record the day-to-day holder as the assigned person, and note the accountable owner — a department or a named individual — in the notes. That keeps a shared or loaned asset from drifting into "owned by whoever currently has it."

What should I do when an asset changes hands?

Update the assigned person and add a short dated note describing the change. Documenting the handover rather than silently overwriting it preserves the history, so a later question — "who had this in May?" — has an answer.

Does recording ownership prove our assets are secure?

No. Responsibility is one operational fact: who is accountable and who holds the asset. It supports security questionnaires and management reviews, but it is not a security verdict, a certification, or an audit guarantee, and CertPilot does not scan or monitor anything to produce it.