Educational platforms are infrastructure. When a platform is unavailable, students can’t learn, educators can’t teach, and programs can’t function. When a platform is insecure, student data is exposed, trust is broken, and institutions face legal and reputational consequences that take years to resolve. Infrastructure and security are not advanced topics for technology teams — they are operational requirements that every institution should understand well enough to evaluate whether their platforms meet them.
This guide covers the technical foundations of a secure, reliable educational platform: what good cloud infrastructure looks like, how identity and access management works, what data security requires, how to maintain availability, and how to respond when things go wrong.
Cloud infrastructure fundamentals
Modern educational software runs on cloud infrastructure — compute, storage, and networking provided by cloud providers and abstracted from physical hardware. Understanding the basics of how this works helps institutions evaluate the security and reliability of the platforms they use.
Multi-tier architecture. A well-designed cloud application separates its components: a presentation layer (what users see), an application layer (where business logic runs), and a data layer (where information is stored). Each layer communicates with the adjacent layer through defined interfaces, and each can be scaled independently. This separation means that a spike in traffic can be handled by scaling the application layer without also needing to scale the database, and that a vulnerability in the presentation layer doesn’t automatically expose the database.
Cloud provider compliance. The major cloud providers (AWS, Google Cloud, Azure) maintain compliance with a range of security frameworks — SOC 2, ISO 27001, FedRAMP, and others. An application built on these providers inherits some of the underlying infrastructure compliance, but only the provider-level controls. Application-level controls — how the application authenticates users, how it stores data, how it handles breaches — are the responsibility of the application vendor, not the cloud provider.
Geographic distribution and data residency. Cloud providers run infrastructure in multiple geographic regions. For institutions with data residency requirements — particularly EU institutions under GDPR, or institutions serving government clients — it matters where the servers running your application and storing your data are physically located. Confirm that your vendor’s data residency practices meet your requirements, not just that they use a cloud provider with global infrastructure.
Ilmiya’s infrastructure. Ilmiya runs on Google Cloud Platform with services deployed across multiple regions. Application services run on Cloud Run (containerized, auto-scaling). Databases use managed GCP services with encryption at rest enabled by default. Static assets are served via global CDN with edge caching. Infrastructure configuration is version-controlled and deployed through automated pipelines, reducing the risk of human configuration error.
Identity and access management
Identity and access management (IAM) is the set of policies and technologies that controls who can access what in a system. It is the primary control layer for preventing unauthorized access to student data.
Authentication vs. authorization. Authentication answers “who are you?” — verifying that you are who you claim to be. Authorization answers “what are you allowed to do?” — determining what actions and data your verified identity can access. Both are necessary; most security failures involve one or both.
Multi-factor authentication (MFA). MFA requires a second proof of identity beyond a password — typically a code from a mobile app, a hardware token, or a biometric. MFA defeats credential stuffing (using stolen username/password pairs), phishing attacks that capture passwords, and brute-force password guessing. For any account with access to student data, MFA should be required, not optional.
Principle of least privilege. Every user and every service should have only the access required to do their specific job. A teacher should be able to see their students’ records; they should not be able to see all students in the school. An application service that reads from a database should not also have permission to delete from it. Minimum-necessary access limits the blast radius of any single compromised account.
Role-based access control (RBAC). Rather than assigning permissions to individual users, RBAC assigns permissions to roles and users are assigned to roles. A “teacher” role has a defined set of permissions appropriate for teachers; a “program administrator” role has a different set. When a teacher’s responsibilities change, you change their role assignment — you don’t have to audit and modify a custom permission set built over time. Ilmiya’s permission model is RBAC-based, with roles that map to real institutional functions.
Single sign-on (SSO). SSO allows users to authenticate once with a trusted identity provider (Google, Microsoft Azure AD, Okta, and others) and access multiple applications without re-entering credentials. SSO centralizes authentication, which means all the security controls at the identity provider level — MFA, session management, suspicious activity detection — apply across all connected applications. It also centralizes offboarding: when a staff member leaves, disabling their account in the identity provider revokes access to all connected applications immediately.
Session management. After a user authenticates, they receive a session token that authorizes subsequent requests. Session tokens have lifetimes — they expire after a period of inactivity or after a maximum duration. Short session lifetimes reduce the window during which a stolen token can be exploited. Platforms that never expire sessions or that allow indefinitely long sessions create unnecessary risk.
Data security architecture
Protecting student data requires controls at multiple layers: encryption, storage design, access controls, and monitoring.
Encryption at rest. Data stored in databases, file storage, and backup systems should be encrypted. Encryption at rest means that physical access to the storage media — a stolen hard drive, a misconfigured storage bucket — does not produce readable data. AES-256 is the current standard for symmetric encryption at rest. Confirm that any vendor handling student data encrypts at rest.
Encryption in transit. Data moving between systems — between a user’s browser and the application server, between application services, between the application and the database — should be encrypted using TLS (Transport Layer Security). TLS 1.2 is the minimum acceptable version; TLS 1.3 is preferred. Encryption in transit prevents interception of data as it moves across networks.
Database security. Databases containing student records should not be publicly accessible. Production databases should live in private network segments that are only reachable from application servers, not from the public internet. Database credentials should be stored in secrets management systems (not in code or configuration files), rotated regularly, and scoped to the minimum permissions the application needs.
Secrets management. API keys, database credentials, encryption keys, and other sensitive configuration values are “secrets.” Secrets stored in code repositories or environment files are frequently exposed through code leaks, misconfigured access controls, or developer mistakes. Secrets should be stored in dedicated secrets management systems that provide audited access, rotation capabilities, and automatic injection into applications without storing secrets in persistent storage.
Audit logging. A comprehensive audit log records every significant access to and modification of student data: who accessed what, when, from where, and what they did. Audit logs serve multiple purposes: they enable forensic investigation of incidents, they satisfy regulatory requirements (FERPA requires a disclosure log), and they provide accountability for data access. Audit logs should be immutable — once written, they cannot be modified — and retained for a period appropriate to regulatory requirements.
Availability and reliability
An educational platform that is unavailable when students and educators need it fails its core function, regardless of how secure it is when it’s running.
Availability targets. Service availability is typically expressed as a percentage of uptime over a period. 99.9% availability means approximately 8.7 hours of downtime per year. 99.95% means approximately 4.4 hours. 99.99% means approximately 52 minutes. For educational platforms used intensively during school hours, availability targets should be stated in terms of availability during peak usage windows, not just calendar averages. A platform that is down every Saturday night has high calendar availability and terrible availability when it matters.
Redundancy. Single points of failure are the primary cause of unplanned outages. A well-architected system has no single component whose failure would bring down the entire system. Application servers run in multiple instances so that the failure of one instance doesn’t take down the service. Databases are replicated across multiple nodes so that the failure of one node doesn’t cause data loss. The question to ask vendors: what is the single point of failure in your architecture?
Graceful degradation. When a component fails or is degraded, well-designed systems continue to function in a reduced capacity rather than failing entirely. If the AI recommendation engine is unavailable, students should still be able to access their course content. If the analytics dashboard is slow, assignment submission should still work. Graceful degradation requires deliberate design — applications that don’t separate concerns will fail completely when any component fails.
Backup and recovery. Data should be backed up regularly, with backups stored separately from primary data and tested regularly to confirm they can be restored. The recovery time objective (RTO) — how long it takes to restore service after a failure — and the recovery point objective (RPO) — how much data can be lost in a failure — should be defined and tested, not assumed. Backup systems that have never been tested are not recovery systems — they are hope.
Change management. A significant percentage of outages are caused by changes: software deployments, configuration changes, infrastructure modifications. Change management practices — automated testing before deployment, staged rollouts to subsets of users, rollback capabilities, and deployment windows outside peak usage — reduce the risk that a change causes an outage. Confirm that your vendors have automated deployment pipelines with testing and rollback capabilities, not manual deployment processes.
Incident response
Security incidents and significant outages will happen. How an organization responds determines whether an incident becomes a crisis. Having a defined incident response plan before an incident occurs is the difference between a managed response and a chaotic one.
Detection. You can’t respond to an incident you don’t know about. Detection requires monitoring: alerts on anomalous activity (unusual login patterns, unexpected data access, performance degradation), log analysis for security events, and vulnerability scanning for known weaknesses. Automated monitoring that pages an on-call responder in real time is significantly more effective than manual log review.
Containment. When an incident is detected, the first priority is containment — stopping the bleeding before investigating the cause. A compromised account gets disabled. An exploited service gets isolated from the network. A misconfigured storage bucket gets its public access removed. Containment actions should be defined in advance so responders aren’t deciding what to do for the first time under pressure.
Assessment. After containment, assess the scope: what systems were affected, what data may have been accessed or exfiltrated, how long the incident was active before detection. The assessment drives notification decisions — who needs to be told, and what do they need to know.
Notification. FERPA requires notification to affected families when student data is improperly disclosed. Most US states have breach notification laws with specific timelines (often 30-72 hours after discovery). GDPR requires notification to the relevant supervisory authority within 72 hours of discovering a personal data breach. Know the applicable requirements for your institution before an incident, not after. Notification that meets regulatory requirements, communicates clearly, and avoids unnecessary alarm is a skill that should be practiced in tabletop exercises, not improvised in response to a real incident.
Remediation. After notification, fix the underlying cause. Not just the specific vulnerability exploited, but the class of vulnerability — if a phishing attack succeeded because a user wasn’t using MFA, the remediation is MFA enrollment for all users with access to sensitive data, not just the one affected user.
Post-incident review. Every significant incident should produce a post-incident review: what happened, why it happened, what was done, and what will be different. Post-incident reviews are not blame exercises — they are learning mechanisms. Organizations that conduct honest post-incident reviews improve their security posture over time; organizations that suppress or minimize post-incident learning repeat the same incidents.
What to require from vendors
Every third-party vendor that touches student data extends your security perimeter. Vendor security is not optional due diligence — it is a core part of your institution’s security posture.
SOC 2 Type II. A SOC 2 Type II report is an independent audit of a vendor’s security controls over a period of time (typically six to twelve months). It covers five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. “Type II” (as opposed to Type I) means the auditor tested whether the controls were operating effectively over time, not just that they existed at a point in time. Require a SOC 2 Type II report from any vendor with access to student data, and read the “exceptions” section — that’s where the problems are.
Penetration testing. Penetration testing is an authorized attempt to compromise a system to identify vulnerabilities before attackers do. Vendors should conduct penetration testing at least annually and be willing to share the results (or a summary) with customers. Ask when the last penetration test was conducted and what the identified findings were, not just whether testing happens.
Subprocessor disclosure. Your vendor likely uses other vendors to provide their service — cloud infrastructure, email delivery, analytics, customer support tools. Each of these subprocessors touches your data in some way. Vendors should maintain and disclose their subprocessor list, and you should have the right to object to new subprocessors. GDPR explicitly requires this; it’s good practice regardless of jurisdiction.
Data processing agreement (DPA). A DPA is a contract that specifies how a vendor handles data on your behalf — what they can do with it, what they can’t do with it, what security measures they maintain, and what happens in a breach. Any vendor handling student data should have a DPA available to sign. If they don’t, their data handling practices are uncontracted, which means they could change without notice.
Incident notification requirements. Contracts with vendors should specify how quickly they will notify you of a security incident affecting your data. Twenty-four hours is a reasonable expectation; “reasonable time” is not acceptable. You can’t notify affected families or meet regulatory notification requirements if your vendor tells you about an incident two weeks after it occurred.