Arx is built for early-stage founders. The data you put into Arx — your cap table, your SAFEs, your investor pipeline, your data room, your financial model — is among the most sensitive information your company holds. This page describes the controls we have in place to keep it safe. It is the public-facing companion to our internal security program and policies.
SRVC Technologies Inc. (dba Arx) is the data controller for our marketing site and the data processor for customer workspace data. This document covers our production environment at app.foundersarx.com.
We commit to (i) protecting workspace data with industry-standard controls; (ii) isolating each customer's data from every other customer's data; (iii) maintaining a written security program reviewed at least annually; (iv) notifying affected customers without undue delay following confirmation of a security incident that materially affects their data; and (v) treating customer content as confidential and not using it to train AI models used by other customers.
The production environment runs on managed cloud providers that are themselves audited under SOC 2 / ISO 27001:
All inbound and outbound traffic uses TLS 1.2 or higher. We do not accept connections on lower protocol versions. HSTS is enabled on all production hosts. There are no on-premise components and no employee laptops store production customer data.
For customers: Sign-in supports email + password, Google OAuth, magic links, and TOTP-based two-factor authentication. Workspace roles (Owner, Admin, Member) gate every mutating action; invites are scoped and revocable. Public sharing surfaces (data room, deck, public booking) require either a per-recipient link or an email-gated viewer session and never expose workspace data beyond what was explicitly shared.
For Arx personnel: Production access is restricted to a small number of named engineers and requires hardware-backed two-factor authentication on every provider console. Each access event is logged at the provider level. Engineers do not have routine access to customer content; ad-hoc access is documented and justified. We do not maintain a customer-support "impersonation" mode.
Each customer workspace has its own company_id. Every authenticated API request resolves the caller's company on the server side and every read or write is scoped by that identifier. PostgreSQL Row-Level Security policies enforce the same constraint at the database layer, so a defect in application code cannot leak rows belonging to another workspace. Background jobs and AI tool calls carry the same company_id binding. Automated isolation tests run on every pull request and on a daily schedule.
dangerouslySetInnerHTML on user-provided content. Email templates render through a sanitizer before send. X-Content-Type-Options, Referrer-Policy, Permissions-Policy) are set on every response.Application logs, request traces, and audit events flow from Vercel and Railway into our observability backend. We retain application logs for 30 days and a per-workspace audit log of mutating actions (who, what, when) for at least 12 months. Alerts page the on-call engineer for error-rate anomalies, authentication abuse, and integration failures. Provider logs (database, storage, authentication) are retained per the provider's retention policy and reviewed during incident response.
We use a small number of subprocessors to provide the Service. Each subprocessor is bound by a written data processing agreement and is selected for its security posture, contractual commitments, and minimum-access footprint. The current list, including data categories sent to each, is published at /subprocessors. We notify customers in advance of any material change to this list.
Our Secure Software Development Lifecycle (SSDLC) is documented at /sdlc. In summary: protected main branch with mandatory peer review and required CI checks (lint, typecheck, automated test suite, build, Docker validation) before merge; static analysis and dependency scanning on every pull request; production-credential isolation; CI-only deploys with audit trail.
We accept responsible vulnerability reports at /responsible-disclosure. Internally, we maintain an inventory of dependencies, scan for known vulnerabilities daily, and patch on a severity-based schedule (critical within 7 days, high within 30 days). Infrastructure and dependency management practices are documented at /infrastructure.
Our incident response process — detection, classification, containment, eradication, recovery, customer notification, and post-mortem — is documented at /incident-response. Confirmed incidents that materially affect customer data trigger written notice to the affected workspace owner without undue delay and, where applicable, within the timeframe required by law.
For security questions, vulnerability reports, or to request additional documentation (security questionnaires, SOC 2 progress letter, sub-processor DPAs):
This document is provided for transparency. It is not legal advice and is not a contract; customer-specific terms may apply to enterprise agreements and DPAs.