By law and region The database Access The data AI governance The code Sub-processors What we do not claim yet Questions Legal centre security.txt

Trust centre

Only what we can show you.

This page lists the controls that exist in the running product today, each with the thing that makes it checkable rather than a promise. Your records are stored in the database and object store we operate, Boston, United States · Hostinger VPS; some optional features — AI drafting, transcription, video visits, email and WhatsApp delivery, GST e-invoicing — send data to the sub-processors listed further down, each in the region shown there. What we have not built, or not yet proved, is at the bottom of the page under its own heading.

Send us your questionnaire What we do not claim yet

21 controls, each with its evidence
One region · infrastructure we operate
DPDP-aligned consent

What we hold, and where

Data stored in: Boston, United States · Hostinger VPS
Hosting: One region · infrastructure we operate
Privacy programmes: HIPAA · in progress UK GDPR · in progress PIPEDA · in progress Privacy Act · in progress DPDP · in progress
Held: None yet. What we do not claim
Sub-processors: 25, listed below
Status as of: 24 September 2026

By law and region

One page per privacy law.

Each with a dated status table as of 24 September 2026: what is in place, what is in progress, and what you would need to do. None of them claims compliance or certification; each is a programme in progress.

HIPAAUnited StatesProgramme in progress1 of 9 of our items in place UK GDPRUnited KingdomProgramme in progress1 of 8 of our items in place PIPEDACanadaProgramme in progress1 of 6 of our items in place Privacy ActAustraliaProgramme in progress1 of 6 of our items in place DPDPIndiaProgramme in progress4 of 7 of our items in place

Weighing MedAppz against other software? See the comparisons, each from the other vendor’s own website and dated.

The database

What the database itself enforces

The two controls a hospital's IT committee asks about first are not written in application code, where a missing line would be enough to break them. They are constraints in the database, so they hold even for code that forgets.

One clinic can never read another clinic’s rowsEvery table that holds tenant data carries row-level security, and the account the application runs as is not allowed to switch it off. The tenant is bound to the transaction, not to a filter someone might forget to write.Enforced by the database, and tested on every push.

The audit trail cannot be edited or deletedPatient record opens, searches and exports are written once — who, when, from which address, under which permission, over which class of data. The log is hash-chained day by day, so removing or altering an entry breaks the chain.Append-only by database trigger; the chain is re-verified nightly.

the account the application runs as — not allowed to switch it offthe tenant, bound to the transactionevery table that holds tenant data carries row-level securityanother clinic’s rows — never read✓ Enforced by the database, and tested on every push.

Access

Who gets in, and for how long

Access is short-lived by default and every widening of it — an emergency, a support visit — has an expiry and a reviewer attached before it is granted.

Passwords are hashed with Argon2id, and accounts lockPasswords are never stored or logged in a readable form. Five failed attempts lock the account, and every sign-in endpoint is rate-limited.Checked on every sign-in, before the password is even compared.

Two-factor authentication is available to every user, and an organisation can require itApp-based one-time codes with recovery codes. The secret is encrypted at rest; an administrator reset needs a written reason and is recorded. An organisation chooses whether a second factor is optional, required of its administrators, or required of everybody.The choice is enforced at sign-in, not suggested by the screen.

Sessions are short and refresh tokens rotateAn access token lasts fifteen minutes. Refresh tokens rotate on use, and re-use of an old one revokes the whole family. Every request re-checks that the session is still live, and shared devices idle out in five minutes.Revocation is checked server-side on the request, not trusted from the token.

Emergency access expires and must be reviewedA clinician can break the glass to reach a record in an emergency. That grant lasts at most four hours, ends by itself, and lands on a review queue; an unreviewed grant stays flagged.The expiry is a database constraint, not a reminder.

Our support access is time-boxed, and you can see itA MedAppz engineer cannot walk into your tenant. Access needs a written reason, defaults to thirty minutes with a two-hour ceiling, can be granted read-only, and appears in your own audit trail while it is happening.Expires on a scheduled sweep; visible to you, not just to us.

Two-person rules where one person should not decide aloneA purchase approval cannot be granted by the person who raised it, and role assignments are checked for the combinations that break segregation of duties.Self-approval is refused by a database constraint, not by a screen.

The data

What happens to the data itself

Secrets, consent, exports, backups, transport, identity numbers and the mailbox — the places where clinic data is most often mishandled.

Credentials you give us are sealed and never shown backGateway keys, mailbox passwords and integration secrets are encrypted with a per-row key bound to your organisation. No screen and no endpoint will read one back to anybody, including us.There is no read-back path in the product; every decrypt is recorded.

Consent is checked per message, at the moment of sendingReminders, results and campaigns are gated on the consent notice the patient actually accepted, by version. Withdrawing consent cancels what is already queued. On a connected WhatsApp number, replying STOP or UNSUBSCRIBE withdraws it without anyone having to act on the message; by SMS the same reply works once the clinic has pointed its SMS gateway at the phone line’s opt-out URL, and until it does a texted STOP reaches nobody.Checked at the point of use and written to the audit trail each time. The SMS half is a setting the clinic makes, and CallDesk says so beside the line.

Exports are whitelisted, permission-checked and recordedOnly views we have listed in advance can leave the product. Each export needs the matching permission and is recorded with the row count and the classes of data it carried; spreadsheet formulas in patient data are neutralised on the way out.A view that is not on the list has no export at all.

Backups run nightly, are verified, and the restore is rehearsedThe database and the files are dumped every night and the dump is checked rather than assumed. The restore has been performed end to end, most recently on 3 September 2026.Verified nightly; the restore drill is a written procedure, not a plan.

TLS everywhere, and a content policy that blocks strangersCertificates renew automatically. The API answers with a deny-everything content security policy, and the application page blocks third-party scripts and connections outright.Set by the application, so it ships with the code rather than with a server setting.

Aadhaar and ABHA numbers are never stored in the clearOnly a hash and the last four digits are kept, which is enough to match a patient and not enough to reproduce the number.Refused by a database constraint if anything tries to store the full number.

Your mailbox is proxied, not copiedConnecting a clinic mailbox opens a live proxy to your own mail server: what arrives is read through the proxy and is never copied into our database. Mail you compose and send from MedAppz is the exception, and it is deliberate — the subject, the body and the recipient list are stored so that a send interrupted half way resumes from the rows rather than starting again, and so you can see afterwards exactly what went out.Received mail has no table to be stored in. Sent batches have one, and we keep it — see “What we do not claim yet”.

AI governance

AI in the product drafts. It does not decide, and it cannot be switched on quietly.

AI is governed like a controlled substanceEvery model call runs through a registered use case with a risk tier. Clinical and financial outputs must be grounded in your own records, and a named person accepts or discards the draft — the model never signs. Prompts are stored redacted and purged on a schedule. You can bring your own model key, or switch AI off entirely and keep the manual path.A call with no registered use case is refused; the retention sweep runs as a scheduled job.

Video visits happen on a server you can nameA video visit needs a video service configured for the deployment — a Jitsi server the clinic runs, not a public room. The join link is a signed token minted for one named person when they say they are going in, and it expires; it is not a room name pasted into a list. The patient gets their own link to the same room, as a guest — no moderator rights and no ability to record. With nothing configured, TeleCare refuses to schedule a visit at all rather than falling back. Turning recording on requires a service that can actually record; without one the switch refuses instead of setting a flag that means nothing.Rooms created before this — public rooms anybody with the link could enter — no longer produce a join link at all.

You decide what leaves for the model, and it applies to the wireOne setting per organisation: off, redacted or full, and redacted is the default. Redacted replaces the name of the patient a request is about with a role word, the date of birth with an age, and removes the hospital number, phone number and email address — from the outbound prompt and from the record excerpts, before the request leaves the process, not merely from the copy we keep. Anything else shaped like a phone number, an email address or a long identity number goes with it. A request whose record we cannot read is refused rather than sent with nothing substituted. Off means the AI buttons and consultation transcription refuse and say why, rather than sending a reduced version. A recording is the exception and we say so on the consent form: a voice cannot be reduced, so audio is either sent for transcription exactly as recorded, or not sent at all. What remains is the clinical text, which can still describe a person: this is a reduction in exposure, not anonymity, and we say so on the consent notice too.Applied between choosing the provider and calling it; each request records which of the three it received.

The code

The discipline around the code

3 checks that fail a build rather than produce a warning nobody reads.

Migrations are forward-only and checksummedA schema change is applied once, in order, and its checksum is recorded. An edited migration fails the run rather than quietly diverging from what production has.The build applies them twice to prove a second run changes nothing.

A build that logs a patient field failsLog statements are scanned for the field names that carry patient data. The build fails on a match, so the class of leak that shows up in a support ticket months later cannot ship.Runs as a required check on every push.

Our own operator console cannot query patient dataThe console MedAppz staff use to run the platform is walled off from clinical data by the build: any code in it that names a clinical schema fails the check.Refused by the build, not by a policy someone remembers.

Sub-processors

Every outside service, and what it receives.

A service reached only because you turned on the feature it powers is still on this list, and so is the company whose machine the database itself runs on. Some rows are your own systems — your mail server, your video server, a database you bring — and each says whose contract covers it. This table is generated from the register the product itself reads, so it cannot describe a set of vendors we no longer use. Nothing outside this list is sent your data, and we hold no signed processing agreement with any of the third parties on it yet.

Service	What it receives	Region and contract
Hostinger — The rented server the database, the application and the uploaded files run on	Everything the clinic stores, at rest and in memory	One rented regionOn our contract
S3-compatible object storage — Where uploaded files and documents live when object storage is switched on	Every uploaded file: scans, reports, photographs, consultation audio	The bucket region the deployment configuredOn our contract
Anthropic — AI drafting and answering	The question asked, and the excerpts of the record it must answer from	United StatesOn our contract
OpenAI — AI drafting and answering	The question asked, and the excerpts of the record it must answer from	United StatesOn our contract
Google (Gemini) — AI drafting and answering	The question asked, and the excerpts of the record it must answer from	United StatesOn our contract
NVIDIA NIM — AI drafting and answering	The question asked, and the excerpts of the record it must answer from	United StatesOn our contract
The configured speech-to-text service — Turning a consultation recording into a transcript	The consultation audio, in full — as a recording after the visit, or streamed while the visit is still going on when live transcription is on	Wherever SPEECH_API_BASE_URL points — api.openai.com (United States) unless changedOn our contract
The clinic’s own Jitsi server — Carrying the live audio and video of a video visit	The live audio and video of the consultation, and the participants’ names	Wherever the clinic hosts itYour own system
Resend — Sending email	The recipient’s address and the message body	United States / European UnionOn our contract
MSG91 — Sending SMS	The mobile number and the DLT-approved message	IndiaOn our contract
Meta (WhatsApp Business) — Sending WhatsApp messages through the official API	The mobile number and the message body	Meta’s global networkOn our contract
The clinic’s paired WhatsApp number — Sending WhatsApp messages from the clinic’s own handset session	The mobile number and the message body	Meta’s global network, through the clinic’s own numberYour own system
The common WhatsApp assistant number — Staff asking the assistant from their own WhatsApp, and patients who write to the common number	The staff member’s mobile number, their questions and voice notes, and the assistant’s replies (patient details reduced out unless the clinic chose full)	Meta’s global network, through the platform’s paired numberOn our contract
Google (Firebase Cloud Messaging) — Delivering push notifications to a phone	The notification title and up to 200 characters of its body	Google’s global networkOn your own key
Razorpay — Taking a payment online, and holding a standing UPI Autopay or e-mandate authorisation	The payer’s name, phone number, email address and the amount; for a standing authorisation, the ceiling it is registered at and each debit taken under it	IndiaOn your own key
PhonePe — Taking a payment online	The payer’s name, phone number and the amount	IndiaOn your own key
Stripe — Taking a payment online	The payer’s name, email address and the amount	United StatesOn your own key
Pine Labs — Taking a card payment on the counter terminal	The amount and the bill reference	IndiaOn your own key
Google Sheets — Receiving a scheduled export	Whatever view the clinic chose to export, patient rows included	Google’s global networkOn your own key
Google Business Profile and Meta — Reading reviews and publishing the clinic’s replies	The reply the clinic publishes — no record data	Google and Meta’s global networksOn your own key
The clinic’s own mail server — The mailbox MedAppz proxies rather than copies	Mail passes through; received mail is never copied into our database	Wherever the clinic’s mail is hostedYour own system
The hospital’s own GST Suvidha Provider — Registering the hospital’s own patient invoices with the Invoice Registration Portal	The invoice: its number and date, both GSTINs, the buyer’s name and address, and each line’s description, HSN/SAC code and value — so a pharmacy line names the medicine sold. No diagnosis and no record data	IndiaOn your own key
The clinic’s own Tally server — Receiving the accounting export, and answering which vouchers it took	Journal vouchers: dates, ledger names and amounts. No patient name and no record data	Wherever the clinic runs TallyYour own system
National Health Authority (ABDM gateway) — India’s national health exchange: linking care contexts and sending records a patient consented to	When the patient consents in their ABHA app: the care contexts they chose to link, and the FHIR records a granted consent covers, encrypted for the requesting provider	India (NHA)On our contract
A database the clinic brings — A destination the clinic asked the product to write to	Whatever the clinic configured the sink to send	Wherever the clinic hosts itYour own system

Tell us

Report a concern, or disclose a flaw.

Report a concernAnyone — clinician, patient, developer or a stranger — can report a safety problem or a security problem. No account needed. It goes to a mailbox a person reads, and we answer with what we found and what we changed.Email hello@medappz.com

Responsible disclosureCoordinated disclosure, ninety days. Please do not test against a live tenant — patient records sit behind these endpoints. We do not run a paid programme today, and we would rather say so than imply one.security.txt hello@medappz.com Security policy

Not yet

What we do not claim yet

A trust page that answers every question is not credible to anyone who has run a procurement. These are the answers a buyer would otherwise have to extract from us.

Not yetWe are not ISO 27001 certified and we are not SOC 2 audited. Neither has been started.
Not yetNo external penetration test has been commissioned yet.
Not yetHosting is a single region — Boston, United States · Hostinger VPS. There is no second region, no failover site and no published status page.
Not yetBackups are nightly and verified, but are not yet held off-site or encrypted at rest.
Not yetMail you send from MedAppz is kept indefinitely — subject, body and recipient list. There is no retention sweep for it yet, and no button that deletes one; ask us and we will.
Not yetCore records are stored on our own server, Boston, United States · Hostinger VPS. Optional features send data to the sub-processors in the table above — AI drafting, transcription and message delivery — and each row there says whether it is on our contract or on a key you brought.
Not yetWe do not yet hold a signed data-processing agreement with any of the third parties in the table above. Getting them is work in progress, and until it is done the consent notice a patient reads says so too.

The policies themselves — terms, privacy, DPDP notice, processing addendum, security, grievance — are in the legal centre, in the version in force.

Questions

What buyers ask first.

Does MedAppz hold ISO 27001 or SOC 2?

We are not ISO 27001 certified and we are not SOC 2 audited. Neither has been started. No external penetration test has been commissioned yet.

Where are our records stored?

Core records are stored on our own server, Boston, United States · Hostinger VPS. Optional features send data to the sub-processors in the table above — AI drafting, transcription and message delivery — and each row there says whether it is on our contract or on a key you brought.

Can we switch AI off?

Yes. One setting per organisation: off, redacted or full, and redacted is the default. Off means the AI buttons and consultation transcription refuse and say why, rather than sending a reduced version.

Can MedAppz staff open our records?

A MedAppz engineer cannot walk into your tenant. Access needs a written reason, defaults to thirty minutes with a two-hour ceiling, can be granted read-only, and appears in your own audit trail while it is happening.

Do you have signed processing agreements with your vendors?

We do not yet hold a signed data-processing agreement with any of the third parties in the table above. Getting them is work in progress, and until it is done the consent notice a patient reads says so too.

Two free self-audits, for the two questionnaires you will actually be handed

This page is what MedAppz does. These two are about what your own clinic or hospital has to do — each line saying whether the software enforces it for you, gives you the desk and the clock, or cannot help at all. Both score in the page; neither asks for anything to be useful.

The NABH readiness list The DPDP self-audit

Send this page to your IT committee, then send us their questions

A hospital's security questionnaire is longer than any page. Give us a number and we will answer it line by line — including the ones above where the honest answer is “not yet”.