Security & trust
Health data, protected at the layer that matters.
Security is built into the platform, not added on. Isolation is enforced in the database, every action is auditable, and data stays in India.
One tenant can never reach another.
Tenant isolation is enforced with PostgreSQL row-level security. A hospital’s data is unreachable from any other tenant, and that isolation is tested on every module, not assumed. Tenant context comes only from the authenticated session, never from client input, so a request cannot ask for another hospital’s data.
Data stays in India.
The platform is built to run on India-resident cloud infrastructure, with the database in an India region and object storage set to an India jurisdiction per environment at deployment. Residency is a deliberate design decision for hospitals that need their patient data to stay in the country, taken ahead of any legal requirement rather than in response to one.
- Database
- Managed PostgreSQL in an India region, with tenant isolation enforced by the database itself rather than by application code.
- Documents and files
- Private object storage, never public buckets. Files are reached through short-lived signed links, and the storage jurisdiction is set per environment at deployment.
- Environments are separate
- Development, staging and production have their own databases and their own storage. Nothing is shared between them, and a credential from one cannot be used in another.
- No patient data in analytics
- The Portal ships no third-party analytics. Nothing about a patient, a hospital or a member of staff is sent to an analytics vendor, because there is no analytics vendor.
Every meaningful action is on the record.
Security-relevant events are written to an append-only, tamper-evident audit trail. Entitlement, permission-override, and audit records are never physically deleted, so you can always answer who did what, and when.
| Event | Actor | Time |
|---|---|---|
| appointment.book | reception@brightcare | 12:04:19 |
| patient.view | dr.mehta@brightcare | 12:03:56 |
| permission.grant | admin@brightcare | 11:58:02 |
| auth.login | dr.rao@brightcare | 11:41:30 |
Security practices
What the product enforces today, and what is a standard we hold ourselves to at deployment. We label which is which.
Role-based access
Enforced todayFine-grained permissions, per-user overrides, and time-bound grants. Explicit deny always wins, and every endpoint re-checks on the server.
Validated and rate-limited
Enforced todayEvery request is schema-validated at the server boundary, and credential routes are rate-limited tighter than ordinary reads.
Sign-in and session protection
Enforced todayRepeated failed sign-ins lock an account with a growing delay, one password policy applies wherever a password is set, and a session left unattended for fifteen minutes signs itself out.
Encryption everywhere
CommitmentAES-256 at rest and TLS 1.2+ in transit is the platform's encryption standard, applied at deployment.
Backups and recovery
CommitmentAutomated backups with defined recovery objectives. The restore drill runs against real infrastructure before go-live.
PII masking
CommitmentPersonal data masked in logs and outside production, on a least-privilege architecture.
PCI-aligned payments
CommitmentThe payment gateway is planned scope. When it ships, card data is never stored on the platform and handling follows PCI DSS-aligned practice.
Designed for India’s regulatory landscape.
The platform is built to align with the frameworks that matter to Indian healthcare:
- Digital Personal Data Protection Act (DPDP), 2023
- Ayushman Bharat Digital Mission (ABDM)
- GST and e-invoicing for billing
- Telemedicine Practice Guidelines, 2020
These describe how the platform is designed and aligned. They are not claims of formal certification, audit, or accreditation, and no third party has certified them. We are happy to walk your compliance team through our controls during onboarding.
Who else touches your data
Every platform runs on other people's infrastructure. Here is ours, what each one sees, and which parts are configuration verified at deployment rather than something already running.
| Provider | Purpose | What it handles |
|---|---|---|
| India-resident cloud hostingIn use today | Application hosting and PostgreSQL | All platform data, in an India region. |
| MSG91In use today | Transactional email and SMS | The recipient’s email or phone number and the message itself, such as a one-time code or an appointment reminder. Never a clinical record. |
| Object storage providerCommitment | Patient documents and uploaded files | Files a hospital attaches to a record, in private buckets reached only through short-lived signed links. The India jurisdiction is configured per environment. |
| Your own payment gatewayCommitment | Online payment, where a hospital enables it | The hospital connects its own merchant account, so money moves to the hospital’s bank. We are not in the funds flow and no card data reaches our systems. |
This is the list as it stands. The definitive, contractual list forms part of your data processing agreement, and we tell you before it changes. A sub-processor you learn about afterwards is not a sub-processor you agreed to.
What we will never do.
Written as prohibitions, because that is the form you can hold us to.
- We never sell, share or mine your patients’ data. There is no second business model behind this one.
- We never send patient, staff or hospital-identifying data to an analytics or advertising vendor.
- We never store card details. Where a hospital takes online payment, it connects its own merchant account.
- We never charge you to take your data out. Report exports to CSV are available today and broader export is planned scope. Neither will be billed as an add-on.
- We never claim a certification nobody has audited. Where we align with a standard, we say aligned, and we will walk your team through the controls.
See it running with your own workflows.
Book a walkthrough and we will map your clinic or hospital onto the platform, module by module.