How Clasra Protects Your School’s Data
Student records, staff information, and financial data deserve strong, honest protection. This page explains what Clasra actually does to keep your school’s data secure — and what it does not yet do, stated plainly.
Our Approach to Security
Clasra holds data that matters deeply — children’s academic records, staff personal information, school financial records. We take the responsibility seriously and apply strong controls across authentication, access, data isolation, and transmission.
We believe that honest disclosure serves schools better than marketing language. On this page, you will find what we actually do and what we do not yet do. If you have questions not answered here, contact us directly.
Authentication
Clasra uses session-based authentication with secure, short-lived tokens. Passwords are hashed using industry-standard algorithms — plaintext passwords are never stored. Login attempts are rate-limited to prevent brute-force attacks.
Hashed credential storage — no plaintext passwords
Session tokens with configurable expiry
Rate limiting on authentication endpoints
Separate login portals per school — not shared login pages
Role-Based Access Control (RBAC)
Every user in Clasra is assigned a role that determines exactly which modules they can access and what actions they can perform. Access is enforced on both the frontend and the API layer — so there is no way to reach data your role is not permitted to see.
Granular roles: Headmaster, Administrator, Teacher, Bursar, Parent, Student
API-level enforcement — not only UI restrictions
Role assignment controlled by school administrators
Audit logs for sensitive role-level operations
Tenant Isolation
Clasra is a multi-tenant SaaS platform. Every school is its own isolated tenant. A teacher at School A cannot access, query, or even discover data belonging to School B — this is enforced at the database query level, not just in the UI.
All data records are scoped by tenantId
API routes resolve tenant identity from authenticated session tokens — not from client-supplied headers
Cross-tenant data access is structurally impossible at the query layer
Tenant resolution is performed server-side only
Private Portals — Not Indexed
School login portals, dashboard pages, student and parent portals, and all authenticated routes carry explicit noindex directives. These pages will not appear in search engine results, protecting school names and student data from exposure through public search.
Dashboard and portal routes explicitly set robots: noindex, nofollow
Student portal, parent portal, and HR routes excluded from search indexing
Public-facing marketing pages are indexed; school operational pages are not
Sitemap excludes all private routes
Data Transmission and Storage
All data transmitted between your school and Clasra travels over encrypted connections. We apply security headers to all responses and follow responsible operational practices for the infrastructure that hosts your school's data.
HTTPS enforced for all connections — no plain HTTP
Appropriate HTTP security headers applied
Database credentials are environment-scoped and not exposed in client code
Dependency updates and security patches applied on an ongoing basis
Responsible Handling Practices
We do not sell school data or use student information for advertising. We apply the principle of least privilege — staff see only the data relevant to their role. We are honest about what Clasra does and does not do, and we do not claim security certifications we have not obtained.
No sale of school, student, or staff data to third parties
Principle of least privilege applied across all roles
Honest disclosure — no false certification claims
Responsible disclosure process for security issues
Who Can See What — and Why It Matters
In a school, not all information is for everyone. A class teacher should see attendance and SBA for their classes — not the school’s full financial records or another teacher’s payslip. Clasra enforces this through RBAC applied at the API layer, not just in the user interface.
This means a technically capable user cannot bypass the UI and make API calls to access data outside their role. The access rules are applied server-side, every time, before any data is returned.
Role Permissions Overview
Headmaster / Principal
Full visibility — all modules, all data, all reports
Administrator
Academic structure, enrollment, fees, attendance, HR (no payroll approval)
Teacher
Own class attendance, own subjects' SBA, own timetable, messaging
Bursar / Finance Officer
Fee records, receipts, expenses, payroll processing
Parent
Own child's attendance, results, fee balance, school messages
Student
Own academic records, timetable, AI tutor, library
How Tenant Isolation Works
Request arrives
A request to the Clasra API includes an authentication session token, not a school identifier supplied by the client.
Server resolves tenant
The API server reads the authenticated session to determine which school (tenant) the user belongs to — server-side only.
Query is scoped
Every database query is filtered by the resolved tenantId. Queries cannot return data outside the authenticated tenant scope.
No cross-tenant access
Even if a user tried to request data for a different school by manipulating parameters, the server-side scope prevents any cross-tenant data from being returned.
Your School’s Data Stays Within Your School
Clasra serves many schools on the same platform infrastructure. The mechanism that keeps each school’s data private from every other school is called tenant isolation — and it is enforced at the data access layer, not just through user interface controls.
Every piece of data in Clasra — every student record, attendance log, fee transaction, staff profile — is tagged with the tenantId of the school it belongs to. When the API processes any request, it first resolves the school from the authenticated session, then adds the tenantId filter to every query automatically.
This is not a UI guard that can be bypassed. It is applied at the server level before any query runs against the database.
School Portals Are Not Searchable by Google
Every authenticated page in Clasra — the school dashboard, the student portal, the parent portal, the teacher view, the HR section — carries an explicit instruction to search engines not to index or follow that page. This is enforced through Next.js metadata on every private route.
This means a school’s login URL, dashboard structure, or any information within the authenticated portion of Clasra will not appear in Google search results. Public marketing pages (including this page) are intentionally indexed so schools can find information about Clasra — but operational pages are kept private.
What Clasra Does Not (Yet) Do
We believe schools deserve accurate information, not reassuring marketing. Here is what we are honest about.
No external audit certifications (yet)
Clasra has not yet undergone formal third-party security audits such as ISO 27001 or SOC 2. We apply strong operational security practices and intend to pursue formal certification as the platform matures. We will say so plainly rather than display badges we have not earned.
No government data-residency commitment
We do not currently make specific data residency commitments regarding Ghana's data protection regulations. Schools with regulatory requirements in this area should ask us directly about our current infrastructure so they can make an informed decision.
We are not the only layer of security
Clasra provides strong platform-level controls, but security at a school also depends on how staff handle their own credentials, how devices are managed, and how login details are shared. We provide the tools — schools must apply responsible practices.
Found a Security Issue? Tell Us Privately.
If you discover a security vulnerability in Clasra, we ask that you report it to us directly and responsibly before making it public. This gives us the opportunity to fix the issue and protect the schools that rely on our platform.
We will acknowledge security reports promptly, investigate them seriously, and communicate clearly about timelines for resolution. We do not pursue legal action against good-faith security researchers.
Report a vulnerabilityPrompt acknowledgement of reports
Serious investigation of all security reports
Clear communication on fix timelines
No legal action against good-faith researchers
Coordinated disclosure before public release
Ready to See Clasra in Action?
Book a demo and talk to us about how Clasra protects your school’s data while giving your staff the tools they need.
