You are being asked to put children’s records into somebody else’s software. Here is exactly what stops one institution seeing another’s, what stops the wrong person inside your own seeing too much, and what happens to all of it if you leave.
The database refuses, not the code
Every row carries the institution it belongs to, and PostgreSQL row-level security enforces it underneath the application. A query that forgets to filter returns nothing at all — not somebody else's children. The app connects as a role that cannot bypass those policies even if it wanted to.
Inside a school, reach is decided once
Who may see which class, mark which register, approve which request — that is one grant matrix per role, authored in one place and consulted by every module. A teacher narrowed to their own room sees their own room on every screen, because no screen keeps a second opinion.
Every write leaves a trail
Who marked it, who changed it, who approved it, and when. Audit is not a feature you buy on a higher plan; it is how the writes are built. A mark that changes after a report card is issued is a visible event, not a quiet edit.
Your records are exportable, always
Scheduled backups, and a full export of members, classes, attendance, marks, fees and documents whenever you ask — including after you tell us you are leaving. Nothing here is held hostage to a renewal.
The practices
The unglamorous half, listed.
None of this is interesting until the day it matters, which is the argument for doing it before then.
Sign-in
Passwordless one-time codes, QR sign-in and device trust
Multi-factor available, and enforceable per role
Refresh-token rotation — a stolen token is usable once
Lockout and rate limits on every authentication door
In transit and at rest
HTTPS everywhere, with modern TLS and HSTS
Secrets encrypted at rest; no credential in a config file
Card numbers never touch our servers — the gateway holds them
Uploads scanned for type and size before they are stored
Who on our side can see anything
Support access is explicit, time-bound and recorded
No standing production database access for day-to-day work
A tenant's content is never used to train anything
No advertising or third-party tracking inside a school's app
Keeping it honest
Isolation is proven by tests that try to cross tenants and fail
Every authorisation door is checked by a build-time gate
Dependencies scanned and patched on a schedule
Backups restored and verified, not merely taken
Questions
The ones committees actually ask.
Where is our data stored?
On servers in India, in a database dedicated to this platform. If your institution needs its own separate database rather than a shared one with row-level isolation, we can do that — it is a supported arrangement, not a special case.
Are you SOC 2 or ISO 27001 certified?
Not today, and we would rather tell you than imply otherwise. We are a small team; the controls on this page are real and testable, and we will walk your committee through any of them in detail. If a certification is a requirement for you, tell us and we will be honest about the timeline.
Can your staff read our messages?
Support access is not standing — it is requested, time-bound, and leaves a record the institution can ask for. Nobody on our side browses tenant data as part of normal work, and chat content is never used for training or analytics.
What happens if we stop using Vatika?
You take a full export of everything, and we delete our copy on your word, subject only to backup-rotation windows we will tell you the length of. That is written into the Terms, not left to good intentions.
How do we report a vulnerability?
Write to us at the address below with what you found and how to reproduce it. We will acknowledge within two business days and keep you posted. We do not run a paid bounty programme, and we will not threaten anybody who reports something in good faith.
Send us your security questionnaire.
We answer them properly, in writing, and we will tell you where the answer is “not yet”. Reach us at vatika.addvertiz@gmail.com.
Vatika