Security
- Your database and files are stored in India (Mumbai).
- Every customer's data is walled off, and apps with patient data get a database of their own.
- Nothing goes live without two approvals: yours and a Bananabytes reviewer's.
- We build and test with made-up data only, never real patient or staff records.
- You own your code from day one.
We only list what is in place today. We hold no security certification or independent audit of our own yet; the gaps are listed at the end of this page.
Where your data lives
Your app's database and stored files sit in Supabase's Mumbai region. The web pages are served from global hosting networks, which carry pages and traffic but do not hold your records.
| Service | What it does | Where data sits | Provider's certifications |
|---|---|---|---|
| Supabase | Database, files, sign-in | Mumbai, India | SOC 2, ISO 27001 |
| Cloudflare Pages | Serves websites and apps | Global network | ISO 27001, 27018, 27701 |
| Vercel | Serves the customer portal | Global network | SOC 2, ISO 27001, PCI DSS |
| Resend | Sends sign-in codes and emails | United States | SOC 2 |
All traffic is encrypted over HTTPS. The certifications belong to each provider, not to Bananabytes. Supabase's system logs are kept in the EU today; an India log archive is on our roadmap.
How your data is kept separate
| Setup | Who gets it | How it is walled off |
|---|---|---|
| Shared database, private space | Small tools with no patient data, such as staff directories and rosters | Each customer has its own private schema and database role. Rules inside the database (row-level security) decide who can read or change each record. |
| Dedicated database | Any app with patient data, larger customers, or anyone who asks | A separate database in Mumbai used by that customer alone. |
Access is enforced in the database itself, not only in the app's screens, so the public address an app uses in the browser cannot read or change anything the rules don't allow. In the apps built so far, every change an administrator makes is written to a change log with who made it and when.
Keys, accounts and who owns the code
- We run the tool accounts. Hosting, database and email accounts are created and paid for by Bananabytes, so your team never manages cloud logins. You can bring your own accounts if you prefer.
- Keys are sealed. When a key has to be supplied, it is encrypted in your own browser before it is sent and can only be unlocked inside the locked-down system that uses it. Keys are never shown again, never kept in test copies, and never written into chat or code.
- Administrators of the apps we build sign in with one-time email codes, so there are no passwords to leak or reuse.
- You own the code from day one. We host it by default and move the code, database and hosting into your own accounts whenever you ask.
How changes reach your live app
- You approve a written plan before any building starts.
- The crew builds and tests on a separate test copy filled with made-up data.
- You try the test copy and ask for changes or accept it.
- You press "go live".
- A Bananabytes reviewer gives the final approval. Only then does your live app change.
Every plan step is recorded with who did it and when. Steps can't be ticked out of order, and payment and both go-live approvals can only be given by a person.
Testing uses made-up data only
Real patient or staff data is never used to build or test. Test copies hold made-up records, and your real data goes in only after both go-live approvals. The crew is also told to keep personal data out of error reports, emails and the progress log you see.
Indian law
This is our reading of each rule and where we stand today. It is not legal advice.
| Rule | What it asks | Where we stand |
|---|---|---|
| DPDP Act 2023 and Rules 2025 | A data processing agreement with each tool that handles personal data | Every provider we use offers one; formally accepting all of them is in progress |
| CERT-In Directions 2022 | 180 days of logs kept in India, incidents reported within 6 hours, clocks synced to Indian time | A written incident plan and the India log archive are on our roadmap |
| Health data (ABDM) | No rule found that forces health data to stay in India | Patient records stay in India anyway, as our own policy |
| SEBI and government work | Government-approved (MeitY-empanelled) cloud | Not offered yet; none of our current providers is empanelled |
Our onboarding checks each customer's sector against these rules and refuses a setup that would break one.
What we don't claim yet
Bananabytes has no security certification (such as ISO 27001 or SOC 2) and hasn't had an independent security audit yet. These are the gaps we are closing:
| Item | Why it matters | Status |
|---|---|---|
| Independent audit by a CERT-In empanelled auditor | Outside proof that the controls work | Planned |
| Accept every provider's data processing agreement | Required under the DPDP Act | In progress |
| 180-day log archive stored in India | Required by CERT-In | Planned |
| Written incident plan with 6-hour CERT-In reporting | Clear steps if something goes wrong | Planned |
| Automatic cross-customer leak tests before each onboarding | Proves one customer can't read another's data | Being built |
| India-based email and error tracking options | Keeps every piece of data in India for those who want it | Planned |
| Published contact for reporting security weaknesses | Lets researchers report issues safely | Planned |
| Lawyer-reviewed customer terms and data processing agreement | Clear legal commitments for hospitals | Planned |
Questions and security reviews
Hospitals are welcome to send their own security questionnaire. Write to [email protected] and we'll answer it item by item, saying plainly where something isn't in place yet. Ask us for this page as a PDF if you need it for your files.