Data Processing Agreement — coreDIRECTED

This Data Processing Agreement ("DPA") forms part of the coreDIRECTED Institutional SaaS Agreement (the "Agreement") between techDIRECTED LLC ("Provider", the processor) and the subscribing school or institution named on the Order Form ("School", the controller). Where this DPA and the Agreement conflict on the processing of personal data, this DPA controls. The order of precedence among the data documents is: Student Data Privacy Agreement and any state exhibit; this DPA; the COPPA Addendum; the AI Rider; then the Agreement.

Notices and contacts. Notices under this DPA (including breach notices, subprocessor changes, and data subject requests forwarded under Section 8) go to the notice and security contacts named on the Order Form; email counts as written notice on receipt.

1. Definitions, roles, and scope

1.1 "School Data" means all personal data processed by Provider on the School's behalf in connection with the service, whether submitted, collected, received through integrations, generated, or derived, including AI prompts and outputs, OCR and transcription text, audit and disclosure records concerning the School's use, classifications and recommendations, and all copies and backups. Limited account, billing, and security telemetry that Provider processes for its own legitimate purposes as an independent controller is governed by Provider's privacy policy, not this DPA.

1.2 The School is the controller of School Data; Provider processes it only as the School's processor.

1.3 This DPA applies to all processing of School Data subject to the EU General Data Protection Regulation, the UK GDPR, the Swiss nFADP, or another law requiring a written processing agreement ("Data Protection Law"), and additionally wherever the parties have agreed that Provider acts as the School's processor.

2. Instructions and use limits

2.1 Provider processes School Data only on the School's documented instructions, including instructions concerning international transfers, unless applicable law requires Provider to process the data; in that case Provider informs the School of the legal requirement before processing, unless the law prohibits that notice on important grounds of public interest.

2.2 The Agreement, this DPA, and the School's configuration and use of the service are the complete instructions at signature; additional instructions must be agreed in writing. Provider will inform the School without delay if, in Provider's opinion, an instruction violates Data Protection Law, and may suspend the affected processing until the instruction is confirmed or changed.

2.3 Provider does not sell, rent, lease, or trade School Data; does not use it for advertising or for profiling unrelated to the service; and does not use School Data, including student data, to train, fine-tune, evaluate, or benchmark any AI model or to improve any provider's models or services. No consequential decision about a person is made by solely automated processing through the service; a human decides.

3. The School's rights and obligations

The School: (a) is responsible for the lawfulness of the School Data it processes through the service, for its legal bases, and for the notices and consents Data Protection Law requires of a controller; (b) has the right to issue documented instructions, receive the compliance information described in Section 11, object to subprocessor changes under Section 6, and require return or deletion under Section 12; and (c) instructs Provider through its configuration of the service, including retention settings and enabled integrations. Nothing in this Section relieves Provider of its own statutory or contractual obligations.

4. Confidentiality of personnel

Provider ensures that every person authorized to process School Data is bound by a contractual or statutory duty of confidentiality, and that access is limited to what each person needs to operate, support, or secure the service.

5. Security

5.1 Provider implements and maintains the technical and organisational measures described in Annex 3, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as required by GDPR Article 32.

5.2 Provider may update Annex 3 with measures that are equivalent or stronger as technology and threats evolve; no update may materially reduce the protection of School Data.

6. Subprocessing

6.1 The School gives general written authorization for the subprocessors listed in Annex 2, which Provider keeps current and makes available at the service's legal index. Provider gives the School at least thirty (30) days' written notice before adding or replacing a subprocessor.

6.2 The School may object on reasonable data-protection grounds within the notice period; if the objection cannot be resolved, the School may terminate the affected service and receive a pro-rata refund of prepaid fees for it.

6.3 Provider imposes on every subprocessor, by written contract, data-protection obligations no less protective than this DPA, and remains fully liable to the School for each subprocessor's performance. Third parties the School contracts directly or directs Provider to connect (its identity provider, its cloud storage, its AI provider) are not subprocessors; Provider transmits to them only what the enabled integration requires, and the School's own contracts govern them.

7. International transfers

Provider processes School Data in the locations stated in Annex 2. Where processing involves a transfer from the EEA, the UK, or Switzerland to a country without an adequacy decision, the parties incorporate by reference, as applicable: the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, Module Two, controller to processor); the UK International Data Transfer Addendum to those clauses; and the Swiss adaptations recognized by the FDPIC. Annex 1 serves as the description of transfer; the competent supervisory authority is that of the School's establishment (for the UK, the ICO).

8. Assistance with data subject rights

Taking into account the nature of the processing, Provider assists the School with appropriate technical and organisational measures, including the service's export, subject-access, redaction, and disclosure tooling, to fulfil the School's obligation to respond to data subjects exercising their rights. If a data subject contacts Provider directly, Provider forwards the request to the School without undue delay and does not respond on the School's behalf except on instruction.

9. Assistance with compliance obligations

Provider assists the School, insofar as possible given the nature of the processing and the information available to Provider, with the School's obligations regarding security (Art. 32), breach notification (Arts. 33 and 34), data protection impact assessments (Art. 35), and prior consultation (Art. 36).

10. Personal data breach

Provider notifies the School without undue delay, and in any event within [ 48 ] hours, after becoming aware of a personal data breach affecting School Data. Initial notice is not delayed until all facts are known; Provider provides rolling updates. The notification describes, to the extent then known: the nature of the breach, the categories and approximate numbers of data subjects and records concerned, the likely consequences, the measures taken or proposed, and Provider's security contact. Provider documents breaches, preserves relevant evidence, mitigates effects, and cooperates with the School's own notification obligations. Notification is not an admission of fault.

11. Audits

11.1 Provider makes available to the School the information reasonably necessary to demonstrate compliance with this DPA and GDPR Article 28, including summaries of the tenant-isolation and security controls the service documents about itself.

11.2 The School (or an independent auditor it mandates, not a competitor of Provider) may audit Provider's compliance once per year on at least thirty (30) days' notice, during business hours, without disrupting other customers, and subject to confidentiality; findings are shared with Provider. The frequency and notice limits do not apply where an audit follows a personal data breach, reasonable evidence of material noncompliance, a supervisory authority's request, a material subprocessor or processing change, or verifies remediation, and nothing restricts an inspection required by Data Protection Law.

12. Return and deletion

12.1 The School may export School Data covered by the service's export registry in open formats at any time, without Provider's involvement. Provider will assist with the return of any remaining School Data not available through self-service tooling.

12.2 On termination, at the School's choice Provider returns or deletes School Data, by layer: live systems within [ 60 ] days; service-generated export archives on delivery to the School's storage; logs per Annex 3; host-level disaster-recovery backups on the hosting provider's documented aging cycle of [ pending the hosting provider's written confirmation ], 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 School Data is not returned to active use. If the School makes no election within [ 30 ] days, Provider deletes. Provider certifies completed deletion or return in writing on request. Deletion yields to legal holds and retention required by law, in which case the retained data is isolated, protected, and processed for no other purpose.

13. Liability, term, survival

Liability under this DPA is governed by the limitations of the Agreement, except where Data Protection Law does not permit them. This DPA runs for the term of the Agreement, and all provisions necessary to protect School Data, including Sections 2 through 12, continue for as long as Provider retains any School Data.

Annex 1 — Description of Processing

• Subject matter: provision of the coreDIRECTED compliance platform: compliance assessment and records, policy lifecycle, governed records archive, redaction and subject-access fulfilment, retention scheduling, and training and readiness modules.
• Duration: the term of the Agreement plus the windows in Section 12.
• Nature and purpose: hosting, storage, display, indexing, deterministic rules evaluation, and human-directed AI assistance (explanation, transcription, suggestion) over records the School processes in the platform, under the Section 2.3 rule that no consequential decision is made by solely automated processing.
• Categories of data subjects: current and former students, parents and guardians, staff, governors, alumni, and third parties appearing in archived school records.
• Categories of personal data: names and contact details; roles and employment data; identifiers, IP addresses, and device and session data; compliance and assessment records; audit and disclosure records; AI prompts and outputs, OCR and transcription text, and uploaded images concerning identifiable people; policies and governance documents; documents the School uploads to the governed archive, which may incidentally contain any category of personal data present in school records, including special categories and disciplinary or offence-related information. The service's redaction, access-tier, and disclosure controls exist for exactly this material.

Annex 2 — Approved Subprocessors (completed per execution package)

School-directed services (not subprocessors, per Section 6.3): the School's identity provider (Google or Microsoft SSO), the School's cloud storage that archives and exports are written to (Google Drive or OneDrive), and the School's own AI provider accounts. Before execution: name each actual provider, purpose, location, and transfer safeguard for the School's enabled configuration; generic category labels are not sufficient for notice and objection purposes.

Annex 3 — Technical and Organisational Measures (summary)

• Tenant isolation: tenant-scoped access is protected through school and role-based controls, including a registry-driven guarded query path for covered modules and automated tenancy checks in the deployment guard; the platform can produce per-school export and erasure walks.
• Access control: role-based access with per-school feature gating; single sign-on support; administrative access limited to a small, named, reviewable set of people; privileged actions logged as described in this Annex's implementing documentation.
• Credential and session security: passwords stored only as salted one-way hashes; authenticated sessions with expiry and server-side revocation.
• Secrets: designated archive AI credentials are encrypted at the application layer (AES-256-GCM); other integration credentials are restricted through administrative access controls and hosting protections. [ Program item: extending application-layer encryption to all stored integration secrets is under way; counsel decides when it becomes a firm commitment. ]
• Data protection tooling: verified destructive redaction (removed content is re-read to prove it is gone), tiered reading-room access, disclosure registers for outbound sharing, and retention clocks with review states.
• Availability and recovery: scheduled backups with restore tooling; the School can export registry-covered data at any time without Provider's involvement.
• Encryption in transit: TLS for data in transit; storage-level protections per the hosting environment in Annex 2.
• Organisational: breach handling per Section 10; confidentiality per Section 4; subprocessor flow-down per Section 6.