Security & trust
Built to hold the data schools depend on.
A school platform holds children’s records, families’ financial details and staff salaries. This page describes the mechanisms that protect them - and is honest about what still needs to be agreed with you in writing.
Access & isolation
The strongest control is data a person never receives.
Most access problems in school software come from filtering in the interface rather than in the database. Cyber Campus enforces scope where the data is read.
Tenancy in the data model
Records carry their school and campus and are filtered on every read and stamped on every write. Isolation is not a screen that hides rows - the data never leaves the database.
Campus-scoped roles
Roles belong to a campus. A campus administrator cannot view or edit another campus’s users, roles or records, even within the same school group.
Named permissions on every action
Each write action names the permission it requires, so viewing a fee report and posting to the ledger are separate grants that must be given deliberately.
Dashboard data pruned server-side
When a dashboard tile is withheld from a role, its figures are removed from the response on the server. They are never sent to that person’s browser and hidden with styling.
Real-time channels are namespaced
Live notification channels are authorised per audience and carry a per-installation prefix, so events cannot cross between schools sharing infrastructure.
Looking is not editing
When head office opens one of its branches, the whole session becomes read-only and says so on screen. Every write is refused for the duration, so a review of another campus can never turn into an accidental change to it.
Acting as another user is explicit
Support access is an impersonation session a person has to start and can leave again - not a shared password, and not a hidden back door into somebody else’s account.
Sign-in activity is logged
Logins are recorded, and staff access follows employment status so a departing staff member’s access can be closed with their record.
Financial integrity
Books that cannot be quietly rewritten.
For a school owner, the question is not only who can see the money - it is whether last year’s numbers can change after they were signed off.
Every posting is double-entry
Fees, discounts, late fees, expenses, payslips and library fines each write a balanced journal entry, so the ledger cannot silently drift from operations.
Closed years are sealed
After year-end close, model-level guards and posting middleware refuse any transaction dated into that year - with no role able to override it, head office included.
A tamper check you can run
Closing freezes a per-account snapshot, and the platform can recompute balances against it to show whether a closed year still reconciles.
Policy snapshots protect history
Late-fee policy is recorded onto each invoice when it is generated, so changing the policy later never silently re-prices past invoices.
Children & AI
The guardrails, stated as mechanisms.
Any school evaluating AI should ask what stops it going wrong, not what the vendor intends. These are the controls that exist in the product.
No public sign-up
Talko cannot be joined from the open internet. Access requires a school-issued account that the school itself created.
Scoped to the lesson
The tutor only discusses the lesson the student has open. There is no open-web browsing and no general-purpose chat.
Visible to the school
Student activity is recorded as learning evidence for the teacher. Nothing a child does with Talko is invisible to the school.
Server-side scoring and limits
Points and quiz results are computed on the server against the stored answer key, and requests are rate-limited per student with a daily AI budget.
No AI keys in the browser
All AI traffic is proxied through the school’s server. The provider key never reaches a student’s device.
Retention and erasure
The platform ships tested commands to purge child learning events on a retention schedule, and to erase an individual student’s learning record on request.
Student work is used to produce the school’s own learning reports. It is not used to train external, general-purpose AI models.
Agreed in writing
What we confirm with you before rollout.
Some assurances depend on where your school operates and how it is hosted. We would rather put these in your agreement than make a broad claim on a web page.
- Data hosting and residency - Where your school’s data is stored, and the options available in your region.
- Encryption in transit and at rest - The configuration applied to your deployment, confirmed in writing.
- Backup and recovery - Backup frequency, retention period and the recovery commitment for your plan.
- Regulatory position - The data-protection regime that applies to your school, and the terms that follow from it.
- Sub-processors - The third-party services involved in delivering the platform to you.
- Data processing agreement - A DPA covering roles, purposes, retention and deletion.
Security questionnaire, DPA request or a specific compliance question? Write to info@learningwell.pk and we will respond with documentation rather than a sales call.
Bring your IT lead to the demo.
We are happy to spend the call on access control, tenancy and data handling rather than features. Most schools find that the faster route to a decision.