Security
The questions a board asks before choosing a supplier, answered from how the platform is actually built.
Roles decide who can see what, and every call into the system checks a permission. Sign-in tokens live in cookies JavaScript cannot read. Each association’s data is separated, and which association a request belongs to is resolved from the domain it arrives on. Card details are entered at the payment provider and never reach our servers. AI features are off until the association turns them on, and the models run on our own infrastructure. The association is the data controller; we are the processor.
Access is governed by roles made of individual permissions, not by a single "administrator" flag. Every call into the system checks the permission it requires, so a treasurer cannot open minutes and an ordinary member cannot open the admin. Modules an association does not use can be switched off entirely, and then disappear from the menu.
Passwords are never stored in the clear, only as salted hashes. Sign-in tokens are sent as httpOnly cookies, so JavaScript, and therefore an injected script, cannot read them, and they are marked secure and SameSite. Actions that change data also require a CSRF token, and the long-lived session is replaced every time it is renewed.
Every row in the database carries the association it belongs to, and every lookup is scoped to it. Which association a request belongs to is decided by the domain it arrives on, not by anything the client can send along. On top of that, a user needs a role in that particular association to reach the admin at all.
Card details are entered on the payment provider’s own page. The platform gets back an order reference and a status, and never sees the card number. Each association uses its own key with the payment provider; it can be entered but never read back, and is only ever shown masked.
Incidents can be reported anonymously, and when the reporter chooses that, no identity is stored on the case, not even for later use. Each case carries a confidentiality level that decides who in the association can open it at all, so a report about a person is not sitting in plain view of the whole board.
AI is off until the association turns it on, and is only applied to text you hand it: rewriting a paragraph, summarising minutes, answering from your own rulebook. The models run on our own infrastructure rather than at an external model vendor, and every call is logged with its usage so it can be accounted for afterwards.
Pages are served with a strict Content-Security-Policy where each response gets its own nonce, so a script we did not put there cannot run. HSTS pins traffic to HTTPS. Fonts and analytics are served from our own domain, so no third party follows your members around, and analytics only counts after consent.
The association is the data controller and decides what is recorded and who gets access. We are the processor and handle it only to run the service. In practice the part that matters most is yours: keep the list of administrators short, and remove access when a volunteer stops.
Yes. Write to us and we will send it. It is signed together with you, and the text forms part of the terms you can read in advance.
We send the current list on request. It belongs to the data processing agreement and changes with prior notice, so you can object if we replace a supplier.
Yes. The bookkeeping can be downloaded as a SAF-T file directly in the system, and member access and erasure requests are handled in the product. If you are leaving and need everything, we provide a full extract by arrangement.
We notify you without undue delay once we become aware of a breach affecting your data, and give you the information we have so you can meet your own notification duty. That is in the data processing agreement, not only on this page.
More on data and terms: How we use data · Terms and data processing agreement · Contact us