FundView Data Protection and Security Addendum

Version 2.0 Effective August 28, 2026This is the current published version. A signed Order Form is governed by the version identified on it. Superseded versions stay online at the legal index.

This Data Protection and Security Addendum (“DPA”) forms part of the FundView Master Subscription Agreement (“MSA”) between FundView Finance LLC, an Indiana limited liability company doing business as FundView (“FundView”), and District. Capitalized terms not defined here have the meanings in the MSA. If this DPA conflicts with the MSA on privacy, data handling, security, incident response, return, or deletion, this DPA controls.

1. Scope, roles, and instructions

District controls District Data and determines the purposes for which it is submitted and used. FundView acts as District’s service provider and processes District Data only to provide, secure, maintain, and support the Service; follow District’s documented instructions; and comply with law. FundView will inform District if, in FundView’s reasonable opinion, an instruction would violate applicable law.

FundView will ensure that personnel with access to District Data are bound by confidentiality obligations and receive access only as needed for their duties.

2. Data covered

The Service is intended to process:

• district-level financial records, budgets, fund balances, revenues, expenditures, cash-flow models, tax rates, assessed values, debt schedules, and operational plans;
• aggregated payroll, benefits, staffing, and enrollment figures;
• names, district email addresses, roles, and activity of authorized staff users;
• documents District intentionally uploads for enabled document features; and
• reports, narratives, projections, and other output derived from the foregoing.

3. Restricted data

Unless FundView approves a use case in writing and the parties sign appropriate additional safeguards, District will not submit:

• student education records or student-level personally identifiable information;
• Social Security, driver’s-license, passport, or other government identification numbers;
• individual employee payroll, medical, benefits, or human-resources records;
• bank-account, routing, payment-card, or authentication-secret information; or
• information classified as restricted or highly sensitive under District policy or applicable law.

An accidental submission is not automatically a breach by District. Upon identifying restricted data, FundView will promptly restrict access, notify District if FundView discovered it, follow District’s written direction to securely return or delete it, confirm the action, and disclose whether it was transmitted to a Subprocessor before detection.

4. FERPA posture

The Service is designed for district finance and is not intended to receive education records. Aggregated enrollment figures are not student records. If District proposes to transmit education records intentionally, the parties must first execute terms establishing the purpose, District’s direct control, authorized use, access limits, redisclosure restrictions, security, and destruction requirements necessary for the applicable FERPA exception. Until then, FundView is not authorized to receive those records.

5. Architecture and data location

Architecture Schedule

Dedicated per District. Each District runs in its own deployment. FundView provisions a separate application project and a separate database project for each District. There is no shared production database and no shared application instance among Districts.

Isolation control. Isolation is physical at the database level rather than logical within a shared database. Each District's data lives in its own PostgreSQL database with its own hostname, its own credentials, and its own service keys. No table, schema, or row is shared between Districts, so no query, application defect, or access-control misconfiguration can return one District's data to another District's deployment. Within a District's own database, PostgreSQL row-level security is enabled and the public and anonymous roles are denied read access; application access runs through server-side credentials that are never exposed to the browser.

File storage isolation. Uploaded documents, workbooks, tax-rate filings, and district logos are stored in object-storage buckets inside that District's own database project, under the same project-level separation. Buckets holding District documents are private and served only through short-lived signed URLs issued after an authenticated, authorized request. Assets a District chooses to publish publicly, such as its logo on a public board page, are the exception and are marked public deliberately.

User directory and authentication. Each District's deployment has its own authentication directory. Sign-in is Google OAuth against the District's own Google Workspace account; FundView issues and stores no user passwords. A person reaches a District's deployment only if that District's administrator has created a seat record for that exact email address; a valid Google sign-in with no seat record is refused.

Production administrative access. Administrative access to a District's database and hosting projects is limited to FundView's named operator accounts on the database and hosting providers. Access is by individual named account, not a shared login. Service-role database keys and provider API keys are held as encrypted environment variables in the hosting provider's project settings, are never committed to source control, and are never sent to the browser. Application changes reach production only through the version-controlled repository and the provider's build pipeline.

Processing regions. Application compute, the District database, object storage, database backups, transactional email, and AI processing all run in United States regions of the providers listed on the Subprocessor List. The specific database region for a District's deployment is recorded in that District's onboarding record and provided on request.

Third-party access. FundView does not grant any third party administrative access to a District's deployment. The subprocessors on the Subprocessor List have the access inherent in operating the infrastructure they provide, and nothing more.

FundView will not materially reduce the isolation protections stated in the published Schedule during an Order Form term without advance written notice to District.

District Data is stored in the United States. AI and email processing locations are stated in the Subprocessor List. FundView will not describe District Data as processed only in the United States unless every processing path is configured and verified accordingly.

6. Security program

FundView maintains a written security program appropriate to its size, the Service, and the nature of District Data. The controls below are in effect for every District deployment.

Security Schedule

Authentication. Sign-in is Google OAuth 2.0 against the District's own Google Workspace account. FundView does not create, store, or reset user passwords. Multi-factor authentication for District users is governed by the District's own Google Workspace policy, which the District controls. Sessions are carried in signed, HTTP-only, secure cookies and expire.

Authorization and deprovisioning. Access is seat-based. A District administrator grants access by adding a person's exact work email address to that District's seat list with a role, and removes access by deleting that seat record, which takes effect on the person's next request. There is no self-service account creation and no default access. Requests that cannot be positively authorized are refused rather than allowed.

Administrative access. FundView administrative access to production is least-privilege and by individual named account on the hosting and database providers. Personnel with access to District Data are bound by written confidentiality obligations. Service-role and provider API credentials are stored as encrypted environment variables scoped to a single District's deployment.

Encryption. District Data is encrypted in transit with TLS 1.2 or higher, enforced by the hosting and database providers, including for browser traffic, database connections, and calls to subprocessors. District Data is encrypted at rest by the database and object-storage providers using AES-256.

Deployment isolation. As described in the Architecture Schedule: a separate application project, database, object storage, and user directory for each District.

Logging. The Service records authentication events, administrative and settings changes, report lifecycle and release events, publication actions on public-facing pages, and material data-change events on tracked records, with the acting user and timestamp. The hosting and database providers separately retain authentication, request, and database logs under their documented retention settings.

Abuse and rate limiting. AI endpoints, administrative endpoints, and access endpoints are rate limited per user and per source address to limit automated abuse and runaway cost.

Secure development. All Districts run one version-controlled codebase. Changes are reviewed before merge, reach production only through the provider's build pipeline, and are covered by an automated test suite including unit tests and end-to-end browser tests. Database changes ship as versioned, tracked migrations. Dependencies are updated on a regular cadence and when a security advisory affects a package in use.

Backup and recovery. The database provider takes automated daily backups of each District's database, retained for seven days, and FundView can also take an on-demand logical export at any time. Restore is tested when a deployment is provisioned or materially changed.

Incident response. FundView monitors provider alerting and application error reporting, escalates a suspected incident to the FundView incident contact, follows the notice and cooperation obligations in Section 9, and records what happened and what changed as a result.

Subprocessor review. FundView reviews each subprocessor's security posture, contractual commitments, data-handling terms, retention settings, and processing geography at least annually and before adding or materially changing a subprocessor.

What FundView does not claim. FundView does not hold a SOC 2 report, an ISO 27001 certification, or an independent penetration-test report, and does not represent otherwise. If that changes, this Schedule will say so and the evidence will be available on request. FundView will provide the documentation it does have under Section 13.

7. AI processing

FundView may send the minimum District Data reasonably necessary to the commercial AI provider identified on the Subprocessor List to provide enabled narrative, analysis, assistant, or extraction features.

FundView will:

• not use or permit District Data to be used to train a general-purpose or third-party model;
• not opt into provider training or feedback programs for District Data;
• use available limited-retention or zero-retention settings documented on the Subprocessor List;
• restrict AI processing to enabled Service functions;
• maintain human review before District treats output as official or publishes it; and
• review the provider, account settings, training terms, retention, and processing geography at least annually and before materially changing providers.

AI-generated output can be inaccurate. This DPA governs data handling; the MSA governs District’s review and use of output.

8. Subprocessors

District authorizes the Subprocessors listed at fundviewk12.com/subprocessors as of the Order Form date. FundView remains responsible for their processing of District Data to the extent required by the agreement and will contractually restrict them to appropriate use, confidentiality, and security obligations.

FundView will give at least 30 days’ written notice before a new or replacement Subprocessor begins processing District Data, except an emergency replacement may be made first with notice promptly afterward. District may object during that period on reasonable data-protection or security grounds. The parties will work in good faith to resolve the objection. If they cannot, District may terminate the affected feature or Order Form and receive a prorated refund of prepaid unused fees.

9. Security incidents

“Security Incident” means reasonably suspected unauthorized access to, acquisition, use, disclosure, alteration, or destruction of District Data, or an unauthorized event that materially renders District Data unavailable. It excludes unsuccessful activity that does not compromise District Data, such as blocked scans or failed login attempts.

FundView will notify District without unreasonable delay and no later than 24 hours after FundView discovers a reasonably suspected Security Incident. Initial notice may be based on incomplete information and is not an admission of fault.

FundView will provide, as information becomes available: the nature and date of the incident; affected systems and data categories; known or estimated scope; containment and remediation steps; a contact for coordination; and information reasonably needed for District’s legal reporting and notification analysis. FundView will investigate, mitigate, preserve relevant evidence, provide material updates, and reasonably assist District. The parties will coordinate external statements, but neither party may prevent the other from complying with law.

District remains responsible for notices and reports the law assigns to District. FundView is responsible for notices and reports the law assigns to FundView.

10. Government, legal, and records requests

Unless prohibited by law, FundView will promptly notify District of a subpoena, legal demand, or government request seeking District Data and give District a reasonable opportunity to seek protection. FundView will disclose only what it reasonably believes is legally required.

FundView will reasonably assist District with public-records, audit, litigation-hold, and records-retention obligations using available exports. District remains the records custodian and system-of-record owner.

11. Return and portability

During the term, District may use available self-service exports without additional charge. For 60 days after expiration or termination, District may request one complete export at no charge. FundView will deliver it within 30 days in the verified formats listed below:

Export Schedule

• Complete structured data. A full logical export of the District's database, delivered as PostgreSQL dump files together with per-table CSV files, covering every table holding District Data, including financial reports and line items, cash-flow projections and scenarios, assumptions, funds and account structures, tax rates and assessed values, debt schedules, capital and replacement plans, enrollment figures, board records, and the audit and lifecycle event history.
• Reports and workbooks. The report, projection, and forecast exports available in the Service, delivered as XLSX for tabular output and PDF for formatted board-facing documents.
• Uploaded files. Every document, workbook, and filing the District uploaded, returned in the native format in which it was uploaded, with original filenames and the folder or category structure preserved.
• Data dictionary. A written description of the exported tables and columns, key relationships, and units, sufficient for a District or a successor vendor to interpret the export without access to the Service.

Export files are delivered by a mechanism the District accepts, such as an access-controlled transfer link or media the District specifies.

FundView will reasonably assist District in validating completeness. Custom migration, transformation, or consulting work beyond the standard export requires a mutually agreed statement of work.

12. Deletion and backups

Unless District requests earlier deletion after confirming receipt of its export, FundView will delete live District Data no later than 30 days after the later of: (a) the end of the 60-day export-request period; or (b) delivery of the requested export. FundView will confirm deletion in writing on request.

District Data in protected backups will remain isolated and unavailable for ordinary business use and will be deleted or overwritten within thirty (30) days. If a backup is restored for disaster recovery, FundView will reapply the deletion before returning the restored environment to ordinary use.

Deletion may be delayed only by a documented legal hold or legal obligation. FundView will notify District unless prohibited and delete the retained data when the obligation ends.

13. Security information and assessment

On reasonable request no more than annually, FundView will provide available documentation reasonably sufficient for District to assess compliance, subject to confidentiality and security restrictions. FundView is not required to disclose information that would materially weaken security, another customer’s information, or third-party confidential information. The parties may agree on additional assessment terms for a specific procurement.

14. Survival

FundView’s confidentiality, incident-cooperation, return, and deletion duties survive expiration or termination for as long as FundView retains District Data.

Contact for privacy and security matters: support@fundviewk12.com and FundView Finance LLC d/b/a FundView, 22696 County Road 32, Goshen, IN 46526.