Trust & POPIA
This page sets out how MySentinel protects learner and guardian personal information, and how it meets the Protection of Personal Information Act (POPIA). It is written for the principal, IT lead, or legal advisor who vets a platform before it touches learner data — plainly, and honest about what is shipped versus what is on the roadmap.
Roles: who is responsible for what
Your school is the responsible party for its learners’ and guardians’ personal information. MySentinel acts as the operator — it processes that information only to run the service on your behalf and on your instructions. That relationship is the backbone of everything below.
Tenant isolation — one school can never see another
Every school’s data is walled off from every other school’s. A user authenticated to one school cannot read another school’s learners, guardians, or records. The school you belong to is taken from your verified login, never from anything a browser can change — so a signed-in user cannot pivot to another school by editing a request. This closes the most common multi-tenant data-leak class by construction.
Role-based access, with passkey step-up
Every action is checked against the role that is allowed to perform it, on the server — the app can hide a button, but the front end is never the security boundary. The four everyday roles each see only their authorised surface, and a class teacher is further scoped to only their assigned classes.
Sensitive, irreversible, or credential-changing actions require a passkey step-up — a fresh fingerprint or face check on top of the session, not a second login. This gates safety drills and lockdown, POPIA subject-access, correction and erasure, school and channel configuration, roster import commits, staff invitations, and session revocation, among others. Recovery is real: if a staff member loses their device, an operator can reset their passkeys — itself an audited, step-up-gated action — and they sign in and re-enrol.
Encryption at rest
Learner photos and guardian and visitor contact details are encrypted at rest, each school under its own key. Because a school’s sensitive data is sealed under that school’s own key, destroying the key renders every sealed record for that school permanently unreadable — a fast, complete erasure primitive for POPIA. The same protection covers each school’s messaging-provider credentials, which are never returned by any read path.
The append-only audit trail
Every security-relevant action writes an immutable audit event: sign-ins (success and failure, with the email hashed, never stored in clear), learner and guardian record changes, gate records, emergency drafts and confirmed sends, operator actions, and the POPIA workflows. Records can be added but never edited — the only sanctioned way anything leaves the trail is the audited retention-purge path below. Audit rows never store plaintext phone numbers, emails, passwords, or provider secrets; contact-shaped values are stripped from the metadata.
POPIA data-subject rights
MySentinel implements the data-subject participation rights POPIA grants:
- Right of access. A subject-access request assembles everything held about a subject, as a step-up-gated admin action, ready to export.
- Right to correction. Records can be corrected through the same first-class, audited flow.
- Right to erasure. Erasure runs as a durable job with a mandatory cool-off period, then cascades across every store that holds a copy of the subject’s personal information — identity, gate history, inbound parent messages, visitor records, and notification subscriptions. The request is marked complete only if every part succeeds; a partial failure leaves it re-runnable and audited, and a cancellation requested during the cool-off is honoured. Unsupported cases fail closed — they never falsely report completion while data still exists.
Retention and minimisation
Each school has a retention policy that is enforced, not just displayed: the oldest data past each cutoff is archived to cold storage and then deleted, in a batched, audited pass. Typical defaults:
| Data | Kept for |
|---|---|
| Gate records and audit history | About 7 years |
| Notification delivery logs | 90 days |
| Parent messages | 1 year |
| Visitor records | About 7 years |
The append-only trails keep their no-edit guarantee; retention is the one sanctioned deletion path, and it archives before it deletes.
Breach posture
Personal information is minimised throughout: identifiers are hashed in logs, contact details and photos are encrypted at rest, and no plaintext contact PII is written to the audit trail. On a suspected compromise, MySentinel notifies the responsible party and follows the POPIA breach-notification obligations to the Information Regulator and affected data subjects.
Honest about the roadmap
- A group-owner login — a single view scoped to only your campuses — is on the roadmap. Today, group-wide oversight runs through the MySentinel team; each campus is fully protected and isolated in the meantime.
- SMS is the one channel a school activates by connecting its own provider; until then, messages travel on the included channels. WhatsApp needs no such arrangement — it is included and sends from MySentinel’s own business account. See Notifications.
The bottom line
MySentinel ships the load-bearing POPIA controls — login-derived tenant isolation, server-side role checks with passkey step-up, per-school encryption at rest, an append-only audit trail, a durable erasure cascade, and enforced retention — and it names what is on the roadmap plainly. Nothing here is a hollow claim.