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 signed-in session is bound to one chamber and that binding is applied on the request, not chosen by the browser.
- Three roles: admin, staff and member. A staff account cannot reach another chamber’s data by editing a URL or an identifier.
- 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.
- Payment gateway credentials are encrypted with AES-256-GCM before they are stored.
- Production fails closed. Without the encryption key the application refuses to start rather than running with secrets in the clear.
Money
Chamberflow never touches card data and never holds a chamber’s funds.
- Payments run on Newebpay or TapPay 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
The automation drafts. It does not act on the chamber’s behalf without a human decision.
- Bank reconciliation proposes a match and shows why. A member is only credited once someone confirms it.
- Campaigns, renewal outreach and member emails wait for an explicit send. Nothing goes out automatically.
- 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 strict Content-Security-Policy on every page.
- 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 limiting and input validation on public endpoints and forms.
- Administrative and internal areas carry noindex at the header level, so they cannot be indexed even when a link is forwarded.
What we do not have
A security page that lists only strengths is not a security page. These are current and accurate as of August 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.
- Audit logging is not yet general.
E-signature envelopes and approvals in the morning briefing are written to an audit log. Other administrative actions are not yet covered. This is the next thing being widened, and it is listed here rather than described as complete.
- No penetration test to publish.
No independent penetration test has been commissioned, so there is no report to share.
- No contractual data-residency guarantee.
The database and application are hosted on managed infrastructure in regions chosen for latency. We do not offer a residency commitment and do not claim one.
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.