Student Data Privacy Agreement (coreDIRECTED)

This Student Data Privacy Agreement ("SDPA") forms part of the coreDIRECTED Institutional SaaS Agreement (the "Agreement") between techDIRECTED LLC, a Massachusetts limited liability company ("Provider"), and the subscribing school or institution named on the Order Form ("School"). Where this SDPA and the Agreement conflict on the handling of Student Data, this SDPA controls. Where the School's processing is subject to the GDPR or UK GDPR, the coreDIRECTED GDPR Data Processing Agreement also applies; each document is executed and attached in full, and nothing in this SDPA depends on an unattached document.

Notices. Legal notices under this SDPA go to the addresses on the Order Form and take effect on receipt; email counts as written notice. Each party names a security contact on the Order Form.

1. Definitions

1.1 "Education Records" has the meaning in 34 C.F.R. § 99.3: records directly related to a student and maintained by the School or by a party acting for the School.

1.2 "Student Data" means information, in any format, that identifies or is linked or reasonably linkable to a current or former student and that is provided to, collected by, generated through, or otherwise processed by Provider in connection with the Services, including Education Records, student-generated content, metadata associated with an identifiable student, derived data, AI prompts and outputs concerning a student, OCR and transcription text, redaction data, and all copies, modifications, and extracts. [ Counsel: confirm treatment of properly deidentified data; see Section 5.5. ]

1.3 "Security Incident" means unauthorized acquisition, access, use, disclosure, alteration, loss, or destruction of Student Data, or Provider's inability to account for it.

1.4 "Subprocessor" means a third party Provider engages to process Student Data on Provider's behalf. Third parties the School contracts directly, or directs Provider to connect (such as the School's identity, storage, or AI providers), are not Subprocessors; Section 8.4 states how they are handled.

1.5 "Authorized User", "Services", "Applicable Law", and "Eligible Student" carry the meanings given in the Agreement and, for Eligible Student, in FERPA.

2. Ownership and FERPA status

2.1 Student Data remains the property and under the control of the School at all times. Provider claims no ownership interest in it.

2.2 Where FERPA applies to the School (an educational agency or institution receiving funds under a U.S. Department of Education program), the School designates Provider a school official with a legitimate educational interest under 34 C.F.R. § 99.31(a)(1)(i)(B): Provider performs an institutional service the School would otherwise use employees for, is under the School's direct control with respect to Education Records through the Agreement, this SDPA, and the School's configuration of the Services, and uses Education Records only for the purposes of the disclosure and consistent with 34 C.F.R. § 99.33(a).

2.3 Where FERPA does not apply to the School (including most private schools and non-U.S. institutions), every protection in this SDPA still applies as a matter of contract; only the regulatory designation in Section 2.2 is inoperative.

3. School responsibilities

The School represents and agrees that it: (a) has the authority to provide the Student Data it processes through the Services; (b) where FERPA applies, includes its school-official criteria in its annual FERPA notification and has determined Provider meets them; (c) manages its Authorized Users and their roles, and notifies Provider promptly of compromised accounts; (d) gives lawful instructions and obtains any notices or consents Applicable Law requires of it; (e) decides which optional integrations to enable (identity, storage, AI) and configures retention inside the Services; and (f) directs Provider's handling of parent and student requests under Section 6. Nothing in this Section makes the School responsible for Provider's own obligations.

4. Use and disclosure limits

4.1 Provider uses Student Data only to provide, maintain, support, and secure the Services, and for no other purpose.

4.2 Provider does not sell Student Data, use it for targeted advertising, or build a profile of any student except in support of the School's authorized purposes.

4.3 Provider does not disclose Student Data except: (a) to Subprocessors under Section 8; (b) to third parties the School has contracted or directed under Section 8.4; (c) at the School's instruction; or (d) where required by law, with prior notice to the School unless legally barred, so the School may seek protective measures.

5. AI processing

5.1 Provider does not use Student Data, or any School data, to train, fine-tune, evaluate, or benchmark any model, to improve any provider's models or services, or to build embeddings or datasets for any purpose beyond providing the Services to the School.

5.2 AI prompts, uploaded images, OCR text, and AI outputs concerning students are Student Data under this SDPA.

5.3 AI features run only where the School enables them. Where the School supplies its own AI provider account, that provider is a School-directed third party under Section 8.4: Provider transmits only what the feature requires, and the School's contract with that provider governs its retention and use. [ Decision: whether the Services enforce an approved-provider list or require School attestation of no-training terms; vendor retention/training/location confirmations are being collected per docs/ai-vendor-retention-request.md. ]

5.4 AI output in the Services is explanatory or suggestive only; no compliance finding, disclosure, redaction, or deletion is executed by a machine without a human decision (the Rider states this architecture in full).

5.5 Provider may use aggregate operational statistics that do not identify a student or the School to operate the Services. [ Counsel: confirm this deidentified-data carve-out and its standard. ]

6. Parent and eligible-student rights

Taking into account the nature of the Services, Provider assists the School in responding to requests from parents and Eligible Students to inspect, review, and seek amendment of Education Records (34 C.F.R. §§ 99.10 through 99.22 where FERPA applies), including through the Services' export, subject-access, and disclosure tooling. If a parent or student contacts Provider directly, Provider forwards the request to the School without undue delay and responds only on the School's instruction.

7. Children under 13 (COPPA)

Where the Services process personal information of children under 13 collected online, the COPPA Compliance Addendum applies and is executed with this SDPA. Its allocation in summary: the School may authorize collection strictly for the educational context; Provider gives the School full notice of its collection, use, and disclosure practices; the School (for parents) may review, delete, and stop further collection; Provider limits use to the school-authorized educational purpose and never uses children's data commercially. [ Decision for the Addendum: whether students under 13 interact with the Services directly at any customer; the answer scopes the Addendum. ]

8. Subprocessors and third parties

8.1 The School authorizes the Subprocessors in Annex 2. Provider gives at least thirty (30) days' written notice before adding or replacing a Subprocessor.

8.2 If the School objects on reasonable data-protection grounds within the notice period, the parties confer; if the objection is not resolved, the School may terminate the affected Services and receive a pro-rata refund of prepaid fees for them.

8.3 Provider binds every Subprocessor in writing to obligations no less protective than this SDPA and remains fully responsible for each Subprocessor's performance.

8.4 School-directed third parties (the School's identity provider, the School's cloud storage the Services write to, the School's AI provider): Provider connects them only at the School's direction, transmits only what the integration requires, and is not responsible for their independent processing; the School's own contracts govern them. Annex 2 lists the categories.

9. Personnel

Provider limits access to Student Data to personnel who need it to operate, support, or secure the Services; binds them to confidentiality; trains them in security and privacy; logs privileged access; and revokes access promptly on role change or departure. Support access to a School's tenant beyond routine operations occurs with the School's authorization.

10. Security

10.1 Provider implements and maintains the technical and organisational measures in Annex 3 and reviews them as technology and threats evolve. Provider may update Annex 3 with measures that are equivalent or stronger; no update may materially reduce the protection of Student Data.

10.2 [ Counsel packet, not contract text: the 2026 exposure-incident brief and current remediation status accompany this draft for review before any warranty is approved. ]

11. Security Incidents

11.1 Provider notifies the School without undue delay, and in any event within [ 48 ] hours, after becoming aware of a Security Incident. Initial notice is not delayed until all facts are known; Provider provides rolling updates as the investigation proceeds.

11.2 The notice describes, to the extent then known, the nature and scope of the incident, the data and students affected, measures taken or proposed, and a contact point. Provider preserves relevant evidence, investigates, and provides the facts the School reasonably needs for its own legally required notifications. Costs, credit monitoring, forensic reports, and regulatory cooperation are governed by the Agreement [ counsel: confirm the Agreement addresses them; otherwise address here ]. Notification is not an admission of fault.

12. Export, retention, return, and deletion

12.1 Export. The School may export its data in open formats using the Services' export tooling at any time, without Provider's involvement, for all data covered by the Services' export registry. [ Known gap being closed: certain legacy tables (including legacy staff, student roster, and restraint records) lack a safe per-school mapping and are excluded from automated export until remapped; the registry reports them rather than hiding them. Target: close before execution, or attach the exclusion list as a schedule. ]

12.2 During the term, retention clocks the School configures inside the Services govern disposition of archived records.

12.3 On termination, at the School's choice Provider returns or deletes Student Data, by layer: (a) live systems: within [ 60 ] days; (b) Service-generated export archives: deleted on delivery to the School's storage, with a seven (7) day download window for direct downloads; (c) temporary files and caches: on their normal short cycles; (d) logs: per Annex 3's log retention; (e) host-level disaster-recovery backups: age out on the hosting provider's documented cycle of [ pending written confirmation from the hosting provider; request sent August 2026 ], during which residual copies are isolated and not actively processed, and, if a backup is restored, Provider promptly reapplies previously recorded deletion instructions so that deleted Student Data is not returned to active use; (f) data in the School's own storage (Drive, OneDrive) and at School-directed third parties: under the School's control and contracts. If the School makes no election within [ 30 ] days of termination, Provider deletes per this Section. Provider certifies completed deletion in writing. Deletion obligations yield to legal holds and retention required by law, in which case the retained data is isolated, protected, and processed for no other purpose.

13. Audits

Provider makes available the information reasonably necessary to demonstrate compliance with this SDPA, including the Services' own documentation of tenant isolation, access control, and disclosure logging. The School, or an independent auditor it mandates that is not Provider's competitor, may audit compliance once per year on thirty (30) days' notice, during business hours, without disrupting other customers, under confidentiality; findings are shared with Provider.

14. Surveys and special-education records

Provider does not determine the content of School surveys or assessments, does not use responses for its own purposes, and does not administer Provider-created marketing research. Where the School uses the Services for activity covered by the Protection of Pupil Rights Amendment, Provider supports the School's configured notice and consent requirements. Where the Services hold special-education or IEP-related records, Provider processes them only as this SDPA allows and counsel will confirm any IDEA confidentiality supplement the School requires.

15. State-law supplement

Where a state student-privacy statute imposes additional requirements on the School, the parties execute the applicable state exhibit. [ Program decision: identify initial target states and prepare approved exhibits in advance rather than negotiating per deal. ]

16. Assignment and change of control

Provider does not assign this SDPA except to a successor to substantially all of its business that assumes it in writing; Provider notifies the School of a change of control, and the School may terminate and take export and deletion under Section 12 if the successor does not assume these obligations.

17. Term, precedence, survival

This SDPA runs for the term of the Agreement and survives for as long as Provider holds Student Data. Sections 2.1, 4, 5, 9, 11, and 12 survive in full. Liability, indemnification, insurance, governing law, and dispute terms follow the Agreement; this SDPA controls only the handling of Student Data.

Signatures. Executed by authorized signatories of Provider and the School on the dates on the Order Form. [ Signature blocks per execution package. ]

*Procurement note (outside the operative agreement): public-school customers may require execution of the applicable SDPC National Data Privacy Agreement and state-alliance exhibits. This SDPA does not replace those instruments.*

Annex 1 — Description of Processing (module schedule)

Data subjects: current and former students, parents and guardians, staff, governors, and third parties appearing in school records. Sensitive categories that may occur: health and counseling, behavioral and disciplinary, restraint and safeguarding, special-education, and any category present in archived historical documents; the Services' redaction, access-tier, and disclosure controls exist for this material. Locations: hosting per Annex 2; remote access by Provider personnel from the United States. Duration: the Agreement term plus Section 12's windows.

[ Per-customer completion at signature: which modules and integrations are enabled; whether students hold accounts; whether AI is enabled and with whose keys. ]

Annex 2 — Subprocessors and third-party categories (VERIFY BEFORE EXECUTION)

Subprocessors (engaged by Provider):

School-directed third parties (Section 8.4, not Subprocessors): the School's identity provider (Google Workspace or Microsoft), the School's cloud storage the Services write archives and exports to (Google Drive or OneDrive), the School's SMTP where configured, and the School's AI provider(s) where enabled (keys held encrypted per Annex 3; transmission limited to the enabled feature).

*Register note: the previous entry naming Hetzner as the production host was unverified and is withdrawn; Hetzner hosts a separate integrated security-awareness service (Darren's platform) and appears in this Annex only if that service processes Student Data under this Agreement.*

Annex 3 — Technical and Organisational Measures

• Tenant isolation: registry-driven school scoping on tenant-scoped reads, enforced for new code by a fail-closed fetch path and verified by automated gates that must pass before deployment; per-school export and erasure walks demonstrate coverage. Known legacy exceptions are tracked in the same registry and are being remapped (Annex 12.1 note).
• Access control: role-based access with per-school feature gating; SSO support; a small, named administrative set; privileged actions logged. [ Confirm and state MFA for privileged/production access. ]
• Sessions and credentials: salted one-way password hashing; secure, HttpOnly, SameSite session cookies with rotation; server-side revocation.
• Secrets: specified sensitive integration credentials are stored encrypted (AES-256-GCM: finance integration credentials, redaction OCR keys). [ Program item before signature: extend at-rest encryption to school AI keys and SMTP credentials, or state their storage precisely. ]
• Data-protection tooling: verified destructive redaction with OCR re-read proof, tiered reading-room access, disclosure registers, retention clocks with review states.
• Transport and storage: TLS in transit; storage protections per the hosting environment in Annex 2.
• Availability: scheduled backups with restore tooling; school-run full export to the School's own storage at any time.
• Development and operations: guarded deployment (isolation gates and checks precede deploys); vulnerability remediation and patching on the platform's maintenance cycle; file-upload controls in the archive pipeline. [ State malware-scanning position accurately before signature. ]
• Incident response: per Section 11, with named contacts and evidence preservation.
• Disposal: per Section 12, including restoration re-deletion.