Data Wipe Before a Laptop Goes to Repair: The Indian SME Checklist

The average laptop in an Indian SME, on the day it goes to a repair shop, contains all of the following: the employee's email archive, browser sessions still signed into customer-management tools, downloaded customer lists, identity documents from HR onboarding, draft documents, screenshots from internal Slack conversations, a few half-finished proposals, and a folder of WhatsApp media that was synced via desktop. None of this is unusual; it's what an actively-used office laptop looks like. None of it should leave your office in a state where the vendor's technician can casually browse it during a slow afternoon. The Digital Personal Data Protection Act has reframed the stakes — the question is no longer whether your data hygiene is good, but whether you can demonstrate that it was. This is the practical pre-handover checklist that gets a device safely out the door.

What's actually on a typical office laptop

It's worth being concrete about this, because the abstract version ("personal data") doesn't land. A 3-year-old laptop belonging to a sales lead in a 50-person company in India typically has:

• 2–6 GB of email archived locally by Outlook or a desktop mail client
• Cached attachments from email — invoices, IDs, signed contracts
• Browser-saved passwords for 30–80 sites if a password manager isn't enforced
• A "Downloads" folder with whatever was downloaded in the last six months
• Multiple SaaS desktop clients (Slack, Teams, Zoom, WhatsApp) with cached message history
• Screenshots and notes from customer calls
• Sometimes: exported CRM data, sometimes spreadsheets with customer contact info
• The browser cookie store, which contains active session tokens for tools the user is signed into

Any of this, in the wrong hands, is either a regulatory event or a competitive event. The repair shop technician is almost certainly not malicious. The point is that "almost certainly not malicious" is not a safeguard; a removable disk and an unattended afternoon is enough.

The pre-repair data checklist

This is the eight-step sequence. Not all eight apply to every device — a completely dead laptop can't be signed out of or wiped. But every device should be assessed against the list, and the steps that don't apply should be explicitly noted in the custody log.

1. Decide the handling tier. Three tiers based on data classification: routine (no personal data of others; mostly internal-only content), elevated (employee personal data, internal documents), high (customer personal data, financial records, identity documents). The tier determines the rest of the steps.
2. Back up. If the device is functional, run a backup before any other step. Encrypted backup to centrally-controlled storage. This protects against repair-induced data loss, which is real.
3. Sign out of everything. Browser sign-out from every signed-in tool. SaaS desktop client sign-out. Email account removal from local client (or at least mailbox-level sign-out where supported).
4. Verify encryption. FileVault on for macOS, BitLocker on for Windows Pro/Enterprise. Recovery key escrowed centrally. If encryption isn't on, this is the moment you discover it — and ideally you fix it before the next device goes out, not just this one.
5. Wipe if possible. For elevated and high tiers on functional devices, perform a full wipe (factory reset / "Erase All Content and Settings" on Apple Silicon, full BitLocker wipe on Windows). For routine tier, wipe is optional; the encryption + sign-out combination is usually sufficient.
6. Document the wipe. If a wipe happened, take a photo of the post-wipe initial-setup screen. Or have the wipe tool generate a certificate (some enterprise tools do).
7. Seal. Tamper-evident bag for elevated/high tier devices, with the seal number recorded in the custody log.
8. Hand over with paperwork. Signed acknowledgement, device photo, custody log open. See our audit trail post for the full custody-log structure.

BitLocker / FileVault behaviour during repair

This is the area most often misunderstood. Disk encryption protects data at rest, when the disk is powered down or pre-boot. It does not protect data once the device boots and the user is signed in. The implications for repair:

• A vendor who boots the device using the user's existing session has full access to the data, encryption notwithstanding.
• A vendor who needs to boot the device for diagnosis — for example, to test a screen replacement — will need either the user's password or a fresh OS install. Establish which up-front.
• For BitLocker, the device generally needs the user password to unlock the disk on boot; the recovery key is the override path if the password is unavailable. Don't share the recovery key with the vendor unless explicitly necessary, and rotate it after the repair.
• For FileVault on Apple Silicon Macs, the same logic applies, with the additional safeguard that "Erase All Content and Settings" cryptographically wipes the disk instantly.

The pragmatic pattern: for any elevated or high tier device, wipe before handover. For routine tier, encrypted + signed-out + tamper-bag is acceptable.

When a full wipe isn't possible (dead device)

A device that won't boot can't be wiped from the OS. Three options, in order of preference:

1. Physical disk removal. For devices with replaceable storage (most pre-M-series MacBooks, many business Windows laptops with M.2 SSD slots), pop the disk before handover. Replace it post-repair, or wipe it separately. This is the cleanest option for high tier data.
2. Chain-of-custody with a trusted vendor. A vendor on a marketplace with signed data-handling terms, sealed transport, and a per-ticket audit trail. The vendor is now the safeguard; the controls are contractual rather than technical.
3. External tooling. Some forensic-recovery shops can wipe a disk from a non-booting device using specialised hardware. Expensive for a single laptop; worth knowing about.

For Apple Silicon Macs with soldered storage, option 1 isn't available, so the chain-of-custody story becomes mandatory.

What a data-wipe certificate from a vendor should say

If you ask a vendor to perform a wipe (because you couldn't), the certificate they return should include:

• Device serial number / asset ID
• Wipe standard used (NIST SP 800-88 Rev. 1 is the most-cited; "Purge" is the right level for office hardware)
• Tool used (Blancco, KillDisk, manufacturer-supplied utility)
• Date and time of the wipe
• Technician name and identifier
• Signature from the vendor's authorised representative

NIST SP 800-88 is the international reference for media sanitisation, and citing it in vendor agreements is the simplest way to specify what "wipe" should mean. The standard distinguishes Clear (overwrite, suitable for most office reuse), Purge (cryptographic erase or block erase, suitable for high-confidentiality reuse), and Destroy (physical destruction, suitable for disposal). For an office laptop going to repair, Purge is the right level.

Cross-link to DPDP context

DPDP applies to personal data — information about a natural person. Most office laptops in India in 2026 have personal data on them (employee data, customer data, or both), so the Act's safeguards-and-accountability obligations apply to the repair workflow. For broader DPDP context, see our face attendance DPDP guide.

The compliance posture is not "we erased everything every time". It is "we had a documented process, the process was followed, and we can show the trail". A reasonable process imperfectly executed is more defensible than a perfect process never recorded.

How a marketplace logs data-handling per ticket

Repair workflows on Fixr include a data-handling section on the ticket itself, populated at the validation step. The validator captures the tier, whether a wipe was performed before handover, the encryption status, and any specific handling notes (sealed pickup, no-tamper-zone constraint). The vendor agrees to the platform's master data-handling terms at onboarding, so per-ticket bespoke agreements aren't needed. The notes stay with the ticket log permanently. None of this is behind a paid feature; the platform is free to use.

A 5-minute version for daily use

Most repair tickets don't need the full eight-step ritual. The 5-minute version for routine-tier laptops:

1. Run a quick backup (or confirm the device is backed up).
2. Sign out of email and the top three SaaS clients.
3. Verify encryption is on.
4. Take a device photo. Hand over with a signed acknowledgement.

For elevated and high tier devices, run the full eight-step sequence. The discipline is to know which tier you're in before you start.

FAQs

Is wiping always necessary? No. Encryption + sign-out is often sufficient for routine-tier devices. Wipe is the right answer when data sensitivity is high, when the device is going outside your direct chain of custody for an extended period, or when the vendor's identity is less established.

What if the user refuses to sign out? Make it policy. The IT admin (not the employee) controls the handover, and standard practice should include sign-out as a precondition. Anything else is a process gap.

Do small repair shops in India accept these data-handling agreements? Marketplace vendors who are part of a verified pool usually have. Walk-in local shops generally won't sign anything bespoke. For high-tier data, route around walk-in shops; that's part of the trade-off.

Is taking a photo really necessary? Yes, for two reasons: it's evidence of device condition at handover (useful if the device returns damaged), and it's part of the chain-of-custody record. Costs five seconds.

Can the device be repaired and returned without ever being signed-in? Many repairs can be diagnosed without sign-in (battery test, screen test, basic hardware diagnostics). Some repairs require a sign-in to verify (USB ports, network, peripherals). Confirm with the vendor before handover whether sign-in is needed; if so, that's the moment to escalate the tier.