Security Overview

Version: 1.7 · October 2026 · Aligned to the current deal-recovery service
Provider: Lazarus Deal Recovery — Lazarus Revenue Intelligence Inc., Ontario, Canada
Contact: support@getldr.ca

Trust Pack: SEC-001 · Referenced by Privacy Policy (PP-001) and DPA (DPA-001)

This document summarizes security and data-handling controls for InfoSec and procurement reviews. It describes the current Lazarus Deal Recovery architecture — not a certification claim. The customer owns the recording, the transcript, and the notes. We process them only to write the report: whether the deal is recoverable or a flat no, what is blocking it, and what to do next. The transcript is not saved. Evidence-quote fields are removed from the stored report. The summary, scores, and next actions are kept. We do not sell that content or train public models on it.

1. Product summary (shipped)

Lazarus Deal Recovery is a deterministic deal autopsy / revenue intelligence engine for stalled B2B pipeline. Customers assemble an evidence package from uploads, mailbox thread search, live meeting transcripts, field capture, optional HubSpot note import, and optional account-signal enrichment. A private API server transcribes audio (optional AssemblyAI), runs AI-assisted extraction (Layer 1), deterministic scoring (Layer 2), and returns a deal autopsy report with evidence quotes, People Map, Deal Risk Index (DRI), and recovery recommendations. Humans decide; Lazarus Deal Recovery does not send outreach or close deals autonomously.

The web console is display-only — scoring logic never runs in the browser. See Terms §1 and Privacy §2.

2. Architecture

2a. Guest freemium vs signed-in persistence

2b. Live evidence channels

Channels are user-initiated. Lazarus Deal Recovery does not silently scrape inboxes or join every meeting. Mailbox search attaches specific deal threads; live sessions require an explicit connect; field capture starts when the rep records.

3. Data classification

4. Security controls

5. Recording and mailbox consent

6. Sub-processors

Same list as Privacy Policy §7. Primary hosting: North America.

7. Incident response playbooks

These are internal operating procedures for Lazarus Deal Recovery. They do not replace legal advice. Contact during an incident: support@getldr.ca (and founder/ops alerts when configured). B2B customers with a DPA are notified of a confirmed personal-data breach without undue delay, consistent with DPA §7.

7a. If someone gets into an account (unauthorized login)

1. Contain. Sign the user out of Lazarus (Supabase Auth session revoke). If they used Google / HubSpot / Salesforce to sign in, tell them to revoke Lazarus on that provider’s security page as well.
2. Rotate. Reset the Lazarus password (email confirmation required). Disconnect mailbox and CRM connectors from the product so refresh tokens are deleted.
3. Scope. Review that user’s saved analyses, CRM deal links, and connected-account email in Ops HQ. Guest runs are not stored under an account.
4. Notify. Email the account holder at the address on file. If a customer org is involved, notify their security contact the same day we confirm misuse.
5. Follow-up. Check API logs for the same IP/time window. Document what was accessed and whether any OAuth token was used after the suspected time.

7b. If the database is dumped or RLS is bypassed

1. Contain. Rotate SUPABASE_SERVICE_ROLE_KEY and the anon key in Supabase, then update Render and the frontend build. Pause analyses from Ops HQ if writes must stop.
2. Assume exposure. Treat saved reports (deal names, values, status, scores, rescue tasks, headline and diagnosis), CRM link metadata, contact-form rows, and encrypted OAuth blobs as in-scope. Transcripts, evidence quotes, and CRM payloads are not stored in those rows. Encryption at rest reduces but does not eliminate risk if the app encryption key was taken too.
3. Rotate application secrets. TOKEN_ENCRYPTION_KEY, OAUTH_STATE_SECRET, webhook secrets, Stripe restricted keys, and LAZARUS_API_KEY.
4. Revoke OAuth. Users must reconnect Gmail / Outlook / Zoom / HubSpot / Salesforce. Delete rows in google_oauth_tokens and on-disk token maps after the new key is in place.
5. Notify. Affected B2B customers without undue delay; include what classes of data were involved and that connector access has been invalidated. Offer password reset and a reconnect checklist.

7c. If Render env / the API host is compromised

1. Contain. Lock the Render service (or rotate deploy credentials), take a snapshot of current env var names only, and deploy a new secret set. This is worse than a table dump: the service role bypasses RLS.
2. Rotate everything in that environment: Gemini, AssemblyAI, Supabase service role, Stripe, Resend, Zoom / Google / HubSpot / Salesforce client secrets, webhook secrets, purge cron secret, token encryption key.
3. Invalidate sessions and connectors as in 7a–7b. Force users to sign in again.
4. Notify customers whose data could have been read through the API. Do not email raw secrets or dumps; describe categories (transcripts, CRM notes pulled by the user, mailbox search results processed during the window).

7d. If meeting captions leak across customers (or a live session is guessed)

1. Contain. End live sessions (process restart clears in-memory buses). Confirm Zoom RTMS is publishing only to the owner’s sessions and that Meet/Zoom SSE requires the session secret.
2. Scope. Live turns are not the system of record. A signed-in save stores the report and does not store the transcript.
3. Notify only parties whose live transcript could have been observed. Tighten or rotate Zoom webhook secret if the webhook was the entry point.

7e. If OAuth tokens or an API key leak (paste, logs, Git)

1. Contain. Revoke the leaked credential at the provider immediately (Google Cloud, HubSpot, Salesforce, Zoom, Stripe, Gemini). Remove it from git history going forward; treat the old value as public.
2. Replace in Render / GitHub Actions. Disconnect affected users so they reconnect with new tokens.
3. Notify if customer mailbox or CRM data could have been pulled with that token. If only a guest API key leaked, rotate it and watch for abuse against /api/post-mortem (rate limits still apply).

After any confirmed incident: write a short internal note (what happened, time window, data classes, who was told, what was rotated). Keep monitoring API error rates and founder Ops alerts until the window is closed.

8. Customer responsibilities

• Obtain recording consent and internal policy approval for uploads, field capture, and live sessions
• Authorize only accounts the organization permits to connect (Gmail, Outlook, Zoom, HubSpot)
• Manage user access within their organization
• Keep source evidence in their own systems. Lazarus stores the report
• Review AI outputs before acting on them in live deals

9. Roadmap (not yet implemented)

Commonly requested — disclosed honestly in security reviews:

• SOC 2 Type II — not yet obtained
• Single sign-on (SAML/OIDC) for customer orgs
• HIPAA business associate agreement
• A signed installer. A standalone install can run this same app on the customer’s server and their database. That is not this hosted service
• Uptime SLA
• Formal penetration test report pack for RFPs
• Dedicated KMS / hardware-backed OAuth token vault (application AES-GCM is in place today)
• Full CRM sync. Revive already writes the score and next step. It does not move the stage
• White-label partner dashboard and custom domains
• Always-on stall detection webhooks (vs user-initiated evidence pull)

10. Document index

This overview is accurate to the current codebase. Have legal and security counsel review before submitting to regulated customers or RFPs that require formal certifications. Lazarus Deal Recovery is not SOC 2 certified today; hosting providers may maintain their own certifications.