Security at Brynlock
Brynlock encrypts all data in transit with TLS 1.3 and at rest with AES-256 via Supabase managed Postgres on AWS. Every facility's data is isolated at the database layer with PostgreSQL Row-Level Security. Payments run through Stripe (PCI DSS Level 1), so Brynlock servers never store raw card numbers. Confirmed incidents are reported to affected operators within 72 hours.
Security contact: hello@brynlock.com
Updated
Controls map
The security controls below align with the SOC 2 Trust Services Criteria. SOC 2 Type II certification is in progress with target completion Q4 2026.
| Area | Control | SOC 2 Criterion |
|---|---|---|
| Data in transit | TLS 1.3 enforced on all endpoints | Security |
| Data at rest | AES-256 via Supabase managed Postgres on AWS | Security · Confidentiality |
| Tenant isolation | PostgreSQL Row-Level Security on every public table | Security · Confidentiality |
| Authentication | Supabase Auth with secure cookies; service-role keys server-only | Security |
| Payment processing | Stripe PCI DSS Level 1; card data never touches Brynlock | Security · Confidentiality |
| Backups | Daily automated backups with 30-day retention; restore tested | Availability |
| Logging & audit | Tamper-evident audit_log table; tracked changes per record | Security · Processing Integrity |
| Vulnerability scanning | Continuous dependency scanning; manual code review on PRs | Security |
| Incident response | 48h acknowledgement · 72h customer notification on confirmed incidents | Security · Availability |
How Brynlock protects your data
Encryption
Encryption is the baseline. All data in transit is protected with TLS 1.3. Data at rest is encrypted with AES-256 via Supabase managed Postgres. Encryption keys are managed by Supabase and rotated on a regular schedule. See Supabase Platform Security for the underlying infrastructure controls.
Database row-level security
RLS is enforced at the database layer, not the application layer. Every public table has PostgreSQL Row-Level Security policies that filter results by the authenticated user's facility_id before any row is returned. An application bug cannot bypass this; the database itself refuses unauthorized reads. Service-role keys are restricted to server-side code paths. Row-level isolation does not limit data portability. See the no vendor lock-in commitment for the export guarantee.
Payment security via Stripe
Card data never touches Brynlock servers. Payment processing runs through Stripe Elements, which sends card data directly from the tenant's browser to Stripe's PCI DSS Level 1 environment. Brynlock receives only the resulting payment_intent_id. See Stripe Security for processor controls.
Infrastructure and backups
All customer data stays in the US. Application and data hosting runs on Supabase US-East-1 (AWS us-east-1). Automated database backups run daily with 30-day retention. Vercel hosts the application layer with edge caching for static assets. No customer data is replicated outside the US.
Incident response
48 hours to acknowledge, 72 hours to notify. Report incidents to hello@brynlock.com. All reports are acknowledged within 48 hours. For confirmed incidents affecting customer data, Brynlock notifies affected operators within 72 hours, consistent with state breach notification laws.
Responsible disclosure
Coordinated disclosure with researcher credit. Send vulnerability reports to hello@brynlock.com with steps to reproduce. Brynlock follows a 90-day coordinated disclosure timeline, credits researchers by name on request, and does not pursue legal action against good-faith research.
Common questions
How does Brynlock encrypt customer data?
All data in transit is encrypted with TLS 1.3. Data at rest is encrypted with AES-256 via Supabase managed Postgres on AWS, with keys managed by Supabase and rotated on a regular schedule. Encryption is enforced at the database layer; no plaintext storage path exists.
How is one facility's data isolated from another?
Every public table has PostgreSQL Row-Level Security (RLS) enforced at the database, not at the application layer. Queries are filtered against the authenticated user's facility_id before rows are returned. An application-layer bug cannot expose Operator A's data to Operator B because the database itself refuses the read.
Is Brynlock SOC 2 certified?
Brynlock is working toward SOC 2 Type II certification with target completion Q4 2026. Current controls align with the SOC 2 Trust Services Criteria for Security, Availability, and Confidentiality. Enterprise customers can request the SOC 2 report once the audit is complete.
Where is customer data stored?
All customer data is hosted in the United States on Supabase US-East-1 (AWS us-east-1). No customer data is replicated, cached, or stored outside the US. Static assets are served via Vercel's edge cache; tenant and facility records remain in the primary US-East region.
How are backups handled?
Automated point-in-time database backups run daily with 30-day retention. Backups are encrypted at rest and stored in the same US region as the primary database. Restoration is tested as part of the SOC 2 readiness process.
Does Brynlock ever store card numbers?
No. All payment processing flows through Stripe, a PCI DSS Level 1 certified processor. Card data passes directly from the tenant's browser to Stripe via Stripe Elements. Brynlock servers never receive, store, or log raw card numbers, CVVs, or full PANs.
What is the breach notification timeline?
For confirmed incidents affecting customer data, Brynlock notifies affected operators within 72 hours of confirmation, consistent with state data breach notification laws. Reports of suspected incidents are acknowledged within 48 hours of receipt at hello@brynlock.com.
How does Brynlock handle responsible disclosure?
Security researchers can report vulnerabilities to hello@brynlock.com. Brynlock follows a coordinated disclosure process, requests 90 days to patch before public disclosure, and credits researchers by name on request. Brynlock does not pursue legal action against good-faith researchers.
Security questions or audit requests?
Email hello@brynlock.com. Enterprise customers can request the in-progress SOC 2 Type II readiness summary.