Legal & Compliance
CAIQ-lite
Self-Assessment
Cloud Security Alliance Consensus Assessments Initiative Questionnaire — lite edition, aligned to CCM v4 control domains. 50 questions. Honest answers.
Document version: 1.0 · Effective: 2026-05-01 · Next review: 2026-11-01
Reading this document: Answers use four statuses. Implemented = control is in production and verifiable. In progress = actively being built or documented, not yet complete. Compensating control = direct control not implemented; an alternative mitigates equivalent risk. Not applicable = control domain is structurally irrelevant to CloakAPI's architecture. We do not inflate answers. Questions without good answers say so.
A — Audit Assurance & Compliance (AAC)
| CCM ID | Control Question | Status | Notes |
|---|
| AAC-01 |
Do you have an established audit programme? |
In progress |
Internal audit schedule drafted; external audit engagement pending first enterprise customer trigger. |
| AAC-02 |
Do you maintain independent verification of security controls? |
In progress |
Penetration test engagement scoped; will execute on first enterprise customer request. |
| AAC-03 |
Are compliance obligations documented and tracked? |
Implemented |
GDPR, UK-DPA 2018, and CCPA obligations tracked in internal register with named DPO-equivalent. |
B — Application & Interface Security (AIS)
| CCM ID | Control Question | Status | Notes |
|---|
| AIS-01 |
Do you use secure SDLC practices (threat modelling, code review)? |
Implemented |
GitHub PR-gated reviews; automated SAST (CodeQL); dependency scanning (Dependabot) on all repositories. |
| AIS-02 |
Do you perform application-layer penetration testing? |
In progress |
Scope defined; engagement to begin on first enterprise customer request. Summary will be published at /trust. |
| AIS-03 |
Are API endpoints protected against injection and abuse? |
Implemented |
Cloudflare WAF (OWASP core ruleset) + input validation on all gateway routes. Rate-limiting per API key. |
| AIS-04 |
Is customer data segregated per tenant at the application layer? |
Implemented |
Tenant-scoped API keys; all DB queries enforce tenant_id predicate; zero cross-tenant query paths in schema. |
C — Business Continuity Management & Operational Resilience (BCR)
| CCM ID | Control Question | Status | Notes |
|---|
| BCR-01 |
Do you have a documented Business Continuity Plan? |
Implemented |
Published at /legal/bcp. Internal operational runbook maintained separately. |
| BCR-02 |
Are backups taken regularly and tested? |
Implemented |
Encrypted backups every 6 hours (age-encrypted, pull model to off-site destination). 30-day retention. Restore tested quarterly. |
| BCR-03 |
Are RTO and RPO targets defined and tested? |
Implemented |
RTO target: 4 hours. RPO target: 6 hours. Annual DR drill committed. Current architecture: single primary region. |
| BCR-04 |
Is multi-region failover available? |
In progress |
Planned; timeline tied to first enterprise customer requiring multi-region. No fake date given. |
| BCR-05 |
Is the DR plan reviewed annually? |
Implemented |
Annual review and drill commitment documented in BCP. |
D — Change Control & Configuration Management (CCC)
| CCM ID | Control Question | Status | Notes |
|---|
| CCC-01 |
Are changes to production systems controlled and logged? |
Implemented |
Changes are version-controlled in git with pre-commit checks; deploys run from scripted, repeatable steps (image rebuilds and static syncs) with change history retained. Production access is restricted to the operator over authenticated SSH. |
| CCC-02 |
Is infrastructure managed as code? |
Implemented |
Server configuration managed via Ansible playbooks under version control. Infrastructure changes require PR approval. |
| CCC-03 |
Are rollback procedures defined? |
Implemented |
Zero-downtime deployments with automatic rollback on health-check failure. Previous release artifacts retained for 30 days. |
E — Data Security & Privacy Lifecycle Management (DSP)
| CCM ID | Control Question | Status | Notes |
|---|
| DSP-01 |
Is customer data classified and labelled? |
Implemented |
Data classification policy in place: gateway metadata (low), billing data (medium), audit logs (high). Handling rules documented per class. |
| DSP-02 |
Is plaintext customer content ever stored by CloakAPI? |
Implemented |
No. Tokenisation occurs on the client device before egress. CloakAPI infrastructure never receives plaintext prompts or responses. Zero-payload invariant enforced in CI. |
| DSP-03 |
Are data retention and deletion policies defined? |
Implemented |
Gateway metadata: 90 days. Billing records: 7 years (legal obligation). Cryptographic receipts: tenant-controlled, delete on request. |
| DSP-04 |
Can customers request data deletion? |
Implemented |
GDPR Art. 17 erasure requests handled via trust@cloakapi.io within 30 days. Account deletion removes all gateway metadata. |
| DSP-05 |
Is data exported for sub-processors under contractual controls? |
Implemented |
All sub-processors listed at /legal/subprocessors operate under GDPR Art. 28 DPAs or standard contractual clauses. No sub-processor receives plaintext customer content. |
F — Datacenter Security (DCS)
| CCM ID | Control Question | Status | Notes |
|---|
| DCS-01 |
Are physical datacenter controls in place? |
Compensating control |
CloakAPI uses Hetzner Nuremberg, an independently audited, externally certified EU data-centre. Physical controls are Hetzner's responsibility; CloakAPI inherits and verifies via Hetzner's published compliance documentation. |
| DCS-02 |
Is access to physical hardware restricted? |
Compensating control |
No CloakAPI personnel have physical datacenter access. Managed hosting model; hardware access controlled by Hetzner. |
G — Encryption & Key Management (EKM)
| CCM ID | Control Question | Status | Notes |
|---|
| EKM-01 |
Is data encrypted in transit? |
Implemented |
TLS 1.2+ enforced on all public endpoints. TLS 1.3 preferred. Cloudflare edge terminates with HSTS preload. Internal service-to-service traffic on private network with mutual auth. |
| EKM-02 |
Is data encrypted at rest? |
Implemented |
Database volumes encrypted at block level (LUKS). Backup archives encrypted with age (X25519 recipient key). Signing keys stored in encrypted keystore, never in environment variables. |
| EKM-03 |
Is there a documented key management process? |
Implemented |
ECDSA P-256 signing keys with documented rotation schedule (annual, or on compromise). Key custodian designated. Rotation triggers public JWKS update with overlap period. |
| EKM-04 |
Are encryption algorithms standards-compliant? |
Implemented |
AES-256-GCM for symmetric, ECDSA P-256 for signing, X25519 for key agreement. No custom cryptography. Library: Go standard crypto + age. |
| EKM-05 |
Are cryptographic receipts independently verifiable? |
Implemented |
Yes. ECDSA P-256 signatures verifiable offline against JWKS at signedreceipts.org. No CloakAPI account required to verify. |
H — Governance, Risk & Compliance (GRC)
| CCM ID | Control Question | Status | Notes |
|---|
| GRC-01 |
Is there a documented information security policy? |
Implemented |
Security policy published at security.cloakapi.io. Covers acceptable use, incident response, key management, and access control. |
| GRC-02 |
Is risk assessment performed periodically? |
In progress |
Initial risk register drafted. Formal periodic cadence (annual) design intent; first formal review scheduled 2026 H2. |
| GRC-03 |
Are roles and responsibilities for security defined? |
Implemented |
Security owner, DPO-equivalent, and incident commander roles documented with named individuals. |
I — Identity & Access Management (IAM)
| CCM ID | Control Question | Status | Notes |
|---|
| IAM-01 |
Is multi-factor authentication required for privileged access? |
Implemented |
MFA enforced on all staff GitHub accounts, cloud provider consoles, and production SSH access (hardware key + passphrase). |
| IAM-02 |
Is least-privilege enforced for production access? |
Implemented |
Role-based access; production database access requires break-glass procedure with audit log. No standing privileged DB sessions for non-DBA roles. |
| IAM-03 |
Are service accounts and API keys managed with rotation? |
Implemented |
API keys scoped to minimum required permissions. Customer-facing keys rotatable on demand. Internal service tokens rotated on 90-day schedule. |
| IAM-04 |
Is access reviewed and de-provisioned upon role change? |
Implemented |
Offboarding checklist includes immediate revocation of all access within 24 hours. Access review performed semi-annually. |
| IAM-05 |
Is SSO / federated identity supported for enterprise customers? |
In progress |
SAML 2.0 / OIDC SSO: design intent; in development; available to any account (beta on request). |
| IAM-06 |
Are privileged sessions logged and monitored? |
Implemented |
SSH session logs retained. Tailscale-gated access with audit events. Alert on anomalous login geography. |
J — Infrastructure & Virtualisation Security (IVS)
| CCM ID | Control Question | Status | Notes |
|---|
| IVS-01 |
Is the network segmented to isolate tenant workloads? |
Implemented |
Production network behind private VPC with no public DB ports. Cloudflare proxy for all public endpoints. Internal services on private subnet. |
| IVS-02 |
Are operating systems hardened according to a baseline? |
Implemented |
Ubuntu LTS with unattended-upgrades; CIS Level 1 baseline applied via Ansible; unnecessary services disabled. |
| IVS-03 |
Is vulnerability scanning performed on infrastructure? |
In progress |
Manual review in place; automated recurring scan (Trivy for containers, Lynis for hosts) being integrated into CI. Target: complete 2026 Q3. |
| IVS-04 |
Are security patches applied within defined SLAs? |
Implemented |
Critical patches: 24 hours. High: 7 days. Medium: 30 days. Automated alerts via Dependabot and USN feeds. |
K — Interoperability & Portability (IPY)
| CCM ID | Control Question | Status | Notes |
|---|
| IPY-01 |
Can customers export their data in portable formats? |
Implemented |
All gateway metadata and cryptographic receipts exportable as JSON via API. No proprietary lock-in format. |
| IPY-02 |
Is there a documented offboarding / data-return process? |
Implemented |
30-day data-export window on contract termination. Full export available via API or provided as archive on request to trust@cloakapi.io. |
L — Logging & Monitoring (LOG)
| CCM ID | Control Question | Status | Notes |
|---|
| LOG-01 |
Are security-relevant events logged centrally? |
Implemented |
Structured JSON logs shipped to centralised log aggregator. Auth events, API errors, config changes, and admin actions all captured. |
| LOG-02 |
Are logs tamper-protected? |
Implemented |
Logs shipped to append-only destination within 60 seconds. Production hosts cannot delete shipped log entries. |
| LOG-03 |
Are alerting thresholds defined for anomalous activity? |
Implemented |
Alerts on: error rate spike, auth failure burst, unusual geographic login, certificate expiry, disk/CPU threshold breach. |
| LOG-04 |
Are logs retained for a minimum of 12 months? |
In progress |
Current retention: 90 days for access logs, 12 months for security events. Unified 12-month retention policy being formalised. |
M — Security Incident Management (SEF)
| CCM ID | Control Question | Status | Notes |
|---|
| SEF-01 |
Is there a documented incident response plan? |
Implemented |
Incident response runbook covering SEV-1 through SEV-4. Named incident commander. Escalation path documented. |
| SEF-02 |
Are customers notified of security incidents within required timeframes? |
Implemented |
GDPR 72-hour supervisory authority notification commitment. Affected customers notified within 48 hours of confirmed breach with material impact. |
| SEF-03 |
Are postmortems published for significant incidents? |
Implemented |
SEV-3+ incidents generate public postmortems within 5 business days, published at status.cloakapi.io. |
| SEF-04 |
Is there a vulnerability disclosure programme? |
Implemented |
Coordinated disclosure policy published at security.cloakapi.io. Safe harbour, scope, and 90-day disclosure deadline defined. |
N — Supply Chain Management & Transparency (STA)
| CCM ID | Control Question | Status | Notes |
|---|
| STA-01 |
Is a full sub-processor list maintained and published? |
Implemented |
Full list at /legal/subprocessors. 30-day advance notice of changes. Email subscription available. |
| STA-02 |
Are third-party dependencies scanned for vulnerabilities? |
Implemented |
Dependabot on all repos. Go module vulnerability database checked in CI. NPM audit in frontend pipeline. |
| STA-03 |
Are container images scanned before deployment? |
Implemented |
Trivy scan in CI pipeline; builds blocked on CRITICAL findings. Base images pinned by digest. |
O — Threat & Vulnerability Management (TVM)
| CCM ID | Control Question | Status | Notes |
|---|
| TVM-01 |
Is there a documented vulnerability management process? |
Implemented |
Patch SLA: CRITICAL/HIGH 24h-7d. Severity assessed against CVSS 3.1. Process documented in security policy. |
| TVM-02 |
Is external penetration testing performed? |
In progress |
Engagement scoped; will commence on first enterprise customer request. Results summarised at /trust on completion. |
| TVM-03 |
Is a SIEM or equivalent threat detection in place? |
Compensating control |
Centralised log aggregation with alert rules covers SIEM-equivalent detection for current threat model. Full SIEM (Elastic/Splunk) is a roadmap item. |
This document is self-attested. Controls marked "implemented" are verifiable by design artefacts, configuration, or operator-provided evidence on request. Contact trust@cloakapi.io to request evidence packages for specific controls.