Data Privacy & Safeguarding
A school holds some of the most sensitive personal data an organisation can hold — about children. The School module is built so that privacy and child-safety are enforced in code, not left to good intentions: parents only see children they are proven to be responsible for, grades only become visible when a school head decides to release them, and the health and child-protection domains are walled off behind restricted permits with every read written to an audit trail. This page explains the mechanisms and the laws behind them.
The two gates that protect the whole system
Two invariants sit under every parent- and student-facing feature. They are simple to state and impossible to bypass from the outside.
A parent can only ever see a child whose guardian link has been verified. A new guardian-to-learner link starts unverified and shows nothing on the portal until a staff member with school_guardians_update verifies it. Verification is itself audited.
Grades and report cards are invisible to parents and students until a school head releases them. Draft, submitted, and approved grades never leak; only released quarterly grades reach report cards and the portals. Releasing is audited and locks the grades.
Segregated, audited sensitive domains
Two categories of data are treated as more sensitive than the rest of the module and are deliberately separated from everyday screens: learner health and child-protection / safeguarding. Each has its own restricted permission, and — because reading them is itself a privacy-relevant event — every read is recorded.
Learner health / medical
- Permission
school_health— a restricted "view" permit, typically held only by the clinic or school nurse.- Audit
- Viewing a learner health record writes a
view_healthlog at critical severity — so there is always a record of who looked, and when. - Principle
- Health information is need-to-know; it is not part of the general learner list that registrars or teachers work with.
Child protection / safeguarding
- Permission
school_child_protection(plus_create/_update) — a restricted permit for safeguarding officers only.- Separate surface
- Safeguarding cases live at
school/safeguarding, a confidential sibling of Student Support. Confidential cases never appear on the ordinary Support list, and their notes are restricted. - Guarded entry point
- The ordinary Support page shows a link into Safeguarding only to holders of
school_child_protection— everyone else never even sees the door. - Audit
- Every safeguarding case read writes a
view_safeguardinglog at critical severity. Opening a case is a logged, accountable action. - Legal basis
- RA 7610 (child protection) and RA 10627 (anti-bullying) — see the Guidance & Clinic Playbook.
view_health and
view_safeguarding are logged on every read, opening one of these cases is never
anonymous. That is a feature: it protects the child, and it protects you by proving that
access was legitimate. Only open what you have a genuine reason to open.
Portal isolation (IDOR-proof by design)
The most common way portals leak data in other systems is insecure direct object reference — accepting a record id from the URL and trusting it. The School portals do the opposite: they never take a learner id from input on a scoped read.
- Parent portal — the set of children is derived strictly from the session user through the verified guardian-link tables. There is no "child id" parameter to tamper with, so a parent can never request another family's records.
- Student portal — the learner is resolved solely from the signed-in customer account (
school_learners.user_id). If the account isn't linked to a learner, a friendly "no record" page shows — never someone else's data. - Existence is hidden — when a portal is disabled or the module is off, the page returns a 404 rather than a "forbidden", so nobody can even confirm the feature exists.
- Released-only — both portals fetch grades filtered to released status and to the current school year, so unreleased work is never exposed even to the rightful owner.
The audit trail
The School module writes a dedicated activity log for every action that carries privacy or governance weight (ordinary create/edit/delete is captured by the base activity log). These entries are the RA 10173 evidence trail — they answer "who did this sensitive thing, and when?" Review them regularly.
| Action | Component | Severity | What it records |
|---|---|---|---|
verify_guardian | school_guardians | critical | A guardian-to-learner link was verified (opens Gate 1 for a parent). |
release_grades | school_grades | critical | Grades / report cards were released to the portals (opens Gate 2, and locks the grades). |
view_health | school_learners | critical | A learner health record was viewed. |
view_safeguarding | school_support | critical | A child-protection / safeguarding case was viewed. |
approve_enrollment | school_enrollment | info | An enrollment application was approved (roster placement created). |
reject_enrollment | school_enrollment | warning | An enrollment application was rejected. |
scan_visitor | school_visitors | info | A visitor pass was scanned at the gate. |
export | school_reports | info | A school report / compliance export was generated. |
update_settings | school_settings | info | School settings were changed. |
Notice that the two gates both leave a critical mark — verify_guardian
and release_grades — as do the two sensitive reads. That is intentional:
the moments where a child's data becomes visible to someone new are exactly the moments the
system records most loudly.
Statutory basis (Philippines)
| Law | What it covers | How School honours it |
|---|---|---|
| RA 10173 — Data Privacy Act | Lawful, need-to-know processing of personal (and sensitive) data. | The verified-link gate, released-only visibility, restricted sensitive domains, and the audit trail. |
| RA 7610 — Special Protection of Children Against Abuse | Protecting children from abuse and exploitation. | The confidential Safeguarding surface with its restricted permit and audited reads. |
| RA 10627 — Anti-Bullying Act | Preventing and handling bullying in schools. | Anti-bullying handled through the same confidential Safeguarding cases. |
Good-practice checklist
- Grant restricted permits sparingly. Give
school_healthonly to the clinic andschool_child_protectiononly to safeguarding officers. - Keep the grade gate split.
school_grade_releaseandschool_grade_approvemust be different people — see Grading Engine. - Verify before you share. Only verify a guardian link once you are sure the person is responsible for that learner — it opens portal access permanently.
- Release deliberately. Releasing grades makes them visible and locks them; confirm the class record is correct first.
- Review the audit log. Periodically check the critical-severity entries (verify, release, view_health, view_safeguarding) for anything unexpected.
- Handle exports responsibly. The masterlist CSV contains learner PII — it is gated by
school_export, audited, and marked internal-only. See Reports & DepEd Compliance.