Security at FORTVISION

1. Architecture & hosting

Data location

• API functions run in Vercel's default region (USA, iad1); no other region is configured.
• Media files, backups and store-plugin data: AWS Ireland (eu-west-1).
• The Redis database region is set per database in the Upstash account and the SES region in the environment configuration — both provided on request.

2. Authentication

• Passwords are stored as scrypt hashes with a per-user random salt (N=16384). Legacy hashes are upgraded transparently on the next sign-in.
• Two-factor authentication: TOTP app or email code. Enrolment issues 8 single-use recovery codes (stored as SHA-256). A device can be trusted for 30 days (device id stored hashed).
• Social sign-in: Google Sign-In and Facebook Login.
• Brute-force protection: rate limits per IP (100 attempts / 10 min) and per email (20 / 15 min), plus a hard 15-minute account lock after 8 consecutive failures — with an alert email to the account holder.
• Sessions: random server-side token only, 7-day lifetime (30 days for a workspace-switch session). Users can sign out all their other sessions with one click.
• API tokens (fvmcp_…): scoped, expire after 90 days by default (max 365), at most 25 active per workspace, stored as HMAC-SHA256 with an environment-held pepper — a database dump alone cannot mint a token. Only the workspace owner can create, revoke or rotate tokens, and an API token can never manage other tokens.
• MCP: OAuth 2.1 with PKCE and dynamic client registration.

3. Authorisation & tenant isolation

• Server-side tenant scoping (lib/tenantScope.js): a restricted user may only touch the ad accounts, pages, sites and Google Ads customer ids granted to them. When a resource cannot be matched to a grant, access is denied (fail-closed).
• Per-user grants: the workspace admin decides which accounts, sites and features (tabs) each user gets.
• Client logins: an end client receives a restricted user granted only their own site/account — and sees only their data.
• API and MCP go through the same application handlers with a real session minted for the token owner — there is no second, separate authorisation layer that could drift. The workspace is resolved from the token, never supplied by the client; ids from another workspace return 404.
• A cross-tenant access review was completed on 1 September 2026; all findings were fixed, and since then the deploy pipeline runs a tenant-isolation probe (with synthetic tenants) on every deploy — see section 6.
• Audit log: sign-ins, lead edits and admin actions are recorded per workspace (kept 180 days, last 2,000 entries); every API/MCP call is logged with who, which tool and the outcome (90 days). The log is visible to the workspace admin.

4. Data protection

• In transit: HTTPS/TLS on every hop — browser↔app, app↔Redis, app↔AWS and third-party providers.
• At rest: encryption at rest is provided and managed by the infrastructure providers (Upstash, AWS, Vercel). Passwords, recovery codes and API tokens are stored only as hashes.
• Secrets: API keys and secrets exist only as project environment variables and are never shipped to the browser. Cron endpoints require a dedicated secret compared in constant time.
• Backups: daily (03:10 UTC) export of configuration and content keys — users and workspaces, on-site campaigns, automations, attribution settings and client-account groupings — as a compressed file to S3 (eu-west-1). Event/analytics data is not included (reproducible from source).
• Retention of operational data: sessions 7 days · pending 2FA 10 minutes · audit log 180 days · API log 90 days · server error log 14 days · degraded-path telemetry 8 days · status counters 45 days. Lead and contact data is kept for as long as the workspace is active.
• Deletion: a workspace admin can delete a user (the user record and all their sessions are removed immediately). Requests to delete an entire workspace or a data subject's records are handled on written request (section 8). Shopify's mandatory customer/shop erasure webhooks (customers/redact, shop/redact) are implemented and HMAC-verified.
• Email: HMAC-signed unsubscribe links in every message, a preference centre, and suppression lists for both email and SMS.

5. Monitoring & incident response

• Active uptime monitoring every 10 minutes: the app, the API, the on-site campaign runtime, event ingestion and the store-plugin API. Each check gets one retry before counting as a failure.
• Alerting after 2 consecutive failures — to the on-call engineer via in-app alert and WhatsApp; a recovery notice when the check turns green again.
• Customer-site event-flow watchdog (hourly): a site that stops sending events, or an unexpected id change, is reported automatically.
• Server errors are captured to a central log; "silent" fallback paths count themselves and are summarised daily so a quiet breakage cannot stay hidden.
• Public status page: /status — current state and 30-day uptime history, with no internal details.
• Security incidents: on a suspected security incident affecting customer data, FORTVISION notifies affected customers without undue delay and no later than 72 hours after becoming aware, with the nature of the incident, the data concerned and the measures taken (see the DPA).

6. Secure development & deployment

• One deploy gate (scripts/deploy.sh) — no manual production deploys.
• Static lint (acorn-based) resolves every identifier in server and browser code and rejects undefined references, plus an inline-handler escaping check — a failure blocks the deploy.
• API canary: every Google Ads query in the committed code is validated against the live API before deploying.
• Verify-then-promote: the new build is first checked on an isolated, protected deployment URL — version stamp, smoke tests, a tenant-isolation probe (synthetic tenants) and a grant-path check (a user with a grant still receives their data) — and only then promoted to the production domains. A deploy lock prevents concurrent deploys.
• Recovery: a failed post-promote check promotes the previous deployment back.
• Inbound webhooks are verified with HMAC-SHA256 over the raw request body (Meta, Shopify, TikTok, WhatsApp relay); signature refusals are logged.
• Automated test suite for the API/MCP gateway (including tenant-isolation tests) runs on every change to that layer.

7. Sub-processors

Providers that process customer data on FORTVISION's behalf, as they appear in the platform code:

Connected platforms (customer-controlled)

The customer chooses to connect their own accounts; these platforms act as independent controllers under their own terms: Meta (Facebook, Instagram, Ads, Lead Ads, WhatsApp Business), Google Ads / Analytics / Business Profile, TikTok for Business, LinkedIn, Shopify, Wix and WooCommerce.

8. Responsible disclosure & contact