HallPal Student Data Agreement

Suggested public route: /legal/student-data-agreement Effective: {{EFFECTIVE_DATE}} Last updated: 2026-08-08

Overview

This document sets out {{COMPANY_LEGAL_NAME}}'s (HallPal) commitments to school districts and independent schools ("LEAs" — Local Education Agencies) regarding the collection, use, protection, and deletion of student data. It supplements our Privacy Policy and our Terms of Service, both of which are incorporated here by reference.

This document is structured to align with the SDPC National Data Privacy Agreement (NDPA) version 1.0r5 so districts that require NDPA signing can complete only the district-specific Exhibit A + rely on this document for Sections 3–7. HallPal will countersign a completed NDPA on request; the countersigned version is the operative contract for that district.

1. HallPal's role under FERPA

When HallPal is used inside a US K-12 school under a contract with the school or LEA, HallPal operates as a "school official" with a legitimate educational interest under the US Family Educational Rights and Privacy Act (FERPA), 34 C.F.R. § 99.31(a)(1)(i)(B). The LEA:

• Retains direct control over the use + maintenance of student education records HallPal stores on its behalf.
• Provides HallPal only the information HallPal needs to perform the contracted service.
• Retains all rights that FERPA gives to LEAs, parents, and eligible students.

HallPal:

• Will not use student data for any purpose beyond providing the contracted service.
• Will not disclose student data to third parties except to subprocessors listed in SUBPROCESSORS.md and in accordance with §5 below.
• Will honour LEA-initiated requests to access, correct, or delete student records within the timelines in §7.

2. HallPal's role under other US student-privacy laws

For LEAs in states with their own student-privacy laws, HallPal's commitments in this document combine with the state-specific commitments in STATE_PRIVACY_RIDERS.md. Where a state's law imposes a stricter requirement than this document, the state's law controls.

3. Data elements collected

HallPal collects the following data about students:

3.1 Directory-type information

• Student's first name + last name
• School-assigned student ID (numeric)
• Grade year
• Classroom / period assignments

3.2 Activity information

• Hallpass records: which student left, from which classroom, at what time, when they returned, optional destination
• Homebase Test-RFID pairing events: card UID paired to student ID, paired-at timestamp, last-tapped timestamp

3.3 What HallPal does NOT collect about students

• Free-text notes, comments, or narrative fields about a student
• Health, medical, or behavioural information (destination selections such as "Nurse" surface only the destination name, no student-specific health data)
• Financial or family information
• Contact information beyond the school-assigned student ID
• Persistent advertising identifiers, geolocation, device fingerprints
• Biometrics (fingerprints, facial-recognition data, voice prints, etc.)
• Non-directory-type PII beyond what is in §3.1

If an LEA's use pattern would require HallPal to collect data not listed here (e.g. a district wants a "reason for pass" field), that collection requires a written amendment to the operative agreement + appropriate updates to this document + the Privacy Policy.

4. Purposes of use

HallPal uses student data only to:

• Provide the hallpass management service (open + close hallpass records, authenticate the correct student at the kiosk, auto-fill on NFC card tap).
• Render analytics + reports about hallpass use to LEA-authorized administrators + teachers.
• Detect + respond to security incidents.
• Maintain an audit trail of administrative actions.
• Debug + improve the service using aggregate, non-identifiable metrics (e.g. "how many kiosk taps per school per day"). Student personally-identifiable information (PII) is never used for product improvement.

HallPal will not:

• Use student data to build a profile of any student except in furtherance of the service.
• Sell student data.
• Use student data for targeted advertising.
• Use student data to train any machine learning model, whether ours or a third party's. (This is a contractual + technical commitment; see PRIVACY.md §6 for the specific arrangement with our AI subprocessor Anthropic.)

5. Sharing + subprocessors

HallPal shares student data only with:

• The LEA that provided the data + its authorized users (administrators, teachers) as controlled by the LEA's configuration.
• Subprocessors listed in SUBPROCESSORS.md, each of which is bound by contract to data-protection terms substantively equivalent to this agreement.
• As required by law (subpoena, court order, or written LEA authorization). HallPal will notify the LEA in advance of any legally-compelled disclosure unless legally prohibited from doing so.

HallPal maintains a machine-readable subprocessor list, provides at least 30 days' advance notice of any material subprocessor change, and offers LEAs an email subscription for change notifications. See SUBPROCESSORS.md for the current list + subscription instructions.

6. Data retention + deletion

6.1 Retention

• Roster + configuration data: retained for the duration of the LEA's contract with HallPal.
• Hallpass records: retained per the LEA's configured retention policy. The LEA chooses the window; where none is configured, records are retained until the LEA sets one or the Agreement terminates.
• Audit-log entries: retained for the life of the Agreement. HallPal does not currently expire audit entries.
• Device telemetry (heartbeats, health data): rolling 90-day window.
• Chat transcripts (if the AI assistant is enabled): rolling {{CHAT_RETENTION_DAYS}}-day window.
• Backups: rolling {{BACKUP_RETENTION_DAYS}}-day encrypted offsite backups.

6.2 Deletion on contract termination

Within {{POST_TERM_DELETION_DAYS}} days of contract termination, HallPal will:

1. Make the LEA's student data available for export in a machine-readable format for {{POST_TERM_EXPORT_WINDOW_DAYS}} days.
2. Permanently delete student data from live systems.
3. Purge student data from backups on the next scheduled backup- rotation cycle (up to {{BACKUP_RETENTION_DAYS}} additional days).
4. Provide the LEA with a written Certificate of Destruction attesting to the deletion, signed by an authorized HallPal officer. A template is available at CERTIFICATE_OF_DESTRUCTION.md.

The LEA may request accelerated deletion at any time (before termination or during the export window) by writing to privacy@hallpal.divz.io.

6.3 Deletion on individual student request

Where FERPA or the LEA's policy grants a parent or eligible student the right to have specific records amended or deleted, the LEA can initiate the request through HallPal's admin UI or by writing to privacy@hallpal.divz.io. HallPal will complete the deletion in live systems within 30 days + purge from backups on the next rotation.

7. Parent + eligible-student rights

Parents (and eligible students) have the following rights under FERPA, which HallPal supports the LEA in fulfilling:

• Access. Right to inspect the student's records HallPal maintains. Requests must be made to the LEA; HallPal will produce a copy within 15 days of LEA authorization.
• Amendment. Right to request correction of inaccurate records. Directed to the LEA; HallPal will apply LEA-authorized corrections within 5 business days.
• Consent to disclosure. Right to consent (or refuse) to disclosure to third parties beyond FERPA's exceptions. HallPal discloses only per §5.
• Complaint. Right to file a complaint with the US Department of Education's Family Policy Compliance Office if the LEA is believed to be out of FERPA compliance.

8. Security

HallPal maintains the following security safeguards (see PRIVACY.md §12 for the full list):

• All data in transit encrypted with TLS 1.2+ (HSTS enforced with 1-year preload).
• All data at rest encrypted at the storage layer.
• All authentication tokens rotated automatically; sessions expire after 120 minutes of inactivity.
• Row-Level Security enforced at the database layer so a request can only reach data the requester's LEA allows.
• Every administrative mutation writes an immutable audit-log entry.
• Rate limiting on every sensitive route to blunt credential-stuffing
  • brute-force.
• Content-Security-Policy + a suite of related security headers on every response.
• Regular automated + manual security + accessibility testing.
• Subprocessors are subject to security-review before onboarding + are re-reviewed at least annually.

HallPal is progressing toward SOC 2 Type II attestation on the following timeline: {{SOC2_MILESTONE_TIMELINE}}.

9. Data breach notification

If a Security Incident affecting student data occurs — meaning the unauthorized access, acquisition, use, disclosure, modification, or destruction of student data — HallPal will:

1. Detection + initial notice. Notify the LEA within 72 hours of confirmed detection. The initial notice will describe the nature of the incident, the categories + approximate number of records affected, HallPal's initial containment steps, and the contact point for follow-up.
2. Ongoing updates. Provide updates as new information becomes available.
3. Written incident report. Deliver a written incident report to the LEA within 30 days of initial notice. The report will include the root cause, the full scope of records affected, actions taken to contain + remediate, and measures adopted to prevent recurrence.
4. Notification to affected individuals. HallPal will cooperate with the LEA in preparing notifications to affected parents, eligible students, or other affected individuals. Where state law requires notification within a specific window (e.g. Connecticut's 30 days, Colorado's 30 days), the LEA is the primary notifier + HallPal supports.
5. Regulatory notification. Where required by law (e.g. state AG notification, ED notification for certain incidents), the LEA is the primary notifier + HallPal supports.
6. Cost. HallPal bears its own costs of investigation + remediation. Costs of LEA-initiated notifications are addressed in the master agreement's indemnification section.

10. Access + audit

The LEA has the right to:

• Request evidence of HallPal's compliance with this document at reasonable intervals (typically annual).
• Request the current SOC 2 report + any current third-party security audits under NDA.
• Request evidence of subprocessor compliance monitoring.

For material contract renewals, HallPal will provide a written compliance attestation on request.

11. Modifications

HallPal may update this document from time to time. Material updates (e.g. adding a data category, adding a subprocessor, changing a retention window in a way that reduces LEA control) require:

• Advance written notice to the LEA at least 30 days before the change takes effect.
• Opportunity for the LEA to object; if the LEA reasonably objects and HallPal + LEA cannot resolve the objection within 30 days, the LEA may terminate the contract without penalty + HallPal will proceed to deletion under §6.2.

Non-material updates (e.g. tightening a commitment in the LEA's favour, correcting a typo, adding a new state-specific rider) take effect on posting.

12. Contact

Student data / privacy questions: privacy@hallpal.divz.io Legal + contracting: legal@hallpal.divz.io Security: security@hallpal.divz.io Postal: {{COMPANY_ADDRESS}} Company registration: {{COMPANY_LEGAL_NAME}}, {{COMPANY_JURISDICTION}}

Appendix A — Certificate of Destruction template

See CERTIFICATE_OF_DESTRUCTION.md.