Who Can See Your School's Data? Backups, Isolation and Honest Answers

When a school moves everything into a CRM — students, money, debts, notes about parents — it effectively entrusts the vendor with its most valuable asset. And almost nobody asks the vendor the uncomfortable questions. A pity: the answers separate systems more sharply than any feature list.

Here are the questions we recommend asking any CRM — with our honest answers for Mimiao.

”Who on your team can look at our database?”

The most uncomfortable question — and the most important one. The industry’s typical answer: “only authorised employees have access, per our internal policy.” Translated: technically they can see everything; they’ve just promised not to look.

We built it differently — the restriction lives in code, not in a policy. Mimiao’s operations console technically cannot return your school’s record content: no student names or contacts, no note text, none of your payment amounts. The platform operator sees the school’s name, plan, billing status and four anonymous counters (such as active students versus the plan limit) — and that’s all. The boundary is pinned by automated tests: code that tried to return more would simply fail the checks.

The only way inside a school is support mode, and it is deliberately inconvenient to abuse: it activates only after your prior approval, lasts at most 24 hours, shows everyone in the school a prominent “support is working in your school” banner, and writes every action into a log that cannot be edited.

What we honestly do not promise: “zero access” doesn’t exist anywhere — every vendor has engineers with server access. The difference is whether the everyday working path is restricted technically, or only “by policy”.

”What happens to our data if your server burns down?”

The right answer to this question is made of numbers, not reassurances. Ours:

• Every 6 hours — a database backup. In the worst case you lose a few hours of work, not weeks.
• Every backup is verified by a restore. A backup nobody has ever tried to restore is a lottery ticket. Our system restores each copy into a test environment and checks the key tables before trusting it.
• A second copy lives in separate storage, in a different region, protected against overwrites and deletion. One data-center disaster can’t destroy both.
• Once a month — an automated restore drill from the off-site copy: we don’t believe recovery works, we rehearse it.
• Before every production update, an extra fresh backup is taken — without it, the update refuses to start.

And a separate point about money: Mimiao’s financial ledger is immutable at the database level. No payment record can be edited or deleted after the fact — not by us, not by you, not by anyone on your team. Mistakes are corrected only with new compensating entries, and the full history stays visible.

”If we stop paying — will you lock up our data?”

A question worth asking before signing, not after. Our answer: no. If the subscription lapses, the school switches to read-only — the owner keeps access to all the data and can come back anytime. And the owner can get the school’s complete archive — students, lessons, invoices, payments, attendance, homework — at any moment, in plain CSV files: the archive is generated automatically, and the link stays valid for a limited time. We refuse on principle to hold data hostage: if you stay with us, it should be because of the product, not because leaving is impossible.

”Inside the school itself — who sees the money?”

Threats to data aren’t always external. Boundaries apply inside the school too: a teacher sees only their own students and never anyone else’s rates, pay or the school’s till; parents see only their own child. Every permission is checked on the server with every request, and when you revoke someone’s access it disappears with their very next request — even in tabs they already have open.

For the most sensitive actions there’s an extra layer — four-eyes mode: refunds, balance adjustments or debt write-offs can be set to execute only after the owner approves. Whoever created the request can never approve it themselves.

The takeaway

Security isn’t a page with pretty padlock icons — it’s a set of decisions you can verify. The full list of what we guarantee (and what we honestly don’t promise) lives on the data security page.