Growing Standard standard DPA template
Student Data Privacy Agreement
Between Growing Standard LLC
and [District Name]
and [District Name]
Service: Potato Class — K-12 math & reading platform (potatoclass.com)
Provider: Growing Standard LLC
LEA (District): [District Name, State]
Effective date: [MM / DD / YYYY]
Initial term: [typically one (1) or three (3) years, renewing annually]
This template covers FERPA (20 U.S.C. § 1232g; 34 CFR Part 99), COPPA (15 U.S.C. § 6501 et seq.; 16 CFR Part 312), Virginia Code §§ 22.1-289.01 and 18.2-186.6, and the common clauses found in Student Data Privacy Consortium (SDPC) / National Data Privacy Agreement (NDPA) v2.2 templates. It adapts cleanly to a New York Ed Law § 2-d rider, California SOPIPA language, or any state-specific addendum. Fields marked [like this] are placeholders completed per engagement. Request a signable copy (PDF or redline-ready DOCX) at privacy@potatoclass.com.
Growing Standard LLC · privacy@potatoclass.com · growingstandard.com
§1 · Parties
This Data Privacy Agreement (“Agreement”) is entered into as of [effective date](the “Effective Date”) by and between:
Local Education Agency (“LEA”)
Legal name: [LEA legal name]
Address: [LEA address]
Authorized signatory: [name and title]
Chief Privacy Officer / designated contact: [name, title, email, phone]
Provider (“Provider”)
Legal name: Growing Standard LLC
State of organization: Virginia
Principal address: [street, city, state, ZIP]
Authorized signatory: Daniel Segal, Founder
Primary contact: Daniel Segal — privacy@potatoclass.com
Data protection contact (security + privacy incidents): [same or alternate]
(Collectively, the “Parties.”)
§2 · Definitions
§2.1 “Student Data”
Any personally identifiable information (“PII”) about a student created, received, maintained, or accessed by Provider in connection with the Services, including but not limited to education records as defined at 34 CFR § 99.3 and the categories enumerated in Exhibit A. Student Data explicitly includes teacher-set accommodation preferences and intervention-tracking status. Provider does not import, receive, or store a student’s IEP or 504 plan status from any source system.
§2.2 “Education Records”
As defined at 34 CFR § 99.3 — records directly related to a student and maintained by the LEA or by a party acting for the LEA. Provider acknowledges that all Student Data processed under this Agreement is part of the LEA’s Education Records.
§2.3 “De-identified Data”
Data from which all direct and reasonably linkable indirect identifiers have been removed, consistent with the guidance at 34 CFR § 99.31(b). Provider’s append-only research log is designed to meet this standard at the class-level join (student identifier paired with grade only; no name, email, classroom, or school reference stored within the log).
§2.4 “School Official”
A party to whom the LEA has outsourced an institutional service that the LEA would otherwise provide itself, and who meets the criteria of 34 CFR § 99.31(a)(1)(i)(B). Provider agrees it will operate only as a School Official under the LEA’s direct control with respect to the use and maintenance of Education Records.
§2.5 “Services”
The Potato Class web and iPad applications, including adaptive practice, teacher-assigned class tests, the Grow adaptive assessment (where licensed), teacher and school/district admin dashboards, and supporting server infrastructure.
§2.6 “Subprocessor”
Any third party engaged by Provider to process Student Data on Provider’s behalf. The subprocessor list as of the Effective Date is attached as Exhibit B.
§2.7 “Data Breach”
Unauthorized acquisition, access, use, or disclosure of Student Data that compromises the security, confidentiality, or integrity of the data.
§2.8 “Parent”
A parent, legal guardian, or eligible student as defined at 34 CFR § 99.5.
Page 2 · Growing Standard DPA template
§3 · Scope and purpose
§3.1 Data ownership
All Student Data is and remains the sole property of the LEA. No provision of this Agreement transfers any ownership interest in Student Data to Provider. Provider holds Student Data only as a custodian acting on the LEA’s direction.
§3.2 Purpose limitation
Provider may use Student Data solely for the K-12 educational purposes described in Exhibit A, namely: (a) delivering the Services to the LEA’s students and staff; (b) tracking per-student mastery and growth for instructional reporting; (c) maintaining de-identified research data for item calibration and validity; and (d) complying with applicable law. Provider shall not use Student Data for any commercial purpose outside the Services, and does not use Student Data to train artificial-intelligence or generative models.
§3.3 No targeted advertising
Provider does not and will not use Student Data for targeted advertising, behavioral advertising, or ad retargeting, whether on the Services or on any other platform. Provider’s Services contain no advertising SDKs and no advertising identifiers.
§3.4 No sale of data
Provider will not sell, rent, license, or otherwise commercially transfer Student Data. This prohibition survives termination.
§3.5 No non-educational profiling
Provider will not build a profile of any student for any purpose other than providing the Services to that student, consistent with Va. Code § 22.1-289.01.
§3.6 De-identified data
Provider may retain and use De-identified Data for internal research, product improvement, validity studies, and reporting, including publication of aggregate findings that cite the LEA as a pilot partner only with the LEA’s written permission. De-identified Data shall not be re-identified by Provider or any Subprocessor.
§4 · Provider obligations
§4.1 School Official status
Provider acknowledges it is a School Official under 34 CFR § 99.31(a)(1)(i)(B), performing an institutional service the LEA would otherwise provide itself, under the LEA’s direct control, and bound by FERPA’s redisclosure and use restrictions at 34 CFR § 99.33(a).
§4.2 COPPA
Provider operates the Services as a school-authorized educational service under the FTC’s guidance permitting district consent to serve as parental consent for children under 13 when collection is limited to the educational context and no commercial use occurs. Provider does not direct, incentivize, or permit commercial use of Student Data.
§4.3 Employee access
Provider shall limit access to Student Data to Provider employees and contractors who (a) have a legitimate educational interest, (b) have completed Provider’s data-handling training, and (c) are bound by a written confidentiality obligation at least as protective as this Agreement. As of the Effective Date, the full list of individuals with standing access is: [list of names + roles].
§4.4 Subprocessors
Provider may engage Subprocessors only if (a) the Subprocessor is listed in Exhibit B or added via the change-notice mechanism in §4.5, (b) the Subprocessor is bound by a written data-processing agreement containing protections substantially equivalent to this Agreement, and (c) Provider remains liable for the Subprocessor’s acts and omissions.
§4.5 Subprocessor change notice
Provider shall notify the LEA at least thirty (30) days before engaging any new Subprocessor that will process Student Data. Notice may be delivered by email to the LEA’s designated contact under §1. The LEA may object in writing within fifteen (15) days; on objection, Provider shall either (a) not engage the new Subprocessor for Student Data related to the LEA, or (b) terminate this Agreement per §8.
§4.6 Training
Provider shall require all personnel with access to Student Data to complete privacy and security training annually, covering FERPA, COPPA, applicable state law, and Provider’s internal data-handling procedures.
§4.7 Audits
On reasonable prior notice, Provider shall cooperate with an LEA-initiated privacy or security audit conducted no more than once per calendar year. Growing Standard LLC has not pursued SOC 2 Type II certification of its own application layer; Provider will engage an auditor when a customer contract requires it or when revenue justifies the engagement. In the interim, Provider’s compliance posture is demonstrated through: (a) this Data Privacy Agreement, (b) a HECVAT-Lite self-assessment available on request, (c) quarterly admin-access reviews per Provider’s documented runbook, (d) a documented incident-response runbook, and (e) a multi-state privacy addendum aligned with CA SOPIPA, NY Ed Law 2-D, IL SOPPA, TX Student Privacy, CO, CT, NJ, MD, and WA statutes. Provider shall make available any SOC 2 attestation (or equivalent third-party report) once issued.
Page 3 · Growing Standard DPA template
§5 · Parental rights, access, and deletion
§5.1 Parental rights
Parents retain the rights provided under FERPA (34 CFR §§ 99.10, 99.20) to inspect, review, and request amendment of their student’s Education Records. Parents shall exercise these rights through the LEA. Provider shall honor LEA-forwarded parental requests within fifteen (15) business days.
§5.2 Parent-facing self-service
Provider offers a parent self-service data-access surface backed by a dedicated data-request queue. The surface shall (a) authenticate the parent via the same identity provider used for the LEA’s student accounts, (b) scope access to the parent’s own student, and (c) log every access to Provider’s audit trail (§6.8).
§5.3 Deletion on request
On written request from the LEA, or forwarded by the LEA on behalf of a parent, Provider shall (a) place the affected Student Data into soft-delete in production within five (5) business days, (b) confirm the action in writing to the LEA contact, and (c) complete hard-delete in production no later than thirty (30) days from the soft-delete date. Provider shall certify deletion in writing if requested. Aggregate de-identified data derived from the deleted records may be retained.
§5.3.1 Backup persistence
Provider operates three structurally-distinct backup lanes (described in §7A.6) for disaster-recovery purposes. Backups taken beforea deletion request retain a snapshot of the Student Data for the duration of the lane’s retention window — currently up to seven (7) days for Firestore Point-in-Time Recovery, fourteen (14) days for Firebase-managed daily snapshots, and thirty (30) days for the project-isolated Google Cloud Storage export lane. The thirty (30) day GCS retention is governed by a bucket-level retention lock and cannot be expedited by Provider, by Provider’s owner credentials, or by any single technical actor; this immutability is a load-bearing security control against credential-compromise destruction of recovery surfaces. Backups taken aftera deletion request reflect the post-deletion state. All backup copies of deleted Student Data age out of all lanes within thirty (30) days of the deletion request. Provider shall not restore deleted Student Data from a backup absent the LEA’s specific written instruction (e.g., for the LEA’s own legal-hold or recovery purposes); routine restore operations exclude any data that has been the subject of a deletion request.
§5.4 Student withdrawal
On student withdrawal from the LEA, the LEA may request deletion of the withdrawn student’s Education Records under §5.3. Absent a specific request, Provider shall apply its standard retention schedule, which is documented at the per-collection level in Provider’s internal data-retention policy (summarized: behavioral / response-pattern data — three (3) years; access logs — three (3) years; classroom membership — through end-of-school-year + four (4) academic years; SME pool-promotion review records — seven (7) years; transient classroom artifacts (game state, roster import scratch space) — thirty (30) days). Material changes to the standard retention schedule shall be communicated to the LEA contact within thirty (30) days of effective date.
§5.5 Data portability
On written request, Provider shall provide Student Data for an identified student or class in a machine-readable format (JSON or CSV, at Provider’s election) within thirty (30) days, at no cost to the LEA or the parent.
§5.6 Directory information
Provider shall not release any Student Data that the LEA has designated as “directory information” under 34 CFR § 99.37 without the LEA’s prior written consent, notwithstanding any general FERPA permission for directory information.
Page 4 · Growing Standard DPA template
§6 · Security
§6.1 Security program
Provider maintains a written information-security program that implements administrative, technical, and physical safeguards appropriate to the nature of the Student Data. The program is reviewed annually and on material architectural change. The most recent full review occurred on [most recent review date].
§6.2 Encryption in transit
All Student Data transmitted between client, edge, and origin travels over TLS 1.3 (minimum TLS 1.2 where a client endpoint does not support 1.3). HTTP Strict Transport Security is enforced on Provider web origins with a one-year max-age including subdomains.
§6.3 Encryption at rest
Primary Student Data store (Google Firestore) is encrypted at rest with AES-256-GCM using Google-managed keys. Cache objects stored on Cloudflare R2 are encrypted at rest with AES-256.
§6.4 Access control
Database security rules enforce the authorization model summarized in Exhibit A. Student Data writes are gated on authenticated identity; admin reads are role-gated; cross-classroom enumeration is blocked at the rules layer.
§6.5 Secret management
All shared secrets (API keys, service-account keys, OAuth client secrets, HMAC signing keys) are stored as Cloudflare Workers secrets or equivalent; none are committed to source control. Secret comparisons use constant-time equality.
§6.6 Content Security Policy
Provider enforces a restrictive Content Security Policy on every web response limiting script, connection, frame, and image sources to an explicit allowlist.
§6.7 Dependency hygiene
Provider runs automated dependency monitoring (Dependabot or equivalent) on all client, server, and worker codebases with weekly package updates and monthly build-tooling updates. High-severity advisories are triaged within five (5) business days.
§6.8 Access audit trail
Provider logs administrative and teacher reads of per-student data to an append-only audit collection and retains such logs for no less than one (1) year. Reads of the access log are restricted to platform administrators. The LEA may request an export of access-log entries scoped to the LEA’s students at any time.
§6.9 Annual security review
Provider shall conduct a comprehensive internal security review at least once per calendar year and shall share the remediation list with the LEA on request.
§6.10 Vulnerability disclosure policy
Provider maintains a published vulnerability disclosure policy at growingstandard.com/security with an RFC 9116 machine-readable contact file at growingstandard.com/.well-known/security.txt. The policy sets a safe harbor for good-faith security research, a 90-day coordinated-disclosure window, and a response SLA (acknowledgment within 72 business hours; initial triage within 7 days). Researcher-sourced findings that meet the Data Breach threshold in §2.7 trigger the breach-notification obligations in §7, regardless of how the finding was sourced.
Page 5 · Growing Standard DPA template
§7 · Breach notification
§7.1 Initial notice
On discovery of a Data Breach affecting Student Data of the LEA, Provider shall provide preliminary written notice to the LEA’s designated contact within twenty-four (24) hours of discovery.
§7.2 Full report
Within seventy-two (72) hours of discovery, Provider shall deliver a written incident report to the LEA containing, to the extent known: (a) nature and scope of the Breach; (b) categories of data affected; (c) identified or likely cause; (d) containment actions taken; (e) mitigation and remediation plan; and (f) whether any regulatory notification is required. The seventy-two-hour window tracks the timeline at Va. Code § 18.2-186.6.
§7.3 Affected-individual notification
Affected-individual notification (to parents and, where applicable, students) shall be coordinated by the LEA and supported by Provider. Provider shall bear reasonable costs of notice where the Breach was caused by Provider’s acts or omissions. FERPA recordkeeping per 34 CFR § 99.32(a)(5) shall be supported within thirty (30) days.
§7.4 Cooperation
Provider shall reasonably cooperate with the LEA’s investigation, including providing system logs, access-log exports, and forensic artifacts, and shall preserve relevant audit logs for the duration of the investigation plus three (3) years.
§7.5 Runbook
Provider’s incident-response runbook requires: revocation of the impacted credential, rotation of application shared secrets and Firebase service-account keys, invalidation of SSO OAuth tokens scoped to the affected surface, and preservation of database audit logs for forensic review.
§7A · Service availability and operational incident response
This section addresses non-security operational incidents (outages, performance degradation, data restoration). Security incidents are governed by §7. Provider’s full operational incident-response and database-restore runbooks are available to the LEA on request.
§7A.1 Service-level commitments
§7A.2 Scheduled maintenance
Provider may perform scheduled maintenance with at least seventy-two (72) hours’ advance notice to the LEA. Scheduled maintenance shall not occur during the LEA’s standard instructional day (defined as Monday through Friday, 7:00 AM through 4:00 PM in the LEA’s local time zone) absent emergency need. Time spent in scheduled maintenance does not count against the uptime commitment.
§7A.3 Incident classification and response
Page 6 · Growing Standard DPA template
§7A.4 Communication during incident
During SEV-0 and SEV-1 incidents, Provider shall: (a) post status updates to a publicly-accessible status page no less than once per hour; (b) email the LEA’s designated contact within sixty (60) minutes of the initial acknowledgment, and again at resolution; and (c) deliver a written postmortem within seven (7) days of resolution if the incident affected the LEA’s users.
§7A.5 Postmortem distribution
Postmortems for incidents affecting the LEA shall be shared with the LEA’s designated contact in writing within fourteen (14) days of incident resolution. Postmortems shall include: (a) timeline; (b) root cause; (c) actions taken; (d) action items to prevent recurrence; and (e) any LEA-specific impact summary.
§7A.6 Data restoration
As of the Effective Date, threerecovery lanes are operational on the production database: (i) Firestore Point-in-Time Recovery, with a seven (7) day window at one-minute restore granularity; (ii) Firebase-managed daily scheduled snapshots, with a fourteen (14) day retention window; and (iii) project-isolated daily Google Cloud Storage exports, in a separately-owned Google Cloud Platform project that excludes the production application’s owner credentials, with object versioning and a thirty (30) day bucket-level retention lock that cannot be shortened or removed for the lifetime of the destination bucket. Database delete-protection is enabled on the production database. Provider’s application service-account principal lacks permissions to mutate any of the three recovery lanes. The third lane provides recovery isolation independent of any single Provider credential — including Provider’s owner-level Google account — and is the load-bearing structural protection against credential-compromise destruction of recovery surfaces. On the LEA’s request, Provider shall restore LEA Student Data from the most recent valid recovery point. Restoration shall be initiated within four (4) hours of the request and completed in accordance with the RTO in §7A.1, except for catastrophic events where best-effort applies. Restoration shall exclude any data that has been the subject of a deletion request under §5.3 (see §5.3.1 for backup-persistence handling). Extending the PITR window beyond seven days toward a thirty-five (35) day target remains a Provider configuration option queued separately and may be enabled on LEA request.
§7A.7 Status page
Provider operates a public service status page at [status URL — e.g., status.growingstandard.com] showing real-time operational status of each component (web, iPad, authentication, audio synthesis). Historical uptime is published at least monthly.
§7A.8 SLA reporting
Within fifteen (15) business days after each calendar month, Provider shall make available to the LEA an uptime report showing achieved uptime percentage, any incidents that occurred, and links to relevant postmortems.
§7A.9 SLA credits
Where uptime falls below 99.5% in a calendar month, Provider shall, on the LEA’s written request within thirty (30) days, provide a service credit equal to one day’s pro-rata fee for each percentage point below 99.5%, up to a maximum of fifteen (15) days’ fee per month. Service credits are the LEA’s sole monetary remedy for missed SLA targets, except in the case of repeated or material breach which is governed by §8.2.
§7A.10 Pre-pilot phase
As of the Effective Date, Provider operates without dedicated 24/7 operations staffing. The acknowledgment commitments in §7A.1 are met on a best-effort basis outside business hours. The LEA acknowledges that Provider is in a pre-pilot operational maturity phase and has agreed to the SLA terms above with this context. Provider commits to staffing or contracted-operator coverage scaling with paid-customer count, with full 24/7 acknowledgment coverage triggered upon reaching ten (10) paid customers or one (1) district-scale deployment, whichever first occurs.
§7A.11 Force majeure
Provider’s commitments under this §7A do not apply to outages caused by: (a) the LEA’s network or device infrastructure; (b) third-party DDoS attacks, unless Provider’s defenses are reasonably expected to mitigate; (c) acts of God, war, or government action; (d) failures of Provider’s listed Subprocessors (Exhibit B), provided Provider exercises reasonable diligence in monitoring and pursuing resolution; or (e) the LEA’s misuse of the Services.
Page 7 · Growing Standard DPA template
§8 · Term and termination
§8.1 Term
This Agreement takes effect on the Effective Date and continues for an initial term of [typically one (1) or three (3) years], automatically renewing for successive one-year periods unless either Party provides written notice of non-renewal at least sixty (60) days before the end of the then-current term.
§8.2 Termination for cause
Either Party may terminate this Agreement on thirty (30) days’ written notice of a material breach that remains uncured after such notice. The LEA may terminate immediately on written notice if Provider’s unremediated act or omission exposes Student Data to unauthorized access.
§8.3 Termination for convenience
The LEA may terminate this Agreement at any time on sixty (60) days’ written notice, without cause.
§8.4 Return or destruction on termination
On termination, Provider shall, at the LEA’s election, either (a) return all Student Data to the LEA in a machine-readable format, or (b) destroy all Student Data and certify destruction in writing to the LEA. Either action shall be completed within sixty (60) days of termination. Aggregate de-identified research data generated under §3.6 may be retained.
§8.5 Survival
Sections 2, 3.3, 3.4, 7, 8.4, 9, and 10 survive termination.
§9 · Governing law and general provisions
§9.1 Governing law
This Agreement is governed by the laws of [state of the LEA — typically Virginia] without regard to conflict-of-laws principles. Venue for any dispute is the state or federal courts located in the county where the LEA is headquartered.
§9.2 Independent contractors
The Parties are independent contractors. Nothing in this Agreement creates a partnership, joint venture, or agency relationship.
§9.3 Assignment
Provider may not assign this Agreement without the LEA’s prior written consent, except in connection with a merger, acquisition, or sale of substantially all of Provider’s assets — in which case Provider shall give the LEA thirty (30) days’ written notice and the LEA may terminate under §8.3 if the successor entity does not accept this Agreement in full.
§9.4 Entire agreement
This Agreement and its Exhibits constitute the entire agreement between the Parties with respect to Student Data and supersede any prior understanding or communication. In the event of a conflict between this Agreement and any Provider terms of service or click-through EULA, this Agreement controls.
§9.5 Amendments
Any amendment must be in writing and signed by both Parties.
§9.6 Severability
If any provision of this Agreement is held unenforceable, the remaining provisions shall remain in effect.
§9.7 Notice
Formal notice under this Agreement shall be delivered by email to the designated contacts under §1, with confirmation of receipt, or by commercial overnight courier.
§9.8 Conflict with state-specific rider
If the LEA’s state requires a specific rider (e.g., NY Ed Law § 2-d, California SOPIPA / AB 1584, Illinois SOPPA, Connecticut § 10-234), that rider shall be attached as an addendum. In the event of conflict between this Agreement and a state-specific rider, the rider controls as to the subject matter it addresses.
Page 8 · Growing Standard DPA template
§10 · Compliance representations
Provider represents and warrants that:
§10.1 FERPA
Provider is a School Official under 34 CFR § 99.31(a)(1)(i)(B) and is bound by FERPA’s redisclosure and use restrictions at 34 CFR § 99.33(a).
§10.2 COPPA
Provider operates the Services consistent with the FTC’s school-consent guidance under 16 CFR Part 312, does not engage in targeted advertising to children under 13, and does not disclose Student Data to third parties except as necessary to operate the Services under the LEA’s direction or as required by law.
§10.3 Virginia
Provider complies with Va. Code § 22.1-289.01 (Student Personal Information Protection, as amended by 2025 c. 364, effective April 25, 2026) and acknowledges that Education Record data processed under this Agreement is exempt from the Virginia Consumer Data Protection Act under Va. Code § 59.1-576(C)(19). Provider is not a “school technology provider” within the meaning of § 22.1-289.01(A) — Provider does not supply hardware to the LEA. The Services do not access or monitor a school-issued device’s location-tracking features, audio or video receiving / transmitting / recording features, or student interactions on the device, and therefore the prohibitions added at § 22.1-289.01(C)(4) by 2025 c. 364 are not implicated by Provider’s operation of the Services.
§10.4 State-specific
[Completed where the LEA’s state has additional requirements — e.g., New York Ed Law § 2-d Bill of Rights attachment, Illinois SOPPA roster requirements, California SOPIPA signed acknowledgment, Connecticut § 10-234bb]
§10.5 Insurance
Provider maintains commercial general liability, cyber / data-breach, errors-and-omissions, and media liability insurance in commercially reasonable amounts. A certificate of insurance is available on request. Current coverage: General Liability $2M, Cyber $1M, Errors & Omissions $1M, Media Liability $1M, Business Personal Property $10K.
§11 · Signatures
IN WITNESS WHEREOF, the Parties have executed this Agreement as of the Effective Date.
Growing Standard LLC (Provider)
Signature
Daniel Segal
Printed name
Founder
Title
Date
[District Name] (LEA)
Signature
[Name]
Printed name
[Title]
Title
Date
Page 9 · Growing Standard DPA template
Exhibit A — Data inventory and purpose map
This Exhibit mirrors Provider’s internal data inventory at the time of signature and is refreshed before each LEA exchange.
A.1 Purpose categories
- Instructional — delivering adaptive practice, class tests, and Grow assessments; informing teacher decisions.
- Operational — authentication, role enforcement, entitlement, game save, audit trail.
- Research — anonymized item calibration, validity, reliability.
- Audit — access-log and parent-request trails required by FERPA and §6.8.
A.2 Data-store summary
Data stores processing LEA Student Data at the Effective Date include (non-exhaustive; mirrored from Provider’s per-collection inventory at signing): student and player profiles; soft-deleted account records held during the deletion window (§5.3); classroom rosters, memberships, and assignments with per-student progress and in-app help requests; classroom challenges, games, groups, lesson sequences, MTSS intervention records, and roster-import scratch space; de-identified research response logs; district-provided external benchmark rows (iReady / MAP / Star / SOL imports, where the LEA supplies them); post-assessment teacher-judgment survey records; opt-in reliability-study records; the append-only access-log audit trail (§6.8); the parent / teacher data-request queue (§5.2); and pre-computed aggregate rollups containing no per-student data.
A.3 PII categories collected
A.4 PII categories NOT collected
Full legal name; Social Security Number; home address; phone number; date of birth; device identifier; biometric data; health data; disciplinary records; free / reduced-lunch status; keystroke telemetry; geolocation; advertising identifier; third-party analytics events.
A.5 Hosting
Primary data resides in Google Cloud us-central1. Edge caches on Cloudflare Workers globally. No Student Data leaves the United States in normal operation.
Page 10 · Growing Standard DPA template
Exhibit B — Subprocessors
Refreshed via the §4.5 change-notice mechanism.
Note: The Potato Class school product, as licensed to LEAs under this Agreement, has no in-app purchases. All entitlements covered by this Agreement derive from annual school / district licenses, invoiced directly by Growing Standard LLC via purchase order or ACH. No payment processor handles Student Data, and no payment-processor subprocessor is required for the service.
Page 11 · Growing Standard DPA template · privacy@potatoclass.com