Security
How BoardHerald stores and protects the data sitting in your tenant — what's isolated, what's encrypted, what's logged, and how to talk to us when something looks off.
Board materials are among the most sensitive documents a company produces. BoardHerald is built around that: every piece of data below either can't physically leave your tenant, can't be read in isolation, or leaves a trail when it's touched. This page is the plain- English reference — no marketing, no architecture diagrams, just what we do.
Tenant isolation
Every tenant is an independent silo. A user in tenant A cannot see a single row belonging to tenant B — not a member list, not an update title, not a meeting date, not the existence of a KPI. That isolation is enforced at the database query layer, not just at the UI: a request that forgets to specify a tenant scope simply returns nothing rather than leaking cross-tenant content.
The same guarantee applies when a single email belongs to several organizations. Switching between them (see Multi-tenant) re-validates your membership on the server, hands the browser a short-lived one-shot credential bound to the target organization, and actively revokes the session you were holding on the source organization — so even in multi-org flows, tenant A's data never crosses the wire for a session scoped to tenant B.
Within a tenant, visibility follows the role + access- group model documented on Permissions. A member who doesn't hold the FINANCE access group never sees a financial update exist, even as metadata. A KPI marked INVESTOR_ONLY doesn't appear in list endpoints or in agent tools for non-investor members. The principle: if you shouldn't see it, you shouldn't learn that it's there.
Encryption
At rest
Sensitive content — board updates, resolutions, meeting descriptions, meeting minutes, financial updates, vote comments, signed NDA names, and integration credentials — is encrypted before it's written to the database, using an industry-standard authenticated encryption scheme with a per-deployment key. A raw database export contains ciphertext only.
In transit
Every network request is TLS-only, no exceptions. HTTP endpoints redirect to HTTPS. Custom domains get TLS certificates automatically and stay auto-renewed.
Passwords and tokens
Authentication uses magic links by default — one-time, short-lived, single-use — so there's no long-lived password to leak. Where passwords are used, they're hashed with an industry-standard key-derivation function before storage; we never see or store plaintext. API keys are hashed the same way (see Secrets below).
Audit log
Actions that change state or reveal content get logged. Representative examples: user invites, role changes, update publishes, resolution opens and closes, votes (including changes), meeting publishes, KPI restatements, API key creates and revokes, NDA rotations, integration connects and disconnects. Every entry carries who did it, when, in what tenant, on what target, and where possible what device and approximate location.
The log is append-only. Edits to an underlying object produce a new audit entry; the previous entry stays intact. An admin tightening a KPI's visibility doesn't retroactively hide earlier activity.
audit:read scope on their API key, and we recommend issuing that only for specific workloads like automated compliance pipelines.Retention. We keep audit entries for the lifetime of your tenant plus a reasonable buffer after cancellation. We do not delete audit trails on request — they're the evidence your board may need years later.
Secrets
API keys
Keys are shown exactly once, at creation time. The raw key never touches the database; only a one-way hash is stored. If you lose it, revoke and reissue — we cannot recover it for you. Rotation is a one-click revoke + create; an existing key keeps working until you revoke it explicitly. Every key carries a scope list (see Capabilities) so a key never has more reach than its documented scopes.
Session cookies
Sessions ride a signed, HTTP-only, same-site cookie scoped to your tenant domain. Cookies are invalidated on the server when a session ends.
Integration credentials
OAuth tokens and API keys for third-party connectors get the same at-rest encryption as everything else. Disconnecting an integration from the admin console removes the stored credential; where the provider supports it, we also call their revocation endpoint so the third-party service forgets us.
Backups and business continuity
Backups. Automated daily backups with multi-day retention, geographically distinct from the primary. Backups are encrypted at rest with keys separate from the live database; restoring a backup is a manual, audited operation.
Business continuity. We can restore the application stack from configuration in well under an hour; the usual bottleneck is database restore time, which scales with tenant data volume. Tenant data is never comingled across restores — an incident scoped to one tenant does not take others down.
Responsible disclosure
If you've found a security issue in BoardHerald, contact your tenant administrator. Admins have an authorised channel in their admin console to escalate issues to us. Please don't post details to public issue trackers, social, or anywhere the write-up could be read by an attacker before the fix lands.