Row-level isolation
Every table carries an access policy that ties each row to the clinic that owns it. A user only ever sees their own clinic’s rows, and no path in the application bypasses that policy.
Security and privacy
Isolation in Modirify is not a hidden button in the interface. Every table carries an access policy enforced inside the database itself, so a request that tries to read another clinic’s data is not refused in the browser — it never returns a row at all.
Every query passes through a policy that resolves which clinic the current user belongs to. No screen and no API can bypass it, because it is not enforced in the application — it is enforced beneath it.

Specific controls you can describe and review, instead of general statements about security.
Every table carries an access policy that ties each row to the clinic that owns it. A user only ever sees their own clinic’s rows, and no path in the application bypasses that policy.
Each team member has an account, a role and an allowed_screens list aligned with responsibility. Reception can reach appointments, a dentist the permitted patient records, and an accountant the permitted numbers, instead of every user receiving unrestricted access.
Changing sensitive permissions and doctor commissions, and permanently deleting team records, is restricted to the clinic owner. Owner-only triggers protect these actions and the database refuses an attempt by another user even if the interface sends it.
Eligible private files use temporary signed links rather than public storage. Clinic, practitioner, service and working-hour settings remain separate and sensitive platform administration stays protected by platform privileges.
All traffic between the browser and our servers runs over HTTPS/TLS, with a policy that instructs the browser to use the encrypted connection on every later visit.
Security headers stop the site being embedded in a foreign frame, block unapproved scripts, prevent file-type guessing, and restrict what the page may request — camera and location included.
Messages arriving from external services such as WhatsApp are not trusted on content. Each is accepted only after its cryptographic signature is verified; an unsigned message is rejected before it is read.
Tokens linking your clinic to external platforms are stored encrypted, and the decryption key is held outside the database — so it is not exposed even to someone reading the tables.
Data decisions remain with the clinic, with a published route for every action.
Set each team member’s role and allowed_screens list, and change it from clinic settings within the owner permission boundary.
Significant actions inside the system are recorded and can be reviewed from the activity log screen.
Share links and WhatsApp messages never carry a patient’s name or details in the URL, so they cannot leak through history, referrers or analytics.
The route to delete an account and its data is published on its own page, and the request can be made without going through a sales team.
Operational access is restricted and used for support only at your request. Database policies restrict reads by clinic, and the processing details are published in the privacy policy.
No. We hold none of those certifications today and we do not claim otherwise. What this page describes are the controls actually implemented in the system, and we are happy to walk through them before you subscribe.
The platform runs on managed cloud infrastructure using a PostgreSQL database and a global content delivery network. Processing and retention details are set out in the privacy policy.
Processing after cancellation follows the privacy policy, the terms of service and the published data-deletion request — not an undocumented fixed period.
A cloud platform that helps dental clinics manage everyday work in one place.
Start with Modirify