Disclaimer: this post is general information about data-handling practice, not legal advice. It states no penalties, section numbers or filing obligations as fact — because those are questions for your lawyer, and they change. Where the law matters, the post tells you to ask counsel. That caution is the point.

Nepali businesses hold more customer data than ever — phone numbers at checkout, citizenship copies for KYC-adjacent flows, location trails from delivery apps, browsing behaviour in GA4 — while operating mostly on vibes and copied privacy pages. The Individual Privacy Act, 2075 (2018) recognizes the right to privacy of personal information and sets limits on collecting and using it; the Electronic Transactions Act, 2063 covers cybercrime, with complaints handled by the Cyber Bureau of Nepal Police. Our course materials state exactly that much, and so does this guide — everything below it is conservative practice that keeps you safe under any reasonable reading, plus clear flags for where counsel is required.

Nepal Privacy Act for Businesses: Customer Data, Opt-Ins and Cookie Basics

1. The principles that cover most situations

Until and unless your lawyer tells you otherwise, run every data decision through these:

  • Consent first: collect personal data with the person’s knowledge and agreement — checkout checkboxes (unticked by default), signup forms stating purpose, QR opt-ins. Pre-ticked boxes and silent list-building are the opposite of consent.
  • Purpose limits: data collected for delivery may not silently become a marketing list, be sold onward, or train a model. New purpose → new consent.
  • Minimization: do not collect what you will not use. Every field on a form is a liability you store — citizenship numbers, precise location and health-adjacent data deserve extra justification or omission.
  • Retention limits: delete or anonymize when the purpose ends (order delivered + warranty window, not forever). A deletion schedule beats good intentions.
  • Security proportionate to sensitivity: access controls, staff permissions by role, and no customer data in personal phones, shared spreadsheets or public chat groups.

2. Email and SMS opt-ins that hold up

  • Separate transactional messages (order updates the customer asked for) from promotional messages (offers they did not explicitly request) — consent standards differ in practice, and mixing the streams poisons both.
  • Keep the consent record: what was agreed, when, where (screenshot the form version). Disputes are won on records.
  • Every promotional message carries a working opt-out: one-click unsubscribe in email, STOP-style instruction in SMS. Honour it immediately and confirm.
  • Never purchase lists, scrape numbers, or add event attendees to marketing without a separate explicit opt-in. See the email deliverability guide for the technical half and Viber for channel consent norms.
  • If the site runs GA4, ads pixels or embedded social trackers, show a cookie banner disclosing categories with accept/decline — and wire the choice into GA4 via Consent Mode so declined means no tracking storage, not a decorative button.
  • Inventory third-party embeds (chat widgets, video embeds, fonts, pixels): each is a data flow to someone else’s server. Remove what you do not use.
  • Keep a short public cookie note naming each category, its purpose and retention. One honest page beats a copied 4,000-word policy nobody maintains.

3B. Anatomy of a Nepali SME privacy policy

Write yours in plain language with these sections — one honest page beats a copied template (see ours for structure, not to copy-paste, since your data flows differ):

  1. Who you are: business name, address, contact for privacy questions.
  2. What you collect and why, per item: orders (fulfilment), phone (delivery coordination), email (receipts and — only with consent — marketing), analytics (site improvement). Purpose beside every category.
  3. Who else touches it: payment providers, couriers, ESPs, analytics — named, with what each receives.
  4. How long you keep it: order records through warranty/tax windows, marketing data until unsubscribe plus a short suppression hold, logs per a stated rotation.
  5. Reader rights: how a customer asks what you hold, corrects it, or requests deletion — with a working contact and response-time promise.
  6. Updates: dated revision note each time practice changes; material changes get an active notice, not a silent edit.

3C. Secure storage minimums for small teams

  • Customer data lives in systems with logins and roles — never in shared spreadsheets, personal phones, or public chat groups. The spreadsheet on someone’s laptop is the breach you will report one day.
  • Backups encrypted and tested by restore (an untested backup is a hope, not a backup); know who can restore and how long it takes.
  • Staff see only what their role needs; revoke everything the day someone leaves — accounts, sheets, ad platforms, chat admin roles.
  • No customer data in screenshots dropped into group chats, and no “just this once” list sharing with partners. The exceptions people remember are the ones that leak.

4. Breach response before you need it

  • Decide now who gets told, in what order, when customer data leaks: internal owner, affected customers, counsel, and (where applicable) the authorities including the Cyber Bureau.
  • Preserve logs before investigating — the instinct to delete first destroys both recovery and evidence.
  • Notify affected customers plainly: what happened, what data, what you did, what they should do. Template the message now; drafting under panic produces the worst version.
  • After-action: how access happened, what closed it, what changed. File it with the incident.

5. Vendor and staff hygiene

  • Contracts with agencies, freelancers and SaaS tools should state who may access customer data, for what purpose, and when access ends. Our own white-label terms model this: defined access, defined purpose, clean exits.
  • Offboard access the day staff or vendors leave — accounts, sheets, ad platforms, chat admin roles.
  • Train frontline staff once a quarter on the three refusals: no customer data in personal phones, no screenshots of customer records in group chats, no “just this once” list sharing.

When to call your lawyer (non-exhaustive)

New data-heavy product launch, cross-border data transfers, handling children’s data, a received complaint or breach notice, employee monitoring disputes, or any plan to monetize customer data beyond its original purpose. Budget a legal review the way you budget hosting — routine infrastructure, not emergency spend.

What to do this week

  1. Add purpose statements to every collection form and untick every pre-ticked box.
  2. Publish the short cookie note and verify declined actually disables tracking.
  3. Delete one dataset you have no purpose for — start the retention habit visibly.
  4. Book the lawyer call for the items in the section above you cannot answer.

Related reading: email deliverability, WhatsApp automation, COD attribution, analytics setup, and contact for analytics and tracking implementation (Rs. 7,200+ scoped work — legal questions go to counsel, not to us).