Careful with your data. Paranoid with your money.
A chamber’s roster is its membership list, its dues history and, in practice, its balance sheet. This page describes what protects it, specifically enough to be checked, and ends with the things we do not have yet.
Separation between chambers
Every chamber is a tenant. A chamber’s own logins are bound to that chamber, and the binding is applied on the request, not chosen by the browser.
- Three roles: admin, staff and member. A chamber’s login cannot reach another chamber’s data by editing a URL or an identifier.
- The platform operator’s own accounts can open any chamber, to support it. Each time one enters a chamber, that chamber’s audit log records it.
- Each chamber’s public website, member portal and workspace resolve from the host, so one chamber’s branding, prices and roster cannot render on another chamber’s domain.
- Registry lookups throw rather than falling back to a default chamber. A missing configuration is an error, not somebody else’s data.
Credentials and secrets
The things worth stealing are the payment credentials and the passwords, so those are handled separately from ordinary data.
- Passwords are hashed with bcrypt. They are never stored or logged in a readable form.
- On a production deployment, a payment gateway credential is encrypted with AES-256-GCM when it is saved, and if the encryption key is missing the application refuses to save it rather than keep it in the clear.
Money
Chamberflow never touches card data and never holds a chamber’s funds.
- Payments run on Newebpay or Stripe against the chamber’s own merchant account. Card details are entered on the gateway, not on Chamberflow.
- Funds settle directly to the chamber. Chamberflow takes no percentage of dues, tickets or sponsorship.
- Payments are fulfilled from a server-side order record keyed to a signed gateway order number, so a tampered callback cannot mark an invoice paid.
A person approves anything consequential
AI drafts, and never sends on its own. Automatic messages, such as event reminders and receipts, follow rules the chamber sets.
- Bank reconciliation proposes a match and shows why. A member is only credited once someone confirms it.
- Campaigns and member emails wait for an explicit send. Event reminders are on by default, and each chamber can change or turn them off. Scheduled campaigns and renewal notices go out automatically only once they are switched on for the chamber, and every run is logged.
- Where the evidence for a match is contradictory rather than merely close, the system refuses to guess and escalates it.
Hardening at the edge
Set as response headers so they apply to every route, including the ones that never render HTML.
- A Content-Security-Policy on every page that limits where scripts, frames and form posts may go.
- HTTP Strict Transport Security for two years, including subdomains, with preload.
- X-Frame-Options set to DENY, so the workspace cannot be framed for clickjacking, and X-Content-Type-Options set to nosniff.
- Rate limits on sign-in and on public forms such as event registration, newsletter sign-up and the contact form, and input validation on what public endpoints accept.
- Administrative and internal areas carry noindex at the header level, so they cannot be indexed even when a link is forwarded.
An audit log in every chamber
Each chamber has a log of who did what, and when. Its Director can read it and download it, and it comes with the chamber’s full data export.
- It records staff sign-ins and whether a second factor was used, two-factor changes, team logins and roles, changes to settings and payment details, member record changes, payments staff record, invoices, receipts and credit notes, e-signature agreements, data exports and list downloads, and refused requests.
- The platform operator’s own actions in a chamber, entering it included, are recorded there and marked as the platform’s, apart from the chamber’s own people.
- The audit log keeps a network address only for staff sign-ins, failed staff sign-ins, two-factor steps, the platform operator entering a chamber, agreements signed or declined electronically and refused requests. It keeps the browser only for agreements signed or declined electronically.
- The application only ever adds rows to the log. It never edits or deletes them.
What we do not have
A security page that lists only strengths is not a security page. These are current and accurate as of October 2026.
- No SOC 2 or ISO 27001 certification.
There is no third-party audit behind this product today. If your board requires one, we are not yet the right answer and will say so.
- Two-factor sign-in is for staff, and the Staff app cannot complete it yet.
Staff can add an authenticator app or emailed codes after their password, and a chamber can require it for its whole team. Members have no password and sign in with an emailed one-time code, with no second factor. Until the next version of the Staff mobile app, an account with two-factor turned on signs in on the web.
- No penetration test to publish.
No independent penetration test has been commissioned, so there is no report to share.
- No residency promise beyond what an agreement says.
Hosting regions are set in each chamber’s agreement. The standard setup runs the application and the database in Singapore. Email delivery, drafting assistance and backups use other providers and regions, which the privacy page lists.
Found something, or need a question answered for your board?
Security reports and board due-diligence questions both go to the same place, and a person reads them.