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

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

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

Where does Fontana run?

Fontana runs on Kubernetes 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 namespace on encrypted persistent volumes. Fontana does not commingle workspace databases or Vault stores across workspaces. 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

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 the 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, Grafana, Convex) require authentication with credentials held in workspace Vault. See Network and hardening.

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 cluster ingress, with certificates issued and renewed automatically by cert-manager from Let’s Encrypt. Traffic between workspace services 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, FalkorDB, 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

How are tenants isolated?

Namespace per workspace: separate databases, graph store, Vault, identity, workflow storage, RBAC, resource quotas, and default-deny NetworkPolicy for each one. There is no shared database or secret store across workspaces, and a workspace can be given its own node pool or its own cluster when a contract requires it. See Workspace isolation.

Is isolation physical or logical?

Default isolation is logical: separate namespaces sharing one cluster control layer and its nodes. For stronger separation, give the workspace a dedicated node pool (no shared kernel) or a dedicated cluster (no shared control layer). Both are values in the deployment config; the product is the same. 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 namespace runs stateless shared services (sandboxed code execution, document parsing, health probes), and each one can instead be consumed from a shared origin or turned off in your configuration. It does not hold workspace databases or secrets. Documented cross-tenant exceptions include compensating controls in Workspace isolation.

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). The 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 Grafana the compliance audit system of record?

No. Grafana and Loki are the operational search plane (logs, dashboards, shorter TTL). They 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?

Gatus probes platform and tenant services; the status page sits behind HTTP basic auth. Operational telemetry flows to platform Grafana/Loki via OTLP, with detection rules on Kubernetes audit events that record WORM evidence per alert. See Operational telemetry.

Backup, recovery, and availability

Do upgrades require downtime?

No. Upgrades roll: a replacement pod must pass its readiness check before the previous one is retired, so the workspace keeps answering throughout. Workloads whose image and configuration did not change are not restarted at all. See Fontana CLI.

How are backups taken?

On a running workspace. Scheduled exports of the workspace file store and backend data go to object storage you control, alongside cluster volume snapshots. A backup window is not a maintenance window. See Backup and restore.

Can we roll back a failed upgrade?

Yes, two ways. A release that never becomes healthy rolls back on its own while the previous version keeps serving. A release that is healthy but wrong is undone by pinning the previous tag and running fontana apply; releases are digest-addressed, so you get exactly the artifact that ran before. See Backup and restore.

Can we export workspace configuration without secrets?

Admin → Deployment → Export/Import exports roles, teams, workflows, schedules, agents, Knowledge Graph files and settings, and other non-secret configuration. Vault secrets and workflow run datasets stay out of the file. See Backup and restore.

How is Vault recovered?

Vault uses Raft storage on its own persistent volume in the workspace namespace. Volume snapshots and your secret-management DR policy are the recovery path for secrets infrastructure. See Backup and restore.

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 and the Fontana CLI. Platform state is declared in fontana.yaml and reconciled by fontana apply. See Deployment architecture.

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 namespace with per-workspace bearer auth and fail-closed ownership enforcement at its proxy. See Tools and MCP and Workspace isolation.

Privacy, retention, and subprocessors

What are your data retention boundaries?

Three stores with separate retention: workflow file store (run data and lineage sidecars), Grafana/Loki 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

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, Grafana alerting, 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.

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