Data Processing Agreement (DPA)

Format: Modeled on the SDPC (Student Data Privacy Consortium) National Data Privacy Agreement v1.0 Vendor: StandUp ("Provider") Effective Date: [SCHOOL: fill in effective date] Version: 1.0 (2026-04-05)

Instructions for Schools/LEAs: This DPA is pre-filled with StandUp's data handling practices. You only need to complete the bracketed [SCHOOL: fill in] fields, sign, and return. Maryland schools should also attach Exhibit MD (see dpa-maryland-exhibit.md).

1. Parties

This Data Processing Agreement ("DPA") is entered into by and between:

Local Education Agency ("LEA"):

• Legal Name: [SCHOOL: fill in LEA legal name]
• Address: [SCHOOL: fill in address]
• Primary Contact: [SCHOOL: fill in name, title, email]
• Data Protection Officer (if applicable): [SCHOOL: fill in]

Provider:

• Legal Name: StandUp (sole proprietorship / pending entity formation)
• Address: Parkville, Maryland, United States
• Primary Contact: Founder, StandUp — danielnwah123@gmail.com
• Website: https://standupedu.com
• Provider's Service: A K-12 educational platform offering an anonymous Q&A Board, an AI Tutor, and a CatchUp lesson-recap feature, available to LEA teachers and students.

The LEA and the Provider are collectively referred to as the "Parties."

2. Term

2.1 Effective Date. This DPA takes effect on the date of the last signature below and remains in effect for the duration of the underlying service agreement or the LEA's use of the StandUp service, whichever is longer.

2.2 Termination for Convenience. Either party may terminate this DPA with thirty (30) days' written notice. Upon termination, Section 8 (Data Return/Destruction) governs.

2.3 Survival. Obligations relating to confidentiality, data destruction, breach notification, and audits survive termination.

3. Definitions

• Student Data — Any information, in any medium, directly related to an identifiable student that is maintained by the LEA or by the Provider on the LEA's behalf. Includes personally identifiable information (PII) as defined under FERPA, 34 CFR Part 99.3.
• Education Records — Records directly related to a student and maintained by an educational agency or institution, as defined in FERPA, 34 CFR § 99.3.
• De-identified Data — Student Data from which all direct and indirect personal identifiers have been removed such that the remaining information cannot reasonably be used to identify an individual.
• Targeted Advertising — Presenting advertisements to a student where the advertisement is selected based on information obtained or inferred over time from that student's online behavior, usage of applications, or Student Data.
• Sub-processor — A third party engaged by the Provider to process Student Data on the Provider's behalf.
• School Official — As defined under FERPA's "school official" exception, 34 CFR § 99.31(a)(1)(i)(B). The Provider operates as a School Official under the LEA's direct control with respect to Student Data.
• Authorized Use — Use of Student Data solely to provide the contracted educational service to the LEA.

4. Data Ownership and Control

4.1 LEA Ownership. All Student Data transmitted to or collected by the Provider in connection with the service remains the exclusive property of, and under the direct control of, the LEA.

4.2 Provider as Custodian. The Provider holds Student Data solely as a custodian acting on behalf of the LEA.

4.3 No Secondary Use. The Provider shall not use Student Data for any purpose other than the Authorized Use set forth in this DPA.

4.4 Parental Access. Upon request of the LEA, the Provider will make Student Data available so that the LEA can respond to parental requests to inspect, review, amend, or delete Education Records under FERPA.

5. Permitted Uses

5.1 Authorized Use. The Provider may use Student Data only to:

• (a) Deliver the StandUp service to the LEA's teachers and students;
• (b) Maintain, support, and improve the service for the LEA;
• (c) Respond to user support requests;
• (d) Comply with legal obligations.

5.2 Prohibited Uses. The Provider shall not:

• (a) Sell, rent, or trade Student Data;
• (b) Use Student Data for Targeted Advertising;
• (c) Build or enhance a profile of a student other than in furtherance of the Authorized Use;
• (d) Use Student Data to train, fine-tune, or otherwise improve any large language model, machine learning model, or artificial intelligence system — whether the Provider's own or a third party's;
• (e) Disclose Student Data to any third party except Sub-processors listed in Section 6 or as required by law.

5.3 No AI Training. The Provider confirms that all AI Sub-processors (Section 6) are configured via API business terms that contractually exclude LEA data from model training.

5.4 De-identified Data Exception. The Provider may use De-identified Data for product analytics, research, and service improvement, provided such data cannot be re-associated with any individual student or LEA.

6. Sub-processors

6.1 Current Sub-processors. The Provider uses the following Sub-processors to deliver the service. Each Sub-processor is contractually bound to protect Student Data and is engaged under terms no less protective than those in this DPA.

6.2 PII Stripping for AI Sub-processors. Before any request is sent to Anthropic or OpenAI, the Provider strips student names, email addresses, and other direct identifiers from the request payload. Only lesson content and the question text (scrubbed) is sent. See the Provider's Security Documentation and the architecture note in lib/ai-provider.ts for implementation detail.

6.3 LEA Opt-Out. The LEA may request that its traffic be routed exclusively through a subset of AI Sub-processors (for example, "Claude only — no OpenAI failover"). The Provider will honor such requests within ten (10) business days.

6.4 Notice of New Sub-processors. The Provider will notify the LEA in writing (including email to the Primary Contact) at least thirty (30) days before engaging any new Sub-processor that would process Student Data. The LEA may object within that notice period; if the objection cannot be reasonably resolved, the LEA may terminate this DPA without penalty.

6.5 Sub-processor Liability. The Provider remains fully liable to the LEA for the acts and omissions of its Sub-processors.

7. Security Controls

7.1 Reference Document. The Provider maintains a Security Documentation page that describes technical and organizational safeguards in detail. It is incorporated into this DPA by reference and available at https://standuplearn.com/security.

7.2 Summary of Controls. At minimum, the Provider implements:

• Encryption in transit — TLS 1.2+ for all client connections and Sub-processor API calls.
• Encryption at rest — AES-256 at the database and storage layer (Supabase managed).
• Access controls — Row-Level Security (RLS) policies on all Student Data tables; role-based access (teacher/student/admin); principle of least privilege for Provider staff.
• Authentication — Supabase Auth with Google OAuth and email/password; session tokens scoped per role.
• Secrets management — All API keys and credentials stored in Vercel environment variables; never committed to source control; rotation procedure documented in the Incident Response Plan.
• AI kill switch — The Provider can disable all AI Sub-processor traffic within minutes via an environment variable flag.
• Content moderation — All anonymous Q&A Board posts are screened by an AI moderation layer before publication to mitigate harassment and bullying.
• Monitoring — Application logs, database audit logs, and Vercel request logs are retained and reviewed.
• Vulnerability management — Automated dependency scanning; automated security scanning (OWASP ZAP baseline) on production endpoints.

7.3 Penetration Testing. The Provider currently relies on automated security scanning. A full third-party penetration test will be commissioned upon the earlier of: (a) first paid pilot contract of $5,000 ARR or greater; (b) completion of a funding round of $25,000 or greater; or (c) explicit request by an LEA as a condition of contract. This posture is disclosed so that LEAs can evaluate it transparently.

7.4 Staff Training. All personnel with access to Student Data receive annual training on data privacy and FERPA obligations. At this time, the Provider is a sole-founder operation and the founder is the only individual with production access.

8. Data Return and Destruction

8.1 Return on Request. At any time during the term of this DPA, upon written request from the LEA, the Provider shall return all Student Data to the LEA in a machine-readable format (JSON or CSV) within thirty (30) days.

8.2 Destruction on Termination. Within sixty (60) days after termination of this DPA or the underlying service agreement, the Provider shall permanently delete all Student Data from its systems and from all Sub-processors' systems, except where retention is legally required.

8.3 Certification. Upon completion of destruction, the Provider shall provide the LEA with a written certification of destruction signed by the Provider's Primary Contact.

8.4 Backups. Backup copies will be overwritten in the normal course of backup rotation within ninety (90) days of deletion.

9. Data Breach — Notice of Unauthorized Disclosure

9.1 Notification Timeline. The Provider shall notify the LEA's Primary Contact in writing of any confirmed unauthorized access, acquisition, use, or disclosure of Student Data ("Breach") within seventy-two (72) hours of discovery.

9.2 Notification Contents. The notice shall include, to the extent known:

• (a) Date and time of discovery;
• (b) Description of the Breach and the categories of Student Data affected;
• (c) Number of students affected (or estimate);
• (d) Steps taken to contain and remediate;
• (e) Planned steps to prevent recurrence;
• (f) Contact information for the Provider's incident lead.

9.3 Cooperation. The Provider shall cooperate fully with the LEA's investigation and shall assist the LEA with any notifications the LEA is required to make to students, parents, or regulators.

9.4 Remediation Costs. The Provider shall bear the reasonable costs of investigation and notification to the extent the Breach resulted from the Provider's acts or omissions.

9.5 Incident Response Plan. The Provider maintains a documented Incident Response Plan (see Plan 01-07) incorporated by reference.

10. Audits and Inspections

10.1 Right to Audit. Upon reasonable written notice (at least thirty (30) days) and no more than once per twelve-month period (except in the case of a Breach), the LEA may audit the Provider's compliance with this DPA.

10.2 Scope. Audits may include review of security policies, Sub-processor agreements, access logs, and written responses to the LEA's security questionnaire.

10.3 Substitute Audits. In lieu of a direct audit, the Provider may satisfy audit obligations by providing the LEA with current third-party attestations (for example, SOC 2 reports from Sub-processors, or the Provider's own SOC 2 report once obtained).

10.4 Costs. The LEA bears the cost of its own audit activities unless the audit reveals a material breach, in which case the Provider bears reasonable costs.

11. Rights of Parents and Students

11.1 FERPA Rights. The Provider acknowledges that parents and eligible students have the right under FERPA to inspect, review, amend, and request deletion of Education Records.

11.2 Facilitation. The Provider will facilitate the LEA's response to any such request within ten (10) business days of receiving the request from the LEA.

11.3 Direct Requests. If the Provider receives a direct request from a parent or student, the Provider will promptly refer the requester to the LEA and notify the LEA of the request.

11.4 Correction and Deletion. Upon LEA instruction, the Provider will correct or delete specific Student Data within thirty (30) days.

12. General Terms

12.1 Governing Law. This DPA is governed by the laws of the state in which the LEA is located, without regard to conflict-of-laws principles. For Maryland LEAs, see Exhibit MD (attached via dpa-maryland-exhibit.md), which provides Maryland-specific terms and controls.

12.2 Order of Precedence. In the event of a conflict between this DPA and any other agreement between the parties, this DPA controls with respect to data protection obligations. If a state-specific Exhibit (such as the Maryland Exhibit) is attached, the Exhibit controls for terms addressed therein.

12.3 Amendments. Any amendment must be in writing and signed by both parties.

12.4 Assignment. Neither party may assign this DPA without the other party's written consent, except in the case of a merger, acquisition, or sale of substantially all assets, in which case the Provider shall provide prompt written notice.

12.5 Severability. If any provision of this DPA is held unenforceable, the remaining provisions remain in full force.

12.6 Entire Agreement. This DPA, together with any attached Exhibits, constitutes the entire agreement between the parties regarding the processing of Student Data.

12.7 Exhibits Attached.

• Maryland Exhibit (Exhibit MD) — Maryland Student Data Privacy Act terms (dpa-maryland-exhibit.md) — attach for Maryland LEAs such as BCPS, CCBC, and Towson University.
• [SCHOOL: attach any LEA-specific riders]

13. Signatures

For the Local Education Agency (LEA):

• Signature: [SCHOOL: signature]
• Printed Name: [SCHOOL: name]
• Title: [SCHOOL: title]
• Date: [SCHOOL: date]

For the Provider (StandUp):

• Signature: _________________________________
• Printed Name: [Founder name on file]
• Title: Founder
• Date: [To be signed on receipt of LEA-signed copy]

End of Main DPA — see the Maryland Exhibit for Maryland-specific terms where applicable.

Appendix A — Data Inventory

The following is a non-exhaustive catalog of the Student Data categories the Provider processes on behalf of the LEA. This appendix is incorporated into Sections 3 (Definitions) and 5 (Permitted Uses) of this DPA.

No collection of: Social Security numbers, home addresses, parent names/contact (unless explicitly provided by the LEA), health records, immigration status, disciplinary records, or biometric identifiers.

Appendix B — AI Data Handling Detail

This Appendix supplements Section 5.3 and Section 6.2 of the main DPA and implements the transparency commitments adopted by the Provider regarding AI Sub-processors.

B.1 Request Flow. When a student or teacher interacts with the AI Tutor, submits a question to the Q&A Board that triggers an AI-suggested answer, generates a quiz, or requests a CatchUp lesson recap:

1. The client sends the raw request to the Provider's backend (hosted on Vercel).
2. The backend retrieves relevant lesson context from Supabase (the teacher's uploaded material) via a Retrieval-Augmented Generation (RAG) pipeline.
3. The backend strips direct identifiers (student name, email, any embedded PII detected via pattern matching) from the outgoing payload.
4. The backend routes the request to the selected AI Sub-processor (Anthropic Claude by default; OpenAI as failover, unless the LEA has opted out per Section 6.3).
5. The AI Sub-processor returns a completion; the backend stores the response in Supabase associated with the originating student (for chat history and audit) and returns it to the client.

B.2 Zero Retention. The Provider configures API calls to Sub-processors with zero-retention flags where available (Anthropic: zero_retention via Commercial Terms; OpenAI: store=false on Chat Completions where supported). In all cases, the Sub-processor's terms contractually exclude API inputs and outputs from model training.

B.3 AI Kill Switch. The Provider maintains a feature flag that can disable all outbound AI Sub-processor traffic within minutes. If the LEA instructs the Provider to temporarily disable AI features for any reason, the Provider will comply within one (1) business day.

B.4 Moderation. Anonymous Q&A Board posts pass through a moderation layer (Claude with a moderation prompt, or OpenAI's moderation endpoint as failover) before being visible to other students. Posts flagged for harassment, hate speech, sexual content, or self-harm are held for teacher review rather than published.

Appendix C — LEA Fill-In Checklist

The school-side contact reviewing this DPA only needs to complete the following fields:

• Section 1 — LEA legal name, address, Primary Contact (name, title, email), and optional DPO.
• Section 2.1 — Effective date.
• Section 12.7 — Attach the Maryland Exhibit if the LEA is located in Maryland; attach any additional LEA-specific riders.
• Section 13 — LEA signature, printed name, title, and date.
• If Maryland: also complete Section MD-8 of the Maryland Exhibit.

That is the full list of school-side actions. Every other field in this DPA has been pre-filled by the Provider.

Appendix D — Frequently Asked Questions for Reviewing IT Administrators

The following questions are the ones most often raised by school IT administrators during DPA review. Answers are summarized here for convenience; authoritative terms remain those stated in the main body of this DPA.

Q1. Does StandUp sell student data? No. Section 5.2(a) prohibits sale of Student Data. The Provider's revenue model is paid subscriptions.

Q2. Is student data used to train AI models? No. Section 5.2(d) prohibits use of Student Data to train, fine-tune, or improve any AI system. API calls to Anthropic and OpenAI are made under commercial terms that contractually exclude inputs from training, and where supported, the "zero retention" flag is enabled (Appendix B.2).

Q3. Where is student data stored? In the United States, at Supabase's us-east-1 region. See Section 6 and Appendix A. Cross-border transfer requires LEA consent (Maryland Exhibit MD-5.5 for Maryland LEAs).

Q4. Who can access student data on the Provider's side? At present, only the founder has production access. All access is logged. A future ops role would be subject to the same obligations (Section 7.4).

Q5. How quickly will we be notified of a breach? Within 72 hours of discovery (Section 9.1). Maryland LEAs also receive the MPIPA notice under Exhibit MD-4.

Q6. Can we request deletion mid-term? Yes. Section 8.1 requires return within 30 days of a written request; Section 11.4 requires correction or deletion of specific records within 30 days.

Q7. What happens if Anthropic or OpenAI has a security incident? The Provider is fully liable to the LEA for Sub-processor acts and omissions under Section 6.5, and will notify the LEA under Section 9 upon confirmation.

Q8. Is penetration testing performed? Automated scanning is performed today; full third-party pen testing is triggered by specific revenue/funding/LEA-request thresholds disclosed in Section 7.3. This is stated transparently rather than obscured.

Q9. How is anonymous Q&A protected from harassment? Every Q&A Board post passes through AI content moderation before publication; flagged posts are held for teacher review (Appendix B.4).

Q10. Can we opt out of a specific AI Sub-processor? Yes. Section 6.3 allows an LEA to request routing to a subset of Sub-processors (for example, Claude only).

Document version 1.0 — questions about this DPA may be directed to danielnwah123@gmail.com.

Exhibit MD — Maryland Student Data Privacy Terms

Attachment to: Data Processing Agreement (dpa-template.md) Applies to: Maryland Local Education Agencies (LEAs), including Baltimore County Public Schools (BCPS), the Community College of Baltimore County (CCBC), Towson University, and any other Maryland public or non-public educational institution. Version: 1.0 (2026-04-05)

This Exhibit modifies and supplements the main DPA to address Maryland-specific requirements. In the event of a conflict between the main DPA and this Exhibit for a Maryland LEA, this Exhibit controls for the matters it addresses.

MD-1. Governing Maryland Statutes

This Exhibit implements the Provider's obligations under:

• Maryland Student Data Privacy Act of 2015 (Md. Code, Education Article § 4-131), including subsequent amendments.
• Maryland Personal Information Protection Act ("MPIPA") (Md. Code, Commercial Law Article §§ 14-3501 – 14-3508), governing breach notification.
• Maryland State Department of Education (MSDE) vendor data privacy expectations and related guidance from the Maryland Association of Boards of Education (MABE).
• Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g; 34 CFR Part 99, as incorporated by Maryland law.

Where applicable, the Provider also respects the provisions of the Maryland Confidentiality of Medical Records Act to the extent any health-adjacent information (for example, accessibility accommodations) is processed.

MD-2. Targeted Advertising Prohibition

In addition to Section 5 (Permitted Uses) of the main DPA, and consistent with Md. Code, Education § 4-131:

1. The Provider shall not engage in targeted advertising of any kind directed at any Maryland student or at any individual based on information obtained from the Provider's service.
2. The Provider shall not use Student Data (including usage patterns, metadata, or inferred characteristics) to target advertising either on the StandUp service itself or on any other site, application, or service.
3. The Provider shall not sell Student Data. This includes disclosure for monetary or non-monetary consideration, except as a necessary component of a merger, acquisition, or bankruptcy, in which case the successor entity is bound by this Exhibit.
4. The Provider confirms that its revenue model is subscription-based (paid by the LEA or teacher) and does not rely on advertising.

MD-3. Biometric Data Restrictions

1. The Provider does not collect, store, or process biometric identifiers (fingerprints, face geometry, voiceprints for identification, retinal scans, or similar) as part of the StandUp service.
2. The Live Voice Tutor feature processes audio for transcription only; audio is not used for voice-based identification, is not retained beyond the active session unless the LEA explicitly opts into recorded session history, and is never shared with Sub-processors for model training.
3. If the Provider ever introduces a feature that would process biometric identifiers, the Provider will notify the LEA in writing at least sixty (60) days in advance and obtain written authorization from the LEA before enabling the feature for the LEA's users.

MD-4. Maryland Breach Notification (MPIPA)

This section supplements Section 9 (Data Breach) of the main DPA.

1. Timeline. For any Breach affecting Maryland residents, the Provider shall notify the LEA's Primary Contact as soon as reasonably practicable, but in no event later than forty-five (45) days after discovery, which is within the maximum MPIPA timeline (Md. Code, Commercial Law § 14-3504). The seventy-two (72)-hour notice required by Section 9 of the main DPA takes precedence where applicable — in practice, Maryland LEAs will receive notice within 72 hours.
2. Attorney General Notice. Where MPIPA requires notification to the Maryland Office of the Attorney General (generally, Breaches affecting 500 or more Maryland residents), the Provider shall cooperate with the LEA so that the LEA can make the required notification, or, where the Provider is the party required to notify under MPIPA, the Provider shall make the notification and provide the LEA with a copy.
3. Contents of Notice. Notices shall comply with MPIPA § 14-3504(g), including: description of the incident, categories of information affected, steps taken, contact information, and advice on steps individuals can take to protect themselves.
4. Credit Monitoring. Where a Breach exposes Social Security numbers, financial account numbers, or similar sensitive information of Maryland residents, the Provider shall provide at least eighteen (18) months of credit monitoring at no cost to affected individuals, as required by MPIPA § 14-3504(g)(2).
5. Language of Notice. Notices shall be provided in plain English and, upon request, in Spanish or other languages commonly spoken in the LEA's community.

MD-5. MSDE Vendor Expectations

The Provider acknowledges and commits to the following expectations derived from MSDE and MABE vendor guidance:

1. Data minimization. Collect only the Student Data necessary for the educational purpose — the Provider collects student name, email (school domain), grade level, class enrollments, and user-generated content (questions, answers, quiz responses). It does not collect Social Security numbers, home addresses, financial information from students, or health records.
2. Maryland-located primary contact. The Provider's founder resides in Maryland and is available to respond to Maryland LEA inquiries within one (1) business day.
3. Compliance with MSDE audits. The Provider will cooperate with any MSDE inquiry or guidance applicable to K-12 vendors.
4. Accessibility. The Provider commits to WCAG 2.1 AA-level accessibility efforts for student-facing interfaces, consistent with MSDE accessibility expectations.
5. Data residency. All Student Data is stored in the United States (Supabase us-east-1). The Provider will notify the LEA in writing before relocating Student Data outside the United States, and such relocation requires LEA consent.

MD-6. Parental Rights under Maryland Law

In addition to Section 11 of the main DPA, the Provider acknowledges that Maryland law reinforces parental rights to:

1. Inspect and review any Student Data held by the Provider about their child.
2. Request correction of inaccurate Student Data.
3. Request deletion of Student Data that is no longer necessary for the educational purpose.
4. Receive a copy of this DPA and this Exhibit upon request to the LEA.

The Provider will facilitate the LEA's response to such requests within ten (10) business days, as specified in Section 11.2 of the main DPA.

MD-7. Cross-References to Main DPA

This Exhibit cross-references the following sections of the main DPA:

• Section 5 (Permitted Uses) — supplemented by MD-2 (targeted advertising) and MD-3 (biometric data).
• Section 6 (Sub-processors) — unchanged; the Sub-processor list in Section 6 applies to Maryland LEAs without modification. Maryland LEAs retain the opt-out right in Section 6.3 of the main DPA.
• Section 7 (Security Controls) — unchanged; the controls listed in Section 7 meet or exceed MSDE vendor expectations.
• Section 8 (Data Return and Destruction) — unchanged.
• Section 9 (Data Breach) — supplemented by MD-4 (MPIPA notice, credit monitoring, AG notice).
• Section 11 (Rights of Parents and Students) — supplemented by MD-6.
• Section 12.1 (Governing Law) — for Maryland LEAs, this DPA is governed by the laws of the State of Maryland, without regard to conflict-of-laws principles. Venue for disputes lies in the state or federal courts located in Baltimore County, Maryland, or in the county where the LEA is located, at the LEA's election.

MD-8. Signatures (Exhibit Acknowledgment)

The undersigned Maryland LEA and the Provider acknowledge that this Exhibit MD is attached to, and forms an integral part of, the main DPA.

For the Maryland LEA:

• Signature: [SCHOOL: signature]
• Printed Name: [SCHOOL: name]
• Title: [SCHOOL: title]
• LEA Name: [SCHOOL: LEA legal name]
• Date: [SCHOOL: date]

For the Provider (StandUp):

• Signature: _________________________________
• Printed Name: [Founder name on file]
• Title: Founder
• Date: [To be signed on receipt of LEA-signed copy]

End of Exhibit MD. Return with the signed main DPA to danielnwah123@gmail.com.