Data Processing Agreement
District-facing data processing terms
This page summarizes the main terms WhyDive expects to address in a district-facing Data Processing Agreement for school and student data.
Effective date: April 6, 2026
Last updated: April 6, 2026
Document version: Public Summary v1.0
Document summary
- Who this is for
- District reviewers, school teams, authorized users, and public visitors evaluating WhyDive Education.
- What this covers
- This page summarizes the main terms WhyDive expects to address in a district-facing Data Processing Agreement for school and student data.
- How to ask a question
- Use the contact page or email [email protected].
- Current status
- Public Summary v1.0
Why a DPA matters here
School districts and educational institutions commonly require a Data Processing Agreement before adopting a platform that handles student, roster, assessment, or reporting data. For this platform, a DPA is expected to define permitted processing, confidentiality, service-provider responsibilities, security commitments, subprocessors, deletion or return obligations, and other institutional privacy terms.
Processor role and permitted processing
In most district implementations, WhyDive expects to process covered student, roster, reporting, and administrative data only to provide the contracted educational service, support authorized implementation and reporting workflows, maintain security, and perform related support or operational functions permitted by the governing agreement. A final DPA should make clear that the district or institution directs the permitted educational use of covered data within the agreed service scope.
Covered data and confidentiality
The final DPA should identify the relevant categories of covered data, such as student identifiers, roster information, assessment responses, diagnostic placements, reporting outputs, account details, and implementation records. It should also require confidentiality obligations for personnel and contractors with access to covered data.
Security and incident handling
The final DPA should describe baseline technical and organizational security measures, including access control, encryption expectations where applicable, role-based handling, vendor management, and a process for responding to security incidents or unauthorized disclosures involving covered data.
Subprocessors and vendors
The final DPA should address how subprocessors are used, what notice or transparency is provided, and how WhyDive remains responsible for subprocessors used to support the service. Public-facing vendor information should also stay aligned with the subprocessor list published on this site where applicable.
Deletion, return, and retention
The final DPA should explain what happens to covered data at termination or offboarding, including whether data is returned, deleted, retained for limited legal or security reasons, or handled under a separate district agreement. The timeline and format for return or deletion should be agreed explicitly with the institution.
Audit and district review
If audit, review, or questionnaire rights are offered, the DPA should explain how those are handled, including documentation, timing, security review processes, and any reasonable limits that apply to protect other customers and platform security.
District templates and review
Many districts use their own DPA templates. WhyDive expects that district procurement and legal review may require either a district-supplied DPA or a negotiated WhyDive form. Questions about DPA review may be sent to [email protected].
Current status
This page is a public-facing summary rather than a final executable DPA. District-ready DPA forms are handled during formal procurement review and should be aligned to WhyDive’s actual security controls, vendor list, and contracting model before use.