Skip to article
SplatWorks Wiki
Read in your language

Google machine translation · Opens a new tab.

Translation help
Privacy and district review
Source

For District Reviewers

DrawSplatTM NDPA / DPA Review Packet

Current deployment scope

Use the wiki’s compliance and district review reference to match this document to your actual installation. Apps Script console controls apply to Drive/Sheets workflows; they do not automatically administer district MariaDB/MySQL private boards, rosters, assignments, submissions, or feedback. Templates and review packets do not establish a signed NDPA/DPA or certify legal compliance.

Everything a K–12 district reviewer typically asks for in one place. The Student Data Privacy Consortium’s National Data Privacy Agreement (NDPA) is a standardized contracting framework whose standard clauses are not meant to be redlined — changes belong in exhibits. This page is the exhibit packet: product description, data elements by deployment mode, data flow, subprocessor list, security controls, breach SOP, retention, parent workflow, accessibility, and the FERPA / COPPA / SCOPE / CIPA crosswalks.

District agreement status

See the State & District DPA Register for executed agreements and pending reviews. This technical packet is not an executed agreement. Contracting parties, deployment scope, data categories, notice contacts, security obligations, and signatures must be confirmed for each district.

1. Product description & approved educational purpose

DrawSplatTM is a self-contained interactive whiteboard for K–16 classrooms. It runs as a static web app and can optionally save boards, templates, collaboration rooms, and student turn-ins to a Google Apps Script + Sheets backend the district controls, or to a self-hosted Node + MySQL backend the district runs on its own infrastructure.

Approved educational purpose: classroom drawing, notes, diagrams, charts, sticky notes, audio notes, collaboration, turn-in workflows, and supporting classroom activities. DrawSplatTM is not used for advertising, behavioural profiling, or AI training. Full feature list.

Which deployment is your district reviewing?

Public website use: students visit DrawSplat.org to use the browser-based whiteboard, games, or other local tools without a configured storage backend. In this mode, board content and saved game progress remain on the user device or in files the user saves. The public website still receives normal web requests, and its hosting/CDN services process request metadata such as IP address, user agent, and requested URL. Public website use should not be described as involving no data processing.

District-hosted installation with MySQL: the district hosts the application, API, and database and administers accounts, storage, access, backups, retention, and deletion. Student records and work saved through that backend are held in district-controlled infrastructure. Hosting or support access by any outside party must be documented; installing the software does not itself grant the DrawSplat operator access to the district database.

Optional integrations change the scope: connecting a backend, enabling sign-in or cloud saving, sharing content, or opening third-party services requires a separate review of the selected feature and its data flow. The Google Apps Script option is also documented below but should be included in an agreement only if the district selects it.

Before completing Exhibits A and B, confirm the district’s selected website or hosting location, enabled features, student data categories, and who can access that data. The district MariaDB/MySQL path supports private saving, roster-linked classrooms, assignments, student submissions, and feedback. Validate the actual deployment and its operational controls before student use; see Recommended production posture.

2. Three deployment modes and what each collects

ModeWhere data livesStudent identifiers collected
Browser-only (public website or district-hosted static app, without a configured backend) The visitor’s browser. Optional local .drawsplat.json file the user explicitly saves. No student account required for local whiteboard or game use. Local content is not uploaded to a storage backend in this mode. The website host/CDN processes web request metadata; optional connected features require separate review.
Google Apps Script (supported production) The teacher or district’s own Google Workspace tenant — Drive folders and a Sheet that the script creates inside the operator’s account. What a teacher chooses to enter: student name on a turn-in, class section name, age band the admin assigns. No password storage, no biometric data, no precise location, no advertising identifiers.
District MariaDB / MySQL A MySQL database running on the district’s own infrastructure, fronted by a Node + Express API the district hosts. Same as the Apps Script row. Email + scrypt+pepper hashed password if the district opts into local email/password accounts. OAuth subjects if Google or Microsoft SSO is enabled. Optional Clever roster sync if the district connects it.

3. Data flow diagram

Browser-only mode:
  [Student browser] <-- board content and game progress stay local.
  [Website host / CDN] <-- page and asset requests include request metadata.

Google Apps Script mode:
  [Student / teacher browser]
      |
      |  HTTPS POST/GET, only when the teacher has configured a script URL
      v
  [script.google.com /macros/s/.../exec]  (the district's own Apps Script project)
      |
      v
  [Google Sheet]  (Boards / Rooms / TurnIns / Audit / ParentRequests / Users etc.)
      and
  [Google Drive]  (per-board JSON + PNG files in the district's Drive)

District MariaDB / MySQL mode:
  [Student / teacher browser]
      |
      |  HTTPS to the district's own domain
      v
  [district.example.org/api/drawsplat/mysql]  (Node + Express in the district's infra)
      |
      v
  [MariaDB / MySQL]  (accounts, private boards, roster membership, assignments, submissions, feedback)

4. Subprocessors

DrawSplatTM as a product has no required subprocessors. Subprocessors only enter the picture when a district opts into a feature that needs them, and the relationship is between the district and that subprocessor — not between the vendor and that subprocessor:

SubprocessorUsed whenData exposedWhose contract
Google Workspace (Drive, Sheets, Apps Script)District chooses the Google Apps Script storage modeBoard JSON, sheet rows, audit log — lives in the district’s own Workspace tenantDistrict’s existing Google Workspace agreement
Google Identity ServicesDistrict enables school Google sign-in on its database-backed installationGoogle ID token verification (email, sub, display name)District’s existing Google identity agreement
Static-host CDN (Cloudflare Pages by default; can be any static host)When the operator chooses a public CDN; a district can serve the entire suite locallyStandard HTTP request metadata (IP, UA, URL) at the edgeWhoever the district / operator picks

5. Security controls matrix

ControlCurrent scopeVerify on your installation
Transport and database privacyDistrict domain HTTPS through the gateway; database credentials remain on the API server. Localhost is for local verification. Remote databases require verified TLS.Gateway response, database network restrictions, and deployed API settings.
Content Security PolicyPolicies vary by application and enabled services. Embedded tools and Google sign-in have different requirements from documentation pages.Inspect actual response headers and page policies; test enabled origins.
District authenticationInstallation creates a district administrator password account. Google identity is verified server-side and linked to rostered school accounts. Roster-only deployments disable public registration and invitations.First-time setup, school Google client/origin/domains, and account sign-in tests.
District authorizationDistrict administrators manage rosters; teachers access their classes and student submissions; students access enrolled classes and their own submissions. Private Save/Open enforces account ownership.Test separate administrator, teacher, and student accounts against private boards and classroom endpoints.
Safety filters, room freeze, and image reviewThe Apps Script Compliance Console configures Drive/Sheets safety and moderation workflows. These controls do not automatically cover district private-board or classroom records.Apps Script console configuration and test saves; establish separate district procedures where needed.
Activity recordsApps Script records activity in its Audit sheet; backend event coverage depends on the endpoint. Operator-controlled logs are not tamper-proof certification evidence.Review actual events, administrative access, and protected log backups.
RetentionApps Script supports configurable cleanup triggers. District private boards, assignments, submissions, and feedback need an operator-defined, tested retention and deletion procedure; do not infer coverage from legacy cron code.Test cleanup and retention against every relevant record type and backups.
Student export and deletionThe Apps Script console supports student exports and deletion of its Drive/Sheets records. The district database requires a separately verified record-request procedure.Export downloads, request identity verification, deletion checks, and district-approved delivery.
Backup and recoveryDistrict launchers include database/configuration backup guidance. Preserve the password pepper and keep protected off-server copies.Restore to a separate installation and verify account-owned boards and classroom work.

6. Breach notification SOP

  1. Discovery. A teacher, admin, parent, or external researcher reports a suspected breach via Contact / Information Request or the audit log surfaces an anomaly.
  2. Triage within 24 hours. Operator confirms scope: which deployment mode, which records, which audit trail rows are affected.
  3. Contain. Use the containment procedure appropriate to the backend: freeze supported Apps Script boards/rooms, revoke affected account sessions, restrict server access, or stop an affected service. Do not assume room-freeze controls cover district private boards.
  4. Notify within 72 hours. Operator notifies the named district Privacy / Security Contact from the District Data Privacy Addendum using the breach notice contact method declared there. Notice includes: what happened, what data was involved, what containment was done, what the district should do next.
  5. Investigate & remediate. Operator investigates root cause, patches, re-tests. The Activity Records audit log is preserved for the investigation.
  6. Post-incident report. Written summary delivered within 30 days, including timeline, scope, remediation, and any changes to security controls.

7. Retention schedule

ModeBoards archiveBoards deleteAudit logParent requests
Browser-onlyn/a — user-managed filesn/an/an/a
Apps ScriptDefault 90 days — configurable in Compliance ConsoleDefault 365 days — configurableDefault 365 days — configurableDefault 3 years — configurable
District MariaDB / MySQLOperator-defined retention and deletion procedures for private boards, assignments, submissions, and feedback. The Apps Script console does not configure these records. Validate any backend cleanup job’s actual table coverage before relying on it.

Apps Script retention windows are configurable from the Compliance Console. Its cleanup writes a RETENTION_ACTION event. District database classroom records need their own validated retention and deletion procedures.

8. Parent / student request workflow

  1. Parent visits Family Access Tools and submits a request (view, export, correct, delete, pause, safety report, privacy question).
  2. For the Apps Script workflow, the request lands in the ParentRequests sheet tab as pending_verification. District database requests follow the district’s separately published procedure.
  3. Compliance admin gets an email notification (Apps Script MailApp.sendEmail) and reviews the request in Teacher Admin.
  4. Identity verified via teacher-issued one-time 8-character code (SHA-256 hashed, 14-day expiry, single-use).
  5. Verified request transitions to verified, then approved / denied / completed by an admin click.
  6. Export: the Apps Script administrator downloads the student ZIP and delivers it through an approved district channel after verifying the requester. The console does not automatically email a temporary download link.
  7. Delete: admin button trashes Drive files, removes rows, logs DATA_DELETED.
  8. Acknowledged within 10 school days; completed within 30 calendar days when feasible.

9. FERPA / COPPA / SCOPE / CIPA crosswalks

FERPA school-official crosswalk

When DrawSplatTM is engaged as a service provider, the district designates the vendor as a school official under FERPA’s school-official exception. Conditions:

  • Performs an institutional service or function. The product is operated as part of classroom instruction (the district’s approved educational purpose stated in section 1).
  • Under direct control of the school. The district controls the deployment mode (browser-only / Apps Script / MySQL), storage location, retention windows, and access rules; the District Data Privacy Addendum names the controlling district and the privacy contact.
  • Use / redisclosure limits. Student data is used only for the school-authorized educational purpose. No advertising, behavioural profiling, AI training, or sale of data. No redisclosure outside the district’s subprocessors.
  • Inspect / correct / delete rights. Parents and eligible students can submit a request via Family Access Tools; the District’s admin verifies and acts on the request from Teacher Admin.

COPPA school-consent notice (for under-13 users)

Under COPPA the district may provide consent on behalf of parents when the service is for an educational purpose and the district retains direct control. The district’s notice to parents typically says, in plain language:

Our school uses DrawSplatTM, a free interactive whiteboard for classroom drawing, notes, and collaboration. The school controls all storage and access. DrawSplatTM does not show ads, does not sell student data, does not use student work to train AI, and does not require student accounts in browser-only use. If you would like to view, correct, export, or delete your child’s data, contact the school’s published privacy contact. Schools using the Apps Script family-request workflow may also provide Family Access Tools at /parents/.

Texas SCOPE / TEC 32.151+

See legal/texas-compliance.html for the plain-language explainer.

CIPA

CIPA is a school / library E-rate internet-safety and filtering obligation, not a vendor privacy law. DrawSplatTM supports CIPA via link allowlists, board freeze, text filtering, the moderation + image-approval queues, and the audit log, but does not replace the district’s network-level filter or its internet safety policy. Full statement: CIPA support statement.

10. District contracting documents

11. Recommended production posture

Choose the installation that matches your district’s requirements: the complete district suite provides MariaDB/MySQL account-based saving, classrooms, assignments, submissions, and feedback; the optional Apps Script deployment provides Drive/Sheets workflows and its Compliance Console. Database installer and classroom checks have been exercised with MariaDB and MySQL. This does not establish a district-wide load rating or legal certification. Validate school Google sign-in, roles, backups, restoration, retention and record-request procedures on your own deployment before student rollout. See Compliance and district review.

These are the screens a district reviewer typically needs to see — the live Compliance Console, the Family Access Tools queue, the District Privacy Packet download, and the audit log. The CAPTURE.md checklist in the repo describes exactly where to find each one and what state to put the app in before capturing. Operators are expected to drop in their own deployment’s screenshots before sharing this page with a district reviewer, since each capture should reflect the district’s own configuration.

Compliance Console overview — capture from the internal Compliance Console with every <details> closed except the header.
1. Compliance Console — overview. Demonstrates that every safeguard is one page, expandable per district reviewer interest.
Image Approval Queue — capture the queue with two pending images, the thumbnail visible, the Approve / Reject buttons visible.
2. Image Approval Queue (Days 1.3 / 1.4). Demonstrates the moderation step between student upload and student-visible image.
Family Access Tools request queue — capture one verified request with the Approve / Decline / Note controls visible.
3. Family Access Tools queue. Demonstrates the parent-request workflow end-to-end.
Activity Records (audit log) — capture filtered to the last seven days, showing at least one row each of BOARD_FREEZE, TEXT_FILTER_HIT, IMAGE_APPROVED, PARENT_REQUEST_CREATED, DATA_EXPORT.
4. Activity Records / audit log. Demonstrates that every compliance-relevant action leaves an recorded activity trail.
District Privacy Packet download — capture the “Download District Privacy Packet” button with the resulting toast showing the zip size and audit-row count.
5. District Privacy Packet. Demonstrates the one-click ZIP that bundles the compliance config + last 90 days of audit + parent-request log.
Per-student Export / Delete — capture the user row in Student Age Band Lock with the Export Data and Delete Data buttons visible.
6. Data export and deletion. Demonstrates FERPA-style inspect / correct / delete rights.

Operator note: replace each .evidence-placeholder div with an <img src="evidence/capture-key.png"> once you’ve captured the screen. The data-capture attribute matches the filename in docs/CAPTURE.md.

Working with us

This packet plus the District Data Privacy Addendum is the contracting surface. If your district’s review process needs a specific format, screenshot evidence, or a custom exhibit, send the request through the Contact / Information Request form and we’ll respond within five business days.