Transferring equipment between organizations: paperwork and recordkeeping

Why you need rules when moving equipment

Equipment transfers between organizations often start informally: someone asked for a few PCs, a driver picked them up, and surprises appear later. A power supply is missing, a case is damaged, or the drive still contains work files. Rules aren’t for the paperwork—they help ensure equipment arrives intact, data doesn’t leak, and there’s no grounds for disputes.

Three common problems arise without clear procedures:

• Data leakage. Computers may retain documents, accounts, passwords and access to mail and services.
• Losses and swaps. Without recording serial numbers and contents, monitors, SSDs, adapters and licenses can easily “go missing.”
• Blurred responsibility. It’s unclear who is liable for damage discovered at the recipient’s site.

Serial numbers, completeness and condition become a common language when nobody wants a fight. A serial number ties a specific workstation or server to documents and maintenance history. The list of included items shows exactly what was handed over (cables, keyboard, adapters, server rails). Condition records what the device looked like before transport.

Before shipping, close a few questions: what exactly is transferred (model, serial number, kit, quantity), who hands it over and who receives it (full names, positions, contacts), what is the device condition and defects, and how and when data wiping and access removal are performed.

A simple example: one unit transfers 20 PCs to a neighboring branch. If serial numbers aren’t checked in advance and two cases have cracked panels, a conflict is likely. If you don’t agree who wipes disks, you might hand over PCs with active files and saved credentials.

Roles and responsibility: who does what

The most frequent failure in transfers is everyone assuming “IT will do it” or “Accounting will handle it.” To avoid losing devices, data and serial records, appoint responsible people in advance and clarify who signs documents and who performs technical work.

Typical role distribution:

• Initiator (head of unit or asset custodian) — creates the request, lists equipment and deadlines, and agrees the reason for transfer.
• Transferring party (asset custodian and commission if needed) — responsible for actual completeness, condition, inventory tags and matching serial numbers.
• Receiving party (asset custodian) — inspects equipment on receipt, records remarks, confirms acceptance and assumes responsibility for storage and use.
• IT service — verifies configurations (RAM, drives, network adapters), checks operability, removes devices from inventory systems, and disables accounts and accesses.
• Security/InfoSec — sets requirements for data wiping and handling media, and monitors cases with personal or sensitive data.

Accounting is involved at almost every step, even if IT physically moves the equipment. They verify the basis for transfer and details, ensure the asset is reassigned to the new custodian and update asset cards.

A helpful rule: IT is responsible for “what’s inside” (data, accounts, operability), the asset custodian for “what’s outside” (completeness, intactness, signatures), and InfoSec for ensuring nothing unnecessary leaves with the device. For example, when transferring a batch of PCs from a clinic to a training center, IT removes devices from the domain and wipes disks, InfoSec ensures no medical data remains on the drives, and two asset custodians verify serial numbers and completeness by list and sign the handover.

Documents usually prepared

To prevent a transfer from turning into a dispute months later, record the basis and rules upfront. Start with an internal document: an order or directive from management. Sometimes a service note with approval stamps is enough. The basis records who transfers, who receives, timing, list of equipment and responsible persons.

The key document is the equipment handover act. It’s made in two copies and signed by both sides. In the act, avoid a vague line like “10 computers”; describe each unit so it can be unambiguously identified.

What to include in the act

Typically the act should list:

• name, model and type (PC, all‑in‑one, server, monitor)
• inventory tag and serial number, and if relevant — seal number
• completeness (power supply, cables, keyboard, mouse, racks, rails)
• condition and defects, date of last repair (if any)
• handed-over documentation and warranty materials (if applicable)

Also update the asset card (or the entry in the accounting system): from where, to where, on what basis, from which date and who is materially responsible. This helps avoid “losing” assets and makes inventories straightforward.

A delivery note or “warehouse movement” document is needed when equipment passes through a warehouse or is treated as inventory rather than immediately assigned to a custodian.

Appendix to the documents

It’s almost always useful to add an appendix to the act: a table listing serial numbers, condition and completeness for each unit. For batch transfers (e.g., PCs and servers) this appendix is often the thing that “saves” you if questions arise later.

Preparation before transfer: inventory and inspection

Spend time preparing before the transfer. This reduces the number of remarks at acceptance and speeds users’ work resumption at the new site.

First, verify the equipment list by actual units, not by memory. Each asset card should match model, inventory tag and serial number. Check the serial on the device label and in BIOS/system info — stickers wear off or get replaced.

Next, check completeness. A frequent scenario: the tower arrived but the power supply, cable, docking station or peripherals stayed behind. For batch moves, record the kit for each unit, not “per box.”

A quick inspection before shipping saves days of correspondence. Usually confirm the device powers on and boots without errors, note external defects (chips, cracks, signs of tampering), check main ports and the screen (for all‑in‑ones), and record seals and their condition.

Agree downtime and migration window in advance. If office PCs (including L200 series) or M200 all‑in‑ones are transferred, decide when staff hand in devices, where they’ll work temporarily, and who moves user data and profiles.

Finally, prepare labeling: seals, stickers, tags or QR labels. The label must survive transport and match the case, the box and the accompanying list. It’s a small detail but helps a lot during loading.

Step‑by‑step transfer flow: from list to acceptance

Follow fixed steps so devices aren’t lost, forgotten data doesn’t turn up, and it’s always clear who accepted what and when.

Start by agreeing what moves and who receives it. Appoint people responsible for preparation and acceptance early to avoid “no‑one saw it, but everyone expected it.”

Typical preparation steps: approve the list (model, serial, kit, destination and recipient), decide on backups (who makes them and where they are stored), perform data wiping and resets, update records (new custodian, location, change date), prepare the equipment handover act and appendix (list, condition, kit), and agree the signature format.

After preparation, sign the documents at the moment the device actually changes hands.

At acceptance, the receiver checks serial numbers, inspects visually, powers on if needed, and records date and time. For a transfer of 20 PCs, don’t limit the act to “20 items”: list each serial number and have the recipient verify it on the device label.

Data wiping: don’t leave traces

Transfer procedures must recognize that “data” isn’t only files on the desktop. It includes email and local archives, browser caches, saved passwords, app accounts, encryption keys, messenger tokens, VPN certificates and autofill data.

A common mistake is deleting folders and calling it done. Traces remain in Recycle Bin, temp files and user profiles, and “deleted” data is often recoverable.

Choosing a wiping method

The method depends on the device and security requirements. For a typical office PC, reinstalling the OS and removing partitions is the clearest option. For all‑in‑ones and laptops, a factory reset sometimes used but may not fully erase data.

For HDDs, overwriting with a specialist tool is more reliable. For SSDs, prefer Secure Erase or the vendor’s utilities. Quick formatting is not enough for either type.

Don’t forget external drives and USB sticks — they’re often passed along and can contain reports, scans and database exports.

Before wiping, check whether disk encryption is enabled (e.g., BitLocker). If so, note where the recovery key is stored and ensure keys and accounts are removed after the work. If encryption wasn’t used, wipe requirements are usually stricter.

A minimal checklist before handing in a device: no local users or profiles remain, logged out of mail/clouds/messengers and app stores, browsers and password managers cleaned, VPN keys and certificates removed, and external drives and USB sticks wiped separately.

Recording the result

Don’t just write “data removed”; record specifics in the act or its appendix. State who performed the work, the date, and the method used (reinstall, Secure Erase, overwrite) and which device this applies to (inventory and serial numbers, and if possible the drive serial). This reduces chances of later claims due to “unexpectedly found” documents or accounts.

Traceability by serial number: how to keep records

Rely on serial numbers to avoid losing equipment or arguing about batch contents. Serial numbers are unique and survive reassignments, making them the most reliable anchor for transfers.

Agree on a single recording format and stick to it. “We’ll fix it later” usually ends with inconsistencies.

Maintain a single table (or accounting system) with one row per device. Minimum fields: serial number (as on the label), inventory tag/asset tag (if any), model and type (PC, all‑in‑one, server), basic specs, completeness, status and event (transferred, received, under repair) with date and responsible person.

Link the serial number to configuration and kit at the time of transfer. For example: “PC L200: SSD 512 GB, RAM 16 GB, power supply, power cable.” If memory or the drive is later changed, log a “replacement” event with date and the new part’s serial if available.

Record moves and repairs as a chain of events. Each entry should answer: where was it, where is it now, and on what basis.

If the serial is unreadable or missing, don’t leave the field empty. Record the reason (worn, damaged), check BIOS/UEFI or procurement documents, assign a new asset tag and note “serial number not present.” Add identifying marks (model, external features, kit) and plan for proper labeling at the next service.

Accesses and security: what to disable and check

The most common problem in transfers isn’t paperwork but leftover accesses. Before transfer, check who or what the device still “trusts”: users, admins and services.

Start with accounts and privileges. On PCs and laptops check local administrators (temporary accounts often remain), domain membership and MDM bindings. When ownership changes, it’s safer to return the device to a clean state and have the new organization onboard it.

Remove anything that enables remote access: VPN profiles and keys, corporate Wi‑Fi networks and certificates, trusted devices and 2FA bindings, saved passwords in browsers and password managers, SSH keys, RDP settings and saved connections.

Also verify service bindings and licenses; a device might remain activated and keep syncing. Practical rule: log out of accounts and unlink the device first, then perform the wipe.

To avoid disputes at acceptance, set rules for testing: who may power on the device, run checks and connect to the network. It’s convenient to appoint one responsible person who records results (does it boot, are there unexpected profiles or network settings).

Servers and network equipment require a separate scenario. Beyond changing admin accounts, check VLAN and routing configs, SNMP community strings, remote management keys (iDRAC, iLO and equivalents), and firewall rules. Test such devices on an isolated bench rather than in the production network.

Example: moving a batch of PCs between institutions

Scenario: the head office sends 25 PCs and 5 monitors to a branch. It seems simple, but without order you can lose cables, mix up serials and leave foreign data on drives.

First, create a single list — the basis for the equipment handover act. Maintain it in a table and print two copies: one for shipment and one for acceptance. For each unit record model and type, inventory tag, serial number (as on the label), completeness, condition (chips, dead pixels, fan noise), and the recipient and destination.

Assign roles for data backups and timelines. The IT specialist, per the owner’s request, makes backups of needed files, then performs wiping according to policy (not just deleting files). The security lead confirms accounts and access keys are removed and devices are ready to issue.

At the branch, acceptance should be done right upon unpacking while packaging and transport documents are at hand. A basic check takes 3–5 minutes: verify serial numbers against the table, ensure there are no old accounts, check ports and monitor image, do a visual inspection and mark completeness.

After acceptance update the records: new location, asset custodian, status (transferred/in service). Close the transfer the same day so inventory won’t show a “missing” item later.

Common mistakes and how to avoid them

The most frequent problem is paperwork done “for the form.” If the handover act is filled without serial numbers and without an appendix list, it becomes nearly impossible to prove what exactly was handed over. The simple solution: record identifiers for each unit and attach the list.

Second mistake — wiping only the computer but not all storage media. People often forget the second SSD, additional HDD, memory cards or modems with SIMs. Before transfer list all media and mark what was wiped and by which method.

Another common failure is mixing similar devices and losing kit correspondence. For example, ten identical PCs but power supplies, cables and keyboards get mixed. Label kits and apply the rule “one serial number — one kit.”

A frequent source of conflict is lack of condition records. If scratches, broken ports or battery wear aren’t recorded, claims about damage during transport are easy. Before shipping mark condition in the act and take 3–5 photos per unit.

Check organizational details too: update location in records and assign a new custodian, determine responsibility for transport and storage, and ensure authorized persons sign the act.

And one more: do not transfer passwords, tokens, encryption keys and access credentials with the equipment. Real cases exist where workstations were handed over with saved accounts and the new user gained access to corporate files. Log out of services, remove accounts, reset TPM/BitLocker bindings (if used) and record this in the notes.

If the equipment is new or under warranty (e.g., L200/S200 series), verify that the package includes documentation with serials and kit — it will be useful for future service.

Quick checklist and next steps

Pre‑transfer checklist

Verify the basics:

• Device list agreed and each device checked by serial number.
• Completeness and condition recorded before shipment.
• Data wiping completed per policy and accesses removed.
• Documents ready and signed by both parties: act with date, place and list of serial numbers.
• Responsible persons appointed and aware who is accountable during transit and who accepts to the inventory.

After transfer update asset cards the same day (location, custodian, status) and reference the act and date.

Next steps to reduce manual transfers

Turn a successful batch move into a standard: a few simple measures suffice — unified labeling rules, a clear lifecycle description (issue, move, repair, disposal), a template appendix for the act (model, serial, kit, condition, wipe date), and a short briefing for responsible staff.

If internal resources are limited, consider external support — a system integrator or vendor service network can handle parts of the process. For example, GSE.kz as a Kazakh manufacturer and system integrator can take on parts of infrastructure support and on‑site equipment servicing.