How Planning Ops keeps your data safe

Your pour schedule, your customer list, your crew assignments, your billing records — every piece of operating data your business runs on lives in our database. Trust is the table stakes for that. This page describes the specific controls in place. We update it as the posture evolves.

Tenant isolation: row-level security in the database

Every customer (tenant) on Planning Ops has a unique tenant_id. Every row in every operating-data table carries that tenant_id as a required column. PostgreSQL row-level security (RLS) policies are enforced at the database layer: a query for "all pours" returns only the pours for the authenticated user's tenant — regardless of what the application code asks for.

This is stronger than application-layer filtering. Even if a bug in our code tried to fetch another tenant's data, the database refuses. The same protection applies to writes, updates, and deletes.

Authentication and Session Management

Encryption

• Encryption in transit: All traffic served over HTTPS (TLS 1.2+). HSTS preload with max-age=63072000; includeSubDomains; preload across every subdomain. The Chromium HSTS preload list is honored — browsers connect via HTTPS by default before any DNS lookup.
• Encryption at rest: All database storage encrypted at rest by our hosting provider (Supabase / AWS RDS underlying).

Browser-side defense: strict Content Security Policy

Every page Planning Ops serves ships with a strict Content Security Policy (CSP) that whitelists exactly which domains can load scripts, styles, fonts, images, and network requests. Plus:

• frame-ancestors 'none' — clickjacking protection
• X-Frame-Options: DENY — same, for older browsers
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy denying camera, microphone, geolocation, payment (except on signup), USB, Bluetooth, accelerometer, gyroscope, magnetometer

Any XSS bug we'd ship would fail to load the attacker's payload because the CSP doesn't trust the source.

Audit Logging

Every meaningful action — pour created, pour canceled, employee added/removed, crew assigned, role changed, branding updated, user invited or removed — writes a row to the audit log with the actor, timestamp, and changed values. Administrators of each tenant can see their own audit log; we cannot read into another tenant's log.

Platform-administrator access (support sessions)

Planning Ops staff may sign in to a workspace as one of your users for the limited purpose of support, investigation, or legal/security response. Every such sign-in is:

• Logged in your audit log as platform.impersonate_tenant — visible to your admins
• Time-limited to 30 minutes via automatic client-side timeout
• Single-use link that expires within 5 minutes if unused and cannot be replayed
• Banner-flagged — an orange banner appears at the top of the workspace while the session is active
• Revocable — your admins can email us to end any active session immediately

We do not maintain standing background access. Routine operations (backups, monitoring) use service-level credentials that read only metadata, not your operating data.

Backups and Disaster Recovery

• Database backups taken continuously by the hosting layer (point-in-time recovery up to 7 days)
• Daily snapshot retention for 30 days
• Geographic redundancy via the hosting provider's multi-AZ deployment
• Stripe and Resend (our payment + email processors) maintain their own backups under their respective security postures (both SOC 2 Type II)

Vendor Sub-Processors

Documented in the Privacy Policy. The short list:

• Supabase — database, authentication, edge compute (SOC 2 Type II)
• Stripe — payment processing (PCI DSS Level 1, SOC 2 Type II)
• Netlify — static site hosting
• Resend — transactional + marketing email
• Twilio — SMS / text-message notifications
• PostHog — product analytics (SHA-256 hashed email only, no plaintext)
• Open-Meteo — weather forecasts (project ZIP only, no personal data)

Vulnerability Reporting

Found a security issue? Email admin@planningops.com with the subject "Security report". We respond within one business day. We do not have a paid bounty program yet but we credit reporters publicly (with permission) when reports lead to fixes.

What we don't claim

Honesty over marketing:

• We are not currently SOC 2 audited. Our sub-processors are; we are not. If you need a SOC 2 report from us for procurement, contact us about timeline.
• We don't claim HIPAA, FedRAMP, or other federal compliance. Not our market.
• We don't have a published bug-bounty program. Reports still go to admin@planningops.com and are reviewed.

Non-Technical Summary

If you're not a security person and just want the takeaway:

• Your data is yours, and another customer can't see it — that's enforced at the database, not just our code.
• Your password is hashed; we never see it.
• You can turn on 2FA for your admin account.
• All web traffic is encrypted. Our data storage is encrypted.
• Every change is logged.
• If we ever need to log in to your workspace for support, it's visible to you, time-limited, and you can shut it down.