Drop Guard

Effective date: September 29, 2026

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, optional birthday, 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, optional demographic/family background fields (economic status, address, barangay/city — encrypted at rest where configured), 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 (unexcused) absences, subject-level missing attendance ratios, daily homework/assignment submission marks, and related fields stored in performance and grading tables.
Risk analytics: risk score/probability and risk level (Low/Moderate/High/Resolved), including risk history generated by the ML component and automated de-escalation outcomes.
Intervention and case data: structured counselor interventions (category, case status across quarters, progress notes), legacy counselor notes, parental engagement metrics (GPTA/PTA/teacher summons), guidance referral history, behavior/discipline logs, 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

Certain guidance and student welfare records processed within Drop Guard—specifically health-related concern flags, individual disciplinary logs, family economic vulnerability markers, and confidential counseling notes—constitute Sensitive Personal Information under Section 3(l) of Republic Act No. 10173. Access to these fields is strictly restricted to authorized Guidance Counselors and Administrators under role-based permissions solely for legitimate educational intervention.

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.
Academic recognition: to identify learners eligible for quarterly Academic Excellence Awards under DepEd Order No. 36, s. 2016 and for school recognition (Academic Achiever, Most Improved), using only finalized subject grades.
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.
Academic performance calculations are aligned with the classroom assessment guidelines of DepEd Order No. 8, s. 2015 in their grading structure and passing standard: subject grades are expressed on a 0–100 scale using the component weights configured by the subject teacher (e.g., quizzes, exams, projects, assignments), 75 is the minimum passing grade, and the general average is the mean of finalized subject grades for the quarter (Junior High) or semester (Senior High). When the school enables DepEd transmutation (the default), subject grades computed from teacher-weighted component scores are converted with the transmutation table of DepEd Order No. 8, s. 2015, and 75 is the minimum passing transmuted grade; grades that are already final ratings (e.g., imported or scanned permanent records) are recorded as given. Teachers should configure component weights consistent with the Order and institutional policy.
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.
Honor lists are visible to counselors and administrators, and to teachers only for students assigned to them; honor-roll exports are recorded in the audit log.
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.

This notice is provided for transparency and privacy-by-design demonstration aligned with RA 10173. It is written to reflect the security and data practices implemented in this repository as accurately as possible; if the code changes, update this notice to match.

Effective date: September 29, 2026

These Terms & Conditions (“Terms”) govern access to and use of Drop Guard, an early warning and student-support information system. By signing in or otherwise using the system, you confirm that you have read these Terms together with the Data Privacy Notice. If you do not agree, you must not use Drop Guard.

1) Definitions and scope

System means the Drop Guard web application, including its user interface, databases, logs, and related documentation deployed for your school or organization.
We / us refers to the party operating the System (in a school deployment, typically the institution as Personal Information Controller; in an academic demonstration, the project team as specified by your instructor).
You / user means an individual who accesses the System with an authorized account (Teacher, Counselor, or Admin).
The System is intended for authorized school personnel only, not for students as end users or for the general public.

2) Eligibility and accounts

Accounts are created and managed by an Administrator or as otherwise defined by your institution.
You must provide accurate information when using profile or request forms and keep your credentials confidential.
You may not share your password, allow others to use your session, or attempt to access areas outside your assigned role.
We may suspend or revoke access where there is suspected misuse, policy violation, inactive employment, or as required by the school.

3) Acceptable use

Use the System only for legitimate educational and student-support purposes aligned with your duties.
Encode accurate, relevant data and update records when appropriate. Follow data minimization: enter only what is necessary.
Maintain confidentiality of student and colleague information. Do not disclose, copy, or export data except as authorized by policy.
Treat risk scores and analytics as decision-support only; professional judgment and school procedures remain primary.

4) Prohibited conduct

Unauthorized access, probing, or interference with the System, accounts, networks, or underlying data stores.
Circumventing security controls (including rate limits, role checks, logging, or session protections).
Uploading malware, conducting denial-of-service activity, or using automated scraping against the System without permission.
Entering false, harassing, discriminatory, or gratuitously intrusive content in notes, referrals, flags, or other fields.
Using the System in any manner that violates applicable law, school policy, or the rights of data subjects.

5) Data, ownership, and your responsibilities

Student and operational data entered into the System generally remain under the control of the deploying institution as part of its records.
You are responsible for your actions under your account, including data you submit and approvals you perform.
Backups, retention schedules, and archival practices may be defined by the institution; the academic build may use simplified defaults.

6) Third-party components

The user interface may load widely used libraries (for example, stylesheets or scripts from public CDNs) to render charts or layout. Your browser may connect to those providers according to their policies. Use of the System should follow your institution’s IT and procurement rules.

7) Intellectual property

Drop Guard branding, documentation, and custom code contributed as part of the capstone or deployment belong to their respective owners as agreed by your school or project charter. You receive a limited, non-exclusive right to use the System as authorized by your account—no reverse engineering or redistribution except as permitted in writing.

8) Disclaimers and limitation of liability

The System is provided “as is” for academic demonstration and/or institutional pilot use, without warranties of uninterrupted availability, error-free operation, or fitness for a particular purpose, to the extent permitted by law.
Outputs (including machine-learning risk indicators) are not a substitute for professional assessment, counseling, or legal advice.
To the maximum extent permitted by applicable law, the project team and, where applicable, the institution disclaim liability for indirect or consequential losses arising from use or inability to use the System, except where liability cannot be excluded by law.

9) Privacy and RA 10173

Processing of personal data is described in the Data Privacy Notice. The System is designed with privacy-by-design concepts intended to align with the Data Privacy Act of 2012 (Republic Act No. 10173), including transparency, legitimate purpose, proportionality, and security safeguards. In case of conflict between a summary and the Notice, the Notice and institutional policy prevail for your deployment.

10) Changes to these Terms

We may update these Terms to reflect features, legal requirements, or school policy. Material changes should be communicated through your administrator or posted with a revised effective date. Continued use after changes constitutes acceptance of the updated Terms, unless your institution requires a separate approval process.

11) Governing law and disputes

Unless your institution specifies otherwise, these Terms are interpreted in accordance with the laws of the Republic of the Philippines. Internal disputes should first follow your school’s grievance or administrative procedures.

12) Severability and entire agreement

If any provision is held invalid, the remainder remains in effect. These Terms, together with the Data Privacy Notice and applicable school policies, constitute the agreement between you and the operator regarding use of the System.

13) Acceptance

By authenticating and signing in to Drop Guard, you acknowledge that you have reviewed, understood, and agreed to be bound by these Terms & Conditions and the accompanying Data Privacy Notice.

For questions about institutional policies, contact your school Data Protection Officer or administration. These Terms are written to align with the Data Privacy Notice and should be read together.

Sign in