Vendor diligence FAQ
Use this page when you map a vendor security questionnaire, SIG-style review, or customer audit request to Fontana. Each answer is short and points to the canonical doc for depth. For the control matrix and Trust Service Criteria map, start with SOC 2 control summary.
How to use this page
Section titled “How to use this page”| If your questionnaire asks about… | Start here | Full control map |
|---|---|---|
| Access, SSO, MFA, RBAC | Identity and access | SOC 2 control summary |
| Encryption, secrets, keys | Encryption and secrets | Secrets and encryption |
| Multi-tenancy, isolation | Tenant isolation | Workspace isolation |
| Audit logs, SIEM, retention | Logging and audit | Immutable audit trail |
| Backups, DR, uptime | Backup and availability | Backup and restore |
| SDLC, vuln scan, releases | Change and supply chain | Supply chain |
| LLM, BYOK, AI data use | AI governance | BYOK, Zero Data Retention |
Questionnaires rarely match this outline exactly. Use the SOC 2 control summary matrix when you need a row-per-control mapping.
Certification and program status
Section titled “Certification and program status”Is Fontana SOC 2 certified?
Fontana is designed for SOC 2 diligence with mapped controls across identity, segregation, secrets, audit, supply chain, and availability. Formal certification posture and programme status are published on Security and governance. Contact Fontana for control narratives and evidence under NDA.
Does Fontana support ISO 27001 or GDPR review?
Security management controls and GDPR-aligned data-processing safeguards are part of the diligence programme described on Security and governance. This docs site focuses on technical controls you can verify on your deployment; legal terms (DPA, subprocessors) are provided under NDA.
Can our auditor test controls on our instance?
Yes. Your auditor may require operating effectiveness testing on your production-class deployment, not only design documentation. Environment scope, pinned releases, and evidence boundaries are documented in Deployment environments.
Deployment models and data residency
Section titled “Deployment models and data residency”Where does Fontana run?
Fontana runs on Kubernetes (k3d) on a host you control or Fontana operates: managed cloud, dedicated single-tenant host, customer VPC, or self-hosted production. Each workspace is a separate cluster with its own data stores. See Deployment and Deployment architecture.
Who holds customer data?
Customer workflow data, configuration, secrets, and audit evidence live inside your workspace cluster on encrypted persistent volumes. Fontana does not commingle workspace databases or Vault stores across tenants on a host. See Workspace isolation.
Which environments are in scope for SOC 2 evidence?
Production-class hosts where regulated customer data lives are in scope. Integration and local developer environments are out of scope for regulated workloads and formal evidence collection. See Deployment environments.
Identity and access
Section titled “Identity and access”Do you support SSO and MFA?
Each workspace runs self-hosted Zitadel with OIDC, enterprise SSO federation, and MFA (TOTP and WebAuthn). End-user sign-in flows through your configured identity provider where applicable. See Identity providers.
Can we provision and deprovision users automatically?
Yes. Inbound SCIM v2 through workspace Zitadel supports automated user lifecycle. Role assignment uses Zitadel project roles mapped to application permissions. See Identity providers and Roles and RBAC.
How is authorization enforced in the application?
Application RBAC in Convex uses a permission registry with team scoping. Admin actions require explicit permissions (for example platform:write for deployment backup). See Roles and RBAC.
How do backend services authenticate?
Dedicated OAuth clients for workflow-engine and observability-api use RFC 7662 token introspection. Service credentials resolve from Vault; they are not embedded in browser sessions. See Network and hardening.
How is operator access to production controlled?
Production hosts expose HTTP and HTTPS only; shell access uses AWS SSM Session Manager on Fontana-managed cloud (no standing SSH ingress). The Kubernetes API binds to localhost. Durable platform changes reconcile through the Fontana CLI and Terraform for host provisioning. Kubernetes operator roles (read-only, deploy, secret-admin) are versioned in git and applied at bootstrap, with drift checked against the committed manifests. Operator dashboards (Gatus, HyperDX, Convex) require authentication with credentials held in workspace Vault. See Network and hardening.
Encryption and secrets
Section titled “Encryption and secrets”How are secrets stored?
Connector credentials, MCP tokens, BYOK LLM keys, and service credentials live in per-workspace HashiCorp Vault (KV fontana). Admin saves secrets write-only: values are never echoed back to the browser. See Secrets and encryption.
Is data encrypted in transit?
TLS terminates at the public edge (host Caddy). In-cluster HTTP is bounded by documented transmission boundaries and NetworkPolicy compensating controls. See Network and hardening.
Is data encrypted at rest?
Workspace persistent volumes sit on encrypted host storage backing Postgres, Convex, workflow file store, Vault, and ImmuDB data. See Secrets and encryption.
Do you support customer-managed keys for AI?
Yes. BYOK stores LLM API keys in Vault at org, team, or person scope. Resolution is fail-closed: missing keys do not silently fall back to shared credentials. See BYOK.
How does secret rotation work?
Rotation replaces values in Vault without embedding secrets in workflow JSON or export files. BYOK, connectors, SCIM tokens, and service credentials follow Vault-backed rotation patterns documented in Secrets and encryption.
Tenant isolation and network security
Section titled “Tenant isolation and network security”How are tenants isolated?
Cluster-per-tenant: separate k3d cluster, Postgres, Convex, Vault, Zitadel, workflow storage, and NetworkPolicy per workspace. There is no shared database or secret store across workspaces. See Workspace isolation.
Is isolation physical or logical?
Default isolation is logical (separate clusters on a shared host kernel). For hard isolation, deploy a dedicated host with one workspace (or fewer tenants). The mechanism is the same; blast radius is smaller. See Workspace isolation.
What network controls apply inside the cluster?
NetworkPolicy default-deny in the workspace namespace, per-workload ServiceAccounts, Pod Security baseline, resource limits, and Vault Agent sidecars. See Network and hardening.
Are there shared platform services?
A platform cluster on each host runs stateless edge services (welcome gateway, shared OpenSandbox MCP, document parsing). It does not hold workspace databases or secrets. Documented cross-tenant exceptions include compensating controls in Workspace isolation.
Logging, audit, and monitoring
Section titled “Logging, audit, and monitoring”Do you maintain an immutable audit trail?
Yes. Security-relevant events append to ImmuDB per workspace (WORM: write once, read many). observability-api is the only writer. See Immutable audit trail.
What events are in the WORM ledger today?
| Source | Status |
|---|---|
| Zitadel identity (sign-in, MFA, SCIM lifecycle) | Automated |
| Kubernetes API audit (auth failures, secret access, destructive verbs) | Automated |
| Convex admin mutations (RBAC, BYOK, teams, deployment settings) | Ingest shipped; individual producers roll out by release |
| Workflow engine (privileged runs, sensitive connector access) | Target path via Convex audit_log |
Full producer map: Immutable audit trail and SOC 2 control summary (audit operating status).
Is HyperDX the compliance audit system of record?
No. HyperDX is the operational search plane (logs, dashboards, shorter TTL). It may mirror WORM events for incident search, but ImmuDB holds compliance evidence. See Operational telemetry and Data retention.
What is workflow lineage vs security audit?
Workflow lineage and port audit items on the workflow file store answer how a value was calculated. The immutable security audit trail answers who changed platform settings, signed in, or accessed the cluster. Do not substitute lineage for WORM evidence. See Data lineage and Compliance evidence.
How do you monitor availability?
In-cluster Gatus probes platform and tenant services; the status page sits behind HTTP basic auth. Operational telemetry flows to HyperDX via OTLP, with bundled alert rules on Kubernetes audit events that record WORM evidence per alert. See Operational telemetry.
Backup, recovery, and availability
Section titled “Backup, recovery, and availability”Do you take backups before upgrades?
Yes. An automatic full-stack snapshot runs before each workspace upgrade (data volume plus pinned release metadata). Operators can also create manual snapshots. See Backup and restore.
Can we roll back a failed upgrade?
Yes. fontana rollback restores the data volume and redeploys the pinned release from a chosen snapshot. See Fontana CLI.
Can we export workspace configuration without secrets?
Admin → Deployment → Backup/Restore exports roles, teams, workflows, agents, and non-secret configuration. Vault secrets and workflow run datasets are excluded by design. See Backup and restore.
How is Vault recovered?
Vault uses Raft storage on the workspace cluster as part of the snapshot boundary. Treat platform snapshots and your DR policy as the recovery path for secrets infrastructure. See Backup and restore.
Change management and supply chain
Section titled “Change management and supply chain”How are releases built and deployed?
CI builds immutable OCI images and a verified deploy bundle. Production hosts pull GHCR only with sha-<git> tags; bundle SHA256SUMS verifies integrity. Upgrades are manual pinned releases via the Fontana CLI. See Supply chain and Fontana CLI.
Do you scan container images for vulnerabilities?
Yes. Trivy runs in CI with a CRITICAL gate on platform images. See Supply chain.
Can production hosts build from source?
No on production-class hosts. Immutable artifacts only; no monorepo checkout required to run tenants. Integration hosts may differ and are out of SOC 2 scope. See Deployment environments.
How is infrastructure provisioned?
Host provisioning uses Terraform (infra-k8s/). Platform state is declared in fontana.yaml and reconciled by fontana apply. See Deployment architecture.
AI governance and data handling
Section titled “AI governance and data handling”Can we bring our own LLM keys and gateways?
Yes. BYOK and approved gateways/models in Admin enforce which providers and models your workspace may call. See BYOK and Gateways.
Does Fontana train on our data?
Fontana routes inference to your configured providers under BYOK. Zero Data Retention (ZDR) applies where the upstream gateway supports it. Provider-specific behaviour is documented in Zero Data Retention.
Are AI tool calls audited?
Tool invocations write structured records with protocol and latency metadata. Correlation with the WORM ledger depends on enabled audit producers. Human approval gates (askHuman, canvas suggestions, NL compile HITL) are documented in Human in the loop.
How is sandboxed agent code execution isolated?
Shared OpenSandbox runs in the platform cluster with per-tenant bearer auth and workload isolation via fontana-sandbox-proxy (fail-closed). See Tools and MCP and Workspace isolation.
Privacy, retention, and subprocessors
Section titled “Privacy, retention, and subprocessors”What are your data retention boundaries?
Three stores with separate retention: workflow file store (run data and lineage sidecars), HyperDX operational logs (search plane, shorter TTL), and ImmuDB WORM (compliance audit, append-only). See Data retention.
Can we control egress and exports?
Workflow egress nodes and export paths are part of your configured workflows. Platform configuration and legal terms for data processing are available under NDA. See Data egress and Security and governance.
Who are your subprocessors?
A current subprocessor list, DPA, and vendor register are provided in the diligence pack under NDA. Self-hosted deployments use your chosen LLM and connector providers under BYOK.
Incident response and evidence requests
Section titled “Incident response and evidence requests”What is your incident response process?
Escalation paths, customer communication, and IR runbooks are diligence topics covered in the NDA pack and Security and governance. Operational detection uses Gatus, HyperDX alerts, and WORM audit review.
Can you provide penetration test results?
Penetration test summaries and formal test reports are available under NDA on request via Security and governance.
Can you export control snapshots for our auditor?
Operators can run evidence collection on production-class hosts before audits. Architecture diagrams, RBAC exports, and extended snapshot fields are described in internal runbooks; contact Fontana for exported control snapshots and the full diligence pack.
Where do I request the full diligence pack?
Use Security and governance or contact Fontana for architecture diagrams, subprocessors, DPA terms, certification programme status, and evidence exports under NDA.
Related documentation
Section titled “Related documentation”- SOC 2 control summary - control matrix and Trust Service Criteria map
- Security overview - topics index and three evidence planes
- Compliance evidence - immutable audit trail and workflow lineage
- Deployment - cloud, self-hosted, backup, and CLI