Security at FORTVISION

1. Architecture & hosting

Data location

• The app, the API, the voice-call service and the primary database run in Frankfurt, Germany (AWS eu-central-1); no other region is configured for compute.
• Media files, backups and store-plugin data: AWS Ireland (eu-west-1).
• The SES sending region is set in the environment configuration — provided on request. AI and messaging providers (section 7) process the content sent to them in their own regions.

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.
• Passwordless sign-in: a single-use sign-in link plus a 6-digit code by email, valid 15 minutes, at most 5 attempts.
• Mobile app: uses the same server-side session; an optional biometric lock (Face ID / fingerprint) is enforced on the device.
• 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.
• Roles per workspace: every member holds Admin, Editor or Viewer inside each workspace (an agency user can be Viewer in one client and Editor in another). Viewers are read-only on the server, not only in the UI; the last Admin of a workspace cannot be removed.
• 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). Passwords, recovery codes and API tokens are stored only as hashes.
• Administrative access: FORTVISION's AWS account is protected by multi-factor authentication on the root account and on the administrator's console user. FORTVISION's own platform administrator signs in to the application with an authenticator app (TOTP).
• Secrets: API keys and secrets live in AWS Secrets Manager (encrypted with KMS), are read by the Lambda execution role only, and are never shipped to the browser. Cron endpoints are invoked by EventBridge Scheduler and require a dedicated secret compared in constant time.
• Backups: every night (03:10 UTC) each workspace's data — users and workspaces, leads and contacts, CRM records (companies, deals, tasks, notes), campaigns and their settings, landing pages, on-site campaigns, automations, consent and unsubscribe lists, connection settings — is exported as compressed files, one per workspace, to a non-public prefix of an S3 bucket (eu-west-1), encrypted at rest (SSE-S3, AES-256). Raw event / analytics streams and caches that are re-synced from the ad platforms are not included.
• Backup retention: daily copies are kept for 35 days; the copy of the 1st of every month is kept for 400 days (enforced by S3 lifecycle rules). The recovery point is therefore at most 24 hours. A backup that is more than 32 hours old, incomplete or readable without credentials raises an alert automatically.
• Restore testing: the restore tool is exercised automatically before every release (dump → wipe → restore, every key compared for type, value, order and expiry; a failure blocks the release). A full production backup was last restored into an isolated environment on 12 November 2026: all 53 bundles (51 workspaces, 33,273 keys) were restored with no failed command, and a sample compared against production matched. Restores can be scoped to one workspace or one data family, are dry-run by default and never overwrite an existing key unless explicitly told to.
• 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. A self-sign-up workspace that holds no data and has no sign-in for 30 days is scheduled for deletion and removed 7 days later.
• 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: a customer erasure runs immediately; a shop that uninstalls the app keeps its data for 30 days after the uninstall and is then erased automatically from every store we operate.
• 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 published as an immutable version and first checked on a separate staging alias that production traffic never reaches — 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 a browser check that opens the main screens in a headless browser (desktop and phone size) and refuses the build on any script error or unrendered screen — and only then promoted to production. A deploy lock prevents concurrent deploys.
• Recovery: a failed post-promote check promotes the previous deployment back. For the first minutes after every release, browser errors from real users are grouped by fingerprint and build; a new error seen by several users rolls the release back automatically.
• 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, Conversions API), Google (Ads, Analytics, Business Profile, Gmail, Calendar, Sheets, YouTube, Merchant Center, Search Console, Display & Video 360), Microsoft (Outlook), TikTok for Business, LinkedIn, Telegram, Reddit, Shopify, Wix and WooCommerce. Contact data the customer sends to an ad platform (hashed audience lists, conversion events) is sent on the customer's instruction to the customer's own account.

8. Responsible disclosure & contact