GDPR compliance summary for DrawSplat^TM.

1. Who is the controller and who is the processor?

Under Art. 4 GDPR, this depends on the deployment path:

• Browser-only mode (no backend configured) — no personal data leaves the student's device or the teacher's browser. There is no processor. The school is the controller of whatever local storage it directs students to use, but no data flows over the network at all.
• Google Apps Script backend — Google is the processor (governed by your existing Google Workspace for Education DPA). DrawSplat^TM is software running inside your Google account, not a third party with its own data access.
• MySQL self-hosted backend — your district or hosting partner is the processor (governed by your existing hosting contract). DrawSplat^TM is the application layer running on infrastructure you already control.
• drawsplat.org (the public marketing/demo site) — Miguel Guhlin is the publisher of the marketing pages. Students should NOT do classroom work on drawsplat.org for production use; that site exists to demo features and serve documentation. School deployments host their own copy.

Because the platform itself is not a third-party SaaS that holds student data, GDPR Art. 28 controller–processor contracting requirements between you and DrawSplat^TM do not arise. They DO arise between you and Google / your hosting provider — those agreements are unaffected by introducing DrawSplat^TM.

2. Lawful basis for processing student data

Per Art. 6 GDPR, the school typically relies on either:

• Art. 6(1)(e) — public task, where the school is performing its public-interest education duty. This is the most common basis in EU/UK state schools for routine classroom tools.
• Art. 6(1)(a) — explicit consent, less common because consent under GDPR can be withdrawn at any time and processing must stop, which is hard to operationalize in a classroom.

For students under 16 (or the lower limit set by the member state, as low as 13 in some countries — Art. 8), where consent IS the basis, parental consent is required. DrawSplat^TM ships a Family Access Portal for parents to request access, exports, and deletion.

3. Data minimisation — what DrawSplat^TM processes

DrawSplat^TM's baseline collection is intentionally minimal:

• Browser localStorage on the student's device: language preference (drawsplat.language), current board JSON, viewer-mode flag, audio mute setting (drawsplat.audioMuted), per-game enabled list, admin session token (sessionStorage, cleared on tab close). No identifiers, no behavioural tracking, no analytics. See the persistent localStorage inventory below.
• When cloud sync is enabled: a room name and a salted-SHA-256 hash of the room password (server-side). Board JSON, image uploads (if enabled), audit events. Student names if the teacher chose to attach them. The district controls retention via the Teacher Admin → Compliance Console.
• No cookies for tracking. The site uses localStorage only for user preferences listed above. No third-party analytics, ad networks, or fingerprinting libraries.
• No outbound network requests on the standalone widgets. The standalone widgets (Concept Map Studio, Bingo Card Generator, Animated GIF Maker, etc.) run entirely in the browser. They never call a server unless the teacher explicitly opts into Cloud Save (Google Drive, OneDrive, or Dropbox via OAuth).

4. Data subject rights — what the platform supports

Articles 15–22 give individuals seven rights. Here's how DrawSplat^TM supports each:

• Right of access (Art. 15) — Teacher Admin → Compliance Console → "Student data export" generates a JSON dump of everything tied to that student. Parents can request the same via the Family Access Portal.
• Right to rectification (Art. 16) — Teachers can edit student boards directly; parents can flag inaccuracies via the Family Access Portal request form.
• Right to erasure / "right to be forgotten" (Art. 17) — Teacher Admin → Compliance Console → "Full data delete" removes the student's boards, audit records, and image uploads. Apps Script deployments delete underlying Drive files; MySQL deployments cascade-delete.
• Right to restriction (Art. 18) — Teacher Admin → "Freeze student" suspends new writes and hides existing content from the student view while preserving it for review.
• Right to data portability (Art. 20) — every standalone widget supports Save .json, and the whiteboard supports Save .drawsplat.json. Boards round-trip; you can re-import them into another DrawSplat^TM deployment or extract them programmatically.
• Right to object (Art. 21) — your DPO documents the objection; the technical action is typically "freeze" then "delete" via the controls above.
• Right re: automated decision-making (Art. 22) — DrawSplat^TM does not perform automated profiling or automated decision-making about students. Optional AI features (where present in widgets) are always teacher-initiated, never autonomous.

Subject-initiated rights flows (parents/students requesting directly without going through a teacher) are scaffolded in the Family Access Portal but rely on the district configuring its own intake and verification process.

5. Data residency and international transfers

Under Chapter V GDPR, transfers of personal data outside the EU/UK / EEA require an adequacy decision or safeguards (Standard Contractual Clauses, BCRs, etc.).

• Browser-only mode — zero transfers; data never leaves the student device.
• Apps Script backend — the data residency is whatever Google Workspace for Education has agreed with you under the EU/UK Data Processing Amendment (DPA). DrawSplat^TM adds no further transfers.
• MySQL self-hosted — you decide where the database sits. Host inside the EU/UK if your DPIA requires it.
• drawsplat.org marketing site — hosted on Cloudflare Pages, which has EU/UK-compliant transfer safeguards in place. Marketing pages collect no personal data.

Document your hosting choice in your Records of Processing Activities (RoPA, Art. 30).

6. localStorage inventory (no cookies, no third-party trackers)

DrawSplat^TM uses browser localStorage and sessionStorage for non-essential UI preferences. Under the EU Cookie Directive (2002/58/EC as amended) plus the ePrivacy interpretation of GDPR, even non-cookie local storage may require notice for non-essential items. Here is the complete inventory the public pages may set, so your privacy notice can describe them:

• drawsplat.language — UI language pick (en / es / vi / ar / zh / uh). Strictly necessary for the language preference to persist between visits.
• drawsplat.audioMuted — whiteboard audio toggle. Convenience setting.
• drawsplat.disabledGames — admin per-game access list (per browser). Convenience setting.
• drawsplat.adminAccess (sessionStorage) — admin role token, cleared when the browser tab closes. Strictly necessary for the admin gate.
• drawsplat.consent.accepted — records that the user has acknowledged this notice so the banner doesn't re-appear. Strictly necessary for the banner itself.
• Per-widget content (e.g. the current concept map, bingo card, dicebreaker draft) — saved locally so a refresh doesn't lose work. The user controls this directly via Save / Load / Clear buttons inside each widget.
• Whiteboard board state — same pattern: the in-progress board persists across refreshes; the user can clear it via the TNT Reset button.

None of these is shared with a third party. The localStorage consent banner that appears on first visit explains this and lets the user dismiss it.

7. Security measures (Art. 32)

• Room passwords stored as salted SHA-256 hashes, never plaintext.
• Strict per-page Content Security Policy (script-src 'self', no inline scripts on admin pages, no third-party origins).
• Role-based access control in the MySQL backend (server/mysql-backend/rbac.js): five roles (admin, teacher, student, parent, viewer) with a permission matrix gate on every mutation endpoint.
• HTTPS-only via Cloudflare Pages for the public site; self-hosted deployments must terminate TLS at their own load balancer.
• Open-source code, so your security team can audit it directly (github.com/mguhlin/drawsplat).
• No third-party JavaScript bundled into the runtime — all dependencies are local files audited at release time.

8. Children's data (Art. 8)

GDPR Art. 8 requires parental consent for information society services offered directly to children under 16 (member states may lower the threshold to 13). DrawSplat^TM is offered to schools, not directly to children — schools obtain consent under the public-task / parental-authority framework. The Family Access Portal provides parents a self-service way to request access, exports, and deletion of their child's data.

If a district uses DrawSplat^TM outside that school-mediated context (e.g. a public after-school club where parents register children individually), the operator must obtain parental consent under Art. 8 directly — DrawSplat^TM does not include a built-in consent-collection flow for that scenario.

9. Data Protection Impact Assessment (DPIA, Art. 35)

A DPIA is required when processing is likely to result in high risk to rights and freedoms (Art. 35(1)). Classroom whiteboards processing children's content typically trigger that threshold under Working Party 29 guidance (children + large-scale processing of vulnerable subjects).

DrawSplat^TM does not ship a turnkey DPIA template, but the NDPA / DPA Review Packet and District Privacy Addendum cover most of the substantive content a DPIA needs: data flows, retention, security measures, third-party processors, subject rights flows. Your DPO can repackage those into your jurisdiction's DPIA template.

10. Breach notification (Art. 33–34)

You must notify your supervisory authority within 72 hours of becoming aware of a personal-data breach that poses risk to data subjects. Because DrawSplat^TM is not a SaaS hosted by Miguel Guhlin — your district hosts the backend — the breach detection and notification flow runs through your existing incident response process, not through us.

That said, if you discover a security vulnerability in the open-source code itself, please report it via the contact form so the patch can ship to all deployments. We treat security reports as urgent and credit responsible disclosure.

11. Records of Processing Activities (RoPA, Art. 30)

You should keep an Art. 30 record covering each DrawSplat^TM deployment. Suggested fields:

• Controller: your school / district name + DPO contact.
• Categories of data subjects: students aged X–Y, teachers, administrators, parents.
• Categories of personal data: name (if attached to boards), student work product (board JSON), uploaded images (if enabled), audit-log events (timestamps + actions).
• Recipients: your hosting provider (Google / your MySQL host / your district IT).
• Transfers outside EU/UK: yes/no — document under Chapter V if yes.
• Retention periods: configurable in Teacher Admin → Compliance Console → Retention.
• Security measures: row of TOMs taken from §7 above plus your own controls (network filtering, MFA on admin, etc.).

12. Honest gaps you should know about

To save your DPO time:

• No GDPR-targeted Standard Contractual Clauses template. DrawSplat^TM is not a controller or processor of your students' data, so SCCs don't apply between you and DrawSplat^TM. They DO apply between you and Google / your hosting provider — those agreements are unchanged by introducing DrawSplat^TM.
• No turnkey DPIA template. See §9 — use the NDPA Packet + District Addendum as source material for your jurisdiction's template.
• The drawsplat.org admin panel is not for production student data. It exists for demo and documentation. Run your own copy of the code for real classroom use, with your own admin password.
• The localStorage consent banner is the default-on path. Self-hosters who want a different consent UI can replace assets/js/consent-banner.js with their own implementation; it's a single small module.

13. Quick checklist for your DPO

Before classroom rollout in the EU/UK:

• Decide the deployment path (browser-only / Apps Script / MySQL self-host) and document it.
• Confirm controller/processor relationships with your hosting provider (Google Workspace DPA, your MySQL host's processor agreement, etc.).
• Pick a lawful basis (typically Art. 6(1)(e) public task).
• Run a DPIA using NDPA Packet + this page as source material.
• Add DrawSplat^TM to your RoPA.
• Configure retention in Teacher Admin → Compliance Console.
• Update your school's privacy notice to mention the localStorage items in §6 and the data subject rights flows in §4.
• Communicate the Family Access Portal URL to parents so they have a clear path for subject rights requests.

Cross-links

• Full Terms & Privacy — the authoritative text including governing law clauses.
• District Privacy Addendum — model contract language.
• NDPA / DPA Review Packet — packet for district reviewers.
• All policy documents in one page — for printing or DPO review.
• Family Access Portal — subject-rights intake.
• Contact form — security disclosure, questions, requests.