DPIA template — EduRegie
A Data Protection Impact Assessment is mandatory when a processing activity is likely to result in a high privacy risk (Art. 35 GDPR). For absence registration at schools this is not automatically the case, but many school boards — and their DPO (Data Protection Officer) — request one as standard because of the combination of "staff data + systematic monitoring". This template is pre-filled with EduRegie-specific answers; the school itself completes the organization-specific parts (legal basis, DPO advice, residual risk acceptance).
1. Description of the processing
Purpose: efficiently and accurately handling staff absence: reporting, timetable impact, substitution, communication and management reporting.
Data subjects: school staff (teachers, education support staff); indirectly students (solely operational timetable information, never the reason for absence).
Data processed: see article 2.3 of the data processing agreement. No special categories of personal data (no medical data, no diagnosis).
Legal basis: [to be completed by the school — usually legitimate interest (Art. 6.1.f GDPR) for business operations, or performance of the employment contract (Art. 6.1.b) for the absence registration itself; consult the school's DPO].
Retention period: in accordance with the Data Retention Policy (dataretentiebeleid.md).
2. Necessity and proportionality
- EduRegie deliberately registers a minimal data set: no diagnosis, complaints, treatment or medication (see the GDPR starting point in
avg-security.md). - Students only see neutral timetable statuses (
Class continues with [substitute],Class cancelled, etc.) — never a link to the reason for absence. - Access is role-based: only schedulers/HR/administrators see absence details; team leaders see only continuity impact; students only see timetable status.
3. Risk inventory
| Risk | Likelihood | Impact | Explanation |
|---|---|---|---|
| Unauthorized access to absence data | Low | Medium | Limited by Row Level Security per school and role-based access in the dashboard (see Security Annex) |
| Data breach at a sub-processor | Low | Medium | See Sub-processor List; sub-processors are screened for EU hosting and contractual safeguards |
| Unintended entry of medical information in free-text fields | Medium | Medium | No input field for diagnosis/complaints in the regular portal; users are instructed via UI text ("no medical information") |
| Visibility of the reason for absence to students | Low | High | Technically excluded — student communication contains only timetable status, no link to the absence case |
| Excessively long retention of historical absence data | Medium | Low | Addressed in the Data Retention Policy with concrete retention periods and an automation proposal (SF 20 - Privacy Retention) |
4. Measures
See the Security Annex for the full technical and organizational measures (RLS, MFA for sensitive roles, encryption, audit logging, least privilege).
5. Residual risk and approval
[To be completed by the school: assessment of whether the residual risks after the measures mentioned are acceptable, possibly after advice from the DPO. In case of doubt about a high residual risk, prior consultation with the Data Protection Authority is legally required (Art. 36 GDPR).]
| Assessed by (DPO/school) | |
| Date | |
| Judgment |