A parent sits down across from a principal in Pokhara and asks a simple question: "You have my daughter's photo, her health information, her exam scores, her address, and my phone number, all in one system. Where exactly is that stored, and who can see it?"
The principal has a good answer for almost everything else about the school. Fee structure, exam schedule, transport routes, teacher qualifications. This question, she doesn't have a confident answer to. She knows the school uses "the software" for admissions, attendance, and report cards. She has never asked the vendor where the servers are, who has access to the database, or what happens to the data if the school switches providers next year.
She's not alone. Most school administrators in Nepal have never had to think about data protection as a distinct responsibility, because until recently, there wasn't much data to protect in any concentrated form. That's changing fast, and the question deserves a real answer.
Why Student Data Protection Matters More Now Than It Did Five Years Ago
Ten years ago, a school's student records lived in filing cabinets, exercise books, and the memory of a handful of long-serving teachers. If someone wanted to see a student's health condition or family income bracket, they had to be physically present at the school and know exactly where to look. The risk was real but scattered - a lost register was bad, but it was one register, one class, one year.
That's not how school data works anymore. A modern school management system holds admission forms, health records, disciplinary notes, exam results, fee payment history, parent phone numbers, and sometimes biometric attendance data - for every student, every year, in one searchable database. That's not a criticism of digitization; centralizing this data is exactly what makes schools more efficient, and it's why school management software has spread so quickly across Nepal in the last few years.
But concentration changes the risk profile. A single compromised login, a single misconfigured permission, or a single vendor with weak security practices can now expose years of records for an entire school population at once, instead of one classroom's worth of paper. The upside of digitization (searchability, speed, one system instead of twenty) is also what makes a security failure so much more consequential than a lost exercise book ever was.
Consider what's actually sitting in a typical school's system today. A student's photo, tied to their name and class. A health note about a chronic condition, entered by a teacher years ago and never revisited. A parent's phone number and home address. If the school has moved to biometric or fingerprint-based attendance, a physical identifier that can't be changed the way a password can. None of this is unusual or excessive - it's the normal operating data of a functioning school. It just didn't used to live in one place, accessible with one login.
This is also happening at a moment when most Nepali schools are choosing software vendors for the first time, often quickly, often based on price and a demo rather than a security review. That's a reasonable way to evaluate a fee-collection feature. It's not a reasonable way to evaluate who gets to see 400 children's health records for the next five years.
If your school has never asked its software vendor "where is our data physically stored, and who at your company can access it," you don't currently know the answer - and that's worth fixing before it becomes a question a parent, a lawyer, or a journalist asks you first.
What Good Data Security Actually Looks Like in Practice
"We take data security seriously" is a sentence every vendor's website says. It tells you nothing. What actually matters is a specific, checkable set of practices - and it's worth walking through what those practices look like concretely, rather than taking the marketing language at face value.
Encryption in transit. Every time data moves between a browser or app and the vendor's servers, it should be encrypted using TLS (the padlock icon in a browser address bar, technically an HTTPS connection). Without this, anyone on the same network - a shared WiFi router, a compromised network device - can intercept login credentials or student data as it travels. This is table stakes; a vendor that doesn't have this by default in 2026 shouldn't be considered.
Encryption at rest. Data sitting in the vendor's database should also be encrypted, not just data in transit. Gurukul, for instance, documents in its privacy policy that it uses AES-256 encryption for data at rest and SSL/TLS encryption for data in transit - the standard combination that means data is protected both while it's moving and while it's sitting on a server. If a vendor can't answer "is our data encrypted at rest," that's a real gap, not a technicality.
Role-based access control. Not everyone at a school needs to see everything. A math teacher shouldn't be able to see another student's health notes. An accountant shouldn't need access to disciplinary records. A parent should see their own child's data and nothing else. A properly built system enforces this at the permission level, so what a person can see is determined by their role, not by trusting them not to look at things they technically have access to.
Tenant isolation. This is the one non-technical administrators rarely think to ask about, and it's one of the most important. In a multi-school platform - which is how most school management software works, with hundreds of schools sharing the same underlying system - tenant isolation means one school's data is walled off from every other school's data at the architecture level. A parent at School A should have zero technical path to seeing anything from School B, even a bug shouldn't be able to cross that boundary. Ask the vendor directly: "if there's a bug in your system, is it possible for one school to see another school's records?" A vendor that's thought about this will have a clear, confident answer.
Data retention and deletion. What happens to a student's data after they graduate, or after a school stops using the platform? A responsible vendor has a stated retention period and a deletion process, not an indefinite "we keep everything forever, just in case." Gurukul's policy states that when a school's subscription ends, its data is retained for 90 days to allow for export, after which it's securely deleted unless a longer period is legally required.
Who owns the data. This should be explicit, not implied. A school's data belongs to the school, not the vendor. In legal terms, this is often described as the vendor acting as a "data processor" (handling data on the school's instructions) while the school remains the "data controller" (the party that actually decides how the data is used). If a vendor's contract or policy doesn't make this distinction, ask them directly who owns the data and what happens to it if you leave.
Breach notification. No system is perfectly secure, and any vendor who claims otherwise is not being honest with you. What matters is what happens when something goes wrong: does the vendor have a stated commitment to notify affected schools, and how quickly? A policy that says nothing about breach notification is a policy that hasn't thought through what happens on a bad day.
Whether the vendor sells data to third parties. This should be a flat no, stated explicitly, not buried in ambiguous language about "sharing with partners for service improvement." Student data, especially data about minors, should never be used for advertising, profiling, or resale - regardless of what a vendor's broader business model looks like.
Authentication basics. This one is easy to overlook because it feels mundane, but weak authentication is how most real-world breaches actually happen - not sophisticated hacking, but a reused password or a shared login. Passwords should be stored as salted hashes, never in plain text, so that even the vendor's own engineers can't see a user's actual password. Ask whether the vendor supports this as a baseline, not an add-on.
None of these practices are exotic or expensive to implement correctly. They're closer to a baseline than an advanced feature. The problem isn't that good data protection is hard to build - it's that most schools have never asked their vendor whether it's actually in place, and most vendors, if never asked, will never volunteer the details.
What Nepal's Law Actually Says About Personal Data
Here's the honest answer, and it's more nuanced than "Nepal has no privacy law" or "Nepal has GDPR-equivalent protection." Neither is accurate.
Nepal does have a general privacy law: the Privacy Act, 2075 (2018), which came into force in September 2018. It's a real, enforceable law, not a draft or a proposal. It requires that personal information be collected with the consent of the data subject, that organizations disclose the purpose for which data is being collected, and that individuals have rights to access, correction, and in some cases deletion of their personal data. It creates criminal penalties for violations, including imprisonment of up to three years and fines, alongside a right to compensation for affected individuals.
It's worth being precise about what this law is and isn't. The Privacy Act is Nepal's general personal-data and privacy law - it applies across every sector, not specifically to schools or student records. It's the closest thing Nepal has to an overarching data protection statute, and it does extend to categories relevant to schools, including a requirement that consent for using a minor's information be obtained from a guardian.
What Nepal does not currently have is an education-specific student-data law - nothing that functions the way the Family Educational Rights and Privacy Act (FERPA) does in the United States, where a dedicated federal law defines exactly what counts as an "education record," who has the right to access it, and what obligations schools and their vendors have specifically because the data belongs to students. Nepal also doesn't have anything resembling the European Union's GDPR, which layers on requirements like data minimization (only collect what you actually need), storage limitation (don't keep data longer than necessary), and a dedicated regulatory authority with the power to investigate and fine organizations that violate the rules.
That gap matters in a specific way. It doesn't mean student data in Nepal has no legal protection - the Privacy Act does apply, and its consent, access, and correction provisions are real rights a parent or school can point to. What it means is that there's no institution-specific rulebook telling a school exactly what it must do with student records, no dedicated data protection authority actively enforcing compliance the way regulators do under GDPR, and comparatively lighter penalties than jurisdictions where a data breach can trigger fines in the millions of dollars.
This is genuinely useful for a school administrator to understand plainly: you are not legally required to meet FERPA or GDPR standards, because those laws don't apply in Nepal. But the absence of a legal requirement is not the same as the absence of risk. A data breach still damages parent trust, still exposes children's sensitive information, and still reflects badly on the school regardless of what the law technically requires. The right posture isn't "the law doesn't make us do this, so we won't" - it's using frameworks like GDPR's core principles (minimize what you collect, encrypt what you store, limit who can access it) as a practical benchmark for good practice, even where Nepali law doesn't mandate it yet.
There's a second, practical reason this matters beyond legal compliance. Nepal doesn't currently have a dedicated data protection authority actively auditing schools or software vendors, which means enforcement, where it happens at all, tends to follow a complaint after harm has already occurred - not proactive inspection that catches a problem early. In a regulatory environment like that, the responsibility for getting this right shifts almost entirely onto the school and the vendor it chooses, because there's no external body checking the work for you. That's not a reason to relax. It's the opposite - it's exactly why the questions in the next section matter more in Nepal than they might in a country with an active regulator doing some of that checking on your behalf.
When you're evaluating a vendor, don't ask "is this legal in Nepal?" - almost anything is legal in Nepal's current, thin regulatory environment for education data. Ask "is this what a responsible vendor would do regardless of what the law requires?" That's a much higher and more useful bar.
The Questions Every School Should Ask a Software Vendor
Most schools evaluate software vendors on features, price, and how the demo looks. Data protection rarely comes up unless something has already gone wrong. Here's a genuine checklist worth working through before signing a contract, or worth applying to whatever system your school already uses:
-
Is data encrypted in transit and at rest? Ask specifically - "in transit" (TLS/SSL) and "at rest" (encryption of the stored database) are two different things, and a vendor should be able to answer both without hesitation.
-
How is access controlled by role? Can a vendor explain, concretely, what a teacher can see versus what an accountant can see versus what a parent can see? Vague answers ("everyone who needs access has access") are a red flag.
-
Is our school's data isolated from other schools on the platform? If the vendor serves multiple schools from shared infrastructure, ask how tenant isolation is enforced, and whether it's technically possible for a bug to expose one school's data to another.
-
What happens to our data if we cancel or switch vendors? Get a specific retention and deletion timeframe, in writing, not "we'll take care of it."
-
Who owns the data - the school or the vendor? This should be unambiguous, ideally stated in the contract or the vendor's public privacy policy, not something you have to infer.
-
Does the vendor sell or share data with third parties? The answer should be a clear no for advertising or resale purposes, with any legitimate service providers (payment processors, hosting, SMS delivery) named explicitly, not left vague.
-
What's the vendor's breach notification commitment? Ask what happens, and how fast the school is told, if something goes wrong.
-
Where is the data physically stored? Not because the answer needs to be "in Nepal" (most vendors, Gurukul included, use established cloud infrastructure that may be located outside the country), but because you should know, and the vendor should be transparent about it, including what contractual safeguards apply when data crosses borders.
-
Can we get our data back in a usable format if we leave? A vendor confident in its product will make export straightforward. One that makes this difficult is signaling something about how replaceable they think they are.
-
Who at the vendor's company can access our raw data, and why? A well-run vendor limits internal access to a small number of engineers, for specific reasons like support and maintenance, not open access across the whole team.
A vendor that answers all ten of these clearly, without hedging or redirecting to marketing language, is one you can trust with sensitive records. A vendor that gets defensive, vague, or can't answer at all is telling you something important before you've even signed the contract.
What This Looks Like Done Honestly
It's worth being specific about what "good" looks like using a real example, rather than describing it abstractly - and the most honest way to do that is to show you exactly what one vendor actually commits to in writing, rather than asserting it in marketing copy.
Gurukul's privacy policy states that the platform uses AES-256 encryption for data at rest and SSL/TLS encryption for data in transit, enforces role-based access controls so each user only sees what their role permits, and maintains tenant isolation so one school cannot access another school's records. It states explicitly that Gurukul does not sell or rent student data, and does not use student data to train general-purpose machine learning models. When a school's subscription ends, data is retained for 90 days to allow for export before deletion. The policy also frames the relationship correctly in legal terms: the school is the data controller, and Gurukul acts as the data processor, meaning the school - not the vendor - decides how its own students' data is used.
None of this is presented as exceeding what the law requires, because in Nepal's current legal environment, there isn't a specific bar to exceed. It's presented as a documented, checkable commitment - the kind you can hold a vendor to, because it's written down rather than implied. That's the standard worth expecting from any vendor handling your students' records, whether it's Gurukul or anyone else.
This is also why a proper school management platform is worth comparing carefully against the alternative of scattered spreadsheets, personal WhatsApp numbers, and informal file-sharing. It's easy to assume that "no dedicated software" means "no data risk," but the opposite is often true - an Excel file on a personal laptop, shared over email or a personal Google Drive, has none of the access controls, encryption, or audit trail that a properly built system provides by default. If your school is migrating from Excel-based records, data protection is one of the strongest, least-discussed reasons to make the move.
How to Actually Evaluate This Before You Sign
Data protection shouldn't be the only factor in choosing a school software vendor, but it shouldn't be an afterthought either. If you're currently choosing a school management platform, build the ten-question checklist above into the same evaluation you're already doing for pricing, features, and support.
Ask to see the privacy policy before you ask for a discount. Ask what happens to your data if you decide to leave, before you decide to stay. Ask who can see your students' health records, before a parent asks you and you don't have an answer. These aren't adversarial questions - a vendor that's actually built its systems responsibly will welcome them, because the honest answers are the ones that build trust rather than lose it.
If your school is also weighing cloud-hosted software against an offline, locally-installed system, data protection is part of that decision too - a properly secured cloud platform with encryption, access control, and tenant isolation is generally a stronger security posture than a local server sitting in an office with no dedicated IT staff to maintain it, despite the intuition that "it never leaves the building" sounds safer.
The parent who asked the principal in Pokhara that question wasn't being difficult. She was asking the question every parent has a right to ask, and every school should be prepared to answer with specifics, not reassurance. Nepal's legal framework won't force that preparation on you yet. Choosing a vendor who's already built for it will.
Gurukul publishes its full data security and privacy practices in its privacy policy - AES-256 encryption at rest, tenant isolation between schools, role-based access control, and a clear commitment to never sell student data. See how it's built into every part of the platform on the features page, or book a free demo to ask your own questions directly.
