Security

Security on ScholaRise is a partnership. Edulae secures the platform itself — the infrastructure it runs on, the way data is stored and transmitted, the access-control engine, and the code we ship. The school controls who, inside the school, is allowed to see and do what. Most real-world incidents in any SaaS come from weak passwords and over-broad access, which sit on the school’s side of that line, so this division matters.

What Edulae is responsible for

• Operating the hosting and network infrastructure securely and keeping it patched.
• Encrypting data in transit and at rest.
• Providing and enforcing the role-based access-control engine across every interface, including the AI assistant.
• Keeping each school’s data logically isolated from every other school’s.
• Maintaining authentication, session handling, audit logging and backups.
• Following a secure development process and keeping dependencies maintained.
• Responding to security incidents and notifying schools as required by law.

What the school is responsible for

• Choosing strong, unique credentials and enabling the account-protection options available to it.
• Granting each user the narrowest role that lets them do their job, and reviewing those grants periodically.
• Removing or suspending a user’s access promptly when they leave the school or change roles.
• Deciding which staff may share documents or generate share links, and supervising that use.
• Establishing the lawful basis for the personal data it enters — including obtaining verifiable consent of a parent or guardian for a child’s data — as the Data Fiduciary.
• Telling its own users not to share login credentials and to report anything suspicious.

ScholaRise runs on Google Cloud Platform (GCP). The application is deployed on Cloud Run, a managed container platform, and uses Google-managed Cloud SQL (PostgreSQL) for its primary database and Google Cloud Storage for files. We do not run our own physical servers; we rely on Google’s data-centre physical security, network controls and platform hardening for the layers beneath the application.

The production environment is hosted in Google Cloud’s India region (asia-south1, Mumbai), with the application, database and file storage co-located in that region. Certain Google-provided sub-services (for example, parts of the AI and email pipeline) may operate from other Google regions; see “Data residency & cross-border” below and the Privacy Policy for detail. [to confirm: any school-specific or contractually-fixed data-region commitment.]

• Compute: Google Cloud Run (managed containers), scaled and patched by Google at the platform layer.
• Database: Google-managed Cloud SQL for PostgreSQL.
• File storage: Google Cloud Storage.
• Primary region: asia-south1 (Mumbai, India).

Data is encrypted in transit and at rest.

• In transit: connections between users’ browsers or apps and ScholaRise are encrypted using TLS (HTTPS). Traffic between our application and Google’s managed database and storage services travels over Google’s secured network.
• At rest: data stored in the managed database, in file storage and in backups is encrypted at rest using the encryption provided by the underlying Google Cloud services.

We do not transmit personal data over unencrypted channels in the normal operation of the platform.

Authorisation in ScholaRise is role-based and deliberately fine-grained. The platform defines over 100 distinct, granular permissions — each tied to a specific capability such as viewing a fee ledger, editing an examination mark, or exporting student records. A user only sees and can only do what their assigned permissions allow.

The access model is built on two principles. Least privilege: roles are assembled from the smallest set of permissions needed, so access is granted, not assumed. Fail-closed: where a permission is missing or cannot be confirmed, the system denies the action rather than allowing it by default.

Multi-tenant isolation

ScholaRise is multi-tenant: many schools share the same platform while their data stays separated. Records are isolated by tenant (the school or trust) and, within a tenant, are scoped further by branch and by academic session. Queries carry this scope, so one school cannot see another school’s data, and access within a school respects branch and session boundaries.

User sign-in is handled by Firebase Authentication, Google’s managed identity service. We do not store user passwords ourselves in plain or recoverable form; credential handling sits with the managed identity provider.

• Email-and-password sign-in managed by Firebase Authentication.
• Optional Google Workspace single sign-on (SSO), where a school uses Google Workspace, so staff can sign in with their school Google account.
• Authenticated sessions issued as time-bound tokens, validated on each request and invalidated on sign-out.

Schools that use Google Workspace SSO can apply their own Workspace sign-in controls (for example, two-step verification) to ScholaRise access. [to confirm: availability of platform-enforced multi-factor authentication for non-SSO accounts.]

ScholaRise keeps an audit log of meaningful actions taken in the platform. Each entry records who performed the action, what was done, and when — and, for changes to records, the relevant before-and-after state. Audit entries are written as an append-only record: they are added, not edited or quietly removed, so the log is a reliable account of what happened.

Audit logging supports a school’s own accountability and helps both the school and Edulae investigate questions about access or changes to data. Access to audit data is itself permission-controlled.

The Vault is ScholaRise’s document store for sensitive files — for example, identity documents, certificates and official records. It is built so that access to documents is explicit and traceable rather than open by default.

• Typed access grants: access is organised by document type and granted through defined permissions and access grants, so the right people see the right categories of document and others do not.
• Share links: where the platform allows a document to be shared by link, the link is generated under permission and the sharing event is recorded; certain sensitive actions (such as managing access, managing document types, viewing the audit trail, or restoring documents) are restricted to higher-privilege roles.
• Per-document audit: actions on a document — such as creating a share — are recorded against that document, so there is a per-document history of what was done and by whom.

For schools that use Google Workspace, ScholaRise can automate the lifecycle of Google Workspace accounts so that access tracks employment and enrolment status rather than relying on manual cleanup.

• Provisioning: Google Workspace accounts can be created automatically for new staff (and, where applicable, students), placed in the appropriate organisational unit.
• De-provisioning: when a person leaves, their Google Workspace account can be suspended automatically, so access is withdrawn promptly on exit rather than lingering.

ScholaRise runs on managed Google Cloud services chosen for resilience. The database and file storage rely on Google’s managed durability, and the application runs on Cloud Run, which Google scales and keeps available at the platform layer.

We take backups of the production database so that data can be recovered after an operational failure. We describe this as a practice rather than a guaranteed service level, because the exact figures should be stated only once confirmed.

We aim to build security into how the product is developed, not bolt it on afterwards.

• Changes to the codebase go through review before they are merged and released.
• Authorisation is enforced centrally so that new features inherit the same permission model rather than re-implementing access checks ad hoc.
• We keep third-party dependencies maintained and update them, including for security fixes, as part of routine engineering work.
• Secrets and credentials for production services are managed through the cloud platform’s secret-management facilities rather than being committed into the codebase.

We describe these as our practices honestly; we do not claim a formal, externally-audited secure-development certification. [to confirm: whether automated dependency-vulnerability scanning and periodic penetration testing are part of the standard cadence.]

To run ScholaRise we use a small set of reputable infrastructure and service providers — our sub-processors — such as Google Cloud Platform for hosting, database and storage, Firebase for authentication, and providers for email, messaging and AI services. We rely on these providers’ own security programmes for the layers they operate, and we limit the data shared with each to what its function requires.

The current list of sub-processors, and the categories of data each one processes, is maintained in our Privacy Policy. Schools should refer to the sub-processor section of the Privacy Policy for the authoritative, up-to-date list.

If we become aware of a security incident affecting personal data on the platform, our objective is to contain it, assess its scope and impact, and notify the people who need to know, in line with our legal obligations.

• We work to identify and contain the incident and to stop further unauthorised access or loss.
• We assess what data and which schools are affected and preserve information needed to understand what happened.
• We notify the affected school (the Data Fiduciary) so that the school can meet its own obligations to its students, parents and staff (the Data Principals).
• We support the school’s breach notification to the Data Protection Board of India and to affected Data Principals as required under the Digital Personal Data Protection Act, 2023 and the rules thereunder, and — for any data for which Edulae is itself the Data Fiduciary — we make the required notifications directly.

Where the school is the Data Fiduciary for the student, parent and staff data it enters, the statutory obligation under the Digital Personal Data Protection Act, 2023 to notify the Data Protection Board of India and affected Data Principals of a personal data breach rests with the school as Data Fiduciary; our role, as its Data Processor, is to inform the school promptly of any breach we become aware of and to give it the information and assistance it needs to make those notifications. For the limited personal data for which Edulae is itself the Data Fiduciary (for example, website visitors and a school’s billing and administrative contacts), Edulae makes the required notifications directly. [to confirm: the target timeframe within which we will notify an affected school of a confirmed incident.]

The primary ScholaRise environment — application, database and file storage — is hosted in Google Cloud’s India region (asia-south1, Mumbai). Some Google-provided sub-services we rely on (for example, parts of the AI and email pipeline) may process limited data in other Google regions.

Any processing outside India is carried out consistent with our Privacy Policy and applicable law, including the Digital Personal Data Protection Act, 2023 and the rules thereunder. The Privacy Policy is the authoritative statement of where data is processed and of any cross-border transfers; if anything here and the Privacy Policy differ on residency, the Privacy Policy governs.

We use phrasing such as “designed to” and “aligned with” deliberately. It reflects measures that are genuinely built into the platform, without implying an external certification we have not obtained. If our certification status changes, we will update this page rather than imply more than is true.

If you are a security researcher and you believe you have found a vulnerability in ScholaRise, we want to hear from you. Please report it to security@edulae.com with enough detail for us to reproduce and assess the issue.

• Report privately to security@edulae.com; please do not disclose the issue publicly before we have had a reasonable opportunity to investigate and remediate.
• Act in good faith: do not access, modify or delete data that is not yours, do not degrade the service, and do not use the issue beyond what is needed to demonstrate it.
• Do not run tests that could compromise the privacy of students, parents or staff, or that could disrupt schools’ use of the platform.

We will not pursue legal action against researchers who report in good faith and follow this guidance, and we will work with you on remediation. [to confirm: our target response window for acknowledging a report.]

Security is only as strong as both sides of the partnership. To recap the school’s part — as the Data Fiduciary and the controller of its own users:

• Use strong, unique credentials and enable the account-protection options available to you, including Google Workspace controls where you use SSO.
• Assign roles on a least-privilege, need-to-know basis, and review who has access — especially high-privilege access — on a regular schedule.
• Remove or suspend access promptly when staff leave or change roles, even where automated de-provisioning is in place.
• Govern document sharing and share-link use, and limit who may grant access in the Vault.
• Establish the lawful basis for the data you enter, including obtaining verifiable parental or guardian consent for children’s data, and use the platform only for the purposes you are permitted to.
• Tell your users not to share logins, and report suspected security issues to us promptly via security@edulae.com.

This Security page is issued by Edulae Technologies Private Limited, a company incorporated under the Companies Act, 2013 and the operator of ScholaRise. Edulae has designated a Grievance Officer to handle complaints, including those relating to the handling of personal data, as required under the Information Technology Act, 2000 and the rules thereunder and the Digital Personal Data Protection Act, 2023.

Legal entity

Edulae Technologies Private Limited

CIN

[to confirm: CIN]

Registered office

Paonta Sahib, Sirmaur District, Himachal Pradesh, India — [to confirm: full registered address]

Security matters

security@edulae.com

Privacy / data protection

privacy@edulae.com

Grievance Officer

grievance@edulae.com ([to confirm: name of the Grievance Officer])

For the full company particulars, our designated Grievance Officer and the complete data-protection contact details, see the Contact sections of our Privacy Policy and Terms. If you remain unsatisfied after using our grievance-redressal mechanism, you may approach the Data Protection Board of India as provided under the Digital Personal Data Protection Act, 2023.