Where Your Data Lives, and Who Can Reach It

Student rosters carry dates of birth, emergency contacts and medical notes. A club's ledger carries who has paid and who has not. If your office is being asked to put that on a third-party platform, "we take security seriously" is not an answer to anything.

Here is the actual mechanism, the parts that are deliberately limited, and the things we do not claim.

The boundary is in the database, not in the application

The failure mode that matters for a multi-tenant platform is one school, or one team, reading another's data. There are two places you can enforce that: in the application code that builds each query, or in the database itself.

Application-layer enforcement fails open. Every new query is a fresh chance for someone to forget a filter, and a forgotten filter returns plausible-looking rows rather than an error, so nothing fails and nobody notices. Database-layer enforcement fails closed: the rows are not returned, whatever the query asked for.

TeamBasin enforces tenancy in the database, through row-level security policies attached to the tables themselves. Every tenant table carries the owning team's id as a required column, and the policies resolve your identity from your authenticated session and check it against real membership records. Application code also filters by team — but as a second layer, not as the boundary. If the application forgets, the database still refuses.

What identity is proved against

This is the detail worth asking any vendor about, because it is where this kind of system usually goes wrong.

A policy has to answer "who is asking, and what are they a member of". The tempting shortcut is to read that from something the request supplies — a header, a parameter, a claim the client sends. It is a shortcut because it is fast and it looks right in review.

It is also forgeable, and we know that concretely: an earlier version of some of these policies trusted a request header, and a member of one team could read and delete another team's records by changing it. It was found by executing the attack against live data inside a transaction that was rolled back, not by reading the policy and reasoning about it. The policies now prove membership against membership records, and a check runs on every change to the codebase that fails the build if a policy authorises on a request header again.

We mention this rather than omitting it because a security page that implies nothing ever went wrong is not believable, and because the response is the actual claim: found by execution, fixed at the boundary, and turned into an automated check so it cannot come back quietly.

Roles are a real boundary, not a hidden menu

Access is scoped by what you are on a specific team, and the scoping is enforced in the same place as tenancy.

• Players see the schedule, their own attendance, the roster and team chat.
• Coaches add attendance and the calendar on top of that.
• Officers and owners reach dues, the ledger and equipment.
• Finance is staff-only. The budget and donor details are not visible to the roster at large. This is enforced by a database predicate, not by which buttons the interface happens to render.
• The most sensitive personal fields — dates of birth, emergency contacts, medical notes — sit behind narrower policies than ordinary roster data, and the everyday "who is on which team" views deliberately do not carry them.

The general rule we hold ourselves to: which columns a screen asks for is a rendering choice, never a security boundary. If something should not be readable, the policy is narrowed, not the query.

What gets written down

• Financial changes are append-only. Every change to a finance record is captured with the person who made it, in a log that has no update or delete path at all — not "we don't expose one", but no policy permitting either operation exists, with the table configured so even its owner is subject to that. If a number is questioned in March, the record of who changed it in October is still there.
• Financial records are never hard-deleted. They are marked deleted and filtered out, so a deletion is recoverable and visible rather than absent.
• Sign-ins are recorded per person per team, which is what lets a school administrator tell an account that is genuinely in use from one that was created and never opened.
• Administrative access to a tenant is read-only. When platform staff need to look at a team's data to answer a support question, the mode that allows it blocks every write. That is enforced by a guard on the mutations themselves rather than by a policy about behaviour.

What we do not claim

• No certifications. There is no SOC 2 report, no ISO 27001, and no third-party penetration test. If your procurement process requires one, we do not have it, and we would rather you learn that here than three meetings in.
• No compliance claim about student records. Whether a platform like this falls under student-records law depends on how your institution adopts it — a club-run tool and an official university system are genuinely different answers. We have done the reading; we have not had it confirmed by counsel, and an institutional agreement is a conversation with your legal office, not a checkbox on a marketing page. Ask us and we will tell you exactly where that stands.
• No claim that nothing will ever go wrong. What we will say is where the boundary is enforced, that defects here are found by trying to break it against real data rather than by reading code, and that each fix becomes an automated check.

Who owns the data

Your program does. It is not sold, and no advertising is run against it. Every person can export their own record, staff can export the roster and the ledger as CSV, and if you leave, that is how the data comes with you.

What to ask us

• Where is tenancy enforced — in queries, or in the database? If the answer is "in our application code", ask what happens when a new query forgets.
• What is your most sensitive field, and which policy covers it? A vendor who answers with a screenshot rather than a rule is describing an interface, not a boundary.
• What can support staff see, and can they change it?
• What is your certification and legal position, exactly? Including the parts that are not done.

If your office needs to work through any of this properly, request access and we will go through the specifics with you — including the parts above that are still open.