When a laptop leaves your office for repair, three audit trails leave with it. Most Indian MSMEs track exactly one — the financial trail — and only because the finance team won't let them not. The other two trails, the chain of custody and the data trail, are invisible until the moment they're not, at which point they become the only thing anyone cares about. The Digital Personal Data Protection Act (DPDP) has changed the stakes here. "We sent the laptop to a shop near the office" is no longer a defensible answer for a device that held customer data. This post is about the three trails, what each one needs, and how to build them without doubling the IT admin's workload.
The three audit trails
Every IT repair event generates three streams of evidence. They each answer a different question.
| Trail | Answers the question | Who needs it |
|---|---|---|
| Financial | What did this repair cost, and is the invoice valid? | Finance, GST audit, internal cost tracking |
| Custody | Where was the device, when, and who had it? | IT, legal, DPDP, insurance |
| Repair-action | What was actually fixed, and is the device safe to redeploy? | IT, warranty, security |
A complete repair record covers all three. Most informal repair workflows in Indian SMEs cover only the first, and only barely — a vendor's handwritten bill stapled to a ledger entry.
The financial trail
This one is well-understood. Under GST, every repair invoice should carry:
- Vendor's GSTIN
- Customer's GSTIN (for B2B)
- HSN/SAC code for the service (IT hardware repair is typically 998713 / 998739; parts have their own HSN)
- Itemised parts and labour
- Tax breakup (CGST/SGST or IGST)
- Invoice number, date, and serial sequencing
- Place of supply
A sample line item layout that finance teams accept:
| Item | HSN/SAC | Qty | Unit price | Tax % | Tax | Total |
|---|---|---|---|---|---|---|
| Laptop motherboard replacement (labour) | 998713 | 1 | ₹2,500 | 18% | ₹450 | ₹2,950 |
| Replacement battery (part) | 8507 | 1 | ₹3,200 | 18% | ₹576 | ₹3,776 |
The two things that go wrong here in practice:
- Below-threshold vendors. A small vendor under the GST registration threshold can issue a non-GST bill. That's legal, but it makes your input-tax-credit math harder and breaks if you're audited. Prefer registered vendors for non-trivial invoice sizes.
- Mixed bills. A vendor combining "service charge" with "parts" into one round-number line is doing themselves a favour and you a disservice. Insist on the breakup; it matters for warranty claims later.
The custody trail
This is the trail that almost nobody is keeping properly, and it is the one DPDP cares most about. The custody trail answers: "Where was the device at every point between leaving your office and returning?"
A defensible custody trail includes:
- Outbound handover — date, time, who handed it over, who received it, signed acknowledgement (digital is fine), photos of the device condition
- Transport phase — courier waybill or vendor pickup record if relevant
- Onsite/offsite repair phase — where the work happened, who performed it
- Return handover — date, time, who returned it, photos of returned condition, signed acknowledgement
If the device travelled with a sealed tamper-evident bag, the custody log should reference the seal number. If photos were taken of the device pre- and post-repair, they should be attached to the ticket. None of this is theatrical — every item is something you'd want to be able to produce if a customer complained their data showed up somewhere it shouldn't have.
The custody trail is also what insurance asks for when an in-repair device is lost or damaged. A laptop that disappeared from a vendor's premises is a different conversation if you have a signed pickup record than if you have a WhatsApp message saying "I'll come tomorrow at 3".
The data trail
The data trail is the newest and the least familiar. It answers: "What data was on this device when it left, who could have seen it, and what was done to protect it?"
DPDP's relevance is specific. If the device contained personal data of a data principal (an employee's identity documents, a customer's contact details, transcripts of customer support conversations, anything qualifying as personal data under the Act), then your organisation is a data fiduciary processing that data — and a third-party vendor with physical access to the storage is, depending on the structure, a data processor. That triggers obligations: contractual safeguards, breach notification, and proof that reasonable security practices were followed.
A clean data trail records:
- Data classification — at handover, a one-line note: "device contains customer data / contains internal-only data / wiped before handover".
- Encryption status — was the disk encrypted (BitLocker/FileVault)? When was the recovery key generated? Where is it stored?
- Backup status — was the device backed up before handover? Where is the backup, and is it encrypted?
- Wipe action — did a wipe happen before handover? If yes, what standard (NIST 800-88 is the common reference)? Is there a wipe certificate from the tool used?
- Post-repair verification — was the device verified clean (or restored to a clean state) before being returned to the employee?
For the practical pre-handover sequence, see our data wipe before laptop repair checklist.
Where DPDP specifically applies
The DPDP Act sets a duty on data fiduciaries (which includes most MSMEs that process personal data) to implement reasonable security safeguards. Two specific implications for IT repair:
- Vendor agreements must contractually require the vendor to handle personal data only as instructed, to maintain confidentiality, and to return or delete data when the engagement ends. A platform-level master agreement is acceptable; per-ticket SOWs are not realistic.
- Breach notification kicks in if a device is lost or accessed by an unauthorised party during repair. Without a custody trail, you cannot determine whether a breach has even occurred — which is itself a compliance failure.
For context on DPDP in another domain, see our face attendance and DPDP guide. The general principles are the same: a fiduciary needs to be able to demonstrate, not assert, that reasonable safeguards were in place.
What a marketplace's per-ticket trail looks like
Repair platforms that are built for the Indian compliance environment record all three trails per ticket. Fixr by Hives.cloud maintains a per-ticket log that includes the financial transaction (GST invoice from the assigned vendor's billing entity, attached to the ticket), the custody timeline (every state transition with timestamps, vendor identity, location stage), and a data-handling notes field that the customer and validator can populate at the validation step. The ticket log is permanent — it stays on the platform after the ticket closes, available for audit.
The platform itself is free for both individuals and organisations; the vendor bills directly. The audit trail isn't behind a paid tier, because the value isn't in the audit pack — it's in being usable by every customer at the same standard.
A 1-page audit pack you can build today
Even if you're not on a marketplace, you can build a defensible per-ticket audit pack with a spreadsheet and a shared drive. The minimum:
Per-ticket folder:
ticket-meta.md # device ID, employee, date opened/closed
custody-log.md # outbound + return handover, signatures
vendor-invoice.pdf # GST invoice
data-handling-note.md # classification, encryption, wipe action, backup
before-repair.jpg # device condition photo
after-repair.jpg # device condition photo
wipe-certificate.pdf # if applicable
For a 30-ticket-a-month office, this is roughly 20 minutes of admin overhead per ticket the first time, then 5–8 minutes as it becomes habitual. The first time you produce this audit pack for a real incident — a missing device, a data exposure claim, an insurance event — you will retroactively decide it was worth it.
FAQs
Do I need a separate data-handling agreement with each vendor? If you work through a marketplace, the platform's master vendor agreement should cover it; verify that it does. If you work direct, yes — a one-page data-handling clause attached to the engagement is the minimum.
What counts as 'personal data' for DPDP in this context? Anything that can identify a natural person, directly or in combination — employee IDs, customer contacts, transcripts, identity documents. Roughly: if you'd be uncomfortable seeing it on a stranger's desk, treat it as personal data.
Is encrypting the disk enough? It's the most important single safeguard, but it's not enough on its own. If the device boots and is signed in, encryption is bypassed for the duration of the repair. Pair encryption with a sign-out before handover and a wipe before transport whenever the data is sensitive.
Who is liable if a vendor leaks data? The data fiduciary (your organisation) is the first point of accountability under DPDP, regardless of the vendor's actions. That's why contractual safeguards and a custody trail matter — they let you demonstrate the safeguards were in place.
How long should I retain repair audit packs? Match your other operational records: typically 5–7 years for finance under GST, and at minimum the device's deployed lifetime + 2 years for IT-side records. When the device is sold or scrapped, archive the pack alongside the disposal record.