# CAIQ-Lite — VAIF Studio **Version:** 0.3 (self-attestation) **Based on:** Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CAIQ) v4.0 **Last updated:** 2026-08-10 **Prepared by:** VAIF STUDIO LLC **Contact:** security@vaif.studio > **Important:** This document is a self-attestation prepared by VAIF Studio against the public CAIQ-Lite v4.0 framework. It has not yet been validated by an independent third-party assessor. A SOC 2 Type 1 audit is planned. No audit firm has been engaged, the audit has not started, and no report date is committed. SOC 2 Type 2 is planned, with no date: a Type 2 observation window can only begin after a Type 1 report exists, and the Type 1 audit is itself only planned. Where a control is not yet in place, it is honestly marked **"Not yet implemented"** or **"Planned"**. --- ## A&A — Audit & Assurance **A&A-01. Are audits performed independently and with a documented methodology?** No. A SOC 2 Type 1 audit is planned. No audit firm has been engaged, the audit has not started, and no report date is committed. Internal control mapping against the AICPA Trust Service Criteria is maintained continuously, which is preparation and not assurance. **A&A-02. Are external audit reports made available to customers under NDA?** No. A SOC 2 Type 1 audit is planned. No audit firm has been engaged, the audit has not started, and no report date is committed. There is therefore no report to share. If one is ever issued it will be offered to Enterprise customers and prospects under NDA on request. **A&A-03. Is a third-party penetration test performed at least annually?** Planned. First third-party penetration test scheduled for Q3 2026. Continuous automated vulnerability scanning is in place today. --- ## CCC — Change Control & Configuration Management **CCC-01. Is there a formal change-management policy for production systems?** Yes. All production changes flow through pull requests with required code review, automated CI tests, and infrastructure-as-code review (Terraform). **CCC-02. Are changes deployed via automated, repeatable pipelines?** Yes. Deploys go through Google Cloud Build with versioned container images and signed deploy artifacts. Migrations run before API deploys (ordering enforced). **CCC-03. Is there separation between development, staging, and production environments?** Yes. Separate GCP projects, separate databases, separate secret stores. --- ## CEK — Cryptography, Encryption & Key Management **CEK-01. Is data encrypted in transit?** Partially — corrected in revision 0.4. All public endpoints are HTTPS-only, terminated by Cloudflare and Google Cloud Run. Those terminators negotiate TLS 1.2 **or** 1.3 with the client: 1.3 is supported, and it is not *enforced*, because no minimum-version SSL policy is configured anywhere in this account. HSTS is sent by the API (`apps/api/src/server.ts`), by the billing console (`apps/billing/nginx.conf`) and, since revision 0.5, by vaif.studio itself (`apps/marketing/nginx.conf`, via `apps/marketing/security-headers.conf`), which also now sends a Content-Security-Policy, Permissions-Policy and the two Cross-Origin-* policies. It is **not** sent by the application console (`apps/web/nginx.conf`), which sends `X-Frame-Options`, `X-Content-Type-Options` and `Referrer-Policy` and no transport-security or content policy. Internal service-to-service traffic runs on private VPC networking with TLS. **CEK-02. Is data encrypted at rest?** Yes. AES-256 at rest via GCP-managed encryption (Cloud SQL, Cloud Storage, Persistent Disks). All encryption keys are platform-managed today: customer-managed encryption keys (CMEK) are **planned** (target Q4 2026, published at https://vaif.studio/roadmap) and are not available on any tier, including Enterprise. **CEK-03. Are keys managed in a dedicated key-management service?** Yes. Google Cloud KMS. Application-level secrets are stored in Google Secret Manager. **CEK-04. Are TLS certificates rotated automatically?** Yes, via Google-managed certificates and Cloudflare edge. --- ## DSP — Data Security & Privacy **DSP-01. Is customer data segregated between tenants?** Yes. Logical multi-tenancy with row-level access enforced at the application layer; tenant isolation tested as part of CI. Dedicated database instances available on the Enterprise tier. **DSP-02. Is customer data ever used to train AI models?** No. Customer data is never used to train VAIF Studio's models or its sub-processors' foundation models. Anthropic and OpenAI inference is configured with zero-retention / no-training enterprise terms. **DSP-03. Are data-deletion requests honored?** Yes, by request — and **not** self-service, corrected in revision 0.4. There is no customer-facing account-deletion route; the only delete endpoints for a user or an organization are administrative (`apps/api/src/routes/admin/users.ts`, `admin/organizations.ts`). A verified request is actioned by VAIF Studio staff and takes effect in two stages: the directly-identifying fields are anonymised immediately (email, name, avatar, phone, credential hash) and every session is revoked, then a scheduled worker purges the record 30 days later (`apps/worker/src/workers/userPurge.worker.ts`, `PURGE_AFTER_DAYS = 30`). Requests under GDPR Art. 17 and CCPA are honoured on that cycle. One disclosure: the original email address is retained in the immutable admin audit entry recording the deletion. **DSP-04. Is there a data-classification policy?** Yes — three tiers (public, internal, customer-confidential). Customer data is classified confidential by default. **DSP-05. Is personal data only retained as long as necessary?** Yes, with one figure corrected in revision 0.4. Default retention is the lifetime of the account and application logs roll off at 90 days. Database backups are **not** retained for 30 days: the configuration keeps the **7 most recent daily snapshots**, plus 7 days of transaction logs for point-in-time recovery (`apps/api/src/lib/gcp-cloudsql.ts`, `backupConfiguration`). Customer-visible audit-log retention is set per plan rather than globally — none on Free, 30 days on Starter and Pro, 90 days on Agency, 1 year on Studio+, custom for Enterprise. Customers may request earlier deletion. --- ## GRC — Governance, Risk & Compliance **GRC-01. Is there a documented information security policy?** Yes. Reviewed annually and on material change. **GRC-02. Is there a designated security owner?** Yes — security@vaif.studio routes to the named security lead. **GRC-03. Are risk assessments performed?** Yes — annual risk assessment plus event-driven assessments on material architectural change. **GRC-04. Is there a vendor / sub-processor management process?** Yes. All sub-processors are vetted, bound by written DPAs, and listed publicly at https://vaif.studio/sub-processors. 30-day customer notice on additions. --- ## HRS — Human Resources Security **HRS-01. Are background checks performed on personnel with access to customer data?** Yes, where legally permissible. **HRS-02. Do all personnel sign confidentiality / NDA agreements?** Yes, as part of onboarding. **HRS-03. Is security-awareness training mandatory and tracked?** Yes — required at hire and annually thereafter. **HRS-04. Is access revoked immediately upon termination?** Yes — same-day deprovisioning via centralized identity (Google Workspace + GCP IAM). --- ## IAM — Identity & Access Management **IAM-01. Is multi-factor authentication required for staff accessing production?** Yes — MFA enforced on Google Workspace, GCP, GitHub, and any console with production access. Hardware security keys required for break-glass admin roles. **IAM-02. Is the principle of least privilege enforced?** Yes. Production access is role-based, time-bound, and audit-logged. Default access is read-only. **IAM-03. Is access to production reviewed periodically?** Yes — quarterly access review. **IAM-04. Is SSO / SAML available to customers?** Not yet — **planned**. SAML / OIDC single sign-on and SCIM provisioning are on the roadmap and are **not available on any tier today**; no tier entitles a customer to it. Teams sign in to the VAIF Studio console with email + password or a social provider (Google / GitHub). Revision 0.1 of this document answered this control affirmatively for the Agency, Studio+, and Enterprise tiers; that answer was wrong and is superseded — see the revision history at the end of this document. **IAM-05. Is MFA available to customers?** Partially. TOTP authenticator MFA with single-use backup codes is available on all tiers for end users of applications built on the platform (`project_user_mfa`). MFA on the VAIF Studio console account itself, and WebAuthn / hardware security keys anywhere, are **planned** and are not available yet. --- ## IPY — Interoperability & Portability **IPY-01. Can customers export their data in a standard format?** Yes — self-service export of project data (JSON / SQL) is available from the dashboard. ZIP, Docker, GCP Terraform, AWS Terraform, and GitHub-push exports are also supported. --- ## IVS — Infrastructure & Virtualization Security **IVS-01. Is production infrastructure isolated in private networks?** Yes. Application services run inside a private VPC; no direct public ingress to databases or worker tiers. **IVS-02. Is a Web Application Firewall (WAF) deployed?** Partially — corrected in revision 0.4. Public traffic is proxied through Cloudflare, which applies its managed ruleset and DDoS mitigation at the plan we hold. **GCP Cloud Armor is not deployed.** No security policy exists in this account, and Cloud Armor appears in `docs/infrastructure-roadmap.md` as a Phase 3 line item costed at +$50/mo, not as current state. Earlier revisions of this document named it as deployed. **IVS-03. Is DDoS protection in place?** Partially. Cloudflare's network-layer DDoS protection covers all proxied traffic. GCP Cloud Armor is not deployed — see IVS-02. **IVS-04. Are containers scanned for vulnerabilities?** Yes — automated image scanning in Artifact Registry plus dependency scanning in CI. --- ## LOG — Logging & Monitoring **LOG-01. Are security-relevant events logged?** Yes — authentication, admin actions, data exports, and infrastructure changes are logged with immutable audit trails. **LOG-02. Are logs retained for a defined period?** Yes, with the split made explicit in revision 0.4. Platform security logs are retained 90 days. The customer-visible audit log is retained per plan — none on Free, 30 days on Starter and Pro, 90 days on Agency, 1 year on Studio+, custom for Enterprise — so "90-day default" describes Agency and the platform logs, not every account. **LOG-03. Is there real-time alerting on suspicious activity?** Yes — automated alerting on auth anomalies, error spikes, and infra changes. --- ## SEF — Security Incident Management, E-Discovery & Cloud Forensics **SEF-01. Is there a documented incident-response plan?** Yes. Includes severity classification, on-call rotation, customer-notification SLAs, and post-incident review. **SEF-02. Is there a public security-vulnerability disclosure program?** Yes — security@vaif.studio. Public bug-bounty program planned for Q4 2026. **SEF-03. What is the customer notification SLA for a confirmed breach involving their data?** 72 hours, consistent with GDPR Art. 33 and our DPA. --- ## STA — Supply Chain Management, Transparency & Accountability **STA-01. Is a current sub-processor list published?** Yes — https://vaif.studio/sub-processors **STA-02. Are sub-processor changes communicated in advance?** Yes — 30-day notice for sub-processors handling personal data; customers may object. **STA-03. Are sub-processors bound by DPAs with terms equivalent to those offered to customers?** Yes. --- ## TVM — Threat & Vulnerability Management **TVM-01. Is automated vulnerability scanning in place?** Yes — continuous dependency scanning, container scanning, and SAST in CI. **TVM-02. Is there a defined SLA for patching critical vulnerabilities?** Yes — critical (CVSS 9.0+): 7 days. High: 30 days. Medium: 90 days. **TVM-03. Is there a coordinated-disclosure / responsible-disclosure policy?** Yes — published at https://vaif.studio/security. --- ## BCR — Business Continuity & Operational Resilience **BCR-01. Are backups performed regularly and tested?** Partially — corrected in revision 0.4. Dedicated PostgreSQL instances have point-in-time recovery enabled with a 7-day transaction-log window, and a daily backup at 04:00 UTC of which the 7 most recent are retained. Plans on shared PostgreSQL have **no** point-in-time recovery. **Restore drills are not performed on a schedule.** No drill has been recorded, and the disaster-recovery procedure is still unwritten — `docs/contributing/soc2-audit-readiness.md` lists it as not yet committed. Earlier revisions of this document claimed annual drills. **BCR-02. Is there a documented business continuity / disaster recovery plan?** No — corrected in revision 0.4. An RTO of 4 hours and an RPO of 15 minutes are stated **targets**, not a documented or tested plan: `docs/contributing/soc2-audit-readiness.md` lists the disaster-recovery document as not yet committed. Treat both figures as intent rather than as a commitment, and see BCR-01 for what is actually configured. **BCR-03. Is the service deployed in multiple availability zones?** Partially — corrected in revision 0.4. Cloud Run services are regional, and Google schedules them across zones within us-central1. The **PostgreSQL instances are zonal**: `enableHA` is not set in `apps/api/src/lib/autoProvision.ts`, so every plan-included Cloud SQL instance is single-zone and a zone failure takes the database with it. Database high availability and multi-region active-active are both on the Enterprise roadmap. --- ## DCS — Datacenter Security **DCS-01. Where is customer data hosted?** Google Cloud Platform — us-central1 (Iowa, USA). Underlying datacenter physical security is inherited from GCP (SOC 2, ISO 27001, ISO 27017, ISO 27018, PCI DSS, FedRAMP High — see Google's compliance reports). **DCS-02. Can customers select a different region?** Regional residency for EU and other regions is on the Enterprise roadmap. --- ## UEM — Universal Endpoint Management **UEM-01. Are employee endpoints managed and encrypted?** Yes — full-disk encryption, endpoint protection, and centralized management on all staff laptops. --- ## Document control | Field | Value | |---|---| | Document owner | security@vaif.studio | | Version | 0.3 (self-attestation) | | Next review | 2026-10-31 (or on material change) | | Validated by external auditor | No — SOC 2 Type 1 (planned — no audit engaged) | **Revision history** | Version | Date | Change | |---|---|---| | 0.5 | 2026-09-18 | **Security headers fixed, and CEK-01 updated to match.** Correcting CEK-01 for revision 0.4 surfaced a delivery bug behind it: nginx inherits `add_header` directives into a block only if that block declares none of its own, and every asset location on both the website and the console sets its own `Cache-Control`. The measured result, against the real configurations running in nginx: every JS, CSS, image and font on vaif.studio was served with **no security headers at all**, and on the console `location /` — the SPA fallback that serves every page in the product — did the same, so an authenticated console with session cookies reached the browser with no `X-Frame-Options` on any route. Both now `include` a single snippet from every block that declares a header. vaif.studio additionally sends the full declared policy it had only ever written down in `public/_headers`: CSP, HSTS (without `preload` — that is a submission to a browser-vendor list and belongs to the domain owner), Permissions-Policy and COOP/CORP. The console received only the headers it already intended to send; it has no CSP, because a policy for a hydrated SPA needs its own analysis and a guessed one breaks the product silently. `X-XSS-Protection` was dropped from both, matching the API's 2026-04-29 removal of its own copy. | | 0.4 | 2026-09-18 | **Nine infrastructure answers corrected against the configuration they describe.** Every claim in this document that named a control was re-checked against the file that configures it, and nine were wrong. **CEK-01** — HSTS was claimed for all public endpoints; it is sent by the API and the billing console and by neither vaif.studio nor the application console, and TLS 1.3 is supported rather than enforced because no minimum-version policy is configured. **DSP-03** — "self-service account deletion" does not exist; there is no customer-facing delete route, and deletion is an administrative action followed by a 30-day purge worker. **DSP-05** — backups were said to roll off at 30 days; the configuration retains the 7 most recent daily snapshots and 7 days of transaction logs. **IVS-02 / IVS-03** — GCP Cloud Armor was named as deployed; it is a Phase 3 roadmap line item and no policy exists. **LOG-02** — a flat 90-day retention was claimed for a period that is set per plan. **BCR-01** — annual restore drills were claimed; none has been performed and the DR procedure is unwritten. **BCR-02** — a documented BC/DR plan was claimed; the document is listed as not yet committed. **BCR-03** — "multi-zone" covered the compute tier only; the database is zonal. Anyone holding revision 0.1, 0.2 or 0.3 should treat all nine as superseded. | | 0.3 | 2026-08-10 | **A&A-01, A&A-02 and the external-validation row corrected, and the preamble with them.** Revision 0.2 said a SOC 2 Type 1 audit was "currently underway with an independent CPA firm (target report Q3 2026)". No audit firm has been engaged and the audit has not started; the answer is now "planned", with no date, because a target window reads as a scheduled engagement. The SOC 2 Type 2 answer is corrected with it: it was phrased as the next step after a Type 1 report that is not coming. Anyone holding revision 0.1 or 0.2 should treat those answers as superseded. These sentences are now GENERATED into marked regions from `apps/api/src/lib/compliancePosture.json`, so this document cannot go stale against the record again — see `scripts/generate-posture.mjs`. | | 0.2 | 2026-08-06 | Three answers corrected from "Yes" to "planned", because the controls are not implemented. **IAM-04** — single sign-on is on the roadmap: there is no identity-provider integration, no SSO sign-in route and no SCIM endpoint on any tier. **IAM-05** — WebAuthn / hardware keys are planned and not implemented anywhere today, and the TOTP MFA that does exist covers end users of customer applications, not the VAIF Studio console account. **CEK-02** — customer-managed encryption keys are roadmap (target Q4 2026); all keys are platform-managed. Anyone holding revision 0.1 should treat those three answers as superseded. | | 0.1 | 2026-04-30 | Initial self-attestation. | No audited control attestation exists today. A SOC 2 Type 1 audit is planned. No audit firm has been engaged, the audit has not started, and no report date is committed. Contact security@vaif.studio for a vendor-review session against this self-attestation.