Версия 1.1 · действует с 7 сентября 2026 г.

Data Processing Addendum

This Data Processing Addendum (“DPA”) forms part of the agreement between Milata LLC, Irvine, California (“Milata”, the processor) and the organisation operating a Milata workspace (the “Operator”, the controller) under the Terms of Service. It is published in English only. It is not a policy a parent accepts: parents are the Operator’s data subjects, and their consents are to the Operator’s privacy notice and to Milata’s own Privacy Policy for the platform.

1. Subject matter and duration

Milata processes personal data on the Operator’s behalf to run the Operator’s workspace — enrolment, scheduling, attendance, invoicing, progress reports and the parent portal — for as long as the workspace exists and for the retention period in section 7 afterwards.

2. Nature and purpose

Hosting the workspace, sending its transactional email, taking card payments on the Operator’s behalf where the Operator has enabled them, producing invoices and reports, and keeping the audit records those require. Milata does not use the Operator’s data for any other purpose and does not sell it.

3. Categories of data and data subjects

Guardians: name, email address, the IP address and browser type recorded when a form is submitted, consent records. Students: first name, grade band, attendance, work handed in through the portal and the Operator’s written assessments of it. Operator staff: name, email address, sign-in records. No birthdates and no health information are collected by the platform.

4. Sub-processors

Milata uses exactly four sub-processors, the same four named on the platform’s security page: Cloudflare (DNS, tunnel, edge TLS, Turnstile, cookie-less analytics), Resend (transactional email from one verified domain), Stripe (card payments on Stripe’s hosted page — card details never reach Milata), and the operator’s own hardware, a single server under the operator’s physical control. Milata gives the Operator at least 30 days’ written notice before adding or replacing a sub-processor; the Operator may terminate the workspace within that period if it objects.

5. Security measures — and their limits

The measures are the ones described on the security page, which this DPA incorporates by reference and does not extend: tenant isolation enforced by the database with forced row-level security, family-level isolation for the parent portal, no inbound ports on the host, signed-in pages never cached at the edge, encrypted nightly backups kept 14 days in the cluster and copied off the host, restore drills performed and dated, an append-only audit of every money mutation, and multi-factor authentication enforced for accounts holding the platform-operator role.

The limits are part of the measure. Milata runs on a single self-hosted server: there is no second machine to take over, the recovery point is up to 24 hours (nightly backups, no continuous log archiving), the recovery time objective is one business day, and a restore is whole-database — every workspace returns to the same backup, and no single workspace can be restored to an earlier moment on its own. One database role serves every workspace, so isolation is a database control over the scope the application asserts, not a separate credential per workspace. Tenant-owner multi-factor authentication is not enforced in this release. No uptime figure is promised, and no third-party attestation of any kind has been obtained.

6. Personal data breach

Milata notifies the Operator without undue delay, and in any case within 72 hours of becoming aware, of a breach affecting the Operator’s data, with what is then known about its nature, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken. Milata is a single operator working business hours; notice is by email to the Operator’s owner address.

7. Return, deletion and retention

Return. On written request, Milata returns the Operator’s data within 30 days as a database export of the whole workspace: every row the workspace holds, in one file, including its consent records, its append-only audit of every money mutation, and the files uploaded to it. The set of tables in that export is read from the database catalogue at the moment it runs, not from a list somebody maintains, so a table added to the platform later is in the export the day it exists; and that no other workspace’s rows can appear in it is asserted by a test against the file’s bytes. The export does not contain the platform’s own shared records — the curated funding-source catalogue and the platform-wide email budget — which are Milata’s and not the Operator’s.

Deletion. On termination, Milata then deletes the workspace’s data: every row carrying the workspace’s identifier, the workspace record itself, and the sign-in accounts whose only membership was that workspace. The deletion is verified inside the same database transaction and rolled back if a single row survives it. Those accounts are logged out and disabled in the identity server rather than erased from it, so an account keeps its email address there until the operator removes it by hand; the Operator may ask for that, and it is done as a separate step. Deleted rows persist in the encrypted nightly backups for up to 14 days, and in the off-host copies of those backups, before ageing out; there is no way to remove one workspace from a backup that already exists.

Retention. Records the Operator or its schools must keep for accounting or a charter school’s audit (five to seven years, per the Privacy Policy) are the Operator’s to keep, and they are in the export — Milata retains no copy of a terminated workspace beyond the backup window above. The two operations are run in that order, return before deletion, on written request. Neither is self-serve: the buttons are not built, and each is a command the operator runs.

8. Data subject requests and assistance

Milata forwards to the Operator, within five business days, any request it receives from a guardian concerning the Operator’s data, and assists the Operator in answering it insofar as the platform’s records allow. Milata does not answer such requests on the Operator’s behalf.

9. Audit

On written request, at most once a year, Milata provides the Operator with the documentation behind the security page — the backup and restore job definitions, the restore drill log and the isolation migrations — so the Operator can verify the measures described. On-site audits are not offered.

10. Beta status

The workspace is provided during a beta on self-hosted infrastructure. The Operator acknowledges the hosting model and its limits in section 5 as a condition of the workspace. Milata will give at least 60 days’ notice of any change to the hosting model that would change section 5.

11. General

This DPA is governed by the law of the State of California. Where it conflicts with the Terms of Service, this DPA prevails for the processing of personal data. Liability is as set out in the Terms of Service.