Patient data is sacred to us
We've built AmritSmile with security at the core — not bolted on. Here is exactly what we do to protect your clinic and your patients' data.
Security by design
In transit: TLS 1.2/1.3 only (older protocols are refused), with HSTS enforced on every production domain — including the hop between our application and the database. At rest: the database, its backups, server disks and document storage are all encrypted with AES-256.
The application, database and document storage run on Amazon Web Services in the Mumbai region (ap-south-1), so patient data is stored and processed in India. AWS data centres carry independent certifications such as ISO 27001 and SOC 2 — those cover the AWS infrastructure we build on, not an audit of AmritSmile itself.
The database has no public address and accepts connections only from our application server. The server itself exposes nothing but HTTPS — there is no SSH or remote-login port open to the internet. Administrative access goes through AWS Systems Manager, where every session is recorded against a named account protected by multi-factor authentication.
Every user has a role: doctor, receptionist, admin, or owner. Each role sees only what it needs, and every permission check happens on our servers on every request — not just hidden in the screen — so one clinic, or one staff member, can never reach another’s data by going around the interface.
Your login session is never written to browser storage, so it can’t be lifted from a stolen laptop, a rogue browser extension, or old devtools data. The short-lived access token lives in memory for that tab only; the session that keeps you signed in is a secure, HttpOnly cookie no webpage script — including ours — can ever read.
Every create, update, delete, login and logout is logged with a timestamp and user identity, so you can always see who changed what and when.
Every part of the system gets only the permissions it needs, and nothing more. Passwords and API keys are kept in an encrypted secrets store — never in source code. Our release pipeline holds no permanent cloud keys at all: it receives short-lived credentials for each release.
Automated daily database snapshots with point-in-time recovery, kept for 7 days. On top of that, a full nightly copy is stored in a separate, encrypted, access-controlled storage location and kept for 30 days. The database is also protected against accidental deletion.
Changes reach production only from a protected release branch, through an automated build pipeline. Each release is health-checked as it goes live and rolled back automatically if it fails, and any previous version can be restored in minutes. Network-level DDoS protection is provided by AWS Shield Standard; a web application firewall and a formal third-party penetration test are on our roadmap.
Patient scans, reports and videos are stored in a private, access-controlled bucket behind a CDN — never a public or permanent link. Every file is served through a signed URL that expires quickly, and access is gated per staff member.
Deleting a file never destroys it on the spot. It is moved to a restricted, time-limited archive with a full record of who deleted what and when — so an accidental delete is recoverable, not a data-loss event.
Responsible disclosure
If you discover a security vulnerability in AmritSmile, please report it to us privately. We investigate all reports and respond within 48 hours. We do not pursue legal action against good-faith researchers.
Report a vulnerability