Privacy Policy - Backbrief

---

1. What data we access

Backbrief is built to connect to your existing business systems - email, QuickBooks, and calendar - through OAuth (revocable, no passwords stored). (These connectors are being built; the OAuth flow is not yet live. This section states what each connector is designed to access once connected.) The data we process is:

• Email: headers, body text, and metadata of messages you receive and send. Backbrief is built so that attachment contents are never fetched, transited, or stored - the file stays in your mailbox. This is structural: it cannot be changed by configuration, only by a deliberate architecture change.
• QuickBooks: transactions, invoices, estimates, payments, customer records, and account metadata. We read these to build your daily brief.
• Calendar: we are building support for reading event titles, times, and participant lists to identify scheduled appointments and deadlines. Which calendar providers are supported, and exactly which fields are retained, will be confirmed here once that connector is live.
• Forwarded artifacts: screenshots or voice memos you send us directly. These have no source system, so we store the extracted text explicitly marked as such.
• Credentials: never stored. Backbrief is built to connect through OAuth only; once the connectors are live, OAuth tokens are encrypted at rest and revocable by you at any time.

2. How we handle your data

2.1 Processing pipeline

Raw content (email bodies) is designed to pass through a quarantine pipeline: scanned, events extracted (a quote sent, a payment received, a customer waiting), then the raw content discarded. (This ingestion pipeline is part of Phase A and is not yet built; the retention ceilings below describe the designed behavior.)

• Raw inbound content: retained temporarily in quarantine. Target hours; hard ceiling 7 days.
• Scanner-flagged items: held up to 30 days for your review, then purged.
• Business Memory (derived events, opportunities, one-line evidence extracts): stored for the life of your subscription. This is the product - your daily brief, opportunity tracking, and voice profile.

2.2 Pointer-first evidence

By design, evidence references are pointers into your own systems - a message ID in your mailbox, a transaction ID in your QuickBooks - rather than copies. When you delete a source item, the evidence link is designed to degrade to its stored one-line extract and to show you honestly that the original is gone. (The live-resolution behavior ships with the connectors; the pointer-first data model is built.)

The one exception: artifacts you forward us (screenshots, voice memos) have no source system, so we keep the extracted text with your Business Memory.

3. Encryption & security

3.1 In transit

Backbrief's outbound connections to your systems are HTTPS-only in code - there is no plaintext path to your data (verified 2026-07-20). Browser-to-server TLS is configured as part of deployment. (The public service is not yet live; when it serves, it serves over TLS.)

3.2 At rest

Per-tenant envelope encryption is built, running, and now covers your financial data. Every tenant gets its own data key, wrapped by a root key held in a different country from the data itself. Sensitive fields - invoice and payment amounts, and the payment allocations that reference them - are encrypted before they reach the database, alongside the QuickBooks refresh token that was already protected this way. Someone holding a copy of our database, without our key-management system, sees event skeletons (types, timings, relationships) and no readable amounts. Verified 2026-07-28 by taking a real database dump and inspecting it - not assumed from the design.

Some fields stay deliberately readable because encrypting them would protect nothing while breaking how the product works: due dates, currency codes, and internal identifiers. None of them is an amount, a name, or a message.

The per-tenant keys are themselves wrapped by a root key held in AWS KMS, Frankfurt (EU). That custody is live: the key material was generated offline, split so that no single copy exists, and imported - and the running system has been performing real encryption and decryption against it continuously since 2026-07-23. This paragraph previously described a local development key; that was true when written and is no longer.

3.3 Zero standing human access

No employee - including the founder - reads your data as part of normal operation. We do not maintain a tool, dashboard, or database console that lets anyone browse tenant content. Access to decrypt your data is not something any of us can do by default; it requires the specific, consent-gated exception described below.

Break-glass (the honest exception): some rare bugs require seeing one tenant's real data. This consent-gated flow, and the audit view that records it, are part of Backbrief's design and are not yet built - what follows describes how that access is architected to work, not a screen you can open today. It will move to present tense when the flow ships. Backbrief is designed so that access can happen only when:

• You are asked in-app and must approve, scoped to named records and time-boxed (default 24h).
• A temporary decrypt grant is issued for exactly that scope.
• The access is written to your own audit trail - you see who, what, when, and why, permanently.
• The grant auto-expires. No consent means no access.

By design, your audit view will carry a standing "Human access history" entry; for nearly every tenant it is intended to read "None" - the visible zero the design exists to make true. (This view is part of the design described above and ships with the break-glass flow.)

3.4 KMS availability

Encryption keys are cached in application memory with a 12-hour TTL (this caching is built). By design, brief delivery, drafting, and sending proceed from cache; if the key service is unreachable and the cache is cold, the affected tenant's reads fail with an honest error - never with partial or degraded data.

4. Where your data lives

This table describes the launch architecture. In the current pre-launch build, the application and database run in Helsinki as shown; the AWS KMS key custody and the Backblaze B2 backup layer are provisioned as part of going live and are not yet in operation.

5. Retention & deletion

5.1 While your subscription is active

Your Business Memory - events, opportunities, audit log, voice profile - is retained for as long as your subscription is active. This is the product; it persists as long as you are a customer.

5.2 After cancellation

Export: You can export your data for 30 days after cancellation. We keep your data available and exportable during this window.

Deletion from live systems: After the 30-day export window closes, we delete your data from our live systems.

Backup purge: Encrypted backups are retained for up to 90 days after deletion and then purged. This window may tighten as our backup schedule is finalized; it will not lengthen without this policy being updated first.

Full timeline:

Cancellation → [30-day hold: data exportable]
             → Deletion from live systems
             → [up to 90 more days: encrypted backups retained]
             → Purged from backups entirely

5.3 Important note about backups

Backup copies are encrypted, but for the reason described above, they remain technically recoverable - through our own key management system - for up to 90 days after deletion from live systems. We disclose this plainly because it is more honest than a claim of instant, total erasure: our restore capability, which exists to protect your data from loss, is the same capability that keeps a deleted copy technically recoverable during this window. Once the window passes, backups are purged entirely.

5.4 Data you can delete any time

Even while your subscription is active, you can request deletion of your full Business Memory at any time. We execute that from live systems within 30 days, with backup purge following the same up-to-90-day tail described above.

6. Our commitments regarding your data

• We never sell your data. Full stop.
• We never share your data across tenants. Each customer's data is isolated by design.
• We do not use your data to train any AI models we develop or maintain. This is a statement about our own conduct. It is not a representation about the general practices of any third-party service we use to help operate Backbrief.

7. Your rights

• Right to know: this document lays out what we access, how, and why.
• Right to access: export your data any time while your subscription is active.
• Right to delete: request full deletion of your data at any time.
• Right to disconnect: revoke any OAuth connection from our app or the provider's side - your credentials are never stored, and disconnection is instant.
• Right to audit: your audit trail shows every significant event, including any rare break-glass access that occurred (with your consent).

8. Data we do NOT collect

• Passwords (OAuth only)
• Credit card numbers (processed by Stripe, not us)
• Attachments from email or messages (Backbrief is built so that attachment contents are never fetched, transited, or stored - the file stays in your mailbox)
• Your customers' data beyond what is needed to build your brief (we process events, not inboxes)
• Browsing behavior, cookies (no tracking scripts, no analytics beacons)
• Anything unrelated to running your business - no personal data about you beyond your account details and business data

---

What is not settled yet

Backbrief is pre-launch. The items below are genuinely undecided or not yet built. We would rather name them than let you find them later.

1. Calendar data. Which calendar providers we connect to, and which fields we would retain from them, are not decided. We have left that unstated above rather than describe a connector that does not exist.
2. Backup storage region. Encrypted off-site backups are planned; the exact storage region is not fixed yet, and we will name it here once it is.
3. Backup purge enforcement. The 90-day backup purge described above is a policy commitment we hold ourselves to. The automation that enforces it on a schedule is not built yet.
4. Attachment handling. The attachment boundary described above is a design commitment, not an observed behavior: the email pipeline it governs has not been built, so it has not yet been demonstrated in a running system.
5. Operating entity. Backbrief is operated by an individual, not a company. If that changes, this policy will be updated to name the new operator.