Data Protection & PDPA

Every conversation about connecting Medivis to a business's systems starts with the same worry: will you copy our contact database, break our records, or leak them? That worry is reasonable, and this page answers it directly.

Your contact records are not our asset. We do not sell them, share them for advertising, use them to build products for anyone else, or keep them when you tell us to let them go. Our revenue comes from business subscriptions — never from contact data.

Malaysia's Personal Data Protection Act 2010 (Act 709), as amended by the Personal Data Protection (Amendment) Act 2024 (Act A1727), assigns clear roles:

• Your business is the data controller (the amendment's term for what Act 709 originally called the "data user"). The business decides why and how contact data is processed, obtains contact consent, and — as a licensed private healthcare facility — registers with the Personal Data Protection Commissioner under the Class of Data Users Order.
• Medivis is the data processor. We process contact data on the business's behalf and on its documented instructions only. We have no relationship with your contacts for purposes of our own, and no right to use their data for any.
• Your contacts are the data subjects, and their health data is sensitive personal data under the Act — the highest-protection category, requiring explicit consent to process.

One change in the 2024 amendment matters especially here: since its phased entry into force through 2025, data processors are directly bound by the Act's Security Principle — no longer only via contract. A processor that fails to protect the data it holds commits an offence carrying a fine of up to RM1,000,000, imprisonment of up to three years, or both. Protecting your contacts' data is not just our promise to you; it is our own statutory duty, with our own liability attached. Our incentives and yours point the same way.

Some businesses ask Medivis to connect to their existing business management system so that appointments stay in sync and the front desk does not maintain two calendars. Asking a vendor for access to the system that holds your contact records is a serious request, so we hold it to a standing set of rules. No connection is made before the scope is agreed in writing — which fields, which direction, and for what purpose — as part of the data processing agreement.

The connection exists to serve your business's bookings, and it stays exactly that size.

These are not aspirations — each of the following is built into the Medivis codebase today, and our Security page describes the full control set.

• Isolation by construction. Every database query is automatically filtered to your business and workspace at the query-engine level — not left to a developer remembering to add a filter — and an automated check fails our build if any application page bypasses the scoped client. Cross-workspace writes are rejected.
• Identity card numbers are never stored in readable form. Only a keyed one-way hash (HMAC-SHA256) is kept, used to recognise a returning contact. A leaked database does not become a leaked list of IC numbers.
• Identifiers are scrubbed before AI. Before any message text reaches the AI provider, identity card numbers, passport numbers, phone numbers and email addresses are replaced with anonymous tokens.
• Credentials encrypted at rest. Secrets held on a business's behalf — including its AI API key — are encrypted with AES-256-GCM before they reach the database. All traffic is encrypted in transit over HTTPS.
• Account protection. Staff passwords are hashed with bcrypt; an account locks automatically after 5 failed sign-in attempts; sign-in endpoints are rate-limited; and business sessions and the platform console use separate signing keys and token audiences, so one can never impersonate the other.
• Audit logging. Significant actions are recorded in a per-business audit log, and platform administrator actions are written to a separate platform log.
• Attachments are permission-gated. A WhatsApp attachment can only be opened by staff with access to that workspace — checked on every request, not once at sign-in.
• Webhooks are signed. Every inbound webhook is verified against an HMAC-SHA256 signature before processing; invalid signatures are rejected.
• Contact opt-outs are enforced at send time. A contact who replies STOP is honoured immediately — including for booking confirmation notices, not just marketing messages.

• A written Data Processing Agreement (DPA) with every business. It records the scope of processing, our security obligations, staff confidentiality, your right to audit our compliance, and the sub-processors we use (our hosting provider, the WhatsApp bridge, and the AI provider).
• Breach notification on the clock the law sets for you. If a personal data breach affects your data, we notify you — the data controller — without undue delay, so you can meet your statutory duty to notify the Personal Data Protection Commissioner as soon as practicable (and within 72 hours where the breach causes or is likely to cause significant harm), and to notify affected contacts within 7 days where required.
• Your data leaves with you. When the contract ends, we return or delete personal data as you instruct, with written confirmation, subject only to retention the law requires of us.
• No processing for our own purposes. Your contacts are not our marketing list, our training corpus, or our product. Processing happens on your instructions or not at all.

Can Medivis staff read our contact records?

Access is role-based and need-based. Your data sits in an isolated workspace, staff access within your own business is scoped to the branches they are assigned to and re-checked on every request, and platform-level administrator actions are written to a separate audit log. Nobody's access — ours included — is invisible.

Will our contact data be used to train AI?

No. Message text goes to the AI provider only to generate a reply for your own business, with identity card numbers, passport numbers, phone numbers and email addresses replaced by anonymous tokens first. Each business's AI key is stored encrypted and used only for that business. Medivis does not use contact data to train models, and does not use it for any purpose of its own.

Where is our data stored?

Application servers and the database are hosted in Singapore. Message text sent to the AI assistant is processed in the United States by OpenAI, with identifiers removed first and a data processing agreement in place. In each case we require a level of protection consistent with the PDPA, and our PDPA Notice sets out the cross-border position in full.

Could you copy our whole contact database through the CMS connection?

No. The connection has no bulk-export path, its scope is limited to the fields agreed in writing, and you can revoke its access at any time. A connection built for appointment sync can do appointment sync — that is the point of scoping it in the contract rather than asking you to trust restraint.

What happens to our data when we stop using Medivis?

You choose: we return it, delete it, or both — with written confirmation, subject only to retention the law requires. A business that merely lapses on payment is locked out, not deleted, so nothing is lost while an account is being settled.

Is Medivis "PDPA certified"?

No — because no such certification exists. Malaysia has no PDPA compliance certification scheme; a vendor claiming to be "PDPA certified" is telling you something the law does not provide for. What does exist: registration of data controllers with the Commissioner (which applies to your business), and direct statutory duties on data processors under the 2024 amendment (which bind us). We meet ours through the measures on this page and the commitments in the DPA — and we would rather tell you that plainly than print a badge that means nothing.

Want a copy of our standard Data Processing Agreement, or have questions before granting CMS access? Ask — before you sign anything, not after.