Security & data handling
What we hold, and what we don't.
Your roster is member records, dues history, and decades of institutional memory. Here is what a fellos site stores, who handles the money, and what your officers control.
Certification
Your vendor questionnaire, answered in writing.
fellos does not hold a third-party security certification today.
No SOC 2 report, no ISO certificate, no auditor's letter. What we can give you is a specific, verifiable account of how the product handles your data — that's the rest of this page.
If your grand lodge, department, or board has a vendor-approval form or a security questionnaire, send it over and we'll answer it directly, in writing.
Send us your vendor questionnaireWhat we store
What a fellos site keeps
Your organization's data lives in your own fellos site. This is the shape of it.
Member records
Names, profile picture, contact details, date of birth, member type, which chapter or org they belong to, officer positions held, and any extra-info fields or attachment types your admins choose to configure. Nicknames and road names too, if your organization uses them. The requests behind membership changes — joining, type changes, transfers, deactivations, and required paperwork — are kept with what was submitted, their approvals, a timeline of the actions taken, and the message thread on each request.
Election records
Election settings and eligibility rules, nominations and who seconded them, candidates' campaign platforms and their discussion threads, every ballot cast, and the certified results. Ballots are secret: fellos shows how a member voted only to that member, who can see their own ballot afterwards as a read-only receipt. Members see no running totals; each candidate's count and percentage reach them after the result is certified. An election is run by an officer whose role carries the Election Conductor designation, or by a Site Admin with Admin Mode on. Whoever runs it follows turnout while voting is open, and sees each candidate's count before certifying the result.
Community content
Feed posts, group posts, comments, reactions, the thread summaries members generate with Summarize, and the files in your document library — including every earlier revision of a file. Who can open a folder's revision history is set folder by folder.
Events and tickets
Event details, RSVPs, ticket purchases, attendee and guest counts, and check-in scans. When a member saves a ticket to Apple Wallet, the pass handed to their device carries the display name and the full name on their profile, your organization's name, the event's title, times, and venue address, the seat line from their purchase — which names their member type — the ticket's own id, and a scan code that stays valid until a week after the event ends. It does not carry their email address, phone number, or home address. A member can also save a ticket to Google Wallet, and that path runs the other way round: fellos registers the pass with Google first, then sends the member a link that carries only the ticket's id and your site's address. The record it registers with Google carries the same two names.
Commerce records
What was sold and to whom: order line items, order status, the shipping address on the order, tracking you enter, and dues charges. Payment status comes back from Stripe by webhook.
Administrative history
An append-only audit log of who did what and when — logins, creates, updates, deletes, approvals, declines, election activity, and AI use — with the actor and a timestamp on every entry.
Notification settings
Each member's own delivery choices: whether notifications also reach them by email, whether they go to their devices by push, and which digest and update emails — getting started, digests, milestones, re-engagement — they want. In-app notifications are always on. Separately, your admins hold which notification types are enabled for each member type, with a few always sent whatever is set, such as a password change or overdue dues. Where a site has browser push configured, it also holds the keys and contact address push delivery needs, and the subscription a member's browser hands over when they opt in on a device. If automated mail to a member's address hard-bounces or draws a spam complaint, that address is held on a suppression list with the reason, and further automated mail to it is held back until it is cleared. Automated mail — notifications, digests, workflow email, password resets — is delivered by Resend: the member's email address and the content of the message are both handed to Resend to send it, and the bounce or spam complaint it reports back is what puts an address on that suppression list.
Sign-in credentials
Email and password. If your Site Admin enables it, members can also sign in with Google, GitHub, or Apple; those logins are matched by email address and never create accounts on their own.
Support tickets
Each ticket's subject, category, priority, and status, the member who opened it, every message on the thread with its author and the time it was sent, and any files attached to it. A member sees their own tickets. fellos support reads the thread, because they are the ones who answer it. A Site Admin with Admin Mode on can read every ticket opened on your site but cannot reply.
What we don't
Three things fellos never touches
Card numbers never touch fellos
Dues, event tickets, and store purchases all check out through Stripe. Card numbers, CVCs, and bank details are entered on Stripe and stay with Stripe. fellos records the order and the payment status Stripe sends back.
We don't sell member data
Your roster is not a product. fellos does not sell, rent, or trade member records, and does not use your members to advertise to anyone. Some of it has to reach an outside company for the service to work at all: Amazon Web Services, which hosts every fellos site, its database and its files; OTTO for search, Ask AI, summaries, the weekly digest summary, the page helpers and the support chat; Resend to deliver email; Google when a member saves a ticket to Google Wallet; Apple's push service, which gets a push token and no member details, to update an Apple Wallet pass; the browser push services of Google, Mozilla, Apple and Microsoft (for Edge), which get the notification encrypted, when a member turns on push; and USPS, UPS, FedEx and DHL, which get tracking numbers only, to track store shipments. Member payments are not on that list: they go through your organization's own Stripe account, so for those Stripe is your organization's provider, not ours.
Your money does not route through us
Payments go directly to your organization's own Stripe account, which your Site Admin connects to fellos through Stripe Connect. Your organization is the merchant, and fellos is not a party to the payment. Funds settle there and pay out to your bank on your Stripe schedule.
Payments
Stripe processes the money, not fellos
Every payment path in the product — dues, event tickets, store orders — runs through Stripe Checkout on your organization's own Stripe account.
Your Site Admin connects your organization's own Stripe account through Stripe Connect. The sign-in happens on Stripe's site, and fellos keeps only the id of the account it connected — no Stripe key is pasted into fellos. Each payment is made on that account, with your organization as the merchant, and Stripe tells fellos when a payment succeeds or fails through a signed webhook. Funds settle into your Stripe account and pay out to your bank on your Stripe schedule. Refunds are issued in Stripe.
That split is also the practical answer for your books: fellos is the record of what was sold and to whom, and Stripe is the authoritative record of the money, fees, and payouts.
AI
Search, Ask AI and summaries run on OTTO
They work on your group discussions — posts and the comments under them. This is what is sent to OTTO, when, and what is logged. The support chat under Help & support is a separate surface, and it is covered at the end.
The provider is OTTO, powered by Watter, under contract to fellos. OTTO does not publish a privacy statement of its own yet; Watter's is the one that covers it in the meantime.
Some of it reaches OTTO without any member doing anything, so it happens whether or not anyone in your organization ever uses an AI feature. Every post and comment is sent when it is indexed for search, with one name for the member who wrote it (their display name, or their full name if they have none), their member type, the group's name and the thread's title; those details are there because they make search and answers better. Each week, up to 48 recent group posts per member are sent to write that member's weekly digest summary: titles, text and group names, without author names. And each time a thread that already has a summary changes, fellos sends it again to regenerate the summary.
The rest is sent when a member uses a feature. A group search sends only the words typed into the search box, so the index can be matched against them; the matching itself runs in your fellos site's own database. An Ask AI question is sent with your organization's name and type, and with the posts and whole threads Ask AI searches and reads to answer it, with each author's name and member type. Summarize sends the posts of the thread with their authors' names and member types. And the page-writing and page-style helpers send the page content they are asked to work on.
Under that contract OTTO does not keep any of it, and does not use your members' posts to train AI models. That is a contractual commitment rather than an audited one — there is no third-party report behind it, for the reason given at the top of this page.
Ask AI answers draw only on groups the asking member is allowed to read, so a private officers' discussion stays out of answers to members outside that group. Each use of Ask AI is written to the audit log with the member and the time, and so is each summary a member generates; whether the automatic regenerations are logged too is something we have not confirmed. An Ask AI question and the answer it returns are not retained anywhere in fellos: no screen shows what a member asked, and the audit entry does not hold the question. A summary is the exception — that one is kept, as the next paragraph describes.
A summary, once generated, is cached in your fellos site. When the thread changes, fellos regenerates it automatically: the thread goes to OTTO again without any member asking. Your admins can switch summaries off, which stops that, and set how long a thread must be before the Summarize button appears. Ask AI has no such switch, and neither does indexing — turning summaries off does not stop posts reaching OTTO. Your site cannot switch off the weekly digest summary either, but each member can unsubscribe from the weekly digest.
The support chat is a second AI surface
Help & support carries a chat panel headed “fellos AI”. By its own greeting it takes questions “about your account, billing, or how to use the platform”, and a “Talk to a human” button sits beside it. It appears only on the Help & support pages, and a member is signed in when they ask, so fellos knows who asked.
OTTO answers it too: the chat is sent to OTTO to draft the answers, and under the same contract OTTO keeps none of it. fellos keeps the chat transcript, and a count of how often each person uses the chat, for as long as your fellos account exists. Unlike summaries, it is not yours to switch off: there is no setting for it in your admin area.
If your vendor review asks about AI, put the questions in your questionnaire and we'll answer them in writing.
Your controls
Most of this is yours to set, not ours
A fellos site is configured by your own officers. These are decisions your organization makes and can change at any time.
- Who can see which profile fields, and which members are visible to whom.
- Which admin levels can request and which must approve onboarding, transitions, transfers, and deactivations.
- Who can curate a document folder and who can see its revision history.
- Your own Terms of Service and Privacy Policy, published at /terms and /privacy on your site and linked from every page. fellos ships default text you are expected to replace with your own.
- Your cookie banner: whether it shows, which consent mode applies (auto by region, opt-in everywhere, opt-out everywhere, or notice only), the wording, and the description of each cookie category.
- Whether social sign-in is available at all, and which providers.
- Who holds site-admin and Comptroller access, with every change recorded in the audit log.
Nothing here is legal advice. Your Privacy Policy and Terms of Service describe your organization's own handling of member data — have them reviewed by someone who knows your jurisdiction and your organization type.
Retention & export
Records are kept on purpose
These organizations need history. The product is built to preserve it rather than quietly discard it.
Deactivation is not deletion
When a member is deactivated their login access is revoked and they come off active rosters, but their profile, posts, event attendance, attachments, and workflow history are kept — that's what governance, historical, and legal record-keeping require. A deactivated member can be reinstated with their history intact.
The audit log can't be rewritten
Administrative actions are append-only. For as long as your site exists, entries cannot be edited or deleted by anyone, including site admins, so the record a board reviews is the record of what happened.
Getting your data out
A Site Admin can download the member roster at any time, as CSV, XLSX or PDF. For the rest of your site's records, a Site Admin can write to support@fellos.app, and we will provide CSV files, with uploaded files as a zip, within 30 days and at no charge. Stripe exports the transaction-level reports for anything touching your bank account. If your organization needs specific data removed, write to privacy@fellos.app.
Cookies & analytics
Nothing loads here until you accept
On this marketing site
One thing measures this site: HeyCatch, which counts page views and clicks so we know which pages earn their keep. Neither this site nor signup.fellos.app loads a Google tag — no Google Analytics, no Google Ads — and neither sets a Google cookie. The banner has one optional category, Analytics, and nothing for it loads until you accept it. Before you choose, and after you reject, HeyCatch is not loaded and sends nothing.
Accept, and HeyCatch stores a random visitor id — in a first-party cookie and in your browser's local storage, for up to a year — so a repeat visit counts as one person and not two. It is never your name or your email, because we don't have them: you don't need an account to read this site, and we don't ask you for one. The sign-in page asks only for your site's name, to check that your site answers and take you there. The one place this site asks for anything about you is the demo-access form, described below.
You can change your choice any time with the Cookie settings link in the footer. Rejecting after you have accepted deletes what HeyCatch stored. If your browser sends a Global Privacy Control signal, it counts as a rejection and overrides every other setting: the banner does not ask, Cookie settings tells you GPC is on instead of offering a choice, and nothing loads.
So that a single answer covers signing up too, the choice is recorded in a small cookie — fellos_consent — on .fellos.app, for one year. It is set whether you accept or reject, and holds only the choice, a format version, and the time you made it; there is no identifier in it. A choice made here or on signup.fellos.app applies on the other, so you are not asked twice, and if you make different choices on the two, the newer one applies.
The demo-access form
The form on See it running is the only thing on this site that asks for anything about you. It takes your name, your email, your organization and what you do there, roughly how many members it has and whether it has chapters, and anything you want to see.
It becomes one email to hello@fellos.app, sent through Resend, the service fellos uses to send mail. Your address goes in the reply-to line so an answer reaches you.
Nothing from it is stored on this site — there is no database here and no file written. The email in that inbox is the whole record, and it is kept for up to two years. The form sets no cookie and is not tied to your analytics choice.
Inside your fellos site
Your Site Admin owns the banner: whether it appears, the consent mode, the wording, and the description of each category. The default mode picks opt-in for the EU, UK, and Brazil, opt-out for the US, and notice-only elsewhere; a visitor whose country can't be worked out gets the banner that asks before any optional cookie is set. Your site loads no fellos analytics or advertising tags.
Strictly necessary cookies — session, security, cart — can't be switched off, because they're what keeps the site working. Everything else your members can toggle from a Cookies link in your footer.
Last reviewed September 2026.
Send us your security questions.
Vendor reviews, security questionnaires, and data-handling questions from a grand lodge, department, or board go to privacy@fellos.app, and get an answer in writing. To report a security problem or an account you think has been compromised, write to security@fellos.app. Anything else goes to hello@fellos.app.