Important. These materials describe how The Long Run Group (“TLR”) presents its website and related services, based on the current implementation in this project. They are not legal advice and are not represented as final or binding until a verified contracting party, applicable law, and counsel review are completed. Where a statement depends on corporate registration, hosting region, or contractual arrangements TLR has not published, the text explains the limitation instead of assuming facts.
This Security Overview summarizes security considerations for The Long Run Group (“TLR”) digital services. It describes intended practices and patterns visible in this repository where noted. It does not certify compliance with SOC 2, ISO 27001, PCI-DSS, or other frameworks unless TLR publishes evidence separately.
1. Governance and scope
TLR maintains security practices appropriate to its services . This page covers the public marketing site and high-level expectations for Runner; customer-specific commitments may appear in order forms and the Data Processing Agreement. Engineering runbooks for the marketing site (migrations, Edge Function secrets, webhook configuration) appear in site form integration documentation in the repository and Supabase project configuration for internal use—not as a public SLA.
2. Shared responsibility
Security is shared: TLR secures infrastructure and application layers it controls; customers configure Runner, manage users, and protect credentials in their environments. Visitors must protect email access used for magic-link login and avoid submitting sensitive data unnecessarily in public forms.
3. Account and access (public site)
Early access may use email magic links (Supabase Auth) without a password field on the public login flow. OAuth provider buttons require explicit configuration before they are active. Database writes from the browser use RPC functions with role grants defined in migrations—not direct anonymous table access.
4. Access control (operations)
- Staff access:
- Public site users: Magic-link authentication via Supabase Auth for enabled flows.
- Database access: Anonymous visitors cannot directly insert into
site_form_submissions; writes go through security definer RPC with validation (see migrations).
5. Application security (marketing site — repo-verified patterns)
- Publishable Supabase key only in browser configuration; service-role keys must remain server-side.
- Honeypot field on forms—automated submissions may receive success without database insert.
- Duplicate submission throttling per email and form type (two-minute window).
- Row Level Security on sensitive tables with grants revoked from broad roles where migrations define it.
- Edge Function
notify-site-formrequires shared secret headerx-tlr-webhook-secretpersite form integration documentation in the repository and Supabase project configuration. - Idempotent email delivery tables to reduce duplicate provider calls on webhook retries.
Additional developer documentation may appear on security-related developer pages .
6. Data protection
Data in transit should use TLS for HTTPS endpoints . Data at rest depends on Supabase and hosting contracts . Form payloads are stored as JSON in Postgres. Collect only fields necessary for each purpose; align with the Privacy Policy.
7. Incident response
TLR maintains procedures to detect, contain, and remediate security incidents . Suspected vulnerabilities should be reported through company contact or channels TLR designates—do not test production without authorization.
8. Business continuity
TLR relies on cloud providers for hosting and data services .
9. Compliance and audits
Publish certificates or audit reports only when available and authorized . Subprocessors: Subprocessors. Acceptable use: Acceptable Use Policy. AI: AI Transparency.
10. Contact
Security Questions: contact TLR via company contact or request demo / sales. General: contact, company contact.