This Data Privacy Notice explains what personal data Drop Guard collects, why it is collected, how it is used,
and the rights you have as a data subject. Drop Guard is an academic system project designed to support early
warning and intervention workflows for students.
1) Personal data we collect
- User account data: username, full name, role (Teacher/Counselor/Admin), email (optional), contact number (optional), account status, and password hash.
- Student profile data: student name, grade level, strand (where applicable), section, LRN (optional), optional face photo path for identification, school-year batch assignments, overall GPA/absences/risk fields on the master record, and an archived flag when a profile is kept for history but excluded from active workflows.
- Student performance and attendance: quarterly GPA/grades proxy, days present, total school days, absences, consecutive absences (and related fields stored in performance and grading tables).
- Risk analytics: risk score/probability and risk level (Low/Moderate/High), including risk history generated by the ML component.
- Intervention and case data: counselor notes, case status, teacher referrals, and issue flags (e.g., Health/Financial/Behavioral).
- Security and audit data: login attempt records (username, IP, success flag, truncated user agent, timestamp), audit logs (action, status, target, description, optional JSON details, IP, user agent), and session identifiers stored server-side.
2) Sensitive personal information
Drop Guard does not require sensitive personal information to function by default. However, some entries may
become sensitive personal information depending on what is written in notes or flags (e.g., health-related
concerns, financial hardship, family issues). Users should only encode what is necessary for legitimate student
support purposes.
3) Why we collect data (legitimate purpose)
- Account data: to authenticate users, assign role-based access, and secure the system.
- Student and performance data: to identify at-risk students and support school-level monitoring.
- Risk analytics: to generate early warning indicators and trends for decision support.
- Interventions and referrals: to document actions taken and improve student support continuity.
- Audit and security data: to detect misuse, investigate incidents, and maintain accountability.
4) How we use and process the data
- Data is encoded through the system UI and stored in a MySQL database.
- Risk scores and risk levels are generated using a Python-based ML module using performance/attendance inputs.
- Authorized users view dashboards, student profiles, and reports based on their role and, for teachers, assigned class visibility (students linked to the teacher in the system).
- Counselors and administrators typically have broader roster access consistent with school duties; exact rules follow your institution’s policy.
- Archived student profiles remain stored but are excluded from active lists, dashboards, and many workflows until restored by authorized staff.
- Security logs are recorded for authentication attempts and significant actions.
5) Who controls the data (Personal Information Controller)
For this academic project, the Personal Information Controller (PIC) is the system owner/operator
(the school office/administrator in a real deployment; for class submission, the project team acts as the PIC for demonstration).
6) Data retention
Policy intent (real deployments). Your institution may adopt retention rules such as: keeping user accounts while active
(with deactivated accounts retained for accountability); keeping student academic/risk history for the active school year and a limited number of additional years for trend analysis;
and keeping security/audit data for a bounded period for investigations. The periods in any school policy should be documented by your PIC/DPO.
- Important—what the software does today: This build does not automatically delete or anonymize rows when a calendar retention period elapses.
Audit logs, login-attempt records, and student data remain in the database until an administrator (or a future automated job defined by your institution) removes or archives them.
Applying retention in production normally requires scheduled maintenance, backups, and legal review.
- Student archiving is a soft status: records are hidden from routine operational views but not erased.
- Account deactivation blocks sign-in; underlying user rows may remain for audit purposes unless your process deletes them.
7) Security measures (as implemented in this project)
The following technical measures are part of the current codebase. They support—but do not replace—organizational policies, training, and infrastructure choices (e.g., HTTPS, database hardening, backups).
- Password security: passwords are verified with PHP’s
password_verify against stored hashes (not plain text).
- Session security: server-side session files; session cookie HttpOnly and SameSite=Lax; strict session mode; session ID regeneration on successful login; optional Secure cookie flag when the site is served over HTTPS.
- Session timeout and binding: sessions end after a period of inactivity (implemented as roughly two hours without requests); the session is also tied to a browser fingerprint derived from the User-Agent to reduce simple session hijack—if the fingerprint no longer matches, the session is invalidated.
- Single active session: each account allows only one concurrent sign-in. Signing in from another browser or device invalidates the previous session.
- Access control: role-based restrictions on pages and actions (Teacher/Counselor/Admin), including teacher-scoped visibility where coded.
- Brute-force protection: failed login attempts are recorded; repeated failures trigger temporary lockouts with progressive delay (per username/IP window).
- CSRF mitigation: state-changing forms use server-issued CSRF tokens validated on POST.
- Audit logging: many significant events (logins, logouts, data changes, denials, etc.) are written to an audit table with contextual metadata where implemented.
- HTTP security headers (baseline): routed pages set headers such as X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, and a restrictive Permissions-Policy for camera/microphone/geolocation.
- Optional application-layer encryption: when a symmetric key is configured, selected text fields (for example parts of notes, audit descriptions, or JSON detail payloads) may be encrypted before storage using libsodium. Student names and LRN remain in plain form in the database in this design so search and uniqueness constraints work; institutions may add database or disk encryption separately.
Vulnerability management, penetration testing, SIEM, and DLP are not built into this academic project; plan them for production.
8) Your rights as a data subject
Under the Data Privacy Act of 2012 (RA 10173), you have the following rights, subject to lawful limitations and institutional process:
- Right to be informed: know what data is collected and why.
- Right to access: request access to your personal data stored in the system.
- Right to correction: request correction of inaccurate or incomplete data.
- Right to erasure or blocking: request deletion or blocking when allowed by law and when no longer necessary for legitimate purposes.
- Right to data portability: request a copy of your data in a usable format when applicable.
How this maps to the app: Staff users can update parts of their profile in the UI; broader requests (export, erasure, blocking) are expected to go through your
school administrator or Data Protection Officer. The system does not currently provide a fully automated self-service portal for every data-subject right for every category of data.
9) How to contact us
For privacy concerns, questions, or requests related to your data rights, contact the system owner/operator
through your school administrator or the project team representative. If you are deploying this system in a real environment,
provide an official email address and office contact details here.