Security

Why this matters for synagogue data

Synagogue records are not generic CRM data. Member rosters have historically been targeted by people with bad intent, including stalkers tracking former partners, individuals harassing community members, and antisemitic actors. Cemetery records, family relationships, and donation patterns each carry real risk if exposed.

KehillahOne was built with that threat model in mind, not the standard B2B SaaS one. Separate databases per synagogue, explicit per-area access, audit trails on every change, and the rule that a member can never see another household's records were chosen for a community context, not borrowed from a generic CRM playbook.

Your data is yours

The records inside your synagogue's workspace belong to your synagogue, not to KehillahOne. We treat that as the default everywhere on this page.

• Export at any time. A synagogue administrator can export members, households, donations, yahrzeits, events, and other records whenever they want, with no special request. CSV is the standard format; a full SQL dump is available on request.
• Correction and deletion are immediate. Administrators can update or delete any record from inside the application, without going through us. The recycle bin and audit log exist for the synagogue's use, not ours.
• Leaving KehillahOne. If a synagogue cancels, we provide a full export of the workspace's data on request. Active records are retained for 30 days after cancellation in case the synagogue wants to return or restore. After that, the workspace database is permanently deleted, and copies inside off-site backups age out on the standard rotation.
• No data hostage. Exports are not gated behind a higher pricing tier, an exit fee, or a support ticket. The format is straightforward and the process is the same whether you're staying or leaving.

Tenant isolation (database-per-tenant)

A "tenant" is each synagogue that uses KehillahOne. Every tenant gets its own separate database with its own credentials. Your members, donations, yahrzeits, and financials are not mixed in with any other synagogue's records.

A common alternative is to store every customer's records in one shared database, separated only by a customer-ID column on each row. That approach depends on the application applying the right filter on every query. A single missed check can expose another customer's data. KehillahOne does not work that way; there is no shared table to leak from.

Technical detail: each tenant is a separate MySQL database. The application connects with a database user whose permissions are limited to tenant data. The account that can create or delete databases runs in a separate management process the public app never loads.

Encryption

• In transit: TLS 1.2+ on every connection between your browser, KehillahOne's servers, and any integrated services (such as QuickBooks Online). HTTPS is enforced and HTTP requests are redirected, so sensitive data never travels over the public internet in plain text.
• At rest: Sensitive values stored by the application, including per-tenant database connection credentials and integration refresh tokens (e.g., QuickBooks Online), are AES-GCM encrypted using a key held only on the application server. The key is not stored in the database it protects, so a stolen copy of the database alone is not enough to decrypt those values.
  • Daily backups of every tenant database are encrypted in transit to off-site storage and remain encrypted at rest with the storage provider.
  • Encrypted secrets stay encrypted inside the backup. Restoring a backup does not expose the underlying values.

Personal information we hold

KehillahOne is a system of record for synagogue operations, so by design it holds personal information about your members and the families connected to your community. We collect only what's needed to run the workflows you turn on. Typical categories include:

• Contact details: names, mailing address, email, phone numbers.
• Household & family relationships: spouses, parents, children, and how members are grouped into households.
• Lifecycle dates: birthdays, anniversaries, dates of death, yahrzeit observance dates, b'nei mitzvah dates.
• Giving and dues history: pledges, payments, fund designations.
• Engagement records: event RSVPs, attendance, school enrollment, cemetery plot assignments.
• Member portal credentials: email and bcrypt-hashed password for members who self-serve.

What we don't store: KehillahOne does not store Social Security numbers, government IDs, or full credit card / bank account numbers. Donation payment processing is handled by your payment provider, who returns only a token and a record of the transaction. The card or account number itself never reaches our systems.

How it's used: personal information is used only to operate the synagogue's own workflows on its own behalf: sending yahrzeit reminders, producing dues statements, coordinating events, generating board reports. We do not sell personal information, we do not share it with third parties for marketing, and we do not use one synagogue's data to train models or improve unrelated products.

Sub-processors (vendors who, by virtue of running infrastructure for us, may process personal data on our behalf) are limited to a small set: our cloud hosting provider, our transactional email provider, our media storage provider, and QuickBooks Online (Intuit) when the QBO integration is enabled. Each is bound by its own data-processing terms, and none receive bulk member exports. A current list of named sub-processors is available to customers on request.

Access on request: a synagogue administrator can export, correct, or delete any record at any time from inside the application. If a member or family asks the synagogue for a copy of what's on file about them, or asks for it to be removed, the synagogue can fulfill that request directly without contacting us.

Roles & access control

Inside each synagogue's workspace, KehillahOne's permissions model is built around explicit access to each kind of record. In plain terms: a staff member or volunteer can only see, add, change, or remove a category of information (members, donations, yahrzeits, events, financials, and so on) if a synagogue administrator has specifically granted them that access. The default for any new user is no access; rights are added one area at a time, on purpose.

Permission checks happen on the server. The browser's interface hides controls a user shouldn't see, but that hiding is a convenience. The actual enforcement is the access check the server runs before any record is read or written. A user who somehow crafted a request for an area they haven't been granted would receive an authorization error, not the data.

Authentication and sessions: passwords are bcrypt-hashed and never logged in plaintext. New accounts are required to change their password on first login. When a user signs in, their session is bound both to their user account and to that synagogue's workspace. Even if a session token were somehow copied off a user's device, it could not be replayed against another synagogue's subdomain. Server access by our operators is SSH key-only, restricted to a small named set, and protected by a host-based firewall and brute-force protection.

Recoverability & audit

Records are not hard-deleted. When a member, household, donation, or any other record is removed, KehillahOne marks it deleted and moves it to a recycle bin where an administrator can restore it. Accidental deletions, a common cause of "lost" data, are recoverable without involving support.

Every change to a record is written to an audit log capturing who made the change, when, and what changed. Administrators can review this history to answer questions like "who edited this donation amount?" or "when was this person's email updated?"

Security incidents

If KehillahOne suffers a security incident affecting your synagogue's data, we will tell you. Our commitment:

• We notify the affected synagogue's administrator within 72 hours of confirming an incident, and earlier when we can.
• The notification includes what we know at that point: what happened, what data was involved, and what we're doing about it.
• We follow up with a post-incident report once our investigation is complete, including root cause and the changes we've made to prevent a recurrence.
• We assist the synagogue in meeting any of its own notification obligations under state law. Most US states require that affected individuals be notified directly; KehillahOne will provide the information you need to do that.

QuickBooks Online integration

KehillahOne connects to QuickBooks Online using Intuit's standard OAuth 2.0 flow. We never see or store your Intuit credentials. You sign in directly with Intuit, and Intuit returns a short-lived access token plus a refresh token to KehillahOne.

The data we read from QuickBooks (chart of accounts, general ledger entries, budgets) is stored only inside your synagogue's private database. We do not write data into QuickBooks, and we do not share QuickBooks data with any third party.

You can revoke KehillahOne's access at any time from the Apps section of your QuickBooks Online account, or by clicking Disconnect on KehillahOne's Integrations page.

Backups & disaster recovery

Daily encrypted backups of every tenant database are pushed off-site. Local copies are kept for one week; off-site copies are kept for ninety days. We can restore an individual synagogue from backup without affecting other tenants.

Data residency: primary data and backups are stored on US-based infrastructure.

Reporting a vulnerability

If you believe you've found a security issue, please email security@kehillahone.com with as much detail as you can share. We acknowledge reports within one business day and will keep you updated as we investigate. Please do not disclose publicly until we've had a chance to address the issue.

Good-faith security research conducted under this policy will not result in legal action.