Security & Trust Center
What we actually do to protect this data
Elevate ERP holds the records of children. Below is a specific account of the controls that are in force today, each one checkable against the product — followed by an equally specific list of the ones that are not in place yet.
- Google Cloud infrastructure
- Deny-by-default database rules
- No certifications of our own
In force today
Each row below is a control that exists in the product as shipped. Where a control belongs to Google Cloud or Vercel rather than to us, it says so — and where it is real but partial, it says what it does not cover.
- Sign-in is handled by Firebase
- Elevate does not store, hash or ever see an account password. Sign-in runs through Firebase Authentication — Google’s identity service — with email-and-password and Google sign-in as the two methods, so credential storage, password verification and reset are Google’s to do rather than ours. What Elevate holds is the account record the sign-in resolves to.
- Transport security
- Every request is served over HTTPS. TLS is terminated by Vercel for the application and by Google’s APIs for the database, and both support TLS 1.3 — the version actually used is whatever your browser and theirs negotiate, so it is their guarantee to give, not ours. Elevate itself sets no transport headers: no HSTS, no content security policy, no framing policy.
- Encryption at rest
- Firestore and Cloud Storage encrypt stored data with Google-managed AES-256. This is Google Cloud’s platform default rather than something Elevate implements, and the keys are Google’s. It protects against someone obtaining the physical media; it does not protect against a mistake in our own access rules.
- Sealed provider credentials
- The one thing encrypted by Elevate’s own code. When a school supplies its own AI provider API key, that key is sealed with AES-256-GCM — authenticated, so a tampered value fails to decrypt instead of being sent onward as a bearer token — and stored in a subcollection no client connection can read. Nothing else in the product is encrypted at the application layer.
- Database rules deny by default
- The Firestore rule set ends with a catch-all that refuses every read and write, so any path not explicitly granted is denied rather than allowed. Access is scoped by a school identifier carried on the signed-in token, with per-module permission checks layered on top of that.
- Role-based access control
- Permissions are checked in the application and again in the database rules, and every tool the AI agent can call declares the permission it requires — the field is not optional, so a tool cannot be registered without one. The agent’s authorisation path fails closed: an account whose role cannot be resolved is denied rather than defaulted to an administrator, and a checked-in regression test exercises that behaviour so it cannot silently revert. Scoped honestly: roles are read from stored user records rather than from token claims, several roles present in the data model have no permission mapping yet, and plan-level feature gating still lets a tenant through when its plan lookup fails.
- Append-only audit logging
- Mutations record the actor, their role, the action, the target document and the before and after values. Database rules refuse updates and deletes on those entries, so they are append-only to anything using a client connection. They are not tamper-proof against us: server code runs with an administrative connection that bypasses rules by design. Log writes are also best-effort — a failed write is reported to the server console and does not fail the operation that caused it — so treat the log as a strong record, not a complete one.
- Audit-log retention
- There is none in force. A pruning job exists in the codebase but is not registered on any schedule, so audit entries accumulate indefinitely. Until a window is running and published here, assume audit history is kept.
- Signed payment webhooks
- Razorpay webhooks are rejected unless the request carries a valid HMAC-SHA256 signature computed over the raw request body with the shared webhook secret. A request arriving with no signature header is refused rather than processed.
- Public form abuse controls
- Forms on this website are rate-limited per client address and carry a hidden field that automated submitters fill in and people never see. These are anti-spam measures rather than access control, and the rate limiter deliberately allows a request through if its own datastore read fails — availability was chosen over strictness for a contact form.
- Where the data goes
- The primary datastore is Firestore on Google Cloud, in the asia-south1 (Mumbai) region. One thing sits elsewhere and it is worth naming rather than averaging away: the Realtime Database instance, which carries presence and live transport tracking, is in asia-southeast1 (Singapore). The regions of Firebase Authentication and Firebase Storage are not established by anything we can point at, so they are not stated. Outside Google: application traffic is served from Vercel’s edge network; media is stored with Cloudinary, in the United States; AI prompts go to Groq, to the Google Gemini API and to a third-party model gateway the assistant tries when those are rate limited; fee and subscription payments go to Razorpay; the optional identity check a member of staff can start sends the Aadhaar number being verified to a verification API; and transactional email is relayed through Google’s Gmail SMTP today, with Resend configured for the newer pipeline and holding data in the United States. Where we hold no residency undertaking from a provider, its entry says so rather than naming a region we cannot substantiate. Each one, its purpose and what it receives are listed on the subprocessors page.
- Certifications belong to Google
- Google Cloud holds SOC 1/2/3, ISO 27001 and ISO 27017 for the infrastructure this product runs on. Those are Google’s certifications and they cover Google’s platform. Elevate ERP holds no certification, attestation or audit report of its own, and nothing on this page should be read as implying otherwise.
- What the AI assistant sends out
- When a member of staff uses the AI assistant, the prompt sent to the configured AI provider includes real records from the school — among them student names with their class and section — so the model can resolve who is being referred to. That content is not anonymised or redacted, and there is no consent step beyond the school choosing to switch the assistant on and use it. A school that would rather no student data left the platform should leave it off.
- Incident response
- Reports go to [email protected] and are handled by the operator directly — there is no round-the-clock rota. Breach notification within 72 hours as required by the DPDP Act, with a written post-incident summary.
Not in place today
Controls a school might reasonably expect, which this product does not have. They are listed here at the same size and in the same shape as the ones above, because finding out from a sales call is worse than finding out from a security page.
- Multi-factor authentication
- Not implemented. Accounts are created with the two-factor flag set to false and nothing in the product ever sets it true: there is no enrolment step, no authenticator secret and no second prompt in the sign-in path. A 2FA enforcement policy is written in our codebase, but the panel holding it is not mounted on any screen, so there is nothing for an administrator to switch on — and no authentication path would read the setting if there were. No Elevate account should be treated as protected by a second factor.
- Single sign-on
- Not implemented. There is no SAML or OIDC integration, and no way to restrict sign-in to your own workspace domain — any Google account can complete the popup and is stopped only by a role check afterwards. Sign-in is email-and-password or Google sign-in through Firebase Authentication. Single sign-on is no longer listed on our public pricing page, but it is still named as a Max-plan feature on the in-app subscription screen, which is ahead of what is built.
- Server-side route protection
- Authorisation is enforced at the data layer, not by a page gate. No session is verified before a page is served — the page shell loads, and the database rules then withhold its contents from a signed-out or wrongly-scoped request. Data itself travels over API calls that do verify your session on the server before returning anything. It is a deliberate architecture, but it means the protection rests on those rules being correct rather than on the page ever being withheld.
- Independent security audit
- None commissioned. No third-party penetration test, SOC 2 examination or ISO 27001 audit has been carried out on Elevate ERP.
- Automated vulnerability scanning
- Not running. Our build pipeline lints the code, runs the test step and builds the application; it does not audit dependencies for known vulnerabilities, does not run a code-scanning analyser and has no dependency-update bot raising patches. Upgrades happen when we notice them, which is not a control. The route for anything you find is the disclosure policy below.
- WCAG 2.1 AA conformance
- Not audited, and not claimed. Contrast on this website is measured against the 4.5:1 threshold and the interface is built to be keyboard-operable, but no full WCAG 2.1 AA audit of the signed-in application has been carried out, and known gaps remain in charts, PDF export and third-party embeds. Our accessibility statement lists them.
- Published uptime commitment
- None, on any plan including Enterprise. We do not yet run the independent availability monitoring a percentage would have to be measured against, so no figure is offered and no service-credit scheme is in force. The service level agreement sets out why.
This is a list of what we know to be missing, not a warranty that nothing else is. Nobody outside the 2 people who wrote this software has examined it, so treat both ledgers on this page as a self-assessment you are entitled to test. If you find something that belongs on this list, the disclosure route below is how to tell us.
Found a Security Vulnerability?
We welcome responsible disclosure from security researchers. If you've discovered a vulnerability, please report it to us.
Related Policies
Privacy Policy
What is collected, why, and the commitment not to sell it.
Data Processing Agreement
Your institution is the Data Fiduciary; we process on your instructions.
Subprocessors
Every third party in the path, its purpose and what it receives — with a location where one is established.
Service Level Agreement
Why no uptime percentage is offered, on any plan.
Accessibility Statement
What is conformant, and the three gaps that are not.
Acceptable Use
What the platform may not be used for.
Set your institution up on Elevate
Start on the free plan for up to 250 students. Paid plans begin at ₹1499 per month, billed to the institution.