Data Privacy Agreement

1. Definitions

• 1.1 “District Data” means all data, content, and records the District or its Authorized Users submit to, or that the Services generate on the District’s behalf within, the Services — including board-member and staff contact information, meeting and agenda content, negotiation and bargaining materials, and evaluation records.
• 1.2 “Government Data” means District Data that is “government data” as defined by the Minnesota Government Data Practices Act, Minn. Stat. ch. 13 (“MGDPA”).
• 1.3 “Personal Data” means District Data that identifies or can reasonably be linked to an individual.
• 1.4 “Subprocessor” means a third party BoardOps uses to process District Data in providing the Services.
• 1.5 “Data Incident” means a confirmed unauthorized access to, or acquisition, loss, or disclosure of, District Data in BoardOps’ control.

2. Roles & ownership

• 2.1 Ownership. As between the parties, the District owns and controls all District Data at all times. BoardOps obtains no ownership rights in District Data.
• 2.2 Roles.The District is the controller and responsible authority for District Data. BoardOps acts solely as the District’s service provider and data processor, handling District Data only on the District’s documented instructions and as needed to provide the Services.
• 2.3 Government data.The parties intend that Government Data remains subject to the MGDPA and under the District’s control while in BoardOps’ custody. BoardOps will handle Government Data consistent with the District’s obligations under the MGDPA to the extent BoardOps has been informed of them.

3. Scope of data

• 3.1 Expected data. The Services are designed for board governance and administration. District Data is expected to consist of governance records, board and staff contact details, negotiation and bargaining content, agenda and meeting materials, and superintendent and board evaluation records.
• 3.2 Student records. The Services are not intended to collect or store student education records. The District will not submit student personally identifiable information or FERPA-protected education records except as the parties agree in writing.
• 3.3 FERPA (contingency). If the parties later agree that the Services will process student education records, BoardOps will act as a “school official” with a “legitimate educational interest” under FERPA (20 U.S.C. § 1232g; 34 CFR Part 99), will use those records only to provide the Services, and will not re-disclose them except as permitted by FERPA and directed by the District. A FERPA addendum will be attached before any such data is submitted.

4. Use of District Data

• 4.1 Permitted use. BoardOps will process District Data only to provide, maintain, secure, and support the Services, and as otherwise instructed by the District in writing.
• 4.2 No sale; no secondary use. BoardOps will not sell, rent, or share District Data, and will not use District Data for advertising, for building or training external or third-party advertising or marketing profiles, or for any purpose other than providing the Services. BoardOps will not use District Data to train third-party or publicly available AI models.
• 4.3 Aggregated / de-identified data. BoardOps may use aggregated or de-identified data that cannot reasonably be linked to the District or any individual to operate and improve the Services. BoardOps will not attempt to re-identify such data.
• 4.4 Personnel. BoardOps limits access to District Data to personnel who need it to provide the Services, and binds them to confidentiality obligations.

5. Subprocessors

5.1 Authorized subprocessors. The District authorizes BoardOps to use the following subprocessor(s) to host and process District Data:

• Google LLC — Google Cloud Platform / Firebase (cloud hosting, database, authentication). Data stored in the United States Central Region.
• Postmark (ActiveCampaign, LLC) — Transactional and notification email delivery (account, system, and meeting notifications). United States.
• Google LLC — Google Workspace / Gmail — Business email correspondence with the District, which may contain District contact information. United States.
• Stripe, Inc. — Payment and invoicing processing; processes District billing and payment information. United States.
• Anthropic, PBC — Powers AI-assisted features by processing District Data solely to generate outputs for the District. Used under Anthropic’s commercial API terms, under which District Data is not used to train models. United States.
• Google LLC — Gemini (via Google Cloud / Vertex AI) — Powers AI-assisted features by processing District Data solely to generate outputs for the District. Used under Google’s enterprise/API terms, under which District Data is not used to train models. United States.

A current, product-wide list of subprocessors is maintained at boardops.org/legal/subprocessors.

• 5.2 Flow-down. BoardOps remains responsible for its Subprocessors and will impose data-protection obligations on them that are no less protective than those in this DPA.
• 5.3 Changes.BoardOps will give the District at least 30 days’ notice before adding or replacing a Subprocessor that processes District Data. If the District reasonably objects on data-protection grounds, the parties will work in good faith to resolve the concern; if they cannot, the District may terminate the affected Services and receive a pro-rated refund.

6. Security

• 6.1 Safeguards.BoardOps will maintain administrative, technical, and physical safeguards designed to protect District Data appropriate to its sensitivity, including: encryption of District Data in transit and at rest; role-based access controls and authentication; logical separation of each District’s data; audit logging; regular backups; and periodic review of its security practices. BoardOps relies on the underlying certifications of its cloud host (Google Cloud / Firebase), which maintains industry-standard certifications such as SOC 2 and ISO 27001.
• 6.2 District controls. The District is responsible for managing its Authorized Users’ access and for using available security features (such as strong credentials).

7. Data incidents

• 7.1 Notice.BoardOps will notify the District without undue delay, and in any event within 72 hours of confirming a Data Incident affecting the District’s Data. Notice will describe what is known about the incident, the data involved, and the steps BoardOps is taking.
• 7.2 Response.BoardOps will take reasonable steps to investigate, contain, and remediate the incident, and will reasonably cooperate with the District’s own breach-response and notification obligations under Minnesota law and applicable federal law. As controller, the District is responsible for determining whether and how to notify affected individuals or regulators.

8. Data practices & individual requests

• 8.1 Access requests. Because the District controls Government Data, requests to inspect, correct, or obtain District Data (including MGDPA data requests) are directed to and handled by the District. BoardOps will provide the District reasonable, timely tools or assistance to locate, export, and produce District Data so the District can meet its response deadlines.
• 8.2 Third-party / legal demands. If BoardOps receives a subpoena, court order, or government demand for District Data, it will, unless legally prohibited, promptly notify the District so the District can seek a protective order or otherwise respond, and will not disclose District Data except as legally required.

9. Return & deletion

• 9.1 Export. During the Term and for at least 30 days after termination, the District may export its District Data in a usable format. BoardOps will provide reasonable assistance with export.
• 9.2 Deletion.Within 60 days after termination (and after the export window), BoardOps will delete or de-identify District Data in its production systems, and will delete it from routine backups within the normal backup rotation cycle, unless retention is required by law. On the District’s written request, BoardOps will confirm deletion.

10. Data location

10.1District Data is stored and processed in the United States. BoardOps will not transfer District Data outside the United States without the District’s prior written consent.

11. Audit & records

11.1On reasonable written request (no more than once per year unless required after a Data Incident or by law), BoardOps will provide the District with a summary of its data-security practices and available Subprocessor compliance reports, so the District can verify BoardOps’ compliance with this DPA without unduly disrupting BoardOps’ operations or compromising other customers’ data.

12. Term & general

12.1This DPA takes effect with the Order Form that incorporates it and remains in effect while BoardOps holds District Data. It survives termination of the MSA until District Data is returned or deleted. This DPA is incorporated into and governed by the MSA, including its governing-law and liability provisions, except that BoardOps’ obligations regarding the security and confidentiality of District Data are treated as set out in MSA §12.2.

Execution

This DPA is executed through the signed Order Form that references it; no separate signature is required. A district that prefers a standalone execution may request a signature copy. Questions: contact@boardops.org. See also our Privacy Policy and Subprocessors list.