Hong Kong has its own privacy law: the Personal Data (Privacy) Ordinance, known as PDPO. It’s enforced by the Privacy Commissioner for Personal Data, the PCPD. If you run a business in Hong Kong and you store customer information in a CRM — names, phone numbers, email addresses, ID numbers, purchase history — PDPO applies to you. It doesn’t matter if you’re a 3-person consultancy or a 200-person agency.
The problem is that most CRMs on the market today were not built with PDPO in mind. They were built for GDPR, the European privacy regulation. GDPR and PDPO overlap in spirit, but they are not identical. Hong Kong SMEs who pick “whatever big CRM” often end up with two issues: they pay for features they don’t need (GDPR consent banners designed for EU visitors), and they lack features they actually do need (a clean way to handle a data subject access request within the 40-day PDPO deadline).
This post walks through what PDPO actually requires, what features your CRM should have to support it, and the questions to ask any CRM vendor before you sign up.
What PDPO actually requires
PDPO is organised around six Data Protection Principles, usually called the DPPs. You don’t need to memorise the legal text — here’s what each one means in plain English, with a concrete CRM example.
DPP 1 — Purpose and manner of collection. Only collect personal data you actually need for a stated purpose, and tell people what that purpose is. If you ask for a customer’s Hong Kong ID number on a contact form, you should have a specific reason (e.g. because you’re running a regulated financial service). If you’re a coffee shop taking loyalty signups, you don’t need an HKID — asking for it would breach DPP 1.
DPP 2 — Accuracy and retention. The data you hold must be accurate, and you cannot keep it longer than necessary. If a lead went cold 5 years ago and is unlikely to ever buy, you shouldn’t still have their phone number sitting in your CRM. Your CRM should let you set retention rules and clean up old data automatically.
DPP 3 — Use of personal data. You can only use data for the purpose you collected it for (or a directly related purpose), unless you get fresh consent. If someone gave you their email to receive an order confirmation, you cannot later use that email for marketing without asking first.
DPP 4 — Security. You must protect personal data from unauthorised access, loss, or theft. This means encryption, strong passwords, role-based permissions, and an audit log of who accessed what. If your CRM stores credit card details in plain text, or every employee has admin access, you’re failing DPP 4.
DPP 5 — Information to be generally available. People should be able to find out, in general terms, what personal data you hold and how you use it. This is why businesses publish a privacy policy. Your CRM choice affects this: if you can’t describe what the CRM stores, you can’t be transparent about it.
DPP 6 — Access and correction. Anyone whose data you hold has the right to ask for a copy of it, and to ask you to correct it if it’s wrong. Under PDPO, you have 40 days to respond to a data access request. Your CRM must make it possible to pull all data on one person in that window.
It’s also worth noting the 2021 PDPO amendments, which introduced criminal offences for “doxxing” — disclosing someone’s personal data without consent, with intent to cause harm or reckless as to whether harm is caused. This raised the stakes for any business that handles contact data. You should verify the current state of the law with the PCPD (www.pcpd.org.hk), as guidance is updated periodically.
CRM features that matter for PDPO
Not every CRM feature has a privacy dimension, but these do. Each one maps to a DPP, and each one is worth asking about before you buy.
Data subject access request export (DPP 6). When a customer emails you asking “what do you have on me?”, you have 40 days to respond. A good CRM lets an admin export all data on one specific person — records, messages, activity history, attachments — in a machine-readable format, in a few clicks. A bad CRM makes you run SQL queries or contact support. There’s a meaningful difference between exporting one contact’s file and exporting a whole workspace: the former is for subject access requests, the latter is for backups or migrating away.
Data erasure that preserves integrity (best practice, and aligned with GDPR if any of your customers are EU residents). PDPO itself doesn’t include an explicit “right to be forgotten,” but retention limits in DPP 2 amount to a similar obligation in practice. A good CRM anonymises personal fields (name, phone, email, ID) while keeping the record’s relational links intact — so your financial history, invoices, and audit trail don’t break. Hard-deleting a contact row sounds satisfying but usually leaves dangling references and corrupted reports. Anonymisation is the safer pattern.
Purpose limitation and PII tagging (DPP 1, 3). Your CRM should let you mark which fields contain personal data: names, phone numbers, email addresses, tax IDs, government IDs, dates of birth. Once fields are tagged, an admin can audit what’s actually being collected and whether it’s still justified. If you discover you’ve been storing HKID numbers on 8,000 contacts but your business doesn’t need them, you can remove the field.
Retention policies (DPP 2). Different data has different lifetimes. Finance records in Hong Kong generally need to be kept for 7 years for tax purposes. A lead that went cold should probably not sit in your pipeline for more than 2 years. Marketing consent often needs to be refreshed annually. Your CRM should let you configure these rules and automatically archive or purge data when it hits the limit — not leave it to a yearly manual cleanup that never happens.
Audit log (DPP 4). Every access and every change to personal data should be logged: who viewed the record, who edited the phone number, who exported the contact list. Keep the log for at least 12 months; longer is better. If you ever suffer a data breach, the audit log is how you reconstruct what was exposed and notify the affected people.
Per-user permissions (DPP 3). The support agent does not need to see the sales pipeline. The marketing intern does not need to see private notes on VIP clients. A CRM where “everyone is an admin” is a DPP 3 failure waiting to happen. Look for proper role-based access: profiles, field-level permissions, and record-level visibility rules.
Encryption at rest and in transit (DPP 4). Data travelling between the browser and the server must be encrypted with TLS (look for the padlock and HTTPS). Data sitting in the database should be encrypted at rest, typically with AES-256. Most reputable CRMs already do this, but it’s worth asking.
Data residency (DPP 4 in spirit). Hong Kong does not have a strict data residency law today — you’re allowed to store personal data overseas. But some regulated industries do have requirements: financial services firms under SFC supervision, healthcare providers, insurers. Even if you’re not regulated, some enterprise customers will ask where their data sits before they sign a contract. A CRM that lets you choose a region (Hong Kong, Singapore, EU) gives you more options.
How HARi approaches PDPO compliance
We built HARi for Hong Kong SMEs, so PDPO was a design input from day one — not a retrofit. Here’s what’s actually in the product today.
Full workspace export. An admin can request a ZIP of every entity, every message, the audit log, attachments, and email history. It’s generated in the background and delivered to the admin’s email as a secure download link within about 15 minutes. The link expires after 24 hours. This covers the case where you want a full backup, or you want to migrate away from HARi (we don’t lock in your data).
Per-record data export. For a DPP 6 data subject access request, you can pull all data on one specific contact: their record, every field, all messages (email, WhatsApp, etc.), the full audit trail of changes, attachments, and activity history. The export is structured so you can hand it to the person who asked, in a format they can actually read.
Data erasure. When a customer asks to be forgotten, HARi anonymises personal fields — name, email, phone, tax ID, LinkedIn URL, bio, salary, date of birth, and any custom fields you’ve marked as PII. The record stays in place (so financial history and audit links don’t break), but the personal identifiers are replaced with anonymised placeholders.
Audit log partitioned monthly. We keep 13 months of audit log by default, partitioned one month per table. Older partitions are dropped automatically — no manual cleanup, no slow deletions. Retention is configurable if you need to keep longer.
Encryption. Data at rest in PostgreSQL, TLS 1.3 in transit between your browser and our servers.
Multi-tenant database isolation. Your workspace is in its own dedicated database. Your data is not in a shared table with other HARi customers. This is unusual in SaaS — most CRMs share one database across all customers with a tenant ID column. Isolated databases make data export, data erasure, and incident response much cleaner.
Self-service “Close my workspace.” If you want to leave, an admin can close the workspace from settings. There’s a 30-day grace period during which everything is recoverable (in case you change your mind, or a disgruntled employee deletes in anger). After 30 days, the database is dropped.
You can read the details in our privacy policy. Pricing is on the pricing page. You can sign up or log in at /app.
Questions to ask any CRM vendor about PDPO
Before you commit to any CRM — HARi or otherwise — take these questions to a sales demo. The answers will tell you a lot about how seriously the vendor takes privacy.
- Where is my data stored? (Hong Kong, Singapore, US, EU?)
- How do I export all the data you hold on one specific contact?
- How do I handle a data subject access request within the PDPO 40-day deadline?
- What’s your default retention policy, and can I configure it?
- Who at your company can access my data? (Ideally: no one, unless I grant support access in writing, and the access is time-bounded and logged.)
- How do I close my account and get my data out?
- Is there an audit log? How long is it kept?
- If I’m breached, how will you help me reconstruct what was exposed?
If the vendor cannot answer these clearly — or if the answers require “contact your account manager” for the basic ones — that’s a signal.
Closing
PDPO compliance isn’t a checkbox. It’s a mindset, and it shows up in the product. A CRM that takes privacy seriously has actual features — data export, anonymisation, audit logs, permission controls — not just a privacy policy PDF on the marketing site. It lets you see your data, correct it, export it, and delete it on your own, without filing a support ticket. A CRM that doesn’t is a liability waiting to become a regulatory problem, or worse, a breach you can’t explain.
If you’re evaluating CRMs for a Hong Kong business and PDPO is on your mind, we’d be happy to walk you through HARi’s compliance features specifically. You can start a free workspace at /app, or email us for a demo focused on the topics in this post. No pressure, no sales script.
This post is general information, not legal advice. For specific questions about PDPO obligations for your business, consult the PCPD (www.pcpd.org.hk) or a Hong Kong-qualified lawyer.