Security

Medivis holds contact details and business conversations for many businesses on one platform. Two properties therefore matter more than any other: a business must never see another business's data, and a leaked database must not become a leaked list of identity card numbers.

Our approach follows the OWASP Top 10 and is designed to meet the Personal Data Protection Act 2010 (Act 709) of Malaysia.

• In transit: HTTPS only, TLS 1.3. Unencrypted HTTP is not served.
• At rest: secrets held on behalf of a business — its OpenAI API key, the platform key, WhatsApp bridge credentials and webhook secrets — are encrypted with AES-256-GCM before they reach the database.
• Passwords: hashed with bcrypt. Plaintext passwords are never stored or logged.
• Identity card numbers: stored only as a one-way hash, used for matching a returning contact. The number itself is never written to the database in readable form.

• Business staff: sign in on the business's own subdomain by picking their name and entering a password. The sign-in page never reveals staff email addresses. A signed session token (24-hour expiry) is issued on success.
• Platform administrators: a separate realm with its own account table and its own cookie. Password plus a 6-digit code emailed at sign-in; the console is unreachable from any business subdomain.
• Lockout: 5 failed attempts locks an account for 15 minutes. Sign-in responses are uniform, so a wrong password and an unknown account are indistinguishable.
• Password reset: a single-use token valid for 30 minutes. Only its SHA-256 hash is stored, so a database leak does not yield working reset links.
• Role-based access: owner, admin, doctor, staff and marketing, checked on every request rather than only at sign-in — a deactivated account loses access immediately, not when its token expires.
• Branch scoping: staff assigned to a branch can only reach that branch's conversations and calendar.
• No contact logins. Contacts reach the business through WhatsApp only. There is no contact portal to attack and no contact credential to steal.

Every business is a separate tenant with its own subdomain, its own session cookie, and its own slice of the database. Isolation is enforced in three places rather than trusted to discipline:

• At the door: one choke point resolves the tenant from the hostname and refuses a session whose business does not match it. Replaying another business's cookie gets you nowhere.
• At the query: application pages run against a database client that rewrites every query on a tenant-owned table to carry the business filter. Forgetting the filter is not possible, because the filter is not written by hand.
• At build time: an automated check fails the build if any page in the business, branch or staff areas imports the unscoped database client at all.

These controls are application-level and are covered by an automated cross-tenant test suite that runs against a live database.

• WhatsApp Business Platform: reached through a Meta-authorised Tech Provider partnership, not an unofficial gateway.
• Inbound webhooks: every payload is verified against an HMAC-SHA256 signature before it is processed, and events are deduplicated so a replayed delivery cannot double-post a message.
• Outbound sends: resolved to the WhatsApp account that belongs to the requesting business. A message can only leave on that business's own number.

Medivis is built and operated by a recognised partner and Tech Provider — giving us direct access to the WhatsApp Business Platform, Facebook and Instagram APIs, rather than reselling another vendor's.

• Identifiers — identity card numbers, phone numbers, email addresses — are scrubbed from message text before it is sent to the AI provider.
• A guard layer blocks medical-advice requests and hands the conversation to business staff rather than answering.
• The agent can only take actions the business has enabled, and every action it takes is written to the audit log with its inputs and outputs.
• Bookings the agent makes are re-validated inside the writing transaction, so it cannot double-book a slot that filled while it was replying.

• Sign-ins, sensitive actions and data changes are logged with a timestamp, the account, and what changed.
• Platform administrator actions are written to a separate append-only log that business staff cannot reach.
• Audit logs are retained for 5 years and are not editable through the application.

• Automated daily backups of the whole database, encrypted before storage.
• Point-in-time recovery for disaster scenarios.
• Retention: 30 days of daily backups, plus weekly snapshots kept for 3 months.
• Suspension is not deletion: a business locked out for non-payment keeps every row until it asks us to remove them.

• Hosting: Singapore region, keeping data resident in Asia.
• Database: PostgreSQL, reachable only from the application network.
• Network: a web application firewall and DDoS protection at the edge.
• Monitoring: continuous infrastructure monitoring with automated alerting.

• Detection: continuous monitoring and automated alerting on security events.
• Notification: affected businesses and the DPO are notified within 72 hours of a confirmed personal data breach.
• Regulatory reporting: breaches are reported to the Department of Personal Data Protection Malaysia (JPDP) within the legally required timeframe.
• An incident response plan is maintained and regularly tested.

• Personal Data Protection Act 2010 (Act 709) — Malaysia's data protection law
• Meta Business Platform Terms — as an authorised Meta Tech Provider
• OWASP Top 10 — industry best practice for web application security
• ISO 27001-aligned — information security management practices; certification is not held

We welcome reports of potential vulnerabilities. Please contact us at kobaranteguh@gmail.com.

We commit to:

• Acknowledge your report within 48 hours
• Give an estimated timeline for a fix
• Take no legal action against researchers acting in good faith