Security Overview

• Application: Vercel (United States region). The application runs as serverless functions; there is no long-lived server with persistent disk.
• Database and file storage: Supabase (United States region). Postgres database with row-level security policies, plus an S3-compatible object store for uploaded documents.
• CDN and DNS: Cloudflare. Static assets are served from Cloudflare’s edge; the application origin is reached via Vercel.
• Email: Resend. Outbound transactional email only, magic-link sign-in, agent invites, pay-period notifications, daily reminders.
• Optional integrations: Google Drive (file sync, only when Customer connects it) and Telegram (team-chat bot, only when Customer configures it).

See Privacy Policy §8 and Data Processing Addendum §7 for the complete subprocessor list and our change-notification policy.

• In transit: All traffic to and from the Service uses TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enabled. Insecure HTTP requests are redirected to HTTPS at the edge.
• At rest: Database content and object storage are encrypted at rest using AES-256 by our storage subprocessor (Supabase).
• Application secrets: Environment variables and API keys are stored in Vercel’s encrypted secret store. No secret is committed to source control.

Envelope encryption of stored W-9 PDFs and other sensitive documents is on our roadmap for customers whose risk profile requires it. The current posture is detailed below.

• Magic-link sign-in. No passwords are stored. To sign in, the user receives a one-time link at the email address on file. The link is single-use and expires after a short window.
• Session lifetime. Sessions are bound to a server-side cookie. The cookie expires after a fixed absolute lifetime and after a shorter idle lifetime. Both are enforced server-side.
• Audit logging. Sign-in events, sign-out events, and session timeouts are recorded in an authentication audit log visible to owners and admins of the agency.
• Account compromise response. Reports of suspected compromise to support@ragencyos.com result in immediate session invalidation and investigation.

• Row-level security (RLS). Every database table containing customer data has RLS policies that restrict reads and writes to members of the relevant agency. The policies are enforced at the database layer, not the application layer, there is no application path that bypasses them.
• Role-based access. Within an agency, users are owners, admins, or agents. Each role has a defined set of capabilities; sensitive actions (such as agent termination, pay-rate changes, and access to W-9 documents) are restricted to owners and admins.
• Service-role access. A small set of server-side operations (cron jobs and admin endpoints) uses a service-role key with RLS bypass. These operations are limited to specific code paths, run only on the server, and emit audit events where they touch customer data.

W-9 forms (which contain SSNs), photo identification, and similar identity documents are stored as files in a private Supabase Storage bucket. The bucket is not publicly readable. Owners and admins access these documents only via short-lived signed URLs generated on demand by the application. The signed URL expires automatically after a short window.

We do not extract, OCR, index, or otherwise process the contents of these documents. The SSN never appears in plain text in the application database, in application logs, in email, or anywhere else outside the encrypted PDF itself.

• Application and HTTP request logs are retained by Vercel for the period defined in their service terms.
• Database logs and authentication events are retained by Supabase.
• A separate in-product audit log records sensitive customer-initiated actions (pay-rate changes, agent termination, agent reactivation, W-9 access patterns where relevant, e-signature submissions, etc.). This audit log is available to owners and admins on Premium accounts and is exportable as XLSX up to 25,000 rows per export.

• Database backups. Postgres daily backups are maintained by Supabase. Point-in-time recovery is available within a rolling 7-day window.
• Object storage backups. Uploaded files are replicated within the storage subprocessor’s infrastructure per their service-level practices.
• Restore drills. We test the ability to restore from backup periodically. We do not currently publish a formal Recovery Time Objective (RTO) or Recovery Point Objective (RPO); we will do so before pursuing SOC-2 certification.
• Data deletion and backup rotation. Customer data deleted from the live database is removed from backups within 30 days as backups rotate.

• Dependency management uses a lockfile and pinned versions; security advisories from npm, GitHub Dependabot, and our package registry are reviewed and addressed.
• Source code is hosted in a private repository with branch protection on the production branch. Production deploys are tied to merges into that branch.
• Inputs from users and uploaded files are validated server-side. Output rendering uses framework-default escaping; we do not use dangerouslySetInnerHTML with user-supplied content except in carefully reviewed paths (such as branded email bodies, which are rendered server-side).
• Cross-site request forgery is mitigated by the framework (Next.js server actions require origin matching).
• Cross-origin requests are restricted to known origins by the application’s CORS configuration.

Each subprocessor listed in Privacy Policy §8 has been selected for its security posture as well as its functional fit. We monitor each vendor’s public security disclosures and status pages. Customers are notified by email when the subprocessor list changes materially (see DPA §7).

When we become aware of a confirmed security incident affecting Customer data, we will follow the breach-notification procedure described in Privacy Policy §13 and DPA §11. Affected account owners will receive email notice within 72 hours of confirmation, with as much detail as we can responsibly share at that point and a follow-up as the investigation progresses.

To report a suspected security issue, email support@ragencyos.com. Please include as much detail as you can; we will respond within one business day.

We are honest about where we are:

• SOC 2 Type II: Not yet pursued. On the roadmap when customer demand justifies the audit cost.
• ISO 27001: Not pursued.
• HIPAA: Out of scope. The Service is not designed to receive PHI. We do not sign Business Associate Agreements. See Privacy Policy §14.
• GDPR: The Service is currently offered only in the United States. If we expand to the EU/UK, we will implement Standard Contractual Clauses and update this page.
• CCPA / CPRA, VCDPA, CPA, CTDPA: Honored. See Privacy Policy §12.

Security questions, audit requests, vulnerability disclosures: