Security & data handling

How Beech protects firm and Vault data — the same facts as the public Security page, written for operators. Hand the public page (/security) to a client; use this guide to know where to click.

Encryption

• In transit — TLS for Beech; Vault multipart uploads to B2 with firm-key headers; shares/chat/zip often stream through Beech.
• At rest (Vault) — AES-256 with a per-firm data key (SSE-C) on Backblaze B2. Backblaze cannot decrypt without keys Beech supplies.
• Secrets — MFA and integration tokens encrypted with AES-256-GCM in the database.
• This is not end-to-end encryption and not client-held-only keys — Beech unwraps firm keys for scan, zip, and support.

Who can access Vault

• Project Vault — any project member (Admin, Manager, Contributor) can manage files. Admins see all projects.
• Firm Library — everyone can browse; only Admins can upload or organise.
• External shares — any project member by default. Admins can restrict to Admins and Managers in Firm settings → Vault.

Audit log

Admins open Firm settings → Audit log to see Vault file access, external share activity, active share links (with revoke), and Beech support sessions. Retention: one year.

Beech support access

Beech does not give engineers ad-hoc access to your Vault. Support uses audited impersonation only. Those sessions appear in your firm's audit log as Beech support.

Full statement for clients

Print or share the public Security & data handling page at /security (footer → Security). It covers encryption, roles, logging, subprocessors, and support access.

Before you start

• You understand which role in your firm is accountable for security decisions.
• You know where your client deliverables and Vault files are stored and shared.

Workflow checks and quality guardrails

• ✓

  Checklist item 1: Review permission tiers every month and deactivate accounts that no longer need access.

• ✓

  Checklist item 2: Use expiring and password-protected links for external deliveries when the data is sensitive.

Common mistakes to avoid

• Leaving dormant member accounts active after staffing changes.
• Sharing permanent links externally when project policies require time-bound access.

Troubleshooting

1. 1
   Troubleshooting step 1

   If a user can see more than expected, inspect their role and project membership scope.

2. 2
   Troubleshooting step 2

   If a shared file should no longer be accessible, revoke the active deliverable link immediately.

What to do next

1. Open /docs/roles and continue with the next workflow.
2. Open /docs/team and continue with the next workflow.
3. Open /docs/deliverables and continue with the next workflow.