Security Practices

StartManaging-Legal serves law firms — material that, mishandled, can break client privilege and end a firm. We treat the security of the Service as a first-class engineering concern. This page describes the technical and operational controls we rely on, and how they align with the GLBA Safeguards Rule framework that the FTC applies to financial institutions (including law firms providing financial services to their clients).

1. Encryption

• In transit. TLS 1.2 or higher with modern cipher suites for every public endpoint, enforced via HSTS (max-age = 1 year, includeSubDomains, preload). HTTP redirects to HTTPS automatically.
• At rest. AES-256 encryption on the application database (Neon Postgres) and on object storage for backups (Cloudflare R2). Encryption keys are managed by the respective providers and rotated on their published cadence.
• Passwords. Bcrypt cost factor 12. We never store plain-text passwords and we cannot recover one — only reset.

2. Multi-tenant isolation

Every customer firm runs in a logically isolated tenant in a shared Postgres database. Isolation is enforced at two layers:

• Database row-level security. Each tenant- scoped table carries a tenantId column and a Postgres RLS policy that admits only rows whosetenantId matches the session variableapp.tenant_id, which is set inside an explicit transaction at the start of every API request.
• Application permission check. Every API route runs through withApi(), which resolves the caller’s session, opens an RLS-pinned transaction, and requires the caller’s role to grant the right permission before mutating any data.

A cross-tenant query is therefore both unreachable (RLS returns zero rows even if the application forgets to filter) and unauthorized (the permission check is independent of RLS).

3. Authentication and access

• Every Firm User must enroll in time-based one-time password (TOTP) multi-factor authentication on first login. We do not rely on SMS as a second factor.
• Sessions live in signed JWT cookies with HttpOnly, Secure, and SameSite=Lax attributes.
• Role-based access control with per-permission gates on every mutating endpoint. Owners can grant or revoke a teammate’s permissions immediately without re-login.
• Internal StartManaging-Legal, LLC staff (which includes designated Shoal Valley Systems executives acting on the subsidiary’s behalf) access the customer database only via the admin console at admin.startmanaging-legal.com, which is IP- allowlisted, MFA-mandatory, and audit-logged. We do not run ad-hoc queries against the production database from engineering laptops.

4. Auditing and monitoring

• Every successful mutation through the API is recorded as anAuditEvent with actor, tenant, IP, user-agent, entity, and entity ID. Owners and Read-only Auditors view the timeline under Firm Settings → Audit Log.
• Application errors are reported (without PII) to Sentry. Uptime is monitored externally by Better Stack with a public status page at status.startmanaging-legal.com.
• Authentication-failure spikes, 5xx surges, database pool exhaustion, and backup-job failures fire pages to on-call.

5. Backups

• The application database has point-in-time recovery enabled with a continuous 7-day window.
• A daily snapshot is copied to a separate immutable Cloudflare R2 bucket in a different region. Bucket lifecycle retains snapshots for 35 days; we test-restore a snapshot at least once per quarter.
• Customers can additionally export a full JSON backup of their own tenant from /backup at any time.

6. Software supply chain

• Dependencies are managed with npm + a committed lockfile. New dependencies are reviewed before merging.
• Continuous dependency vulnerability scanning runs in CI. High-severity advisories block deploys until patched.
• GitHub branch protection requires a passing build and a peer review for every change to main.

7. Incident response

We follow a documented incident-response runbook. The on-call engineer triages within 30 minutes. If the incident affects any Firm User’s data we notify the affected firm without unreasonable delay, and in any event within 60 days, as required by Texas Business & Commerce Code §521.053. The notice will describe what happened, what data was involved, what we are doing about it, and what the firm should do.

8. GLBA Safeguards alignment

StartManaging-Legal’s controls map to the FTC Safeguards Rule (16 C.F.R. §314) as follows:

• §314.4(a) Qualified Individual. StartManaging-Legal’s Head of Engineering serves as the qualified individual responsible for the information security program.
• §314.4(b) Risk assessment. Updated at least annually and after any material change to the Service.
• §314.4(c) Safeguards. Sections 1–4 of this document describe the in-place safeguards.
• §314.4(d) Testing. Quarterly access reviews, quarterly backup-restore drills, annual third-party penetration test.
• §314.4(e) Training. All engineering staff complete annual security and privacy training.
• §314.4(f) Service providers. Each sub- processor (Neon, Vercel, Resend, Sentry, Cloudflare) is bound by a written contract incorporating equivalent safeguards. The list of sub-processors is current as of the effective date and updated when it changes.
• §314.4(g) Program updates. The program is updated as risks change.
• §314.4(h) Incident-response plan. See Section 7.

9. Responsible disclosure

If you have discovered a vulnerability, please email security@startmanaging-legal.com. We do not threaten or pursue researchers who act in good faith, who do not access data they aren’t entitled to, and who give us a reasonable window (typically 90 days) to fix the issue before publicly disclosing it.