Skip to article
SplatWorks Wiki
Read in your language
Privacy and district review
Source

District privacy review worksheet

Use this worksheet to prepare the deployment-specific exhibits and evidence for an NDPA/DPA review. The shared commitments and schedules are in Security, privacy and terms; record agreement execution in the DPA Register.

1. Identify the parties and approved scope

  • District/controller, deployment operator and any outside hosting/support parties.
  • Approved educational purpose, apps/versions, website origins and storage modes.
  • Student age/grade bands, school authorization or required parental-consent basis, family notice and eligible-student rights.
  • Monitored privacy/security contact, incident contact method and provider-change notice contact.

2. Record the data flows

Selected modeRecord in the exhibit
Public or district-hosted browser-only appsLocal drafts/imports/media/settings, exported files, device/profile controls and host/CDN request metadata. Mark optional connections off unless approved.
District MariaDB/MySQLAccounts, private boards, rosters/classrooms, assignments, submissions/feedback, sessions/usage and logs; API, database and file/object storage locations.
Google Apps ScriptConfigured whiteboard Drive/Sheets records, room/turn-in workflow, audit and family-request records, tenant and account owner.
Optional servicesActual cloud/AI/identity/roster/media/bot/sharing providers, selected inputs, requested permissions, retention and data transfers.

Attach the component inventory plus a runtime data-flow check for the selected features. Record exact processing, log and backup countries/regions and outside administrator access. Self-hosting does not automatically switch off external connections.

3. Approve providers and agreements

For each enabled provider, record company/entity, role, purpose, data, jurisdiction, service region, contract/DPA, transfer safeguards, access scopes, deletion and security terms. Start from the provider register. Confirm educational-purpose and no-sale/no-profiling/no-training restrictions, notice/objection and incident duties. List the actual contracting parties.

4. Attach operating evidence

  • HTTPS/hardening and remote database TLS; secrets stay server-side.
  • Device, disk/database/object and backup encryption; MFA and least privilege.
  • Administrator/teacher/student tests of private-board ownership and classroom boundaries.
  • Protected audit events, patching and appropriate vulnerability review.
  • Identity-verified access/correction/export/deletion rehearsal with redacted receipts for every relevant store and copy.
  • Enabled retention job results, export/termination deletion and backup expiry/restore with erasure replay.
  • Incident drill, named notification contacts and escalation/containment procedure.

For Apps Script, collect the Compliance Console configuration, parent-request workflow and District Privacy Packet with recent Activity Records. For MariaDB/MySQL, collect the actual API/database settings and role/retention/export/erasure results. Match each piece of evidence to the backend and components it covers; legacy name-only submissions and exported/media copies need separate handling.

5. Complete the schedules and notice

Select a schedule for each data type from the retention policy. Document any legal retention basis/end date, backups, exports and restored-copy handling. Add local contacts and consent/notice details using the Privacy Notice Builder.

6. Complete the agreement exhibits

Use the district's applicable NDPA/DPA form and District Privacy Addendum. Confirm purpose/components, data elements, hosting/providers, security, retention, notice/incident terms, contacts and signatures. Consult the accessibility statement and the policy's regional review for additional evidence requirements.

7. Approve, then maintain

Have authorized district reviewers assess the evidence and remaining gaps before student rollout. Record the PROTECT deployment review, complete the applicable agreement, and retain the approved configuration. Repeat review annually and after material changes to hosting, authentication, storage, providers or components.