Privacy & data sharing

Eduhost is a school-management platform sold to institutions. When your school signs up, a clear line is drawn about who is responsible for the data inside it:

• Your school is the data controller. It decides which students, guardians and staff are entered, what is recorded about them, and why. The records belong to the school, not to Eduhost.
• Eduhost is the data processor. We store and process that data on the school’s instruction, to run the features the school has turned on — and for nothing else.

This matters for a school ERP: most of the people in the system are children. We never decide on our own to use, share, or repurpose their data. Anything beyond running the product for your school needs the school's instruction.

On the school's behalf, the platform holds:

• People: students, guardians and staff — names, contact details, admission and enrolment records, roles.
• Academics: classes, sections, subjects, attendance, timetables, exam marks and report cards.
• Money: fee structures, invoices, receipts and payment status. Card and bank details are handled by our payment processor — they never touch Eduhost’s servers (see “Fees & payments”).
• Operations: library, hostel, transport, payroll and HR records, where the school has enabled those modules.
• Account & technical: the credentials used to sign in, and standard security logs (who did what, and when) needed to keep the account safe.

Which of these exist for a given school depends entirely on the modules that school has switched on.

We use the data only to operate the service for your school:

• To provide the features the school has enabled — admissions, attendance, fees, results and the rest.
• To secure the account: authentication, abuse and fraud prevention, and audit logging.
• To keep the school informed about the service, and to provide support when asked.
• To meet a legal obligation where one genuinely applies.

We do not sell your data, and we do not use it for advertising. We do not build a profile of any student for our own purposes.

We share data with a short, fixed list of sub-processors — service providers that carry out a specific job so the platform can work. Each receives only what that job needs, is bound to use it only for that job, and is listed here:

Beyond that list, data leaves the platform in only two other cases:

• Because you asked it to. If the school turns on Broadcast, the notices it sends travel through the SMS, email or messaging provider needed to deliver them — at the school’s instruction.
• Because the law requires it. A valid, binding legal order — and even then, only the minimum, and we tell the school unless we are legally barred from doing so.

We never share one school's data with another, and we never share it with a data broker or advertiser. There is no “partner network” your records are fed into.

Isolation between schools isn't a setting we can get wrong — it's the architecture:

• A database per school. Each school’s data lives in its own dedicated database, not in shared tables filtered by a column. There is no query that can accidentally return another school’s records.
• Server-side authorisation on every request. Which school you’re acting in is resolved on the server and checked against your membership — a client cannot ask for another school’s data by changing a header.
• Roles that are enforced, not just displayed. A parent sees only their own child’s attendance, results and fees. The interface hides what you can’t do; the API refuses it.

Fee money does not flow through Eduhost. When a parent pays online, Razorpay Route settles the amount directly into the school's own bank account. Eduhost holds no pool account and takes no cut of a fee — so we never hold your money, and card or bank details are handled by Razorpay under its own PCI-compliant systems, never stored on our servers.

Eduhost AI runs server-side. The model's API key stays on our servers and is never exposed to the browser. Two limits are built in, not optional:

• It acts with your permissions, in your school only. The assistant calls the same authorised APIs your role already can — it cannot read a school you don’t belong to, or do anything your role can’t.
• It asks before it changes anything. Every action that would create, edit or delete a record stops at a confirmation you have to approve, and each approved action is written to the audit log.

When the assistant is used, the question and the relevant records are sent to our third-party AI provider to produce the answer. That data is not used to train the provider's models.

Most people in a school ERP are minors, so their records get particular care. Student data is entered and controlled by the school — the institution acting in its lawful role — not collected by Eduhost directly from children. We do not market to students, profile them, or use their data for any purpose beyond running the school's own system. A guardian can see and correct their child's record through the school.

We keep a school's data for as long as the school's account is active, because it is the school's working record. When an account is closed, the school can export its data, after which we delete it within a defined window — save for the minimum we are legally required to retain (for example, tax records tied to fee payments). Because each school has its own database, deleting a school's data is a discrete, complete operation.

Under India's Digital Personal Data Protection Act, 2023 — and equivalent laws such as the GDPR where they apply — individuals have rights over their personal data: to access it, to correct it, to have it erased, and to complain to a regulator.

Because your school is the data controller, these requests are made through your school, which decides and responds using the tools Eduhost provides. As the processor, Eduhost supports the school in honouring them. If you are a student, parent or staff member, contact your school's administrator; if you are the school and need our help to act on a request, contact us below.

Eduhost is built for institutions in India, and school data is processed accordingly. Where a sub-processor operates from another country, that transfer is covered by an appropriate data-processing agreement. We will tell schools before making a material change to where their data is processed.

If we change this policy in a way that materially affects how a school's data is handled, we'll let schools know before it takes effect. The date at the top shows when it was last revised.

Questions about privacy or data sharing? Write to gigacode.in@gmail.com.