A large school group's ERP holds more sensitive information than almost any other system it runs: names, dates of birth and addresses of thousands of children, parents' phone numbers and income documents, health and disability notes, marks, attendance, live bus locations, fee payments and staff salaries. School ERP data security in India is therefore not a feature checkbox. It is a legal duty under the Digital Personal Data Protection (DPDP) Act, 2023, and a question of trust with every parent.

This guide is for CIOs, IT heads, information security and compliance teams, directors and trustees at large schools and education groups. It explains what data needs protecting, the threats schools actually face, what Indian law requires and when, how cloud and on-premise deployment change the risk threat by threat, how to check a vendor's security claims, and what to do in the first 72 hours of a breach. It ends with a 30-point checklist your team can use.

Quick Answer: How do you keep student data secure in a school ERP?
Secure school ERP data with the same core controls whether the ERP runs in the cloud or
on-premise: named accounts with MFA for administrators, role- and campus-scoped access,approval for fee and marks changes, encryption, audit logs, tested backups and prompt patching.Cloud ERP shifts infrastructure security to the vendor; on-premise gives the institution direct control and the work that comes with it. Under the DPDP Act, the school remains accountable in both.

Key Takeaways
• Hosting location does not decide data security. Controls, operations and contracts do.
• Under the DPDP Act the school or trust is the Data Fiduciary and stays accountable even when a vendor hosts the ERP.
• Most DPDP Rules obligations, including security safeguards, 72-hour breach reporting and parental consent, apply from May 2027.
• The school exemption is narrow: it covers tracking and behavioural monitoring for educational activities or child safety, not all processing of children's data.
• Many of the biggest risks are people and process risks: shared logins, excess access, bulk
exports, phishing and untested backups.
• Ask vendors for evidence such as certificates with their scope, recent test reports and contract terms, not assurances.

What Is School ERP Data Security?

School ERP data security is the set of technical controls, processes and contracts that keep the personal and financial data in a school ERP confidential, accurate and available, and that let the institution prove it. It covers who can access which records, how data is protected in storage and transit, how changes are recorded, how data is backed up and recovered, and how incidents are detected, reported and fixed.

For Indian schools, "prove it" now matters as much as "do it". Under the DPDP framework, the institution must be able to show reasonable security safeguards, keep logs, report breaches on time and answer parents' requests about their children's data.

What Data Does a School ERP Hold, and Why Is It Sensitive?

Security starts with knowing what you hold. In a multi-campus group, the ERP typically contains the categories below, and most of them relate to children, which raises the stakes under the DPDP Act.

Data category Typical examples Who usually needs access Main risk if exposed
Student identity Name, date of birth, photo, address, Aadhaar or APAAR ID where collected, admission number Admissions, class teachers, principal Identity misuse; child safety
Parent and guardian data Phone numbers, email, occupation, income certificates (e.g. for RTE), ID documents Admissions, accounts, communication staff Fraud, targeted scams, harassment
Health and special needs Medical conditions, allergies, disability and CWSN details, counselling notes Nurse, counsellor, special educator, principal Serious harm and stigma; highest sensitivity
Academic records Marks, report cards, assessments, remarks, transfer certificates Teachers, exam cell, principal Tampering; reputational harm
Attendance and biometrics Daily attendance, biometric templates or IDs, gate entry logs Class teachers, admin, HR Location tracking; irreversible if biometrics leak
Transport and location Bus routes, stops, live GPS location of buses carrying children Transport in-charge, parents (own child) Physical safety of children
Fees and payments Fee ledgers, concessions, refunds, payment references, bank mappings Accounts, finance head Financial fraud; diverted payments
Staff HR and payroll PAN, bank accounts, salaries, appraisals, leave HR, payroll, management Fraud; employee harm; internal disputes
Communication history SMS, WhatsApp and email logs, notices, feedback Admin, communication staff Privacy complaints; phishing material

"Who usually needs access" is a starting point for role design, not a rule. Each group should set its own access decisions and record them.

Two practical consequences follow. First, access should be designed per data category, not per module, because a fee clerk does not need counselling notes and a teacher does not need parents' income documents. Second, health, special-needs and location data deserve stricter controls, such as masking, restricted roles and extra logging, than routine academic data.

What Threatens School ERP Data in Practice?

Many data incidents do not begin with sophisticated hacking. They begin with ordinary weaknesses in how people and systems are run. Two data points set the context:

• Check Point Research reported that Indian education and research organisations faced an
average of 8,487 attempted cyberattacks per organisation per week over the six months to
September 2025, almost twice the global average of 4,368 (reported September 2025).
• Verizon's 2025 Data Breach Investigations Report, which analysed 12,195 confirmed breaches across sectors worldwide, found third-party involvement in 30% of breaches (double the previous year), ransomware in 44%, and a human element in roughly 60%.

In a school group, those patterns translate into the following threats:

Threat How it typically happens in schools First line of defence
Stolen or shared credentials One office login shared by several staff; passwords written down; phishing emails to accounts staff Named accounts, MFA for admin and finance roles, lockout and alerting
Excess access and insider misuse Staff keep access after transfers or exits; campus users can see other campuses; curiosity browsing Role and campus scoping, joiner-mover-leaver process, quarterly access reviews
Bulk exports and data sprawl Student lists exported to Excel and shared on WhatsApp groups or personal email Export permissions, export logging, watermarking where possible, policy and training
Payment and bank-detail fraud Fraudster impersonates a vendor or staff member to change a bank account in payroll or fee mapping Maker-checker approval and call-back verification for any bank detail change
Ransomware Malware on an office PC spreads to servers and encrypts the database and backups Patching, segmentation, endpoint protection, offline or immutable backups, restore tests
Internet-facing app flaws Parent app or API lets one parent view another child's record by changing an ID Object-level authorisation checks, security testing against OWASP ASVS, rate limiting
Third-party and vendor access Vendor support logs in with a permanent admin account; integration keys stored in scripts Time-bound, approved and logged support access; secret management; contract terms
Backup failure Backups run but have never been restored; backups are on the same server as production Separate backup location, encryption, scheduled restore tests
Lost devices and paper Unlocked office PCs, printed lists, lost laptops with downloaded reports Screen locks, device encryption, minimal local downloads, clean-desk practice

Notice that none of these threats is solved by hosting location alone. Each needs a control that someone owns.

What Do India's Data-Protection Rules Require From Schools?

Schools that process personal data digitally are Data Fiduciaries under the DPDP Act, 2023. They must take reasonable security safeguards, report breaches, obtain verifiable parental consent for children's data unless an exemption applies, honour parents' rights and erase data when it is no longer needed. The DPDP Rules, 2025, notified by MeitY in November 2025, phase these duties in. Most apply from May 2027.

When the obligations apply

Period What applies What it means for schools
From November 2025 DPDP Act commencement provisions; Data Protection Board set up; Rules 1, 2 and 17-21 Framework and regulator exist; time to prepare
From November 2026 Rule 4 (registration of Consent Managers) Little direct impact on most schools
From May 2027 Rules 3, 5-16, 22 and 23: notice, security safeguards, breach intimation, retention, contact details, children's consent, rights and grievance redressal The substantive duties apply; ERP controls must be in place
Until May 2027 IT Act Section 43A and the SPDI Rules, 2011 continue for bodies corporate "Reasonable security practices" already apply where the entity is covered; ISO/IEC 27001 is named as one acceptable standard
Already in force since 2022 CERT-In Directions under Section 70B of the IT Act 6-hour incident reporting, 180-day logs within India and time synchronisation for covered entities

The school exemption is narrower than many people assume

Section 9 of the Act requires verifiable parental consent before processing a child's (under 18) personal data and prohibits tracking, behavioural monitoring and targeted advertising directed at children. The Fourth Schedule of the Rules exempts educational institutions from the consent and tracking provisions only where the processing is restricted to tracking and behavioural monitoring for the institution's educational activities, or in the interests of the safety of enrolled children. A similar exemption covers transport providers engaged by schools, limited to tracking children's location during travel for their safety.

In practice, attendance, academic progress tracking and bus GPS for safety can fall within the exemption. Other processing, such as admissions data, fee records, photographs used in marketing, or data shared with third-party apps, should be planned on the assumption that verifiable parental consent and notice are needed, unless legal counsel advises that another basis applies. Rule 10 allows verification using reliable identity and age details the school already holds, details the parent provides, or a virtual token from an authorised entity such as DigiLocker.

DPDP obligations mapped to ERP controls

This is the table most compliance teams need: what the law asks, and what the ERP must actually do.

Obligation Source What the school ERP should support
Clear notice to parents and staff Act s.5; Rule 3 Store notice versions, record who received which version and when, in the admission and staff onboarding flows
Verifiable parental consent Act s.9(1); Rule 10 Consent capture in admissions with purpose, method of verification, timestamp; withdrawal handling; consent register reports
Limits on tracking children Act s.9(3); Fourth Schedule Restrict monitoring features to educational and safety purposes; no advertising or profiling features using student data
Reasonable security safeguards Act s.8(5); Rule 6 Encryption or masking, access control, monitoring and log review, backups and continuity, processor contracts, effective organisational measures
Keep logs and processing records Rules 6 and 8(3) Retain logs and associated records for at least one year; protect logs from alteration
Breach intimation Act s.8(6); Rule 7 Detect and investigate quickly; contact data to notify affected parents; evidence for a detailed Board report within 72 hours
Erase when no longer needed Act s.8(7) Retention schedule per data category; archive and delete workflows; legal holds for records the school must keep
Rights: access, correction, erasure, grievance Act ss.11–13; Rule 14 Request intake (e.g. parent portal), tracking and audit; resolution within the published period, not exceeding 90 days
Published contact person Rule 9 A named contact for data questions shown on the website and app, included in responses to requests
Contracts with processors Act s.8(2); Rule 6 Data processing agreement with the ERP vendor covering security, breach notice, sub-processors, return and deletion

Penalties under the Act's Schedule are significant: up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore each for failing to notify a breach or to meet children's-data obligations, and up to ₹50 crore for other breaches of the Act or Rules. Whether a particular trust, society or company is also a Significant Data Fiduciary, with extra duties, depends on government notification. Confirm your institution's position with legal counsel.

Review Your ERP Data-Security Requirements
Map your data categories, campuses, user roles and DPDP obligations with the Campus On Click team, and discuss which deployment model and controls fit your group before you shortlist vendors.
Discuss your ERP security requirements →

Cloud vs On-Premise: What Actually Changes for Data Security?

Deployment changes who performs each security task. It does not change who is accountable. In a cloud (SaaS) ERP, the vendor runs the servers, patches the platform and holds the backups; the school still owns user access, approvals and its legal duties. In an on-premise ERP, the school or its IT partner runs all of that, with the vendor responsible for application fixes. For the full deployment comparison, including cost and a decision scorecard, see our guide to cloud vs on-premise school ERP.

Threat-by-threat comparison

Threat Cloud (SaaS) ERP On-premise ERP What decides the outcome
Stolen or shared credentials Same risk; depends on MFA and login controls the vendor offers Same risk; you can enforce your own identity policies and SSO MFA, named accounts, monitoring. Hosting is irrelevant
Insider misuse and excess access Same risk Same risk Role and campus scoping, access reviews, export controls
Ransomware Vendor's defences and backups protect the platform; office PCs remain your risk Your patching, segmentation and offline backups decide recovery Backup isolation and restore testing
Unpatched infrastructure Vendor patches centrally, usually faster Depends on your team's patch discipline Patch ownership and timelines
Internet-facing app flaws Vendor fixes once for all customers Vendor supplies fixes; you must apply them Secure development and how fast fixes reach you
Vendor or third-party access Vendor staff can access data by design; control is contractual You decide when vendor support connects, and you can log it Time-bound, approved, logged access
Visibility and logs Limited to what the vendor exposes Full access to application, database and network logs Contract terms for cloud; monitoring capacity for on-premise
Physical security and disasters Professional data centres Depends on your server room or colocation choice Location quality and a separate DR copy
Data location and log residency Depends on vendor regions; must be specified in contract Known by design Contract or design choice
Exit and data return Depends on export and deletion terms Data already in your environment Documented exports and schemas

Reading the table: cloud tends to be stronger where security depends on specialist infrastructure operations, such as patching, physical security and platform-level fixes. On-premise tends to be stronger where security depends on visibility and control, such as logs, vendor access, data location and exit. The people and process threats at the top of the table, which account for a large share of breaches across sectors, are the same in both models.

The 12 Controls That Matter Most, Whatever the Hosting Model

If you can only fund a few improvements, start here. The list starts with controls for the people and process threats described above, then moves to technical safeguards. Technical implementation details, such as network segmentation and HA/DR design, are covered in our guide to on-premise multi-campus ERP architecture.

  1. Named accounts only. No shared "office" or "accounts" logins. Every action must trace to a person.
  2. MFA for privileged and finance roles, and for any remote or vendor administrative access.
  3. Role plus scope. Permissions combine what a user can do with which campus, class or entity they can do it for. See Multi Institute Management and Campus Management.
  4. Maker-checker for money and marks. Fee concessions, refunds, bank-detail changes, payroll changes and mark edits after publication need a second approver. Campus On Click | Blog 6: School ERP Data Security India Page 11
  5. Joiner-mover-leaver process. Access is granted from HR records, changed on transfer and removed on exit, with a quarterly access review, especially after term-end staff changes.
  6. Export controls. Limit who can bulk-export student or parent data, log every export, and give staff a sanctioned way to share lists that does not involve WhatsApp or personal email.
  7. Encryption. TLS for all traffic; encryption at rest for databases, document storage and backups; masking of identifiers such as Aadhaar and bank account numbers on screens and in reports.
  8. Audit trails that cannot be quietly edited, covering logins, permission changes, exports and high-value transactions, kept for at least one year.
  9. Backups that survive ransomware: encrypted, stored separately, with at least one offline or immutable copy, and a restore test on a schedule.
  10. Patching with deadlines. Named owners and target times for operating system, database, web server and ERP updates, with emergency patches handled faster.
  11. Secure parent app and APIs: per-record authorisation checks, rate limiting, and security testing before major releases.
  12. Controlled vendor access: support sessions approved per request, time-limited, recorded, and covered by the data processing agreement.

How Security Needs Change at 10, 50 or 100+ Campuses

More campuses mean more users, more administrators, more devices and more ways for access to drift. The table gives indicative patterns, not fixed rules.

Area About 10 campuses About 50 campuses 100+ campuses
Security ownership IT head owns security alongside ERP Named security lead; DPDP contact person appointed Dedicated security function; formal data-protection governance
Access reviews Quarterly, manual Quarterly, with campus heads signing off Automated reports with exceptions reviewed centrally
Monitoring ERP audit logs reviewed weekly Central log collection and alerts Security monitoring service (in-house or managed), 24×7 where justified
Testing Vendor test evidence; basic vulnerability scans Annual independent VAPT VAPT plus testing after major releases; red-team exercises where justified
Incident response Documented contacts and steps Tested plan with legal and communications Retained incident-response support; regular drills
Training Induction for office staff Annual phishing and data-handling training Role-based training and simulated phishing

How to Check a School ERP Vendor's Security Claims

"Bank-grade security" and "100% secure" are not evidence. Ask for documents, and read what each one actually covers.

Ask for What it shows What to check
ISO/IEC 27001 certificate An information security management system has been independently certified The scope: does it cover the ERP product, its hosting and support teams, or only an office?
SOC 2 Type II report (if offered) Controls were tested over a period, not just designed Period covered, exceptions noted, which services are in scope
Recent VAPT summary Independent testing of the application and infrastructure Date, tester (CERT-In empanelled auditors are available in India), whether critical findings were fixed
Secure development practices How vulnerabilities are prevented in the code Use of a standard such as OWASP ASVS; how fixes reach on-premise customers
Data processing agreement Contractual security and breach duties Breach notice to you within hours, sub-processor list, data location, return and deletion on exit
Audit-log catalogue What the ERP records Logins, exports, permission changes, financial edits; retention and export of logs
Support access model How vendor staff reach your data Approval, time limits, recording, named individuals
On-premise hardening guide How to install securely Supported OS and database versions, configuration baseline, patch cadence

A certificate is a starting point, not a guarantee. The most useful question is often: "Show us how a campus accountant's account is prevented from exporting another campus's student list, and show us the log entry when they try." For the full set of commercial, functional and technical questions, see our enterprise school ERP buying guide

What to Do in the First 72 Hours of a School Data Breach

A breach response plan should exist before go-live, with names and phone numbers, not job titles. Under the DPDP Rules, from May 2027 a school must inform affected individuals and the Data Protection Board without delay, and send the Board a detailed report within 72 hours of becoming aware. Covered entities must also report specified incidents to CERT-In within 6 hours under its 2022 Directions, which already apply.

When Actions Who leads
First hour Confirm the incident; contain it (disable accounts, isolate systems, revoke keys); preserve logs and evidence; start an incident log IT or security lead, ERP vendor
Within 6 hours Decide whether CERT-In reporting applies and, if so, report; brief management; engage legal counsel Security lead, legal
Without delay Initial intimation to the Data Protection Board (nature, extent, timing, location, likely impact); notify affected parents and staff in plain language Data-protection contact, principal or communications lead
Within 72 hours Detailed report to the Board: facts, causes, mitigation, who was responsible if known, remediation, and the notices sent Data-protection contact, legal
After containment Fix root causes, reset credentials, test restores, review access, update the plan, brief trustees IT head, management

The Board may allow more than 72 hours on a written request. Notices to individuals must include what happened, likely consequences, steps taken, steps they can take, and a contact. Confirm CERT-In applicability for your entity with counsel.

For cloud ERP, your contract must require the vendor to notify you fast enough for you to meet these deadlines. A vendor commitment of "within 72 hours" leaves you no time; ask for notification within hours.

A 30-Point School ERP Data Security Checklist

Use this with your IT, finance and academic leads. Each item should have a named owner and a status.

# Area Checklist item
1 Governance A named owner for ERP data security and a published DPDP contact person
2 Governance A data inventory by category, campus and system, including spreadsheets and messaging groups
3 Governance A retention schedule per data category, with legal holds for records the school must keep
4 Governance Notice and consent records built into admissions and staff onboarding
5 Governance A process to receive and resolve parents' data requests within the published period (not over 90 days)
6 Governance Security and data-protection review included in every new integration or app
7 Access Named accounts only; shared logins removed
8 Access MFA for administrators, finance roles and all remote or vendor access
9 Access Roles combine function with campus and entity scope
10 Access Maker-checker for concessions, refunds, bank details, payroll and post-publication mark changes
11 Access Joiner-mover-leaver process linked to HR; quarterly access reviews
12 Access Restricted roles for health, counselling and special-needs data
13 Data protection TLS everywhere; encryption at rest for database, documents and backups
14 Data protection Masking of Aadhaar, bank and similar identifiers on screens and reports
15 Data protection Bulk-export permissions limited and every export logged
16 Data protection Test and training environments use masked data, not live student records
17 Data protection Secrets and API keys stored securely, never in scripts or shared documents
18 Data protection Parent app and APIs tested for per-record authorisation
19 Resilience Encrypted backups stored separately, including an offline or immutable copy
20 Resilience Restore test completed and recorded at least twice a year
21 Resilience Patching owners and deadlines for OS, database, web server and ERP
22 Resilience Agreed RPO and RTO, approved by management
23 Vendor Data processing agreement signed, with breach notice to you within hours
24 Vendor Certificates checked for scope; recent VAPT summary reviewed
25 Vendor Vendor support access approved, time-limited and recorded
26 Vendor Exit terms: complete export, documents, logs, and written deletion confirmation
27 Monitoring Audit logs protected from alteration and kept at least one year; system logs kept 180 days in India where CERT-In applies
28 Monitoring Alerts for failed logins, privilege changes, mass exports and unusual hours
29 Response Written incident plan with names, CERT-In and DPDP timelines, and parent notice templates
30 Response An incident drill run at least once a year, plus annual data-handling training for office staff

Common Data-Security Mistakes in School ERP Rollouts

• Migrating everything. Old records of students who left years ago are copied into the new ERP without a retention decision. See school ERP migration [link to Blog 9 when live] for a safer sequence.
• Using live data for testing and training. Copies of the production database end up on laptops and test servers.
• Giving the implementation team permanent admin rights that are never removed after
go-live.
• Treating the vendor's security as yours. A secure platform does not stop a staff member
exporting a class list to WhatsApp.
• Assuming the school exemption covers everything. It covers specific tracking and
monitoring purposes, not all processing.
• Never testing the breach plan until a parent reports seeing someone else's child's report card.

How Campus On Click Approaches School ERP Data Security

Campus On Click is an Indian school ERP with more than 100 modules, including Multi Institute Management and Campus Management for groups, Staff Management, Document Management and Gate Management, with integrations for biometric devices, payment gateways, accounting software, SMS, WhatsApp, email and vehicle tracking.

For institutions that want direct control over where student data lives, Campus On Click offers on-premise deployment, so the group can hold administrative control of servers, database, logs and backups, and decide when vendor support connects. The useful security conversation starts with your data inventory, campus and entity structure, role design, integrations and DPDP obligations, and ends with a written responsibility model: what Campus On Click is responsible for, what your IT team is responsible for, and how incidents are handled between you.

Whichever vendor you evaluate, including Campus On Click, ask for the evidence listed in the due-diligence table above and test the controls in a demonstration using your own scenarios. For the wider on-premise picture, see our guide to on-premise school ERP software in India.

Plan a Secure Multi-Campus ERP Deployment
Walk the Campus On Click team through your campuses, user roles, integrations and data
categories, and discuss how an on-premise or hybrid deployment could give your group control over student data and logs.
Plan your multi-campus ERP architecture →

Conclusion: Make Security a Design Decision, Not a Hosting Label

School ERP data security in India comes down to three things: knowing what data you hold, putting the right controls around it, and being able to prove those controls work when a parent, an auditor or the Data Protection Board asks. Cloud ERP suits institutions that want a specialist vendor to runinfrastructure security and can secure strong contract terms. On-premise ERP suits large schools and education groups that need direct control over data, logs, vendor access and data location, and that can staff the operations it requires.

The criteria that matter most are the sensitivity and volume of your data, your IT and security capability, the visibility you need for DPDP compliance, and the strength of the vendor's evidence. With the main DPDP obligations applying from May 2027, the time to close gaps is the coming academic year.

Your next step: build your data inventory, score yourself against the 30-point checklist, and take the gaps into vendor conversations and your deployment decision.

Request an Enterprise ERP Security Consultation
Share your campus count, current ERP and key concerns with Campus On Click. In the
consultation, the team can review your data categories and access model, map DPDP obligations to ERP controls, discuss whether on-premise, cloud or hybrid deployment suits your security requirements, and outline a responsibility matrix for your group.
Request an enterprise ERP consultation →

FAQs

How do we keep student data secure in a school ERP?

Start with a data inventory, then apply the controls that address the most common risks: named accounts, MFA for administrators and finance staff, permissions limited by role and campus, approval for fee and marks changes, export controls, encryption, audit logs, separately stored backups with regular restore tests, and prompt patching. Add a written incident plan and annual training for office staff. These controls apply whether the ERP is cloud-hosted or on-premise.

Does the DPDP Act apply to schools in India?

Yes. A school, trust or society that processes personal data of students, parents or staff in digital form is a Data Fiduciary under the Digital Personal Data Protection Act, 2023. The DPDP Rules, 2025 phase in its duties, and most of them, including security safeguards, breach reporting, parental consent and parents' rights, apply from May 2027. Schools have a limited exemption for certain tracking and monitoring, but the Act otherwise applies to them in full.

In most cases, plan for it. The Act requires verifiable consent from a parent or guardian before processing a child's personal data. The Fourth Schedule exempts educational institutions only where processing is restricted to tracking and behavioural monitoring for educational activities or children's safety. For admissions, fees, photographs and third-party apps, capture and record parental consent in the ERP, using details the school already holds or a verified token, unless counsel advises another basis applies. Campus On Click | Blog 6: School ERP Data Security India Page 16

Who is responsible if a cloud school ERP vendor suffers a data breach?

The school remains responsible to parents and the Data Protection Board as the Data Fiduciary, even though the vendor is the Data Processor. The vendor's obligations come from your contract. That is why the data processing agreement should require the vendor to maintain specified safeguards, notify you within hours of a suspected breach, support your investigation and reporting, and carry liability terms you have reviewed.

How quickly must a school report a data breach in India?

Under the DPDP Rules, from May 2027 a school must inform affected individuals and the Data Protection Board without delay, and submit a detailed report to the Board within 72 hours of becoming aware, unless the Board allows more time on request. Separately, entities covered by the CERT-In Directions of 2022 must report specified cyber incidents to CERT-In within 6 hours. Confirm which obligations apply to your entity with legal counsel.