Why Real-Time EdTech Needs Security Built In, Not Bolted On

The Breach That Changed How the Industry Talks About This

In December 2024, a 19-year-old used a single compromised support credential to access PowerSchool's customer portal. He stayed in the system for nine days before anyone noticed. By the time the breach was disclosed, he walked away with data on approximately 62 million students and 9.5 million teachers - the largest breach of children's data in US history.

What struck me most about it wasn't the scale. It was this: most of the families affected had never heard of PowerSchool. They didn't know the company existed, let alone that it held their children's birthdates, home addresses, social security numbers, medical records, and academic histories. They had no relationship with PowerSchool whatsoever and no way to opt out. They enrolled their child in school. That was it.

The data exposed in that breach doesn't expire, which is exactly why student data privacy has become one of the most urgent issues in modern education. A stolen credit card gets cancelled. A stolen child's identity like their social security number or clean credit record on the other hand, can be exploited for years before anyone notices. According to research cited by TechPolicy Press, 97% of individuals whose names and SSNs appeared on dark web markets experienced attempted identity theft. For a child who was seven years old when the breach happened, the first signal might come more than ten years later when they apply for their first student loan at eighteen.

PowerSchool paid a ransom. They received a video purportedly showing the data being deleted. The lawsuits came anyway.

This isn't a cautionary tale about one company's mistakes. It's a description of what the threat environment looks like for any platform holding student data at scale, where data privacy and data security are now mission-critical requirements. The K-12 and higher education sectors are one of the most targeted in the world. It holds some of the most sensitive PII imaginable, often retains it for years, and has historically had a weaker security posture than financial services or healthcare. That combination makes it attractive.

According to a 2024 RAND survey of K-12 principals, 60% reported at least one cybersecurity incident in the 2023-2025 school years. 60%! A Comparitech analysis found that 3.9 million student records were breached in 2025 alone, up 27% from the year before. These aren't outliers. They're a trend of the growing cybersecurity threat.

The Compliance Question Nobody Enjoys But Everyone Has to Answer

When walking into a conversation with an EdTech team that's preparing for an enterprise procurement review or a district IT evaluation, there's usually a moment where someone pulls up a list of acronyms - FERPA, CCPA, SOC 2, GDPR, HIPAA - and asks if we cover all of them.

It's a fair question. The honest answer is: yes, but what matters more is whether your architecture is actually built to satisfy these requirements, or whether you're trying to paper over gaps with documentation.

Here's what each of them actually requires, in plain terms. FERPA is a federal law that restricts how student education records can be accessed, shared, and used. If your platform violates it, the consequences for your school district customers can include loss of federal funding. That tends to get people's attention most. CCPA and CPRA add specific rules for minors under 16. You need opt-in consent before their data is used for advertising, and California has a habit of setting the standard that other states follow. SOC 2 Type 2 is what enterprise procurement teams check before they sign a contract. GDPR applies the moment you have EU students or operate in Europe. HIPAA becomes relevant when platforms capture health or wellness data about students. This is  more common than you’d think for platforms once you include things like disability accommodations and mental health resources.

These look like five separate compliance and data privacy projects. They're not. The underlying requirements overlap almost completely. Role-based access control. Encryption. Audit logging. Data minimization. Clear retention and deletion policies. Build that foundation once, build it properly, and you cover most of what all of them require. The teams that treat each regulation as a separate workstream end up rebuilding the same controls five times over.

What the regulations actually have in common

• Role-based access control: who can access what. (enforced at the data tier, not the application layer)
• Encryption in transit and at rest: baseline for SOC 2, GDPR, and FERPA
• Audit logging: every access to student records is traceable (who saw what & when)
• Data minimization and retention policies: collect only what you need, keep it only as long as required
• Clear deletion workflows: CCPA/CPRA right to erasure, GDPR right to be forgotten, contractual obligations to school districts

The Teacher Who Could See Too Much

Here's a scenario I use in architecture conversations because it makes the access control problem concrete.

A middle school teacher has a dashboard showing real-time engagement scores and quiz results for her 28 students. That's exactly what she needs. It’s granular on live data she can act on mid-lesson. 

Now imagine that the same account, because of a misconfigured permission, also gives her access to aggregate performance data for every school in the district. Or that a parent logging in to check their own child's progress can, through the same misconfiguration, see records for other students in the same class.

Either of those is a FERPA violation. Neither requires a breach. It just requires someone to have access they shouldn't have.

This is the principle of least privilege. Every user gets exactly what they need to do their job and nothing more. Not as a policy document, but as an architectural constraint enforced at the database layer. In an EdTech platform serving multiple stakeholder types, that means the access model looks something like this:

The important word in all of that is “enforced.” Application-layer controls, the kind that live in your frontend code or API logic, can be bypassed. A developer with database access can query around them. A misconfigured integration can ignore them. A disgruntled employee can find the gaps. The only access control that actually holds is one implemented at the database layer, governing every query regardless of how it arrives.

GoGuardian processes millions of real-time student events every day, serving educators across more than 18 million students while keeping classroom, school, and district data cleanly separated. Their setup is a working example of what fine-grained, role-based access control looks like at production scale.

Building the Foundation: What This Actually Requires

I want to avoid turning this into an acronym list. There are enough of those already. But there are four things that every EdTech platform needs to get right in practice:

1. RBAC at the data tier, not the application tier. I've touched on this already, but it's worth diving deeper. Role-based access control needs to live in the database in query policies and permission models that apply regardless of which application or integration is making the request. The goal is that there's no path to student data that doesn't go through the same access rules.
2. Multi-tenancy with real isolation. Most EdTech and online learning platforms serve multiple schools and districts from shared infrastructure. The requirement is that one tenant's data is completely invisible to another's, even under load, even during a query error, even when a new integration is misconfigured. Logical separation at the storage and query layer, not just a 'where tenant_id = X' clause that someone could accidentally omit.
3. Identity management that propagates in real time. When a teacher changes schools, they should lose access to their old students' data the moment their identity is updated in the directory. When a student transfers districts, their previous school's data shouldn't follow them. Centralized authentication through SSO (via SAML or OIDC) makes this tractable. Batch-based access updates don't.
4. Audit logging that answers the question. When a district administrator asks “who accessed this student's record in the past 30 days”, the answer needs to be immediately available and accurate. Not reconstructed from logs. Not approximate. For platforms supporting statewide accountability programmes under ESSA, this traceability isn't optional.

Curriculum Associates runs real-time feedback loops for educators across more than four million students while maintaining exactly this kind of governed, traceable data access. Their architecture is a useful reference for teams trying to understand what real-time performance and strong governance look like together.

If It Works in Banking and Healthcare, It Works Here

When EdTech procurement teams push back on security claims, especially from a database vendor they haven't worked with before, I reference two other industries.

Banking environments run under PCI-DSS. That means the same fine-grained access controls, encryption standards, and audit trail requirements we've been discussing are required. The difference is the consequence of getting it wrong is a fraud at scale and regulatory action from multiple federal agencies instead. Pharmaceutical companies operate similarly with managing clinical research data operated under 21 CFR Part 11 and HIPAA. Strict data integrity controls, access logging for every record, PII protection that extends to the database layer. SingleStore runs in both of those environments.

The architecture patterns that satisfy compliance at that level of scrutiny (RBAC, multi-tenancy, immutable audit logs, encryption in transit and at rest) are the same patterns we apply in EdTech. The underlying technology doesn't care whether the regulated data is a patient record or a student's IEP.

SingleStore's cloud platform is SOC 2 and GDPR compliant, and is architected to support HIPAA requirements for customers who need them. If it holds up in a HIPAA-regulated environment, it holds up in a FERPA-regulated school district. Check out the Helios Cloud Security Whitepaper and the Cloud Security Blog Series for more information.

Security Is the Appetizer, Not the Side Dish

Something a colleague of mine said recently stuck with me: security is the appetizer that makes sure everything that follows is worth eating. That framing gets it exactly right.

The goal isn't to build a highly secure educational technology platform that happens to be slow and difficult to use. The goal is a platform that can deliver personalized, real-time online learning experiences. The kind that actually help students progress and give parents confidence they made the right investment and can do all of that in a way that's trustworthy. Strong data security isn't the constraint on that goal. It's the prerequisite.

The EdTech teams who get this right don't treat security as something to retrofit before a procurement review. They build RBAC before the first stakeholder dashboard goes live. They configure audit logging before the first student event is ingested. They validate multi-tenancy before the first school district is onboarded. Because the alternative of rebuilding those controls under pressure while enterprise customers are waiting and compliance timelines are closing in is far worse.

There's also a practical upside that I don't hear mentioned often enough. Once the security foundation is properly in place, the iteration speed actually goes up. You can add new stakeholder tiers, new analytics views, new third-party integrations without rebuilding the access model every time. The compliance burden is manageable because the controls are already there. And when a district IT team, a state agency, or an enterprise procurement process asks to see your security architecture, you're showing them something running in production, not something on a roadmap.

Real-time performance and strong security aren't in tension. One enables the other.

Want to see how this architecture works in practice?

Talk to a SingleStore solutions engineer about designing a secure, real-time data foundation for your EdTech platform. We do architecture reviews regularly - they're free, and they tend to surface things worth knowing before the next procurement review does.

Schedule an architecture review ->   |   Explore the SingleStore EdTech solution page