What DrawSplat^TM does NOT yet do — and why.

USA — Federal

COPPA (Children's Online Privacy Protection Act)

• No built-in parental consent collection flow. DrawSplat^TM is designed to be deployed by schools, which typically rely on the COPPA school-authorization carve-out (school acts as the parent's agent for consent for instructional purposes). If you operate DrawSplat^TM outside of school authorization — for instance, a parent-facing direct-to-consumer product or a public after-school club where parents register children individually — you must collect verifiable parental consent yourself. The product does not ship a verifiable-consent flow (credit-card check, government-ID check, signed form upload, etc.).
• No automated COPPA notice generator. The Privacy Notice Builder can produce a customized notice, but you fill in the COPPA-specific fields by hand; we do not generate the FTC-style "Notice to Parents" form for you.

FERPA (Family Educational Rights and Privacy Act)

• The district is the educational agency under FERPA, not DrawSplat^TM. Subject access requests (parents requesting their child's education records) must be handled by the district. The platform provides export endpoints (Teacher Admin → Compliance Console → Student Data Export) but does not include a parent-facing FERPA-request intake form. The Family Access Portal scaffolds this; the district configures verification and SLA.
• No automated annual notification. 34 CFR § 99.7 requires the school to give annual notification of FERPA rights; the platform does not generate or distribute that notice.
• No directory-information opt-out flow at the platform level. If your district designates board labels or display names as directory information, the opt-out workflow lives in your SIS, not in DrawSplat^TM.

CIPA (Children's Internet Protection Act)

• DrawSplat^TM is not a network filter. CIPA requires the school to deploy a "technology protection measure" at the network level that blocks visual depictions of obscenity / child pornography / harmful-to-minors content. DrawSplat^TM ships safety primitives (link allowlist, text keyword filter, image approval queue) that support CIPA but do not replace your district's network filter or its internet safety policy. See CIPA support statement.

USA — Texas

SCOPE Act (Texas Securing Children Online through Parental Empowerment Act)

• No age-verification mechanism at the platform level beyond the optional Age Band Lock. SCOPE focuses on operators of digital services directly used by minors. In a school deployment the district handles age registration in its SIS; DrawSplat^TM doesn't independently verify a user's age. If you deploy outside a school SIS context, you would need to add age verification yourself.
• No advertising / monetization controls — because we don't advertise. SCOPE restricts targeted advertising to minors. DrawSplat^TM runs zero advertising and no third-party trackers, so the rules are moot in this product. There is no "ad preference" UI because there is nothing to set preferences against.
• Harmful-content strategy is district-side. SCOPE requires operators to publish a strategy for preventing minors from accessing harmful content. Text and link safety filters ship in the Compliance Console; the broader strategy document (which the law requires you publish on your service) is something the district adapts from the model language in Texas Compliance and District Privacy Addendum.

TEC 32.151–32.156 (Student Data Privacy Agreements)

• No pre-signed master TEC DPA. The TEC chapter requires the district and the operator to have a data sharing agreement in place. DrawSplat^TM is open-source software you deploy under your own control — there is no "operator" entity to countersign a DPA with. If your district's procurement office insists on a signed DPA, point them at the District Privacy Addendum as the model contract language; your superintendent or board can adopt it as policy without a counterparty.

State NDPA (Network of Data Privacy Agreements) interoperability

• No SDPC signatory page. DrawSplat^TM is not registered as an NDPA vendor on the Student Data Privacy Consortium signatory list because there is no commercial entity to sign. The NDPA / DPA Review Packet mirrors the data points an NDPA reviewer needs, but it's not the same as being on the consortium's signatory list.

European Union / United Kingdom — GDPR & UK GDPR

Controller / processor contracting

• No DrawSplat-to-district Data Processing Agreement (Art. 28) template. Because DrawSplat^TM is open-source software you deploy under your own control, there is no operator entity to sign a processor agreement with. Article 28 obligations sit between you and your hosting provider (Google Workspace, your MySQL host) — those DPAs are unaffected by introducing DrawSplat^TM.
• No turnkey Standard Contractual Clauses (SCCs). SCCs apply between controller and processor for international transfers. Same reason as above — they're not contracted between you and DrawSplat^TM, they're between you and whoever hosts the backend.

Data Protection Impact Assessment (Art. 35)

• No automated DPIA template. Classroom whiteboards processing children's content usually trigger DPIA threshold under Working Party 29 guidance. The GDPR Compliance Summary, NDPA Packet, and District Privacy Addendum together cover the substantive content a DPIA needs, but your DPO must repackage that into your jurisdiction's DPIA template (CNIL in France, ICO in the UK, etc.). We do not generate the DPIA file for you.

Consent and cookie/storage notice

• Consent banner is acknowledge-only, not granular. The localStorage notice has one "Got it" button. We do not offer granular toggles for "necessary / preferences / analytics / advertising" because the platform stores nothing in those last two categories — there is no analytics and no advertising. Strict EU jurisdictions sometimes expect granular controls even when categories are empty; if your DPO insists, replace assets/js/consent-banner.js with a Cookiebot / OneTrust / Klaro integration in your self-host fork.
• No "withdraw consent" workflow. Because the only "consent" we collect is acknowledgement of a localStorage notice, there's no withdrawal flow — clearing your browser's storage clears it. For school-mediated processing the relevant legal basis is typically Art. 6(1)(e) public task, not consent, so withdrawal isn't applicable.

Children's data (Art. 8)

• No direct-to-consumer parental consent flow. Same reason as the COPPA gap above. The school-mediated deployment model is the intended use; direct-to-parent registration is not.

Data subject rights (Arts. 15–22) — subject-initiated path

• Identity verification for subject requests is district-configured. The Family Access Portal accepts requests but does not perform identity verification itself (no government-ID upload, no notarized form, no SAML login). Your district decides how to verify a requestor's identity and configures the intake accordingly.
• No 30-day SLA timer. GDPR Art. 12(3) requires response "without undue delay and at the latest within one month." The platform does not track request age or send reminder emails to administrators; that's on your case-management workflow.

Records of Processing Activities (Art. 30)

• No RoPA template. The GDPR Compliance Summary §11 lists the suggested fields you should record; we don't generate or maintain the RoPA file itself.

Breach notification (Arts. 33–34)

• No automated 72-hour breach notification. The platform does not detect breaches in your hosting environment (we have no telemetry to do so). Your incident response process runs through your hosting provider and supervisory authority. If you find a vulnerability in the open-source code, report it via the contact form and we'll patch and release.

Cross-cutting gaps that apply everywhere

• No Data Protection Officer on file. DrawSplat^TM is open-source software, not a corporate entity with a designated DPO. The named contact for security issues and questions is Miguel Guhlin via the contact form; that's not a substitute for your district's DPO.
• No SOC 2 / ISO 27001 attestation. Same reason — there's no SaaS operator to be audited. If your procurement office requires those, point them at your hosting provider's attestation (Google Workspace and major MySQL hosts have them).
• No formal subprocessor list. The platform itself uses no subprocessors (no SaaS dependencies, no analytics, no advertising). When you self-host the MySQL backend, YOUR hosting provider is a subprocessor between you and your students — that's covered in your contract with them, not in ours.
• No bug bounty program. We do credit responsible disclosure publicly. There is no monetary reward.
• Penetration test cadence is informal. Code is open-source and your security team can audit it directly; we do not publish scheduled third-party pen-test reports.
• Accessibility audit is informal. The Accessibility Statement describes the standards we target and the known issues; there is no third-party WCAG audit certificate.
• No vendor questionnaire pre-filled. Common district vendor questionnaires (HECVAT, SIG, CAIQ) are not pre-completed. Most of the data points needed are in the existing policy documents; you map them to your questionnaire format manually.

Things we deliberately do not do

Some "gaps" are intentional design choices, not roadmap items:

• No telemetry. Nothing about user behavior is reported back to anyone. This means we cannot proactively detect misuse, generate usage analytics for your district, or surface aggregate adoption metrics. If your district wants those, you instrument them at your hosting layer.
• No third-party JavaScript. All runtime dependencies are local files. This means we cannot use Google Analytics, Mixpanel, Sentry, etc. for error tracking — your hosting provider's logs are the source of truth.
• No SaaS operator to contract with. The whole project is open-source software you deploy. This means there is no entity to sign a DPA / SCC / NDPA / TEC DPA with. The model contract language documents (District Addendum, NDPA Packet) exist so your district can adopt the same language as internal policy.
• No mandatory cloud features. Browser-only mode works fully. Cloud sync, Google Drive save, MySQL backend, image approval, parent portal — all opt-in. This lets a school start without ANY data processing concerns and scale up only as policy allows.

How this list is maintained

Every commit that closes a gap should remove the relevant bullet here. Every commit that introduces a new compliance obligation should add a bullet. If you spot something we've missed — a regulation you need that isn't named — please file it via the contact form and we'll either close the gap or document it here.

Cross-links:

• GDPR Compliance Summary
• Texas Compliance
• Terms & Privacy
• District Privacy Addendum
• NDPA / DPA Review Packet
• All policy documents in one page