Security Protocol

Overview

BoardRecord is built to hold institutional records for condo and co-op boards — bid packages, vendor correspondence, board decisions, and financial approvals. We treat every piece of data as if it could be subpoenaed, because it can. This page describes the security infrastructure that protects your board's project record.

Questions about our security practices? Contact security@boardrecord.com.

• All data is encrypted in transit using TLS for every connection between your browser and our servers.
• All data is encrypted at rest using AES-256, managed by our cloud infrastructure providers (Supabase/Postgres and AWS S3).
• Payment and bank details are tokenized by Stripe — BoardRecord never stores raw card or bank account numbers.
• Vendor tax identifiers for 1099 reporting are collected and held by Stripe, not stored in our database.

• Role-based access control (RBAC) scoped to each board workspace — owners, admins, and members each see only what their role permits.
• Tenant isolation is enforced at the database layer with Postgres row-level security (RLS), so one board can never read another board's data.
• Session management uses secure, HTTP-only cookies, with CSRF protection on state-changing requests and rate limiting on sensitive endpoints.
• Multi-factor authentication (MFA) is on our roadmap ahead of enterprise general availability.

• Your organization retains full ownership of all data uploaded to or generated within BoardRecord.
• Export all of your workspace data at any time from Settings → Data & Privacy as machine-readable JSON.
• Delete your workspace and all associated records permanently at any time from Settings.
• We do not sell your data, and we do not use your content to train AI models.

• Hosted on established cloud infrastructure (Vercel, Supabase, and AWS); see our Subprocessors page for each provider and its processing region.
• Automated daily backups provided by our managed database platform.
• Secrets and credentials are stored in managed environment configuration, never committed to source code.
• Row-level security (tenant isolation) policies are automatically audited in our CI pipeline before any schema change ships.

• Whitelisted sender verification for inbound email — only recognized addresses are processed into a board's record.
• Vendors interact exclusively over email and never receive direct platform access; payouts run through Stripe Connect.
• SPF, DKIM, and DMARC validation on inbound and outbound email.
• Public vendor onboarding links are protected with HMAC-signed, time-limited tokens.

• Append-only audit trail for payment authorizations, votes, and governance decisions, exportable to CSV.
• Verifiable counsel export: each Board Pro brief includes a SHA-256 content hash and HMAC-signed timestamp. Anyone with the manifest id can confirm integrity at /api/verify/export without seeing tenant data. Verification proves the record was not altered — it is evidence for counsel, not legal advice or a claim of admissibility.
• We follow privacy-by-design principles and honor data access and deletion requests (see our Privacy Policy).
• A current list of the sub-processors we rely on is published on our Subprocessors page.
• SOC 2 Type II and independent penetration testing are planned ahead of enterprise general availability.

Responsible Disclosure

If you discover a security vulnerability in BoardRecord, please report it responsibly. Contact security@boardrecord.com with details of the issue. We will acknowledge receipt within 48 hours and work with you to understand and resolve the issue before any public disclosure.

Related Policies

For information about how we collect and use your data, see our Privacy Policy. For the list of third parties that process data on our behalf and how long we retain data, see our Subprocessors & Data Retention page. For the terms governing your use of the Service, see our Terms of Service.