Data separation, consents and honest limits
A club entrusts us with children’s data. So below is a mechanism, not an assurance: how separation is built, who sees what, what gets deleted and where the limits are — including the ones we do not like.
-
Separation lives in the database, not the application
Every club is its own tenant. The separation rule stands under every row in the database and applies to the database owner too — not just to code that someone can forget to write.
-
Fail closed
If a query runs without a club context, it returns zero rows. It does not return everything and does not raise an error — it returns nothing. A bug in our code therefore cannot become a disclosure of someone else’s data.
-
One context, one transaction
The application reaches data only through a club context set inside a single transaction, gone when it ends. It does not carry across concurrent requests.
-
Support enters only with a recorded reason
When support needs a look into your club, we enter through the same separation rule. A reason is mandatory — without it there is no entry — and entry and exit are written to the event log.
Separation is the only thing on this page that cannot be added later. That is why it was built before the first feature — and why it has its own test, run on every change.
Every product change must pass this test. If any of the five claims fails, the change does not merge.
-
A club sees only its own membersTwo clubs, the same query, two different results.
-
Without context: zero rowsNot everything, not an error — nothing.
-
Context does not leak between connectionsTwelve concurrent queries, each stays with its own club.
-
A write into another club is rejectedSeparation applies to writes, not only reads.
-
An invalid club is rejected up frontBefore the first query even runs.
tenant_id = nullif(current_setting('app.tenant_id', true), '')::uuid
Without context the value is empty, the condition never holds and the result is empty. That is the entire rule.
A mechanism, not a promise: the test lives in the code repository and gates the merge — it is not a statement in a page footer.
The guardian holds the account
For a minor member it is the guardian who has access, gives consents and receives the invoice. A child’s record is not a standalone unit without a guardian.
-
Access
A minor member has no access that bypasses the guardian. Guardianship is a recorded relationship between a person and a member, not just a phone-number field.
-
Consents
The right to give and withdraw consents rests with the guardian. The member records which guardian is primary and which holds that right.
-
The age of self-consent
It is tied to the club’s country and set in the product’s code, not in a setting someone could move in an admin panel. In Slovenia it is 15.
-
Payer
For each child the club sets who pays — so separated parents can each pay for their own child. The payer can also be someone who is not the child’s guardian: an employer, a municipality or a sponsor.
What of this the parent sees in their app is described on For parents →
Four typed consents
A consent is not a free-text note. There are four types, each with its own state, the person who gave it, and the time.
| Consent | Status | Given by | Recorded |
|---|---|---|---|
| Media for club use Photos and video that stay within the club. |
given | guardian · A. K. | 3. 9. 2025 |
| Media for public posting Photos and video on the club’s public channels. |
withdrawn | guardian · A. K. | withdrawn 14 Jan 2026 |
| Health data Processing of allergies, conditions and medication — special-category data. |
given | guardian · M. K. | 3. 9. 2025 |
| Notifications Optional. Without it the member stays enrolled and loses nothing. |
not given | — | — |
Sample view. One recorded decision per consent type — not two conflicting entries about the same thing. A withdrawal is recorded with its time and version; the previous state is not overwritten as if the consent had never existed.
sample view · demo club names and dates are an illustration, not club data
Health data
Allergies, conditions and medication are structured fields on the member, separate from the rest of the record — so they can be deleted without deleting the member.
A separate record
Health data stands in its own record tied to the member. The separation is not cosmetic — it enables deleting just this part.
Notes stay with the club
Internal notes on a member are visible to the club admin. When the coach leaves, they stay with the club; when the member leaves, they go with them.
The emergency contact
Recorded on the member, so that in an injury it is reachable on the field, not in an office folder.
A coach sees the members of their own divisions — and only those: personal and health data, attendance and by-name reports for the divisions they are assigned to. A refused attempt to read health data is recorded. A coach with no division assigned sees no members at all.
The club schedule stays fully visible, because clash detection is only correct against every session. Name-free club reports and volunteer shifts stay club-wide — stated here, not in fine print.
Permissions are closed by default
Every screen and every deep link requires an explicit grant. Without it the server returns no content — even if someone forwards the address.
| Role | Sees | Does not see |
|---|---|---|
| Club admin Chair, secretary |
Everything: members, schedule, finance, reports, settings, sign-ups, data migration. | — |
| The treasurer Whoever keeps the books |
Fee plans, invoices, payments and arrears, financial reports, the list of members and groups (so they know who to bill). | Children’s health data — money does not need it; editing members, staff or club settings; parents’ conversations. |
| Coach Group leader |
The members of their own divisions and their health data, the attendance of those divisions, the club schedule (for clash detection), announcements, volunteer shifts and the attendance report for their own divisions. | Fee plans, invoices and receivables; editing club settings; editing a member’s personal data; the sign-up queue. |
| Parent Guardian |
Their own children, their schedule and cancellations, their family’s invoices, announcements, volunteer shifts. | Other members and their guardians; other people’s health data; club finances; internal notes. |
| Member An adult or an older minor |
Their own schedule and announcements and their family’s matters, same as a guardian. | Same as for a parent: nothing concerning other families or club finances. |
There are five roles and no more; they add up, so the same person can be treasurer and parent. The treasurer exists precisely so a club does not have to hand full administrator rights to whoever keeps the books — and because money does not need a child’s health data, this role does not see it. A new feature is closed until somebody explicitly opens it, never the other way round.
A shared link · illustration
GET /invoices/9f2c… → 403 · the invoice content is not returned
An invoice address forwarded in a group chat opens nothing. Nothing is visible “just because you have the link”.
The full list of areas and their limits is on Features →
Retention and deletion
Deletion is a product feature, not an e-mail request. It has one limit we cannot remove and two shortcomings we do not hide.
-
Deleting a member in the product
Removes the member and with them their session RSVPs, attendance records, photo, consents, health record and group memberships.
-
The limit: issued invoices
While an invoice exists for the member, deletion is refused — issued invoices may not be deleted, because the records must hold up to review. In that case the member gets a leaving date.
-
Rejected applications in the product
A rejected or returned application holds a child’s data with no membership basis. After 60 days its personal data deletes automatically; only the state and timestamp remain, so the queue statistics stay honest.
-
Configurable retention periods
In settings, the club enters how many months after a member leaves their personal data is erased — six at minimum. With no setting, nothing is erased; there is deliberately no default. Before saving, the club sees by name whose record the next pass would empty.
-
An individual’s request for a copy of their data
A parent or member downloads their copy themselves, without the club or us in the middle. The export always concerns the signed-in person and the children they are guardian of — there is no route by which somebody pulls another family’s file.
Export — at its true limit
The full club export is one action: an administrator downloads a ZIP of CSVs — members, guardians, consents, schedule, attendance, invoices and payments. Health data sits in its own file. Alongside it, you still separately export the the invoice journal and the payment journal for the accountant. No conditions and no exit fee.
Exactly what both journals contain and how accounting uses them is described on For the board →
Hosting being confirmed
On most websites this would say the data stays in the EU. Here it says when you will get that in writing, in a verifiable form.
“We name the hosting location and the subprocessors in the data-processing agreement, before you sign. Until the agreement is confirmed, we do not state these items as fact.”
That is why you will not find a provider name, a region name or a data-location claim on this page. The commitment is made; the written proof is not yet published, and until it is, this row is not green.
The data-processing agreement
The club is the controller, youthstack is the processor. This is not a formality — it fixes who decides about the data and who may only process it.
The club decides
The club determines which data is processed and why. The data is the club’s, including when it leaves us.
We process it on the club’s instructions — not for our own purposes, with no ads and no selling or sharing with third parties.
Signature before data
We sign the data-processing agreement before the first real data enters the system. Migrating your member list is part of setup and happens after the signature, not before.
Subprocessors are named in it individually. Until you get the agreement to review, we claim nothing about them on this page.
Before anything is uploaded
The demo takes 30 minutes and walks through your club: your groups, who coaches whom, who pays. We migrate your existing member list.
You get the data-processing agreement to review before anything is uploaded. · 30 minutes · we do the data migration · setup ≈ 75 minutes of your time, spread over four days