Last reviewed: May 27, 2026 Questionnaire version: CAIQ-Lite v4.1.0 (138 questions across 17 domains)
Answer scoreboard: Yes: 46 · Partial: 48 · No: 26 · NA: 15 · CSC: 3
Answer key: Yes · No · Partial (control exists in practice but not as a formal written policy) · NA (not applicable to our scale or operating model) · CSC (customer security responsibility under the shared-responsibility model).
Principle: a "yes" that turns out false under probing is worse than a transparent "no." Every "Yes" cites the actual control — file path, vendor attestation, or documented commit.
Security testing: OWASP ZAP authenticated DAST scans run periodically against the application (OWASP Top 10 scope); most recent September 2026 — no injection-class findings. See TVM-03.1.
Yovico.ai is a multi-agent AI SaaS delivered on Kubernetes. Two-person founding team, bootstrapped Delaware C-Corp. Customer data: meeting transcripts, uploaded documents, OAuth tokens for Drive/OneDrive connectors. We host on managed cloud infrastructure (inheriting the provider's SOC 2 / ISO 27001 attestation for physical and network-edge controls). All application-tier secrets are encrypted at rest under per-tenant data-encryption keys (AES-256-GCM, envelope encryption). No on-premise deployment today; no employees.
Are independent audit and assurance assessments conducted according to relevant standards at least annually?
No. Two-person bootstrapped team, pre-customer. We don't run external audits today. When a customer requires SOC 2 Type 1 and is willing to help fund the ~$8–15k engagement, we'll do it; until then the cost vs. deal-value math doesn't work. Compensating controls: this CAIQ-Lite self-attestation + a published security posture page + periodic OWASP ZAP DAST scans (see TVM-03.1).
CCM control: A&A-02 (Independent Assessments)
Are independent audit and assurance assessments performed according to risk-based plans and policies, and in response to significant changes or emerging risks?
No. No formal risk-based audit plan. Closest equivalent: code review on every PR, dependency scanning via GitHub Dependabot, the engineering rule that no plaintext secrets land in the DB (our engineering rule against plaintext-secret storage).
CCM control: A&A-03 (Risk Based Planning Assessment)
Is compliance verified regarding all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit?
Partial. We track relevant frameworks (CCPA, GDPR-ish data subject rights) but don't run a formal compliance verification cycle. /privacy, /dpa, and /subprocessors document our position; DPA available on request.
CCM control: A&A-04 (Requirements Compliance)
Is a risk-based corrective action plan to remediate audit findings established, documented, approved, communicated, applied, evaluated, and maintained?
No. No formal remediation plan process — security-relevant issues live in GitHub Issues and PRs. Founder triage, no SLA. Honest constraint of the team size.
CCM control: A&A-06 (Remediation)
Is the remediation status of audit findings regularly reviewed and reported to relevant stakeholders?
No. Same as A&A-06.1 — no formal remediation review cadence.
Are baseline requirements to secure applications established, documented, and maintained?
Partial. Baseline practices implemented (TypeScript strict mode, Go static analysis, no plaintext secrets, OWASP top-10 mindset) — see internal engineering guidelines and our engineering rule against plaintext-secret storage — but we don't publish a single formal application-security baseline document.
CCM control: AIS-02 (Application Security Baseline Requirements)
Is a secure SDLC process defined and implemented for application requirements analysis, planning, design, development, testing, deployment, and operation per organizationally designed security requirements?
Yes. Every change goes through a branch + PR (our PR workflow rule). PRs require build + tests green. Branch protection on main blocks direct pushes (pre-push hook + GitHub branch-protection rule).
CCM control: AIS-04 (Secure Application Development Lifecycle)
Are strategies and capabilities established and implemented to deploy application code in a secure, standardized, and compliant manner?
Yes. Deployment via Kubernetes manifests + scripts/up.sh (Kubernetes migration). Immutable container images tagged by commit; no manual production edits.
CCM control: AIS-06 (Secure Application Deployment)
Is the deployment and integration of application code automated where possible?
Yes. Engine + frontend build via Docker on docker compose up / ./scripts/up.sh; K8s migration (Kubernetes migration) added one-command redeploy. No manual SSH-and-edit path.
Are application security vulnerabilities remediated following defined processes?
Yes. GitHub Dependabot enabled; advisories surface as PRs. Application-level vulns get a GitHub issue + fix PR. Periodic OWASP ZAP DAST scans (see TVM-03.1) surface application-level findings; all findings are triaged and tracked in GitHub Issues.
CCM control: AIS-07 (Application Vulnerability Remediation)
Is the remediation of application security vulnerabilities automated when possible?
Partial. Dependabot auto-suggests upgrade PRs; we review and merge. No SLA, but median time-to-fix on security-relevant issues has been days, not weeks (encryption rollout: audit-to-fix under three weeks).
Are processes, procedures, and technical measures defined and implemented to secure APIs?
Yes. Engine API requires authenticated sessions for all customer endpoints; CORS-restricted; rate limiting at the K8s ingress. Internal WS protocol documented in REQUIREMENTS.md and the Agda spec at spec/Yovico/.
CCM control: AIS-08 (API Security)
Are reviews and updates for any improvements conducted at least annually, or upon significant changes?
Partial. Review happens on every PR that touches the API surface, not on a fixed annual cadence. The Agda spec acts as a forcing function — protocol changes go through /spec-reconcile.
Are business continuity management and operational resilience policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?
No. No formal BCM policy. Two-person team; an extended outage in our cloud provider would take Yovico offline. Honest constraint.
CCM control: BCR-01 (Business Continuity Management Policy and Procedures)
Are the policies and procedures reviewed and updated at least annually, or upon significant changes?
No. No formal review cadence — there's no formal policy to review.
Are criteria for developing business continuity and operational resiliency strategies and capabilities established based on business disruption and risk impacts?
No. No formal risk-assessment-and-impact-analysis criteria.
CCM control: BCR-02 (Risk Assessment and Impact Analysis)
Are the risk assessment and impact analysis reviewed and updated at least annually or upon significant changes?
No. Same as BCR-02.1.
Are strategies being established to reduce the impact of business disruptions, and are resiliency and recovery from business disruptions being improved?
No. No formal continuity strategies. Recovery would be: redeploy from git + rehydrate Postgres from whatever backup exists. Targeting RTO < 4h once the backup gap is closed.
CCM control: BCR-03 (Business Continuity Strategy)
Are backups performed periodically?
No. Postgres backups are NOT yet automated to off-host storage — operational gap on the roadmap.
CCM control: BCR-08 (Backup)
Is the confidentiality, integrity, and availability of the backup ensured?
No. Same as BCR-08.1 — no backups means no confidentiality/integrity guarantees for them.
Can backups be restored appropriately for resiliency?
No. Same as BCR-08.1.
Is a disaster response plan established, documented, approved, applied, evaluated, and maintained to ensure recovery from natural and man-made disasters?
No. No DR plan today.
CCM control: BCR-09 (Disaster Response Plan)
Is the disaster response plan updated at least annually, and when significant changes occur?
No. Same as BCR-09.1.
Are policies and procedures for managing the risks associated with applying changes to assets owned, controlled, or used by the organization established, documented, approved, communicated, applied, evaluated, and maintained?
Yes. All changes go through git + PR + automated tests. Branch protection on main (pre-push hook + GitHub rule). One PR at a time (our PR workflow rule).
CCM control: CCC-01 (Change Management Policy and Procedures)
Are the policies and procedures reviewed and updated at least annually, or upon significant changes?
Partial. No formal annual review of change-management procedures, but the workflow has evolved through documented decisions in internal engineering guidelines and feedback memories.
Is a defined quality change control, approval and testing process, incorporating baselines, testing, and release standards, established, maintained and implemented?
Yes. PRs require build + tests green before merge. CI runs go test ./..., npx tsc --noEmit, npx vitest run, and (where applicable) Agda type-checking. Founders review each other's work.
CCM control: CCC-02 (Quality Testing)
Is a procedure to authorize the addition, removal, update, and management of assets owned, controlled, or used by the organization, implemented and enforced?
Yes. Same workflow for security-impacting changes. A recent example (the May 2026 encryption rollout) followed the standard PR flow with founder review.
CCM control: CCC-04 (Unauthorized Change Protection)
Are provisions to limit changes directly impacting service customer-owned environments (tenants) to explicitly authorized requests included within service level agreements?
CSC. Customer-owned environments don't exist today — Yovico is multi-tenant SaaS only. NA today; CSC if/when we offer self-hosted.
CCM control: CCC-05 (Change Agreements)
Are change management and configuration baselines established, documented and implemented for all relevant authorized changes on organizational assets?
Partial. Baselines exist in code (Dockerfiles, K8s manifests, env defaults) but not as a separate baseline document.
CCM control: CCC-06 (Change Management Baseline)
Are the baselines reviewed and updated at least annually or upon significant changes?
Partial. Baselines update with the code; no separate review cycle.
Are detection measures implemented with proactive notification if changes deviate from established baselines?
Partial. Config is in services/engine-go/config/config.go (env-var-driven), docker-compose.yml, and K8s manifests — all in git. No automated drift detection beyond kubectl diff on deploy.
CCM control: CCC-07 (Detection of Baseline Deviation)
Is a process to proactively roll back changes to a previously known "good state" defined and implemented in case of errors or security concerns?
Yes. Rollback is git revert + redeploy. K8s deploys are by image tag; reverting a tag = rolling back the change.
CCM control: CCC-09 (Change Restoration)
Are cryptography, encryption, and key management policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Implementation is documented in code + our engineering rule against plaintext-secret storage. No separate written cryptography policy document.
CCM control: CEK-01 (Encryption and Key Management Policy and Procedures)
Are cryptography, encryption, and key management policies and procedures reviewed and updated at least annually, upon significant changes?
Partial. Reviewed informally as decisions are made (envelope encryption rollout, triggered the major review for May 2026).
Are cryptography, encryption, and key management roles and responsibilities defined and implemented?
Partial. Roles informal — both founders touch crypto code; both founders own the master KEK. Documented in our internal engineering guidelines.
CCM control: CEK-02 (CEK Roles and Responsibilities)
Are data protection at-rest and in-transit, and where applicable in use, provided using cryptographic libraries certified to approved standards?
Yes. AES-256-GCM for application data at rest (envelope encryption rollout, May 2026). TLS 1.2+ in transit (HTTPS public surface, STARTTLS on SMTP, TLS on Postgres in production). Bcrypt for password hashes; SHA-256 for bearer-token hashes (refresh, reset, invitation).
CCM control: CEK-03 (Data Protection)
Are encryption algorithms following industry standards utilized for protecting data, based on the data classification and associated risks?
Yes. AES-256-GCM (NIST SP 800-38D), SHA-256 (FIPS 180-4), bcrypt for passwords. All Go stdlib crypto/* and golang.org/x/crypto/bcrypt.
CCM control: CEK-04 (Encryption Algorithm)
Are standard change management procedures established to review, approve, implement and communicate cryptography, encryption, and key management technology changes that accommodate internal and external sources?
Yes. Crypto changes go through the same PR workflow as all other changes. The May 2026 encryption rollout is the canonical example — design proposal → architect plan → PR → review.
CCM control: CEK-05 (Encryption Change Management)
Are cryptographic keys generated using industry-accepted and approved cryptographic libraries that specify algorithm strength and random number generator specifications?
Yes. Keys generated via crypto/rand (Go stdlib, sources from /dev/urandom). KEK = 32 bytes; DEKs = 32 bytes; nonces = 12 bytes (GCM standard). crypto_envelope.go.
CCM control: CEK-10 (Key Generation)
Are cryptographic keys rotated based on a cryptoperiod calculated while considering information disclosure risks and legal and regulatory requirements?
No. Rotation tooling not shipped. The version column in tenant_encryption_keys and kek_version column exist for when it lands; no production rotation cycle today.
CCM control: CEK-12 (Key Rotation)
Are cryptographic keys revoked and removed before the end of the established cryptoperiod (when a key is compromised, or an entity is no longer part of the organization) per defined, implemented, and evaluated processes, procedures, and technical measures to include legal and regulatory requirement provisions?
Partial. DEK revocation = PurgeTenant (drops the row → ciphertext is cryptographically erased). KEK revocation requires re-wrapping all DEKs — not implemented.
CCM control: CEK-13 (Key Revocation)
Are processes, procedures and technical measures to securely destroy cryptographic keys when they are no longer needed, defined, implemented, and evaluated, and include provisions for legal and regulatory requirements?
Yes. PurgeTenant in crypto_envelope.go implements cryptographic erasure on tenant deletion. Dropping the DEK row makes every ciphertext for that tenant unrecoverable, including from any DB backup that doesn't also hold the DEK.
CCM control: CEK-14 (Key Destruction)
Are policies and procedures for maintaining a safe and secure working environment (in offices, rooms, and facilities) established, documented, approved, communicated, enforced, and maintained?
NA. NA. We don't operate physical datacenters. Production runs on managed Kubernetes; physical and environmental controls inherit from the cloud provider's SOC 2 / ISO 27001 attestations.
CCM control: DCS-04 (Secure Area Policy and Procedures)
Are policies and procedures for maintaining safe, secure working environments (e.g., offices, rooms) reviewed and updated at least annually, or upon significant changes?
NA. NA. We don't operate physical datacenters. Production runs on managed Kubernetes; physical and environmental controls inherit from the cloud provider's SOC 2 / ISO 27001 attestations.
Is the classification and documentation of physical and logical assets based on the organizational business risk?
Partial. Logical assets cataloged in code (Kubernetes manifests, docker-compose.yml, db/migrations/). No physical assets to classify.
CCM control: DCS-06 (Assets Classification)
Are assets’ classifications reviewed and updated at least annually or upon significant changes?
Partial. Catalog reviewed implicitly via PR review on infrastructure changes.
Are all relevant physical and logical assets at all CSP sites cataloged and tracked within a secured system?
NA. NA. We don't operate physical datacenters. Production runs on managed Kubernetes; physical and environmental controls inherit from the cloud provider's SOC 2 / ISO 27001 attestations.
CCM control: DCS-07 (Assets Cataloguing and Tracking)
Is the catalogue reviewed and updated at least annually or upon significant changes?
NA. NA. We don't operate physical datacenters. Production runs on managed Kubernetes; physical and environmental controls inherit from the cloud provider's SOC 2 / ISO 27001 attestations.
Are policies and procedures established, documented, approved, communicated, enforced, evaluated, and maintained for the preparation, classification, protection, and handling of data throughout its lifecycle according to all applicable laws and regulations, standards, and risk level?
Partial. Privacy posture documented at /privacy, /dpa, /subprocessors (public compliance pages). No separate internal data-security policy document beyond internal engineering guidelines + feedback memories.
CCM control: DSP-01 (Security and Privacy Policy and Procedures)
Are data security and privacy policies and procedures reviewed and updated at least annually, or upon significant changes?
No. No formal annual review cadence.
Is a data inventory created and maintained for sensitive, regulated and personal information (at a minimum)?
Yes. Personal data inventory: users (email, name, avatar), meeting transcripts, uploaded documents, OAuth tokens, billing data via Stripe. Documented in /privacy.
CCM control: DSP-03 (Data Inventory)
Is the inventory reviewed and updated at least annually or upon significant changes?
Partial. Inventory updates with the schema; no separate annual review cycle.
Is data classified according to type and sensitivity levels?
Yes. Data classification implicit in the schema: secrets (encrypted at rest), personal data (subject to deletion), transcripts (per-tenant). Documented in REQUIREMENTS.md.
CCM control: DSP-04 (Data Classification)
Is data flow documentation created to identify what data is processed and where it is stored and transmitted?
Partial. Data flow at the system level is documented in REQUIREMENTS.md (engine ↔ LiteLLM ↔ provider; engine ↔ Postgres). No formal DPIA per record category.
CCM control: DSP-05 (Data Flow Documentation)
Is data flow documentation reviewed at defined intervals, at least annually, or upon significant changes?
Partial. Updated when REQUIREMENTS.md is updated (every PR per the project rule); no separate annual review.
Is the ownership and stewardship of all relevant personal and sensitive data documented?
Partial. Owner of each data category is implicit: founders are accountable for all of it (team of two). Listed in /privacy.
CCM control: DSP-06 (Data Ownership and Stewardship)
Is data ownership and stewardship documentation reviewed at least annually?
No. No formal review.
Are systems, products, and business practices based on security principles by design and per industry best practices?
Yes. Security-by-design: every endpoint requires auth; every query is tenant-scoped; secrets encrypted at rest (envelope encryption rollout, May 2026); bearer tokens hashed. Default-deny posture.
CCM control: DSP-07 (Data Protection by Design and Default)
Are systems, products, and business practices based on privacy principles by design and according to industry best practices?
Yes. Privacy-by-default: account deletion is irrecoverable (account deletion); data export is the user's data only (data export); cross-tenant access is impossible without explicit invitation.
CCM control: DSP-08 (Data Privacy by Design and Default)
Are systems' privacy settings configured by default and according to all applicable laws and regulations?
Yes. Privacy settings default to restrictive: meetings are per-team, not public; share links are explicit opt-in (share-link feature), encrypted, and individually revocable.
Are processes, procedures, and technical measures defined, implemented, and evaluated to ensure any transfer of personal or sensitive data is protected from unauthorized access and only processed within scope (as permitted by respective laws and regulations)?
Yes. Sensitive transfers: outbound to LLM providers (via LiteLLM, TLS), to Stripe (billing, TLS), to Slack/Teams webhooks (TLS, URL encrypted at rest). No customer data leaves the cluster unencrypted.
CCM control: DSP-10 (Sensitive Data Transfer)
Are processes, procedures, and technical measures defined, implemented, and evaluated to enable data subjects to request access to, modify, or delete personal data (per applicable laws and regulations)?
Yes. Personal data access (data export), reversal (account deletion), and rectification (Settings → Profile). Documented in /privacy.
CCM control: DSP-11 (Personal Data Access, Reversal, Rectification and Deletion)
Are processes, procedures, and technical measures defined, implemented, and evaluated to ensure personal data is processed (per applicable laws and regulations and for the purposes declared to the data subject)?
Yes. Personal data is used only for the meeting / advisory use case the user signed up for; we don't sell or share with marketing partners. Stated in /privacy.
CCM control: DSP-12 (Limitation of Purpose in Personal Data Processing)
Are processes, procedures, and technical measures defined, implemented, and evaluated for the transfer and sub-processing of personal data within the service supply chain (according to any applicable laws and regulations)?
Yes. Sub-processors disclosed at /subprocessors: Anthropic, OpenAI, Google (OAuth/Drive), Microsoft (OAuth/Graph), Stripe, HubSpot, etc.
CCM control: DSP-13 (Personal Data Sub-processing)
Are processes, procedures, and technical measures defined, implemented, and evaluated to disclose details to the data owner of any personal or sensitive data access by sub-processors before processing initiation?
Yes. /subprocessors is the published disclosure. Updated with every new vendor.
CCM control: DSP-14 (Disclosure of Data Sub-processors)
Do data retention, archiving, and deletion practices follow business requirements, applicable laws, and regulations?
Partial. Retention: meetings + transcripts live until the user deletes them. Audit logs retained at-cluster only (no formal off-cluster archive). No formal retention policy document.
CCM control: DSP-16 (Data Retention and Deletion)
Are processes, procedures, and technical measures defined and implemented to protect sensitive data throughout its lifecycle?
Yes. Encryption-at-rest (envelope encryption rollout, May 2026) protects secrets; per-tenant isolation in every DB query protects transcripts; bearer-token hashing protects invitations/sessions.
CCM control: DSP-17 (Sensitive Data Protection)
Are processes, procedures, and technical measures defined and implemented to specify and document physical data locations, including locales where data is processed or backed up?
Yes. Data location documented at /dpa: we run in [cloud region per deployment]; sub-processors disclosed at /subprocessors. Customer data does not cross the cluster boundary unencrypted.
CCM control: DSP-19 (Data Location)
Are information governance program policies and procedures sponsored by organizational leadership established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Engineering principles are documented in internal engineering guidelines, feedback memories, and the proposals/ directory. No separate formal information-governance policy.
CCM control: GRC-01 (Governance Program Policy and Procedures)
Are the policies and procedures reviewed and updated at least annually, or upon significant changes?
Partial. Reviewed informally with every memory/policy update.
Is there an established and maintained formal, documented, and leadership-sponsored enterprise risk management (ERM) program that includes policies and procedures for identification, evaluation, ownership, treatment, and acceptance of risks?
No. No formal risk-management program. Risk decisions get made in PR discussions and design proposals; no central register.
CCM control: GRC-02 (Risk Management Program)
Are roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs defined and documented?
Partial. Founders own everything by default (team of two). Documented in our internal engineering guidelines. Both founders are technical.
CCM control: GRC-06 (Governance Responsibility Model)
Are all relevant standards, regulations, legal/contractual, and statutory requirements applicable to your organization identified and documented?
Partial. Tracked informally: CCPA/GDPR for EU/CA users, Stripe DPA for billing, etc. Not in a central register.
CCM control: GRC-07 (Information System Regulatory Mapping)
Are the identified requirements reviewed at least annually or upon significant changes?
No. No formal annual review.
Are policies and procedures requiring unattended workspaces to conceal confidential data established, documented, approved, communicated, applied, evaluated, and maintained?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: HRS-03 (Clean Desk Policy and Procedures)
Are policies and procedures requiring unattended workspaces to conceal confidential data reviewed and updated at least annually, or upon significant changes?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Both founders work remotely from home. No formal remote-work policy; both manage their own devices. Implicit standard: full-disk encryption + screen lock + strong account passwords.
CCM control: HRS-04 (Remote and Home Working Policy and Procedures)
Are policies and procedures to protect information accessed, processed, or stored at remote sites and locations reviewed and updated at least annually, or upon significant changes?
No. No formal annual review.
Is a security awareness training program for all employees of the organization established, documented, approved, communicated, applied, evaluated and maintained?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: HRS-11 (Security Awareness Training)
Are regular security awareness training updates provided?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
Are identity and access management policies and procedures established, documented, approved, communicated, implemented, applied, evaluated, and maintained?
Partial. IAM patterns are implemented in code (services/engine-go/auth.go, refresh.go, members.go) but not in a separate policy document.
CCM control: IAM-01 (Identity and Access Management Policy and Procedures)
Are identity and access management policies and procedures reviewed and updated at least annually, or upon significant changes?
Partial. Reviewed implicitly on every auth-touching PR.
Is the inventory of identities managed, stored, and regularly reviewed, and is their level of access monitored?
Partial. Identities (users, teams, companies) inventoried in the schema. Reviewed implicitly; no formal cadence.
CCM control: IAM-03 (Identity Inventory)
Is the separation of duties principle employed when implementing information system access?
Partial. Separation of duties at the team-owner / member level. Two-person team means founders can't fully separate operations.
CCM control: IAM-04 (Separation of Duties)
Is the least privilege principle employed when implementing information system access?
Yes. Least privilege enforced by team-scoped queries everywhere. The team-owner role is the only escalation; admin (ADMIN_USERS env var) is separate from regular user accounts and only used for billing / debugging escalation.
CCM control: IAM-05 (Least Privilege)
Is an identity access provisioning process defined and implemented which authorizes, records, and communicates data and assets access changes?
Yes. Provisioning via invitation flow: owner invites a user → email link with hashed token → user accepts → membership row created. Documented in services/engine-go/invitations.go.
CCM control: IAM-06 (Access Provisioning)
Is a process in place to de-provision or modify identity access in a timely manner?
Yes. De-provisioning: owners can remove members (members.go); users can delete their own account (account deletion), cascading through all team memberships.
CCM control: IAM-07 (Access Changes and Revocation)
Are reviews and revalidation of identity access for least privilege and separation of duties completed with a frequency commensurate with organizational risk tolerance, and at least annually or upon significant changes?
Partial. Access reviews happen ad-hoc (when founders notice anomalies in the Settings → Members view). No formal quarterly review.
CCM control: IAM-08 (Access Review)
Are processes, procedures, and technical measures for the segregation of privileged access roles defined, implemented, and evaluated?
Yes. Privileged role (admin) is segregated: separate ADMIN_USERS env-var-based credential, not in the user table; admin actions are logged. Customer-facing roles are owner/member only. Admin endpoint isolation is included in periodic OWASP ZAP DAST scans (see TVM-03.1).
CCM control: IAM-09 (Segregation of Privileged Access Roles)
Is an access process defined and implemented to ensure privileged access roles and rights are granted for a limited period?
Yes. Admin role is opt-in via env var only — there's no UI to grant it. To gain admin, you have to deploy with your email in ADMIN_USERS, which goes through the same PR flow.
CCM control: IAM-10 (Management of Privileged Access Roles)
Are procedures implemented to prevent the accumulation of segregated privileged access?
Yes. Same — there's no in-app path to accumulate admin.
Are processes, procedures, and technical measures for authenticating access to systems, application, and data assets including multifactor authentication for a least-privileged user and sensitive data access defined, implemented, and evaluated?
Yes. Strong auth: bcrypt password hashing (DefaultCost), OAuth via Google/Microsoft (inherits provider MFA). For email/password we don't yet require MFA — gap to close before customer launch.
CCM control: IAM-13 (Strong Authentication)
Are digital certificates or alternatives that achieve an equivalent security level for system identities adopted?
Partial. OAuth covers the equivalent-security path for users who use it; password users get bcrypt + the planned MFA addition.
Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for communications between application interfaces (e.g., APIs)?
Partial. Implementation supports open standards (OAuth 2.0, OpenAPI-style routes, JSON / Markdown exports) but no separate policy doc.
CCM control: IPY-01 (Interoperability and Portability Policy and Procedures)
Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information processing interoperability?
Yes. Customer data is portable: account deletion + data export) cover GDPR Art. 17 + Art. 20.
Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for application development portability?
Yes. Export formats are open: JSON, Markdown, PDF. No proprietary container.
Are policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained for information/data exchange, usage, portability, integrity, and persistence?
Yes. API: REST over JSON. No client-required SDK; any HTTP client works.
Are interoperability and portability policies and procedures reviewed and updated at least annually, or upon significant changes?
Partial. Reviewed implicitly on every export-touching PR; no separate annual review.
Are communications between environments, services, and applications monitored?
Yes. All inter-service communication logged at the engine level (log.Printf with consistent prefixes). K8s network logs available via the cloud provider.
CCM control: I&S-03 (Network Security)
Are communications between environments, services, and applications encrypted?
Yes. Engine ↔ Postgres: TLS in production. Engine ↔ LiteLLM: TLS upstream. Engine ↔ external (OAuth, Stripe, Slack/Teams): HTTPS only. SMTP: STARTTLS on port 587.
Are communications between environments, services, and applications restricted to only authenticated and authorized connections, as justified by the business?
Yes. Service-to-service communication restricted to K8s cluster network; public ingress only on the frontend + engine API endpoints (TLS, authenticated).
Are network configurations reviewed at least annually?
Partial. Network config reviewed on PRs that touch K8s manifests; no separate annual review.
Are network configurations supported by the documented justification of all allowed services, protocols, ports, and compensating controls?
Yes. K8s manifests checked into git with explanatory comments. docker-compose.yml documents each port mapping.
Is every host and guest OS, hypervisor, or infrastructure control plane hardened (according to their respective best practices) and supported by technical controls as part of a security baseline?
CSC. Container base images (Alpine, distroless) are minimized. Host OS hardening inherits from the K8s cloud provider's SOC 2; CSC for self-hosted deployments (not currently offered).
CCM control: I&S-04 (OS Hardening and Base Controls)
Are applications and infrastructures designed, developed, deployed, and configured such that service customer (tenant) access is appropriately segmented, segregated, monitored, and restricted?
Yes. Tenant isolation operates at two layers. At the application layer, every DB query is scoped by team_id or company_id; no shared mutable state across tenants in the engine. Verified periodically via OWASP ZAP IDOR zone scans (see TVM-03.1). At the network layer, Kubernetes NetworkPolicies (Calico-enforced) deny cross-namespace traffic by default; each app namespace declares explicit allow rules for the shared datastores and services it needs. Cross-namespace allows are applied before per-env migration to make the ordering independent of bring-up sequence. Policy declarations live in k8s/dhall/transforms/shared/network-policies.dhall and k8s/dhall/transforms/app/policies-pass.dhall.
CCM control: I&S-06 (Segmentation and Segregation)
Are secure and encrypted communication channels including only up-to-date and approved protocols used when migrating servers, services, applications, or data to cloud environments?
Yes. TLS 1.2+ enforced on all external comms; HTTPS on public surface; HSTS via cloud provider's edge.
CCM control: I&S-07 (Migration to Cloud Environments)
Are processes, procedures, and defense-in-depth techniques defined, implemented, and evaluated for protection, detection, and timely response to network-based attacks?
CSC. Defense-in-depth: app-tier authn/authz, TLS, encryption-at-rest, K8s network policies, cloud provider's edge (DDoS, WAF). On-prem deployment is CSC.
CCM control: I&S-09 (Network Defense)
Are logging and monitoring policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Logging implemented; no separate logging-and-monitoring policy doc. Conventions documented in internal engineering guidelines (Go error-logging rules).
CCM control: LOG-01 (Logging and Monitoring Policy and Procedures)
Are policies and procedures reviewed and updated at least annually, or upon significant changes?
No. No formal annual review.
Is audit log access restricted to authorized identities, and are records of that access maintained?
Partial. Logs go to stdout/stderr and aggregate at the K8s log pipeline. Access to logs requires cluster credentials (founder-only). No formal access record beyond cloud-provider audit log.
CCM control: LOG-04 (Audit Logs Access and Accountability)
Are capabilities implemented and maintained to correlate and monitor security audit logs for the detection of suspicious or anomalous activity that deviates from typical or expected patterns?
No. No SIEM or correlation engine at our scale. Manual grep on the engine logs is the current state.
CCM control: LOG-05 (Audit Logs Monitoring and Response)
Is a process established and followed to review and take appropriate and timely actions on detected anomalies?
Partial. Issues surface via GitHub Issues / user reports; founders investigate. No formal SLA.
Are technical measures defined, implemented, and evaluated to enable service customers to detect and scrub or tokenize sensitive data from logs, in order to prevent unauthorized exposure as per applicable laws and regulations?
Yes. Engine logs are append-only (stdout/stderr → K8s log pipeline → cloud provider). Customers can't modify them. Per-tenant data in logs is sparse — IDs, not content.
CCM control: LOG-08 (Audit Logs Sanitization)
Is a security incident response plan that includes a communication strategy for notifying relevant internal departments, impacted service customers, and other business-critical relationships (such as supply-chain) established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Informal IR — founders are the on-call. No formal IR runbook yet; gap to close before customer launch.
CCM control: SEF-03 (Incident Response Plans)
Is a structured approach followed to evaluate the effectiveness of incident response plans at planned intervals or upon significant changes?
No. No IR testing today.
CCM control: SEF-04 (Incident Response Testing)
Are processes, procedures, and technical measures defined, implemented, and evaluated for timely and effective response to security incidents in accordance with incident categories and severity levels?
Partial. Informal IR; we'd contact affected users via the email on file.
CCM control: SEF-07 (Incident Management and Response)
Are these processes and procedures reviewed, updated, and tested at least annually?
No. Not yet tested.
Are processes, procedures, and technical measures for security breach notifications defined and implemented?
Partial. Breach notification process informal; would email affected users and post on /security. GDPR's 72-hour clock is the operative deadline.
CCM control: SEF-08 (Security Breach Notification)
Are material security breaches reported (including any relevant supply chain breaches) as per applicable SLAs, laws, and regulations?
Partial. No supply-chain breaches to report; reporting cadence informal.
Are policies and procedures for supply chain risk management established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Vendor selection documented in PRs / proposals; no separate supply-chain risk policy doc.
CCM control: STA-01 (Supply Chain Risk Management Policies and Procedures)
Are policies and procedures for supply chain risk management reviewed and updated at least annually, or upon significant changes?
No. No formal annual review.
Is the SSRM applied, documented, implemented, and managed throughout the supply chain?
Partial. SSRM documented implicitly via /subprocessors and this CAIQ-Lite. Not a separate policy document.
CCM control: STA-03 (SSRM Supply Chain)
Is the shared ownership and applicability of all CSA CCM controls delineated according to the SSRM?
Partial. Control ownership per row in this CAIQ-Lite (CSC vs CSP); not a separate SSRM matrix.
CCM control: STA-05 (SSRM Control Ownership)
Is an inventory of all supply chain relationships developed and maintained?
Yes. Supply chain inventory: /subprocessors (public compliance pages) lists every third-party processor with role + region. Updated with every new vendor.
CCM control: STA-08 (Supply Chain Inventory)
Are policies and procedures to protect against malware and malicious instructions established, documented, approved, communicated, applied, evaluated, and maintained?
Partial. Anti-malware policy: containerized workloads run from minimal base images; no user-controlled binaries on the cluster. No endpoint AV per se. The engineering rule that no plaintext secrets land in the DB (our engineering rule against plaintext-secret storage) closes a class of supply-chain risk.
CCM control: TVM-02 (Malware and Malicious Instructions Protection Policy and Procedures)
Are asset management and malware protection policies and procedures reviewed and updated at least annually, or upon significant changes?
No. No formal annual review.
Are processes, procedures, and technical measures defined, implemented, and evaluated for vulnerability detection on organizationally managed assets at least monthly?
Yes. Vulnerability identification via three layers:
CCM control: TVM-03 (Vulnerability Identification)
Are processes, procedures, and technical measures defined, implemented, and evaluated to update detection tools, threat signatures, and compromise indicators weekly (or more frequent) basis?
Yes. Detection updates pull automatically: Dependabot is GitHub-hosted; CodeQL ruleset refreshes with the action.
CCM control: TVM-05 (Detection Updates)
Are processes, procedures and technical measures defined, implemented and evaluated based on identified risks to support scheduled and emergency responses to vulnerability identification?
Partial. No formal SLA, but the median time-to-fix has been days. Higher-severity issues get prioritized within the founders' next sprint. DAST findings (see TVM-03.1) feed directly into the same triage queue.
CCM control: TVM-08 (Vulnerability Remediation Schedule)
Is a risk-based method used for the prioritization and mitigation of threats, leveraging an industry-recognized framework to guide threat decision-making and protection measures?
Partial. Threat response is risk-based at the issue level (label + founder triage) — no formal threat model document. Periodic OWASP ZAP DAST scans (see TVM-03.1) provide structured OWASP Top 10 coverage; findings are labeled and triaged immediately.
CCM control: TVM-10 (Threat Response)
Is a process defined and implemented to track and report vulnerability identification and remediation activities that include stakeholder notification?
Partial. Tracking via GitHub Issues + Dependabot graph. No separate vulnerability-management report; founders look at the dashboard.
CCM control: TVM-11 (Vulnerability Management Reporting)
Is there a defined, documented, applicable and evaluated list containing approved services, applications, and the sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-02 (Application and Service Approval)
Is an inventory of all endpoints used and maintained to store, access and process company data?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-04 (Endpoint Inventory)
Are processes, procedures, and technical measures defined, implemented and evaluated, to enforce policies and controls for all endpoints permitted to access systems and/or store, transmit, or process organizational data?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-05 (Endpoint Management)
Are all relevant interactive-use endpoints configured to require an automatic lock screen?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-06 (Automatic Lock Screen)
Are anti-malware detection and prevention technology services configured on managed endpoints?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-09 (Anti-Malware Detection and Prevention)
Are software firewalls configured on managed endpoints?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-10 (Software Firewall)
Are processes, procedures, and technical measures defined, implemented, and evaluated to enable remote company data deletion on managed endpoint devices?
NA. NA. Two-person founding team; no employees, contractors, or fleet to manage. Founder-direct controls and trust replace formal HR processes at this scale.
CCM control: UEM-13 (Remote Wipe)