Security at Lead Friendly
Lead Friendly handles call data, contact records, recordings, deal records, and credit applications — including the Social Security numbers, dates of birth, and driver's licence numbers a customer supplies to a dealership when applying for financing — on behalf of customers. This page describes the controls we have in place to keep that data safe and the posture we hold ourselves to. For binding commitments, see our Terms of Service and Privacy Policy.
Data encryption
All traffic to Lead Friendly is forced over TLS 1.2+ via HSTS with a two-year max-age and includeSubDomains; preload. Customer data at rest in our Supabase Postgres database is encrypted with AES-256. Sensitive fields — credit-application identifiers, income and credit score (on the deal record as well as the application), identity-verification records, the IP recorded with a consumer's telephone-consent entry, and the IP inside every e-signature record — carry an additional layer of application-level AES-256-GCM encryption under separately managed keys. Server-side access to the decrypted identity fields is audit-logged with anomaly alerting. See Credit-application data below for exactly which fields are covered and which reads are logged. Call recordings are stored in object storage with server-side encryption and short-lived signed URLs for playback.
Credit-application data
A credit application submitted through Lead Friendly is written directly into per-column ciphertext. Two groups of fields are covered. The identifiers: the applicant's and co-applicant's Social Security number, date of birth, and driver's licence number, plus the employer identification number on a business application. The financial picture: stated gross monthly income, other income, previous-employment income, the monthly housing payment, the co-applicant's address, employment and income, and the applicant's credit score together with the date it was pulled and the adverse-action reason codes recorded against it. All of it is encrypted with AES-256-GCM (random 96-bit IV, authentication tag verified on every read) before the row reaches the database. The key is a 256-bit value held in server environment configuration, never in the database and never in the browser, and supports rotation without a ciphertext-format change. Encryption fails closed — if the key is absent or malformed, the write is rejected rather than stored in plaintext. The same figures are encrypted the same way on the deal record the desk builds from the application, which holds its own copy of the income and the score — a figure encrypted in one table and left in the clear in another is not encrypted.
The rest of the application is not in that layer, and the list is worth being specific about rather than leaving to inference: applicant and co-applicant names, contact details, address, employer and job history, marital status, the state that issued the licence, the personal references a customer supplies, the down-payment figure, the credit band an applicant selects for themselves on the intake form, the manager's decision notes, and the e-signature record apart from the signer's IP address, which is encrypted: the name, user agent, timestamp and document hash stay readable, deliberately, because evidence you cannot inspect without a key is worth less as evidence. The IP addresses recorded when a dealership's own staff accept our terms, attest to a DNC scrub, or attest that they hold a customer's consent are not in the application-level layer either; those identify the store, not the consumer. Three pieces of scoring metadata stay in the clear on purpose: which credit bureau supplied the score, the scoring model used, and that model's floor and ceiling. Those are the same handful of values for every consumer scored — the bureau is one of three national agencies — so encrypting them would obscure nothing about anybody. Everything in this paragraph is protected by database-level AES-256 encryption at rest, row-level-security tenant isolation, and the access controls described here.
The identifiers are decrypted on the server on three paths only: the dealer's printable application, the lender credit-application export, and the lender submission packet. Each requires an authenticated user in the owning organization with the dealer-desk entitlement; the two lender paths additionally require the run-credit permission and a recorded attestation that the customer consented. The application list, detail, and activity views never select those columns at all, and the applicant-facing copy of the form prints those fields blank. We log every one of those decryptions to an internal PII access log naming the actor, the fields revealed, the record, and the reason, and those rows feed bulk-read and off-hours anomaly alerting.
The financial picture works differently, and the difference is worth stating plainly. Income and the credit score are decrypted for the finance manager's ordinary credit-review and desking screens, because reviewing an application and structuring a deal are exactly the acts of reading them — so they are not individually written to the access log. Logging a screen that lists every open application would generate more entries in one page load than the bulk-read alert is tuned for, and would bury the identifier alerting that the log exists to provide. What encrypting them buys is therefore specific: the figures are unreadable in a database backup, a read replica, or by anyone holding stolen database credentials without the application key. It is not an additional record of which employee looked at them.
Tenant isolation
Every customer organization is a row-level-security boundary in the database. Every domain table carries an organization_id with an org-scoped RLS policy. The application uses the service-role key only inside trusted server paths (cron jobs, webhooks, billing); user requests run with the authenticated user's session token, so a database query can never cross-tenant a row by accident.
Authentication
Sessions run on Supabase Auth (cookie-based, HttpOnly, Secure). Optional Google OAuth on registration. Passwords are checked against the Have I Been Pwned k-anonymity API on signup to prevent reuse of breached credentials. Session cookies are SameSite=Lax and rotate on privilege change.
Telephony + voice security
Outbound voice + SMS run through Telnyx with 10DLC registration for US local-number traffic. Every outbound message goes through a unified compliance guard that checks KYC tier, AUP status, per-number quarantine state, internal DNC + opt-out ledger, and quiet-hours window before a single byte leaves the platform. Federal and state DNC scrubbing of customer-uploaded lists is the customer's responsibility under the AUP and DNC attestation. Inbound webhooks are HMAC-verified (Telnyx signature, Resend via Svix).
Web application security
Strict Content-Security-Policy with scoped allow-lists for every external origin. X-Frame-Options: DENY plus CSP frame-ancestors 'none' block clickjacking. X-Content-Type-Options: nosniff, Referrer-Policy strict-origin-when-cross-origin, and a tightened Permissions-Policy round out the header baseline. The marketing surface is statically rendered — no sensitive data ever crosses an unauthenticated origin.
Sub-processors
Lead Friendly relies on a small set of named sub-processors for hosting, telephony, payments, and email. The current list is published at /legal/subprocessors and is updated whenever the stack changes.
Compliance posture
TCPA, the FCC's February 2024 AI-voice ruling, 10DLC + TCR, and DNC obligations are wired into the outbound guards documented in our Acceptable Use Policy. Two-party-consent rules gate call recording: in two-party or unknown-jurisdiction states, rep-dialed calls are not recorded unless a deterministic recording announcement is in place. Every outbound guard decision across voice, SMS, and email — and every consent, opt-out, and recording-gating event — is written to an immutable compliance audit log. Our SOC 2 Type I audit is in progress; we do not yet hold a SOC 2 report. HIPAA is not in scope today and the platform must not be used to transmit protected health information.
Incident response
Suspected security issues should be reported to security@leadfriendly.com. We acknowledge confirmed reports within one business day, triage within three, and follow a coordinated disclosure process. We will notify affected customers of any material security incident as required under our Data Processing Addendum and applicable law.
Vulnerability disclosure
We welcome good-faith security research. Please test only against your own organization, do not run automated scanners against production, do not access other customers' data, and give us reasonable time to remediate before publishing. Reports to security@leadfriendly.com.
Need a security questionnaire or DPA?
Email security@leadfriendly.com for our latest security questionnaire response, the standard Data Processing Addendum, or any custom security review your procurement team needs.