StartOS Trust Center
StartOS is a B2B SaaS platform for finance teams. It holds sensitive operational data: salaries, cap tables, bank balances, tax IDs, and ledger records. We treat that data with the controls a CFO and a CISO would expect: strict access boundaries, encryption in transit and at rest, application-layer encryption for high-sensitivity fields, and audited workflows for every irreversible financial action.
This page is the public mirror of our internal security tracker. Every claim here is backed by concrete implementation: code, configuration, and audit logs. Items are marked LIVE, ON REQUEST, or ROADMAP, with an explicit trigger or target date.
Last updated: July 23, 2026
StartOS is a pre-launch, pre-revenue B2B SaaS platform. We have not completed a SOC 2 audit and we are not SOC 2 attested. What we do have is a foundation of concrete, code-level controls mapped to the SOC 2 Trust Services Criteria (CC1–CC9 plus Confidentiality), an internal control matrix that names every remaining gap, and a public roadmap for closing them. Every claim below points at the actual implementation.
The gap between what we claim and what we deliver is zero, and the roadmap is public. We would rather under-claim and demonstrate than over-claim and disappoint you on the first security questionnaire.
Controls decay without a review rhythm. Ours is published so you can hold us to it. Each review is dated and recorded; records are available to auditors and enterprise customers under NDA.
Monthly security review
A human pass over incidents, newly disclosed CVEs, and control health. The detection side runs continuously: Dependabot opens PRs on new advisories, and npm audit plus gitleaks run on every pull request, every push to main, and again every Monday. The monthly review is where anything those surface gets triaged and closed.
Quarterly access & sub-processor review
A dated review of who holds access to production systems (AWS, Supabase, Vercel, GitHub) confirming each account is still appropriate, alongside a review of every sub-processor listed below: current SOC or ISO report, data-processing agreement, and whether we still need them. Cadence established July 2026.
Annual policy & Trust Center review
Security policies, the incident response runbook, and this page are reviewed at least annually, and updated immediately whenever a material control changes. The last-updated date at the top of this page is that record.
Identity provider
Supabase Auth handles all account login. Email/password or magic link. Session cookies are secure-flagged, HTTP-only, SameSite=Lax.
Password requirements
Minimum 8 characters with complexity enforced by Supabase. Hashing via bcrypt. Account lockout after repeated failed logins.
Two-Factor Authentication (TOTP)
Optional second factor for sign-in. Users enroll via Settings → Profile, scanning a QR code with any standard authenticator app (1Password, Authy, Google Authenticator). Sign-in enforces the second factor for every enrolled user via Supabase's AAL2 contract.
SSO / SAML for enterprise
SAML federation via Supabase SAML provider. Trigger: first enterprise prospect requires it.
Target: On request
Row-Level Security (RLS)
Postgres RLS policies enforce tenant boundaries at the database layer. Even if application code had a bug, the database refuses cross-tenant queries.
Per-request org-membership resolution
Every API route resolves the caller's organization via a single audited helper (`getOrgMembership`). A CI guard fails the build if any new route bypasses this helper.
Instant access revocation
Removing a team member immediately fails every authorization gate, revokes the user's active sessions across all devices (Supabase global sign-out), and invalidates any outstanding magic link (a revoked user who clicks a still-open link is bounced at the auth callback). The membership row is soft-deleted, not hard-deleted, so the record of who had access, and when, survives for audit.
Read-only auditor & accountant seat
External accountants and auditors can be invited with an AUDITOR role that has read access to the books and zero write capability, enforced at every mutation gate in code (not just hidden in the UI). No permission override can grant this role a write.
Segregation of duties on financial actions
Bill approval requires two distinct gates (recognition + payment). Optional strict-mode enforces different users for each gate. Permissions are decoupled from system role so 'CFO who can approve payments but cannot edit settings' is configurable.
Period close locks
Once an accounting period is closed, retroactive postings are refused at the engine level. Same enforcement on year-end close + AP/AR subledger locks.
Encryption in transit
TLS 1.2+ on every connection. HTTPS-only via Vercel's automatic certificate provisioning. HSTS headers.
Encryption at rest (database)
Supabase Postgres is encrypted at rest by the provider.
Application-layer encryption for sensitive fields
Integration credentials (API keys to Stripe, Plaid, HubSpot, etc.) and tax identifiers (SSN/EIN) are encrypted with AES-256-GCM using envelope encryption. Each row has its own 256-bit data encryption key wrapped by a customer-managed master key in AWS KMS (eu-west-3). The master key never leaves AWS; every decrypt call is recorded in CloudTrail. The data is unintelligible to an attacker who exfiltrates the database without also compromising the IAM role.
KMS-grade key custody (production)
Envelope-encryption is active in production. The platform's previous single-key fallback (SECRETS_KEK) has been retired from production environment variables; key material lives entirely in AWS KMS. Annual automatic key rotation is enabled. KMS resolves the correct historical version when decrypting stored DEKs, so rotation is zero-downtime.
Audit log for high-sensitivity actions
Every invoice approval, bill approval/payment, period close, year-end close, vendor credit issuance, and similar action writes an audit-log row with actor, timestamp, IP, and structured metadata. Queryable from /accounting/audit-log.
Per-call audit log for AI tool execution
Every Iskra tool invocation (in-app, via Slack, or via the MCP server) is logged with input, output, duration, and error state. Used for both security audit and tool-quality monitoring.
Off-platform log aggregation
Every audit-log event is dual-written as a structured JSON line tagged audit:true, with PII (emails, names, tax IDs) redacted at the logger boundary, so a SOC 2 auditor has a second independent path to verify any single event. Production Vercel Log Drains forward these lines to Axiom, and the internal admin triage viewer (/admin/logs) queries Axiom directly. Every audit event is also fully retained in-database and queryable from the customer-facing audit-log UI above.
StartOS uses AI agents to read, classify, and (with your authorization) write to your books. The controls below exist so the AI can't make claims it can't back, can't take an irreversible action without your hand on the wheel, and can't cost you anything you can't see.
Numeric fidelity: deterministic answers, no hallucinated math
Every Iskra answer about your data is backed by a typed, Prisma-backed tool call against your GL. The AI does not do arithmetic; the database does. A NUMERIC FIDELITY system-prompt rule enforces that any number in an answer must appear verbatim in a tool response. A nightly + weekly eval harness (`scripts/iskra-eval/`) regression-tests 202 corpus items and fails the build on accuracy drops.
Preview → Apply → Undo on every state-changing AI agent
No AI agent posts a journal entry, sends an email, or applies a payment without an explicit two-step pattern: Preview returns what WOULD happen, Apply commits with an audit trail tagging the originating workflow run, Undo reverses cleanly. Email-sending agents add dedup windows (24h investor email, 7d AR reminders, 24h CFO digest) so you can't double-fire. Bank auto-match returns proposals; you Apply per-match or in batch. Full pattern documented in our internal Agent Design Rubric. Every state-changing agent in production complies.
Per-call AI cost + token logging
Every LLM call (Iskra tools, Iskra chat, IskraFlow interpret, AI bill reader, flux narrative, etc.) writes a structured `AiUsageRecord` with model, provider, token counts (input/output/cache-create/cache-read), USD cost, calling-feature attribution, and tenant scope. You can audit AI spend per-agent + per-period; we can detect cost regressions before you see them on a bill.
Refusal classifier on every Iskra answer
A secondary Haiku classifier runs post-response on every Iskra answer, flagging paraphrased refusals (`I don't have access to that data`, `outside my scope`) that escape exact-string match. Catches scope-violation attempts + tracks Iskra's refusal discipline as a quality metric.
Tenant scope enforced inside tool executors
Every Iskra tool validates the target organization against the caller's allowed-orgs set inside the executor, not the prompt, not the LLM. A model that hallucinates an `orgId` will be refused at the tool boundary with an error message the LLM can self-correct from. Portfolio (VC/PE) tools enforce firm-membership the same way.
Rate limiting
Sliding-window rate limits on every API route. Sensitive auth endpoints get stricter caps (5/min, 30/hr). Standard endpoints are 120/min, 2000/hr. Per-user keying on authenticated routes; per-IP otherwise.
Input validation on mutation routes
Zod schemas validate every incoming mutation request before it touches the database. Prisma's parameterized queries prevent SQL injection on every DB call.
Dependency scanning
GitHub Dependabot opens PRs for any new CVE in our dependency tree. `npm audit` fails CI on any high or critical CVE in the dependency tree, blocking the merge. Re-runs every Monday morning to catch CVEs disclosed after a PR has already merged.
Secret scanning
gitleaks scans every PR and every push to main for accidentally-committed API keys, AWS keys, private keys, and similar credentials. Full git history is scanned, not just the diff; secrets leaked in older commits are still leaks today.
Status page
Public status page showing uptime and any active incidents. Hosted by Better Stack with a 3-minute uptime probe against startos.io from multiple regions. Visitors can self-subscribe to incident notifications.
status.startos.io →Incident response runbook
Documented procedure for security incidents: detection, containment, customer notification timelines, post-mortem cadence. 5-phase response (Detect → Contain → Eradicate → Communicate → Review) with severity tiers, containment-action playbook, communication templates, and post-incident review template.
EU hosting
The primary Supabase project hosting customer data is in eu-west-3 (Paris). Customer data does not leave the EU unless you explicitly sync it to a third-party service you control.
GDPR right-to-erasure flow
Self-serve deletion request form (authenticated or anonymous). Hard-deletes auth + memberships + API keys; anonymizes Contact/Employee PII; retains financial records (invoices, bills, transactions) under tax/audit legal hold per GDPR Article 17(3)(b). 30-day response window. Every processed request writes a detailed audit log.
Request deletion →DPA (Data Processing Agreement) template
Lawyer-reviewed Standard Contractual Clauses for EU customers.
Target: Tier 2
SOC 2 readiness assessment
Complete. Every Trust Services Criterion is mapped to a specific StartOS control, with an owner, evidence type, and evidence location, plus an honest list of what is still open. That matrix is maintained internally and is what a compliance-automation platform and auditor will work from. Summary published below; full matrix available under NDA.
SOC 2 Type II
We've mapped our existing controls to the SOC 2 trust service criteria (CC1–CC9 + Confidentiality) and are selecting a SOC 2 automation platform to begin the formal engagement. Full Type II attestation is targeted for the post-funding milestone. We'll share the report under NDA to customers once available.
Target: Post-funding milestone
External penetration test
Focused scope: web app + API + MCP server. Pre-launch milestone. Report will be summarized publicly + available in full under NDA.
Target: Pre-launch
ISO 27001
Not started. We have not performed an Annex A gap analysis and make no claim of alignment today. SOC 2 comes first because it is what our buyers ask for; ISO 27001 follows if EU enterprise demand requires it.
Target: EU enterprise requirement
SIG Lite questionnaire
A pre-filled SIG Lite security questionnaire is available on request. Email security@startos.io.
We use the following third-party services to operate StartOS. Some are always-on (database, hosting, email); others are activated only if you explicitly connect them as integrations. We do not send customer data to a third-party service unless you have explicitly authorized that integration.
| Service | Purpose |
|---|---|
| Supabase | Database, authentication, storage |
| Vercel | Application hosting, edge network, and cookieless web/performance analytics |
| AWS | KMS for envelope encryption |
| Resend | Transactional email |
| Stripe | Payment processing |
| Anthropic | LLM for Iskra (Claude) |
| OpenAI | AI Spend + L4 categorization |
| Plaidif connected | Bank connection sync |
| HubSpotif connected | CRM sync |
| Salesforceif connected | CRM sync |
| Gustoif connected | Payroll sync |
| Cartaif connected | Cap table import (one-time) |
| Bill.comif connected | AP sync |
| Anrok / Avalaraif connected | Sales tax calculation |
| Ramp / Brexif connected | Corporate card sync |
| QuickBooks / Xeroif connected | Migration import (one-time) |
| Snowflakeif connected | Cost / SPCS revenue sync |
| GCPif connected | Vertex AI cost sync (BigQuery) |
| Toggl / Harvestif connected | Timesheet sync |
| Slackif connected | Slash commands + DM Iskra |
The SOC 2 Security category, the Common Criteria CC1 through CC9, is mandatory in every SOC 2 examination. The table below is the external view of how our current controls map to it. Physical and infrastructure criteria are inherited from sub-processors that each carry their own SOC 2 Type II (Supabase, Vercel, AWS), which is the standard carve-out an auditor expects. Where a criterion is met in practice but the written policy is still being drafted, we say so rather than rounding up.
| Criteria | StartOS controls (external view) |
|---|---|
| CC1Control environment | Security ownership named at founder level. Documented incident response runbook with severity tiers. Segregation of duties on financial actions (recognition and payment are distinct gates, with an optional strict mode requiring different approvers). Role-based access with permissions decoupled from system role. Read-only auditor seats enforced at every mutation gate in code.Open: A written Code of Conduct and Information Security Policy are not yet published. The practice exists; the documents do not. |
| CC2Communication & information | This Trust Center, with explicit status and roadmap per control. An internal security tracker that this page mirrors. An incident runbook containing customer communication templates and notification timelines. Dedicated security@ and privacy@ intake for vulnerabilities, questionnaires, and data subject requests. |
| CC3Risk assessment | Technical risk surfaces are monitored continuously: Dependabot opens PRs on new advisories, npm audit blocks any merge carrying a high or critical CVE, and gitleaks scans every PR plus the full git history for leaked credentials.Open: A formal written risk assessment (asset inventory, threat list, likelihood and impact scoring, treatment plan) does not yet exist. It is our largest single open item ahead of an audit engagement. An external penetration test is on the roadmap. Continuous scanning is a real control, but it is not a substitute for either of those. |
| CC4Monitoring activities | Centralized audit logging of high-sensitivity financial actions, dual-written to off-platform log aggregation (Axiom) with PII redacted at the logger boundary, so evidence survives independently of the application database. Public status page with a multi-region uptime probe. CI gates on every pull request. Per-call AI cost and token logging across every agent. Published monthly and quarterly review cadence (see Governance above). |
| CC5Control activities | Documented five-phase incident procedure (Detect, Contain, Eradicate, Communicate, Review). Accounting period and year-end close locks refused at the engine level rather than hidden in the UI. Segregation of duties on payments with configurable approval thresholds. A Preview, Apply, Undo pattern on every state-changing AI agent, with dedup windows on anything that sends email. |
| CC6Logical & physical access controls | Supabase Auth with secure, HTTP-only session cookies and enforced password complexity. Optional TOTP two-factor, enforced at sign-in for every enrolled user. Postgres row-level security for tenant isolation at the database layer. Per-request organization membership resolved through a single audited helper, with a CI guard failing the build if a new route bypasses it. Instant access revocation that kills active sessions and invalidates outstanding magic links, with soft-deleted membership rows preserving the audit record. Read-only auditor seats. Rate limiting on every route. Physical security inherited from sub-processors under their own SOC 2 Type II.Open: Access reviews moved to a documented quarterly cadence in July 2026, so the record history starts there rather than running back years. |
| CC7System operations | TLS 1.2 or higher on every connection, HSTS, and provider encryption at rest. Envelope encryption for integration credentials and tax identifiers using per-row data keys wrapped by a customer-managed AWS KMS key, with every decrypt recorded in CloudTrail and annual automatic rotation. Zod validation on every mutation and parameterized queries throughout. Structured AI usage recording and a refusal classifier on every AI answer.Open: Vulnerability remediation SLAs by severity are not yet documented, and a backup restore drill with stated RPO and RTO has not yet been performed. Both are prerequisites for electing the Availability criteria. |
| CC8Change management | All changes ship through pull requests with CI gates: authorization-helper enforcement, dependency and secret scanning, type checking, build, and a regression harness that fails the build if AI answer accuracy drops. Deployments run through Vercel and Supabase with no ad hoc production edits. Schema changes follow a reviewed migration path rather than direct writes to production.Open: The written Change Management policy formalizing this practice is not yet published. |
| CC9Risk mitigation | Sub-processors are individually scoped, published with their data flows and current SOC or ISO status, and reviewed quarterly. Optional integrations are tagged so it is clear a third party receives data only once you explicitly authorize it. GDPR erasure hard-deletes identity and access data, anonymizes personal data, and retains only the financial records held under a legal hold. External penetration test and SOC 2 Type II attestation are on the published roadmap. |
For auditors and enterprise security teams, we maintain a full internal control matrix mapping each criterion to specific StartOS controls, owners, frequencies, and evidence locations, including the open items above. We are happy to walk through it under NDA as part of your due diligence: security@startos.io.
If you believe you've found a security vulnerability in StartOS, please report it to security@startos.io, or see the structured policy at /.well-known/security.txt.
Our commitment: we will acknowledge receipt within 2 business days, share an initial assessment within 5 business days, and provide regular updates until the issue is resolved. We do not currently run a paid bug bounty program but we will publicly acknowledge contributions (with your permission) on this page once we have anything to acknowledge.
Please don't:attempt to access data that isn't yours, perform denial-of-service testing without prior coordination, or publish details before we've had a chance to remediate.
Security questions, customer security questionnaires, or SIG Lite requests: security@startos.io
Privacy / GDPR / data subject requests: privacy@startos.io