Security Questionnaire (CAIQ / SIG / VSA)

This page is GateLLM's pre-answered library for standard security questionnaires such as CAIQ (Consensus Assessments Initiative Questionnaire), SIG (Standardized Information Gathering), and VSA (Vendor Security Assessment).

A baseline response to a single security questionnaire typically takes 12-18 hours; this pre-answered library covers the high-frequency items on procurement checklists (VPC, SSO, audit, guardrails, SLA, compliance), allowing procurement teams to quote directly and compress response time from days to hours. For question-by-question answers tailored to your questionnaire or NDA-gated detailed attachments, contact security@gatellm.io.

The content of this library is sourced from and kept consistent with the /security, /dpa, /subprocessors, and /sla pages.

Q: Where is data stored and processed?

A: GateLLM is deployed in a fully self-hosted manner, running within your infrastructure (VPC / on-premises data center). The Processor (Fluxon LLC) does not host runtime instances, and does not receive, store, or relay your prompts or completions. Only account- and license-level personal data (contact information, license status) is held by the Processor, stored on Supabase (US US-East).

Q: Is customer data used to train models?

A: No. The Processor does not come into contact with customer prompt data. Whether a downstream model provider uses data to train its models depends on the provider you select and configure, and its public policy — see the data-use matrix on /subprocessors, which you can review before onboarding. It is entirely opt-in; GateLLM ships with no provider connections pre-configured.

Q: Data retention and deletion policy?

A: Runtime prompts / completions are not persisted in the Processor's systems (forwarded in memory, not persisted). Account and license data is deleted or returned upon service termination, with the Processor providing written confirmation within 30 days of deletion or return (DPA Section 14). The audit-log retention policy is determined by your operations team.

Q: How is personal data transferred cross-border?

A: Account data held by the Processor, if transferred cross-border, is transmitted via SCCs (European Commission Decision 2021/914) or the UK IDTA / safeguards recognized by the Swiss FDPIC. Cross-border transfers to downstream model providers are initiated directly by you; you must ensure appropriate safeguards with the provider (DPA Section 11).

Sub-processor Data-Use Matrix

Q: Is SSO supported?

A: Yes. OIDC (Azure AD / Okta / generic) and SAML 2.0 are supported. Both the GateLLM admin interface and data-plane API can integrate with SSO. Feishu and DingTalk are not yet provided.

Q: Is SCIM automated user provisioning supported?

A: Yes, SCIM 2.0 automated provisioning and deactivation are supported.

Q: Access control model?

A: Role-based access control (RBAC), following the least-privilege principle. All administrative operations and API calls are recorded in audit logs. BYOK keys live only in the gateway process memory, are never persisted, and cannot be read in plaintext by operations personnel.

Q: Password and credential management?

A: GateLLM does not maintain its own password system — authentication is delegated to your existing IdP via SSO (inheriting its MFA, password policies, and session management). BYOK model-provider keys are encrypted at rest in configuration, loaded into memory only, and never persisted in plaintext.

Q: Is MFA supported?

A: Inherited via SSO integration from your IdP's MFA policy. GateLLM itself does not maintain independent MFA factors, avoiding credential fragmentation.

Q: Is there a vulnerability disclosure policy?

A: Yes. See /vulnerability-disclosure. Reporting channel: security@gatellm.io (PGP supported). Response SLA: acknowledgement within 24 hours, initial assessment within 3 business days, remediation by CVSS severity (Critical 7 days, High 30 days, Medium 60 days, Low 90 days).

Q: Is penetration testing conducted?

A: Independent third-party penetration testing is in preparation (scope and rules of engagement are ready), covering the gateway process, authentication & authorization, Edge Functions, API gateway, and key-handling paths. A summary will be published in Section 7 of /vulnerability-disclosure once completed.

Q: Dependency and supply-chain security?

A: A Software Bill of Materials (SBOM) is provided. Dependencies are regularly scanned for known vulnerabilities (CVEs); security patches are released per the vulnerability disclosure policy timeline and annotated with CVE IDs in the changelog.

Q: Is there an SDLC (Secure Software Development Lifecycle)?

A: Code changes go through code review and CI gates (lint, tsc, unit tests, SEO guardrails). Security-related logic (license-key validation, webhook signature verification, rate limiting) is centralized in shared modules for auditability.

Vulnerability Disclosure Policy

Q: Incident response process?

A: Incidents are responded to by P1-P4 severity; see Section 5 of /sla. P1 (Critical) acknowledged within 15 minutes, mitigated within 4 hours; P2 (High) acknowledged within 1 hour, mitigated within 8 hours. A post-incident report (RCA) is produced within 5 business days of P1/P2 resolution.

Q: Data breach notification timeline?

A: The Processor notifies the Controller within 72 hours of becoming aware of a security breach involving the Controller's personal data (DPA Section 10). The notification includes the nature of the breach, impact scope, consequences, and mitigation measures.

Q: Incident notification channels?

A: P1/P2 incidents are notified via the email registered in your account; P1/P2 additionally trigger a phone call (if an emergency contact is registered). Initial notification is sent within 30 minutes; progress is updated every 2 hours for P1 and every 4 hours for P2.

Incident Response & Support (SLA)

Q: Complete sub-processor list?

A: See /subprocessors. It fully discloses GateLLM platform sub-processors (Supabase, Stripe, Resend, Sentry, Google) and the data-use matrix for 100+ downstream model providers — no shadow AI, no hidden sub-processors.

Q: Sub-processor change notification mechanism?

A: Additions/replacements of platform sub-processors are notified at least 30 days in advance (at least 90 days for sensitive data), with a 30-day objection window; change notifications can be subscribed via email. Downstream model providers are added/removed by you and are not subject to this process, but their data-use matrix is continuously maintained and updated (DPA Section 8.3).

Q: Do sub-processors sign a DPA?

A: Yes. All platform sub-processors are bound by written agreements providing the same level of data protection as this DPA.

Q: What is the legal status of downstream model providers?

A: Selected and directly engaged by you via BYOK. When you forward prompts containing personal data to a provider, the legal relationship between that provider and you (independent controller / joint controller / processor) is determined by the provider's terms and applicable law; you must separately assess and execute necessary agreements. The Processor does not assume liability for the data-processing practices of downstream providers (DPA Sections 8.2, 15).

Sub-processor List

Q: Deployment model?

A: Fully self-hosted. Docker (single machine) or Kubernetes Helm (multi-replica HA). Runs within your VPC / on-premises data center; prompt data does not leave your network boundary.

Q: Encryption?

A: TLS 1.3 in transit (external communication), mTLS (internal inter-service); AES-256 at rest (account database). BYOK keys are encrypted in configuration and loaded into memory only.

Q: Network isolation?

A: The gateway process is deployed within your private network; inbound/outbound traffic is controlled by the security groups / network policies you configure. Requests go directly from the gateway to the downstream model providers' official APIs, without passing through any relay server operated by the Processor.

Q: Logging & audit?

A: All administrative operations and API calls are recorded in audit logs; the retention policy is determined by your operations team. Logs can be exported to assist with data subject rights request responses (DPA Section 12).

Q: Compliance certifications?

A: GDPR / CCPA / UK GDPR / Swiss FADP ready (no general certification scheme exists for these regulations; compliance is evidenced through documentation); SOC 2 Type II and ISO 27001 controls are aligned, but certification audits are not yet complete — no report or certificate can be provided at this time. See the /security page for details.

Q: Incident response & support?

A: GateLLM is a fully self-hosted product and does not provide SaaS-style availability percentage commitments; the Processor is responsible for software defect remediation and security incident response, with incidents classified P1-P4 (P1 acknowledged in 15 minutes / mitigated in 4 hours). Gateway process high availability is determined by your deployment architecture (Helm multi-replica + cross-AZ + health checks can reach 99.95%+); see /sla.

Q: Disaster recovery & backup?

A: The gateway process is stateless — any replica can serve any request, supporting instant failover and horizontal scaling. Cross-provider fallback automatically switches when a downstream model provider is down. The license local-cache grace period (14 days) maintains business continuity during License Service fluctuations.

Security & Compliance

For question-by-question answers tailored to your security questionnaire, NDA-gated security architecture documentation, control inventories, and SBOM, or to schedule a security architecture review, contact: security@gatellm.io.

Security & Compliance · Data Processing Agreement (DPA) · Sub-processor List · Incident Response & Support · Vulnerability Disclosure Policy