Skip to content
Security and data

How RAKT protects patient data.

RAKT HMS handles patient health information. This page says what we actually do to protect it — the controls in the product, where data lives, how it is backed up, and how to reach us if you find a problem. It also says what we do not claim.

Encrypted in transit and at rest

All traffic is HTTPS only, with HSTS enforced for a year and preloaded. Government identity numbers on patient records are encrypted at rest in the database.

Permission checked on every request

Access is a code per department, module and action, decided by the server. A receptionist cannot sign a lab report whatever the screen shows.

Append-only audit trail

Every change records the actor, their role at that moment and a structured before-and-after. Edits to records go through change requests, never in place.

One tenant per organisation

Every record belongs to one organisation and one branch. Cross-branch links are explicit, never implied; organisations never share a tenant.
Who reads this page

What to look at, depending on your seat

Six people usually read a security page for six different reasons. Each card points to the sections that answer theirs.

IT committee or CIO

Medical superintendent or quality lead

  • Who changed a record and in which role: Audit and change control
  • Evidence an assessor asks for is kept as you work, not assembled later
  • Consent, checklists and forms as structured records

Owner or promoter

Compliance or data protection lead

  • Your role as Data Fiduciary, ours as processor: Your data, your rights
  • Sub-processors and their locations are listed in Annex 3 of the DPA
  • Consent recorded per purpose; erasure with a cooling-off window

Staff who use it every day

  • No shared logins: a permission code per person, per department: Access control
  • Twelve-character passwords, lockout after five failed attempts: Authentication
  • Corrections go through a change request, so nobody is blamed for a silent edit

Patients

  • Government ID numbers are encrypted at rest: Encryption
  • Reports go to WhatsApp only with consent recorded, and consent can be withdrawn
  • The patient portal signs in with a one-time code; there is no password to leak
Security review

The questions we get in a security questionnaire, answered in one line each

If you are filling in a vendor assessment, this is the short version. Each answer links to the section with the detail.

Where is our data hosted?
On infrastructure in the Bengaluru region of India, one tenant per organisation. Detail
Is data encrypted?
TLS in transit with a one-year preloaded HSTS policy; government ID fields encrypted at rest; backups in encrypted object storage. Detail
How is access controlled?
A permission code per department, module and action, checked by the server on every request. API keys are organisation-scoped, user-bound and read-only by default. Detail
Is there an audit trail?
Append-only, with the actor, their role at that moment and a before-and-after on every change. Edits go through change requests. Detail
How are backups taken and tested?
Nightly database backups to encrypted object storage, retained on a defined lifecycle; restores are periodically tested. Detail
Can we export and delete our data?
A full export at any time; deletion after the export window at the end of a contract; patient erasure with a cooling-off window you set. Detail
How are breaches handled?
Notification without undue delay and within 24 hours of confirmation, with the particulars you need for CERT-In and the Data Protection Board. Section 7 of the DPA.
Who are your sub-processors?
Listed with locations in Annex 3 of the DPA. Patient records stay in India.
Which certifications do you hold?
ISO 9001:2015 for quality management. No SOC 2, ISO 27001 or HIPAA attestation, and we will not imply one. Detail
How do we report a vulnerability?
security@rakt.in. Acknowledged within three business days, triaged within ten. Detail

Access control

Permissions are codes of the form department.module.action, checked by the server on every request. Each department ships its own permission catalogue and named default roles; organisation masters and branch heads short-circuit, and everyone else holds explicit grants per department instance. Screens follow what the server decides — hiding a button is never the control.

API keys are scoped to one organisation and bound to a named user, so every call is attributed to a person. Keys are read-only unless you switch them to writable. AI assistants connected through the MCP server act under the same user-bound, read-only-by-default keys, so what they can see is exactly what that person can see, and every read is logged.

Authentication

  • Passwords require at least twelve characters and are validated against common-password lists.
  • Five failed sign-ins lock the account for a cooling-off period, scoped to the address and username pair, so one bad actor cannot lock out a whole hospital.
  • Sessions use secure, HTTPS-only cookies; the platform redirects all plain HTTP to HTTPS and sends HSTS with a one-year, preloaded policy.
  • Patients sign in to the patient portal with a one-time code rather than a password.

Audit and change control

The activity log is append-only. Every change to a patient, order, admission, invoice or setting records who made it, the role they held at that moment, and a structured diff of what changed. Edits to existing records — a patient’s name, an order item, an invoice line — go through a change request with the before and after captured, so a correction is a decision someone made and can be found later.

Data isolation

RAKT HMS is multi-tenant by organisation: every row belongs to one organisation, and within it to one branch. Staff are granted roles per department per branch. Cross-branch links, where a hospital group wants them, are explicit and visible; nothing is shared by default.

Encryption

Traffic is encrypted in transit with TLS. Government identity numbers stored on patient records are encrypted at rest with application-level field encryption, so they are not readable from a database dump alone. Backups are stored in encrypted object storage.

Hosting and backups

The platform runs on infrastructure in the Bengaluru region of India, operated by RAKT, with one tenant per organisation. The database is backed up nightly to encrypted object storage. If your policy requires another region or an on-premise installation, raise it before you sign so we can answer honestly.

Integrations

  • Outbound webhooks are signed with a shared secret (HMAC), retried on failure and logged, so a receiver can verify that a delivery came from RAKT.
  • The API applies per-key rate limits and per-origin CORS rules.
  • Patient messages on WhatsApp are sent only with recorded consent, per patient, using approved templates; consent can be withdrawn and the withdrawal is logged.

Your data, your rights

Your organisation owns its data. A full export is available at any time over the API or on request. Under India’s Digital Personal Data Protection Act, the hospital is the Data Fiduciary and RAKT is the processor acting on its instructions; a Data Processing Addendum is available on request. Patient erasure requests are processed after a cooling-off window the hospital sets, on a schedule, and every consent action is on the activity log.

Reporting a vulnerability

If you believe you have found a security issue, email security@rakt.in with a description, reproduction steps and the impact. Please do not post it publicly first. You can expect an acknowledgement within three business days, a triage assessment within ten, and a fix deployed before any public disclosure — typically within thirty days for high or critical issues. We credit reporters in release notes unless asked not to. We do not currently run a paid bug-bounty programme.

What we do not claim

RAKT holds an ISO 9001:2015 certificate for its quality management system. That is a quality certification, not a security one. We do not currently hold SOC 2, ISO 27001 or HIPAA attestations, and we will not imply otherwise on a tender. If your procurement needs a control-by-control walkthrough or a questionnaire completed, ask — we would rather show you the controls than a badge.

Have a security questionnaire?

Send it over. We answer them ourselves, control by control.