Trust & security
What we do today, what we're working on, and what we'll happily put in writing. Nothing on this page is aspirational marketing — if it's here, the code is in production.
Where we stand today
Encryptionlive
TLS 1.2+ everywhere
Database + S3 encrypted at rest by AWS-managed keys
Tenant isolationlive
Per-tenant scoping
Every query filtered by tenant_id; no cross-tenant lookup possible at the DB layer
Hostinglive
AWS, US region
Single-region today; multi-region failover not yet
SOC 2planned
Not yet
We start the Type I observation window only when our first paid enterprise customer requires it
The trust boundary
Field users can never directly write to your Procore project.
Every RFI and observation generated from a text gets queued in the Approval queue and requires a PM's click before it's sent to Procore. This is enforced in the code path, not just policy — there is no override.
What we have built
Tenant isolation
Every row in every table carries a tenant_id. All queries — including the LLM tool layer — filter by the requester's tenant before returning anything. The dashboard cannot read another tenant's data even with a forged URL because the API rejects it at the auth layer.
Append-only audit log
Every authenticated request, every approval, every webhook, every LLM tool call is recorded with actor, tenant, IP, payload, and outcome. An admin can export the full log for their tenant from this dashboard at any time.
Role-based access control
Five roles: owner, admin, billing_admin, pm, viewer. Approving drafts requires pm or higher. Adding/removing project members requires admin. Every endpoint enforces the minimum role at the request layer; this is not a UI concern.
Field user verification
Field users self-verify by replying to a one-time welcome text. Their phone number is the identity. If they switch phones, an admin must re-verify them — preventing a stolen-phone takeover.
Webhook signature verification
Every inbound webhook (Twilio, SendBlue, Procore, Stripe) is signature-verified before we'll act on it. Unsigned or replayed requests are rejected and audit-logged.
Same-origin media proxy
MMS attachments are served through an authenticated proxy on our domain. Provider tokens (Twilio Basic auth, SendBlue keys) never leave the server.
What you can turn on yourself
Two-factor authenticationSet up in Account
Owners and admins can enable TOTP-based 2FA on their account from the Account & security page. Works with Google Authenticator, 1Password, Authy, or any RFC 6238 client. Admins can require 2FA org-wide.
SSO via SAML or OIDCConnect in Integrations
If your org uses Okta, Azure AD, Google Workspace, OneLogin, or any other SAML 2.0 IdP, we connect through WorkOS. Once enabled at the org level, password sign-in is disabled and access follows your IdP.
Audit log exportExport from Account
Export your tenant's full audit log as JSONL or CSV from this dashboard. Useful for SOX / internal-controls testing, incident response, or your own observability stack.
What is on the roadmap (and isn't done yet)
SOC 2 Type II
We will start the 6-month observation window the moment a paid enterprise customer requires it for procurement. Vanta or Drata for evidence collection. Honest timeline: ~9 months from kickoff to a Type II report.
Third-party penetration test
No formal pen test has been performed. Planned before our first paid enterprise close — we'll work with Cobalt, NCC Group, or Bishop Fox depending on customer preference. Report shareable under MNDA after that.
Customer-managed encryption keys (BYOK)
On the roadmap for the dedicated-deployment tier. Today, encryption at rest uses AWS-managed keys. If your security team requires BYOK, talk to us before signing.
Single-tenant deployment
Today every customer runs on shared infrastructure with row-level isolation. Dedicated VPC + RDS + KMS deployment is on the roadmap for top-tier accounts; not generally available.
EU / non-US data residency
We run in AWS us-east-1 only today. EU residency is on the roadmap when we have a customer requiring it.
Cyber & E&O insurance
Bound before the first paid enterprise close. Not in place today.
Sub-processors we actually use
| Sub-processor | Purpose | Data category | Privacy |
|---|---|---|---|
| Amazon Web Services | Hosting, compute, storage, encryption | All Customer Data | AWS DPA |
| Anthropic | LLM inference (Claude) | Conversation content + photos sent for analysis | Anthropic DPA |
| SendBlue | iMessage / SMS gateway (primary) | Phone numbers, message bodies, MMS media | Privacy |
| Twilio | SMS/MMS gateway (fallback) | Phone numbers, message bodies, MMS media | Twilio DPA |
| Stripe | Subscription billing + invoicing | Billing contact + card metadata (we never see card numbers) | Stripe DPA |
| WorkOS | SSO + SCIM (only if your org enables it) | Identity attributes from your IdP | WorkOS DPA |
We'll notify you if we add a new sub-processor. We don't use third-party analytics, session replay, or marketing pixels in the dashboard.
Reporting a security issue
Found something? Tell us directly.
Email security@getforward.xyz. We acknowledge within 24h. We don't have a paid bug-bounty program yet but we'll happily credit you in our security disclosures page once we have one.