Data protection policy

The parents' community that runs a class is the controller of that class's data. It decides which children are on the roster, which parents are linked to them, which bank account is read and what each cost is split by. In practice these decisions are made by the chair, on the community's behalf.

The Future Quest Kft. — the company that owns and operates ClassFund.Club, registered seat Budapest, Hungary, company registration number 01-09-349062 at the Fővárosi Törvényszék Cégbírósága, tax number 27094455-2-43, EU VAT number HU27094455 — is the processor. We hold and process that data to provide the service and for nothing else. We never use a class's records for our own purposes — not to improve a model, not to compile statistics we publish, not to sell to anybody.

For a small number of things we are the controller in our own right: your account, the way you sign in, and the plan your class buys. Those are covered by the privacy policy, not by this document.

The subject matter is running a class fund. The duration is for as long as the class exists on the service. The nature of the processing is storage, organisation, matching, calculation and display.

A class is mostly a list of children, so this deserves its own section rather than a line in a table.

• ·ClassFund.Club never collects anything from a child. Children have no accounts, are never asked to agree to anything and never see the app.
• ·What is held about a child is a name and a money record. We do not ask for dates of birth, addresses, health data or school performance, and there is nowhere in the software to put them. The one optional extra is a picture: a guardian, or the chair, may add one to a child's page and may remove it at any time. Nobody is asked for it, nothing depends on it, it is shown only to the people who may already open that child's page, and it is deleted with the child.
• ·A teacher can never see a family's balance or payment. Of the bank, a teacher sees only the outgoing payments of an account the chair has linked to the card that teacher pays with, so that they can attach them to the expenses they record; never the money coming in, and never a payment tied to a family. That separation is enforced on the server, not merely hidden in the interface.
• ·A parent sees their own children and no others.

The chair should put no more into the notes field than the class genuinely needs. It is a free text box, and a free text box is where unnecessary personal data always ends up.

We process a class's data only on the documented instructions of its controller. Using the service is that instruction: when the chair imports a statement, connects a bank, records a cost or links a parent to a child, that is the instruction, and we carry it out.

We will process it otherwise only where EU or member state law requires us to, and in that case we will tell the controller first unless the law forbids it. If we ever think an instruction breaches data protection law, we will say so rather than quietly comply.

Everyone with access is bound by confidentiality, and that obligation outlives their involvement.

We use the suppliers below. Each is engaged under a written contract imposing the same obligations that this document imposes on us, and we remain fully liable to the controller for what they do.

The last two are engaged only once a member asks us for help. A controller whose members never do is one whose data never reaches either of them.

Identity providers — Microsoft and Google — are not sub-processors for a class's data. They authenticate a person; they are never given anything about a class.

Before we add or replace a sub-processor we will give notice in the app and by email to the chair, in time to object. If a controller objects on reasonable data protection grounds and we cannot resolve it, they may terminate and take their data with them.

The technical and organisational measures required by Article 32, stated plainly enough to be checked:

• ·All traffic is encrypted in transit with TLS. Backups are encrypted at rest and stored separately from the running system.
• ·Access is decided by role, on the server, on every request. A parent cannot reach another family's records by editing a URL, and a teacher cannot reach a family's money at all.
• ·There are no passwords to steal: sign-in is delegated to an identity provider the person already uses.
• ·Bank access is read-only. No part of ClassFund.Club can initiate a payment, so no compromise of ClassFund.Club can move a class's money.
• ·Bank consents are limited in scope and time, are tied to the browser that started them, and can be withdrawn by the chair at any moment.
• ·Backups are taken daily, kept apart from the primary system, and their restoration is what the whole arrangement is tested against.
• ·Every amount is stored as an integer in minor units, so a rounding error cannot silently corrupt a balance — an integrity measure as much as an accounting one.

Requests from parents, children's guardians or anybody else in the class go to the controller, because the controller is the one who has to answer them. Most of what is asked for, the chair can do immediately and without us: correct a name, unlink a parent, remove a child, delete a class.

Where the chair cannot do it from the app, we will help — with whatever the case needs, promptly and at no charge. If a request reaches us directly, we will not answer it ourselves; we will pass it to the controller and tell the person we have done so.

We will also help the controller with a data protection impact assessment or a consultation with a supervisory authority, if one is ever needed.

If we become aware of a personal data breach affecting a class, we will notify the chair without undue delay and in any case within 48 hours of becoming aware — which leaves the controller time inside its own 72-hour deadline to the supervisory authority.

The notice will say what happened, which categories of data and roughly how many people are affected, what the likely consequences are, and what we have already done about it. If we do not know everything at first, we will send what we have and then keep sending as we learn more, rather than waiting until the picture is complete.

A class's data is stored in the European Union. Where a sub-processor's group reaches outside the EEA, the transfer rests on an adequacy decision where one applies and on Standard Contractual Clauses where it does not. No class data is transferred for any purpose other than running the service.

When a class is deleted, everything belonging to it is deleted with it: students, guardianships, transactions, activities, shares, adjustments, matching rules, bank connections, the class's audit trail, and its group at our support desk together with every request shared with that group or raised by a member who leaves with the class. So is the account of every member who belongs to no other class. Two things are kept: the accounting record of what was ordered and invoiced, which the law requires us to keep for eight years and which we cannot delete on request; and the copies of the messages the app sent about the class, which our compliance archive keeps for eighteen months after the deletion and then deletes automatically.

A controller may ask for its data back, in a machine-readable form, at any time before deletion. Backups age out on their own schedule after a deletion; within that window a deleted class exists only in an encrypted backup and is never restored to the live system except as part of restoring the whole system after a failure.

We will make available to a controller whatever information it needs to satisfy itself that these obligations are met, and will allow and contribute to an audit or inspection it or its auditor conducts, on reasonable notice and in a way that does not compromise another class's data.

Separately, each class has its own audit trail, which serves the controller's accountability under Article 5(2) of the GDPR. It records every activity in the class — sign-ins, invitations, bank syncs and statement imports, how each cost was recorded, split and changed, corrections, payment links opened, reports sent, changes to the plan and recommendations — each with who did it and when. It can be read only by members with the chair role in that class; no other class and no other member can see it. It is an immutable, transparent record: once an entry is written, nobody using the service — the chair included — can change or delete it, the database itself refuses to, and we do not alter it either. Entries are kept for eighteen months from the event and then deleted automatically; the trail is deleted together with the class.

Anything in this document: privacy@classfund.club. We have not appointed a data protection officer, because the scale of the processing does not require one under Article 37; if that changes we will name one here.