Trust

How we protect your governance data.

Boardroom is the boardroom-portal that publishes its safeguards instead of asking you to trust us. Every claim on this page is enforced in code we can show you.

Boardroom Lockbox — tamper-evident platform-admin log

Every time a Boardroom platform administrator touches your tenant's data, a row lands in your customer-visible activity log with a mandatory reason and a cryptographic chain seal. Inspired by Microsoft's Customer Lockbox, adapted for the boardroom domain, where board records are corporate records.

Mandatory rationale

Platform admins cannot record an action without a justification of at least 10 characters.

Append-only chain

row_hash = HMAC-SHA256(secret, payload || prev_hash)
Tampering breaks the chain immediately and our verification cron pages on the first mismatch.

Customer-visible

Every action surfaces on /org/<tenant>/admin-activity with action name, reason, and ticket reference. The platform admin's identity is masked.

Retention: 7 years (board records are corporate records, longer than the SOC 2 12-month minimum).

Published permission matrix

Below is the default access matrix enforced by can(actor, action, resource, state) on every server action. C entries are configurable per organisation, but the defaults shipped never give an admin sight of whistleblower disclosures or executive-session minutes.

Capability	Admin	Director	Chair	Comm Chair	Comm Member	Corp Sec	Officer	Observer	Auditor	Counsel	Guest
Pack, distributed	✓	R	R	R	R	✓	R	R	C	C	—
Pack, draft (pre-distribution)	✓	—	C	C	—	✓	—	—	—	C	—
Voting Committee members vote only on resolutions of their own committee	—	✓	✓	✓	∗	—	—	—	—	—	—
Resolution sign	—	✓	✓	✓	∗	C	—	—	—	—	—
Minutes, post-adoption edit Both signatures land in the admin audit chain	2P	—	2P	—	—	2P	—	—	—	—	—
Quorum override	2P	—	2P	—	—	2P	—	—	—	—	—
Whistleblower disclosures Visible only to the Audit Committee Chair. Even platform administrators are denied.	—	—	—	✓	—	C	—	—	—	C	—
Director compensation table Full table visible only to the Remuneration Committee Chair	✓	C	✓	C	—	✓	—	—	—	R	—
Executive session minutes True in-camera: no admin / Corporate Secretary access without an explicit invite	—	✓	✓	✓	✓	—	—	—	—	—	—
Litigation matters General Counsel role (officer_kind='GC') also allowed	—	—	✓	—	—	✓	—	—	—	✓	—
Conflict register, all rows Own COI row is always visible to its owner	✓	C	✓	C	—	✓	—	—	—	R	—

✓Full access
RRead-only
—Denied
2PTwo-person rule
CConfigurable per organisation
∗Scoped to own committee

Published rate limits

Most board-portal vendors hide these numbers. We publish them so your developers can plan integrations and your procurement team can scope load. Enforced at the edge (Cloudflare), middleware (per-tenant + per-user + per-IP), and route layer (concurrency limit on PDF render / AI / WhatsApp blast).

Plan	Requests / second	AI calls / month	WhatsApp / day
Free	20	—	—
Starter	100	50	25
Board	200	Unlimited	200
Enterprise	500	Unlimited	Unlimited

429 responses carry Retry-After, X-RateLimit-Remaining, and X-RateLimit-Scope: tenant | user | ip so your developers can route around the right bucket.

Where your data lives

Boardroom runs on a single-region stack today. We say exactly where, rather than leaving it to a sales call.

Hosting & backups

Hosted on Hetzner Cloud, EU. Backups run nightly (database dump + object storage mirror), encrypted client-side (AES-256) and shipped off-site to Backblaze B2 — a separate provider from the host, so a single provider incident can't take out both the live system and its backups.

Recovery targets (RTO / RPO)

RPO ≤ 24 hours (nightly backup cadence — governance data changes at meeting cadence, not transaction cadence). RTO ≤ 4 hours in business hours to a rehearsed restore, ≤ 24 hours worst case. We're a small, focused team; these numbers are honest about that, not inflated.

Residency options

Your data stays in the EU on our shared plans. If your board needs a specific jurisdiction (GCC, UK, or otherwise) or full physical isolation, the identical stack is available as a dedicated, self-hosted Enterprise deployment — ask us.

Subprocessor changes

We'll email every tenant admin before adding or replacing a subprocessor below, with enough notice to raise an objection.

Subprocessors

Name	Purpose	Data shared	Optionality
Cloudflare	Ingress tunnel, edge TLS, DNS	Traffic in transit (TLS)	Core
Backblaze B2	Encrypted off-site backups	AES-256 blobs (unreadable to B2)	Core
Stripe	Billing, card processing	Billing contact, subscription	Core (paid plans)
Resend	Transactional email	Recipient email, notification content	Core
Google	OAuth sign-in; optional Calendar sync	OAuth identity claims	Core sign-in path
Anthropic	AI summaries / ask-the-boardroom	The specific record's text, only on explicit click	Optional (BYOK supported)
Meta (WhatsApp Cloud API)	Notifications, per-tenant credentials	Recipient phone, message	Optional, off by default
Microsoft	Optional OAuth/SSO + calendar	OAuth identity claims	Optional
Sentry	Error monitoring	Stack traces (PII scrubbing on)	Optional, inert without a DSN
GitHub (ghcr.io)	CI-built container images	No customer data	Build/deploy chain only

Encryption, retention, and your data

At rest

AES-256-GCM. Each at-rest secret is encrypted with a key derived from a master via HMAC-SHA256 and a purpose tag (2FA, integration credentials, audit chain), a stolen ciphertext for one purpose cannot decrypt another.

In transit

TLS 1.3, HSTS preloaded, HTTP/2. Webhook payloads from third parties verified via HMAC (Stripe, Meta WhatsApp Cloud).

Retention

Documents follow tenant-set retention policy (1y / 7y / forever). Legal hold suspends retention on selected matters indefinitely.

Exit

Tenant admins can export the entire workspace at any time (board packs, minutes, signatures, registers, audit log) as a folder tree to Google Drive or OneDrive. No lock-in.

Sessions & devices

There is no password to phish, reuse, or leak — every sign-in is Google OAuth or your organisation's SAML identity provider.

Session lifetime

A signed-in session lasts up to 7 days. If your organisation sets an idle-timeout policy, the strictest policy across every organisation you belong to applies — evaluated on activity, so it can't fire mid-task.

Per-device control

Every sign-in registers as a device at /me/security. Revoke one device, or every device but the one you're on, in a single click.

Remote-wipe, honestly scoped

Revoking a device invalidates its session on its very next request. Today that's an access revocation, not yet a cryptographic purge of anything already downloaded for offline reading on that device — see “Offline access” below.

Two-factor & recovery

TOTP two-factor with encrypted seeds and single-use recovery codes, rate-limited. SSO tenants can require it at the identity provider; OAuth tenants can require it per-organisation.

Offline access & document protection

Offline reading

The installable app caches previously-opened board packs so a meeting can proceed without connectivity. That cache uses the browser's standard, OS-managed storage today — protection comes from your device's own lock screen and disk encryption, not yet an additional layer Boardroom adds on top. An app-level encrypted cache with a biometric re-lock is on our roadmap.

Per-document controls

Every document carries a DRM matrix — view, download, print, and export can each be allowed or denied per role, per document.

Watermarking, honestly scoped

An admin can set a watermark for a pack (for example, “Confidential — Acme board only”), stamped diagonally across every page of the compiled PDF. Today that text is the same for every reader of that document; it does not yet embed each individual viewer's name, email, or the time they opened it. Per-viewer traceable watermarking is on our roadmap.

Redaction

Structured, per-block redaction in the pack composer renders redacted blocks as solid bars in every exported and compiled PDF — including copies distributed before this fix shipped, which were re-compiled.

AI and your data

Boardroom sells AI capacity, so here is exactly what that means for your data.

Explicit action only

Every AI feature — meeting and pack summaries, minutes drafting, agenda drafting, and ask-the-boardroom — runs only when a person in your organisation clicks a specific button on a specific record. Nothing scans your workspace in the background.

Provider & training

By default, requests go to Anthropic's Claude API, whose API terms mean your prompts and outputs are not used to train their models. You can instead bring your own AI provider key (BYOK, encrypted at rest) so both spend and data routing stay entirely under your control.

Where the output lives

An AI-drafted summary or agenda is saved as an ordinary record in your workspace, under the same access controls and retention policy as anything else you create. We don't keep a separate, hidden log of your prompts.

Tenant isolation, and redaction's real scope

Ask-the-boardroom is scoped to your company's own records by construction — it cannot retrieve another tenant's data. Per-block redaction today is a board-pack feature: it controls what a compiled or viewed pack shows, not the underlying note, minutes, resolution, or file record. Ask-the-boardroom searches those underlying records directly, so redacting a block in a pack does not remove it from an AI answer. If something must stay out of an AI answer, keep it out of the source record for now — block-level redaction on records themselves is on our roadmap.

Why we don't claim “zero-knowledge”

Some vendors claim it; we won't, because most of what makes Boardroom useful — search, AI summaries, formatted PDFs, notifications — requires the server to read your content. A product that truly never sees your data can't offer those features. What we do instead: every time a Boardroom administrator needs to touch your tenant's data, it requires a reason, lands in a log you can read, and is sealed so tampering with that log is detectable — see Boardroom Lockbox, above. We think a provable, verifiable trail is a more honest promise than a claim we can't back up in code.

Certifications & frameworks

Boardroom is architected against the controls in:

SOC 2 Type II
CC6.1 (logical & physical access), CC7.2 (system monitoring). Planned — audit scheduled after our first enterprise cohort. In the meantime, this page and our internal adversarial audit results are available for buyer risk review on request.
ISO 27001
Architected against Annex A controls. Certification planned to follow SOC 2, on the same evidence base.
GDPR
DPA available. Subject access requests honoured within 30 days via the tenant-export flow.
SOX §302 / §404
Two-person rule on minute amendments, hash-chained audit log of board resolutions and minute adoptions.
UK Corporate Governance Code (2024)
Whistleblower channel scoped to Audit Committee Chair only. Independent-director attribution drives recusal logic.
King IV (Principle 12)
Governance of technology: published security architecture, customer-visible platform-admin activity log.

Documents

Three tiers, honestly labelled — we don't put a “Download” button on anything that doesn't exist yet.

Public, no request needed

This page. The subprocessor list above. A security-overview summary, on request while we finish a downloadable version.

Available on request

A data processing agreement (DPA) covering the terms in our Privacy Policy. A CAIQ self-assessment (planned). A SOC 2 report, once our audit (see Certifications, above) completes.

Under NDA, once they exist

An independent penetration-test summary. We haven't commissioned one yet — it's planned before we onboard enterprise customers who require it, alongside the internal adversarial audits we've already run.

Request any of the above at balayogesh@gmail.com.

Security contact

Report a vulnerability or ask a procurement question to balayogesh@gmail.com. Acknowledgement within one business day; advisory triage within five.

We do not run a bug bounty. We do not pursue legal action against good-faith researchers acting under coordinated disclosure.