Security and data
We say here only what we can show you on screen. No uptime figure, no certificate on the wall. Ask us for the walkthrough on the consultation and we will open the office and show each of these controls where staff use them.
Roles and permissions
| Role | Sees | Can do | Never |
|---|---|---|---|
| Member | Their own profile, the events and groups they opted into, other members only where both have opted in to be seen | Edit their own profile and contact choices, RSVP, book, message another member through the club without exposing a number or an address | Export a list, see another member's contact details, see anything the other member did not choose to show |
| Staff | The members and reservations for their own area: front desk, dining, events | Check in, add a note, apply an approved charge, reply in the club's texting inbox | Broadcast, change consent, export, change another role's permissions |
| Club admin | The whole club: roster, consent log, suppression list, the audit log, every draft waiting for approval | Approve a send, run the importer, connect or disconnect a system, set quiet hours, answer a data request, invite staff and set their role | See a member's private messages to another member; change what a member chose to show |
| Enterprise | The roll-up across every club in the group, drill-down to a club with that club's own admin view | Message a club's managers inside the product, set group-wide policy, provision single sign-on | Bypass a club admin's approval on a member send; export a member roster the club did not release |
Every action by every role is written to an audit log the club admin can read: who, what, when, and from which door.
Ownership and provenance
We read the roster, the statements and the reservations from the system the club already runs. We write back a note, a charge, or the member's own profile. Nothing else. If the club leaves, the club takes its data in an open format and we delete our copy on a date the club sets.
A balance says which system it came from and when it was read. A preference says whether the member typed it or a staff member did. A stale fact says it is stale rather than pretending to be current. Nothing on a screen is a number without a label.
No advertising, no public directory, no data brokers, no list sales. A vendor we connect to sees only what its connection needs and only for the club that connected it. The privacy policy says the same thing in the words a lawyer wants.
We do not keep a second roster that drifts from the club's. The member's spend view, the office's minimums page and the board report are derived from the source each time, so there is one truth and it is the club's.
Protection
Every connection to the member surface, the office and every vendor runs over TLS. There is no plain-HTTP door.
Databases, backups and uploaded files are encrypted on disk by the hosting provider's managed storage. Credentials for vendor connections are held in a secrets store, never in code or in a file the office can open.
Members sign in with a link sent to the email or phone the club already holds for them; no new password to forget. Staff sign in through the club's own Microsoft or Google accounts. Single sign-on is available for groups.
Consent
Nothing sends itself. The system drafts; a person approves. Every outbound message, on every channel, checks the suppression list first, and the ledger row is written before the send leaves.
Next step
On the consultation we open the office and show the consent log, the suppression list and the audit log where staff use them.