CSA CAIQ v4 — Berserk ApS Self-Assessment

The Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ) v4 maps to the CSA Cloud Controls Matrix (CCM) v4. This page provides Berserk ApS's self-assessed answers across the 17 control domains.

Important framing for this self-assessment. CAIQ is built around a SaaS / IaaS / PaaS provider model where the vendor operates the service the customer consumes. Berserk's situation is different: the customer operates the deployment. Many CAIQ controls that target the operating environment therefore answer N/A — Customer Responsibility, with a pointer to the customer-side guidance in our Security Whitepaper. When we ship the planned managed offering, those answers shift to operator responsibility.

Last reviewed: 2026-04-29.

How to read this page

• Yes — control implemented and evidence available.
• Partial — control implemented in part; the gap is named.
• No — control not implemented; remediation status named.
• N/A — Customer — customer operates the deployment; the control applies to them, not to us. Recommendation provided where useful.
• N/A — Stage — control not yet relevant at our company stage; will re-evaluate at the gating event named.

---

A&A — Audit and Assurance

ID	Control (CCM v4)	Answer
A&A-01	Audit and Assurance Policy and Procedures	Partial. Annual review cadence committed (CEO-owned; internal compliance calendar). A standalone Audit & Assurance policy is on the pre-Stage 1 ISO 27001 roadmap.
A&A-02	Independent Assessments	No. Not yet ISO 27001 / SOC 2 audited. Buyer-readiness pack maps to the relevant controls; external audit on the managed-offering roadmap.
A&A-03	Risk-Based Planning Assessment	Partial. Internal quarterly risk reviews against a maintained risk register. No external assessor yet.
A&A-04	Requirements Compliance	Yes. GDPR, Danish corporate law verified internally. NIS2 not directly in scope today (see internal applicability memo); buyer-readiness mapping to Article 21(2) maintained.
A&A-05	Audit Management Process	Partial. First internal audit + management review scheduled Q4 2026 (R-ISMS-01). Formal audit-management process documentation is on the pre-Stage 1 ISO 27001 roadmap (R-ISMS-02 / R-ISMS-03).
A&A-06	Remediation	Yes for internal review findings — tracked in the risk register with named owners and target dates.

AIS — Application and Interface Security

ID	Question	Answer
AIS-01	Application security policy?	Yes. Secure Development Policy.
AIS-02	Threat modeling for applications?	Partial. Required at PR-level for new external-facing surfaces; not yet a separate document.
AIS-03	Application security testing (SAST/DAST)?	Partial. Compiler-enforced lints, dependency-advisory scanning across every ecosystem, and CycloneDX SBOM scanning on every shipped image. No dedicated DAST.
AIS-04	Secure SDLC practices?	Yes, three layers: (1) compiler-enforced lints against unsafe coding practices; (2) secure-baseline guardrails in CLAUDE.md consumed by the AI coding agents so generated code follows the same constraints; (3) internal Secure Development Policy and supporting policies. CI gates run on every PR.
AIS-05	API security?	Yes. TLS on every external HTTP/gRPC interface — Rust backend services use rustls (aws-lc-rs backend); non-Rust surfaces (e.g. the marketing site) use the hosting provider's TLS termination. Input validation rejects malformed wire-format before allocation.
AIS-06	Application change-management?	Yes. Pull-request based with required automated CI checks (build, tests, lints, license/SBOM, secrets scan).
AIS-07	Application vulnerabilities tracked?	Yes. See Security Whitepaper §"Vulnerability management" and the Coordinated Vulnerability Disclosure page. Full policy under NDA on request.

BCR — Business Continuity Management

ID	Question	Answer
BCR-01	BCM policy and procedures?	Yes. See Security Whitepaper §"Business continuity and disaster recovery". Full BCP available under NDA on request to paying customers.
BCR-02	RTO and RPO defined?	Yes. Per critical function, in the BCP. Customer-facing RTO/RPO targets are agreed contractually under each paying engagement (DPA, support contract, managed-offering MSA).
BCR-03	BCM testing?	Partial. Annual rehearsal scheduled; first end-to-end rehearsal is Q3 2026.
BCR-04	Backup procedures?	Partial. Documented in backup-restore procedure. Daily encrypted Postgres dump is roadmap; S3-as-trust-root rebuild is roadmap.
BCR-05	Backup testing?	Partial. First end-to-end rehearsal Q3 2026.
BCR-06	Disaster recovery plan?	Yes. S3-as-trust-root recovery model — see Security Whitepaper §"Business continuity and disaster recovery". Full procedures (backup-restore, BCP) available under NDA on request to paying customers.
BCR-07	Data redundancy?	N/A — Customer for telemetry data (customer's S3 redundancy choice). For our own infra, Hetzner-hosted with cross-region replication on roadmap.
BCR-08	Business impact analysis?	Partial. Critical functions identified in BCP; quantitative BIA not yet performed.
BCR-09	Crisis communications?	Yes. Public commitments in Trust §"Incident response and breach notification", GDPR Compliance §"Personal-data breach notification", and the DPA. Full breach-notification procedure (decision flow, role assignments, notification log) available under NDA on request to paying customers.
BCR-10	Equipment redundancy?	Yes — by design. Berserk is architected for redundancy at every layer: query processing is horizontally scalable (stateless workers + map-reduce coordination), the metadata service is rebuildable from object storage (S3-as-trust-root), and storage durability is inherited from the customer's object store (e.g. S3's eleven-nines). No single host is irreplaceable. The customer chooses the redundancy level of the underlying object store, Postgres, and K8s cluster. For our own internal infra (build, registry, website), cross-region redundancy is on the roadmap.
BCR-11	Recovery testing for changes?	N/A — Stage. Infrequent change cadence; recovery tested per the annual rehearsal.

CCC — Change Control and Configuration Management

ID	Question	Answer
CCC-01	Change-management policy?	Yes. PR-based with required automated CI checks.
CCC-02	Production change-control?	Yes. Helm + Terraform; production deploys are tracked.
CCC-03	Change documentation?	Yes. GitOps-driven: Git history is the primary change record; FoxIDs IdP logs identity/configuration changes in its own audit logs; change-logs in legal/coordinated-disclosure.md for security-relevant changes.
CCC-04	Unauthorized changes detected?	Partial. Bazel sandboxing limits blast radius; centralized change-detection (e.g. file integrity monitoring) on roadmap, triggered at headcount > 25 FTE (or earlier on managed-offering launch).
CCC-05	Configuration baselines?	Yes. Terraform for infra; Helm for K8s.
CCC-06	Configuration changes reviewed?	Yes. PR-required for both Terraform and Helm; ArgoCD applies only what is in git, so reviewed-in-PR is the only path to production.
CCC-07	Configuration drift monitored?	Partial. Terraform-plan as drift indicator; no automated drift alerting.
CCC-08	Software vulnerability management?	Yes. See AIS-07.
CCC-09	Patch-management cadence?	Yes. Daily dependency scanning across every ecosystem; severity-based remediation SLAs (Critical 7 d / High 30 d / Medium 90 d) — see Security Whitepaper §"Vulnerability management".

CEK — Cryptography, Encryption, and Key Management

ID	Question	Answer
CEK-01	Encryption policy?	Yes. See Security Whitepaper §"Cryptography" for the encryption-by-data-state matrix and approved-primitives table. Full Cryptography Policy (key-management table, library-selection process) available under NDA on request to paying customers.
CEK-02	Approved algorithms?	Yes. Listed in Security Whitepaper §"Cryptography" → "Approved primitives (engineering reference)".
CEK-03	Encryption in transit?	Yes. TLS on every external interface — rustls (aws-lc-rs backend) for Rust backend services; provider-terminated TLS for non-Rust surfaces.
CEK-04	Encryption at rest (in our control plane)?	Partial. Provider-managed encryption-at-rest on Hetzner volumes and OCI registry. Internal K8s control-plane encryption-at-rest is on the roadmap (R-PROD-01).
CEK-05	Encryption at rest (customer telemetry)?	N/A — Customer. Customer-controlled S3 / object store; recommend server-side encryption (see Security Whitepaper).
CEK-06	Key management policy?	Yes. Documented in our internal key management policy (available under NDA on request).
CEK-07	Key rotation?	Partial. TLS auto-rotated by cert-manager; SaaS keys rotated on personnel change; database password rotation cadence on roadmap.
CEK-08	Key access controls?	Yes. Per the cryptography policy and access control policy.
CEK-09	Key destruction?	Yes. On personnel departure, shared-credential rotation is part of the leaver checklist.
CEK-10	Customer-managed keys?	N/A — Customer. Customer operates the deployment and chooses key management.

DCS — Datacenter Security

ID	Question	Answer
DCS-01..15	Datacenter physical security, environmental controls, etc.	Inherited from suppliers. Hetzner operates the physical datacenter; Hetzner's certifications cover ISO 27001, ISO 9001, ISO 14001, ISO 50001. We rely on Hetzner's published controls. Customer-side: customer's own datacenter / cloud provider applies.

DSP — Data Security and Privacy Lifecycle

ID	Question	Answer
DSP-01	Data classification?	Yes. Four classes: Public (released SBOMs, container images, the website, pre-release license terms — anyone may receive); Internal (architecture docs, the codebase, build configs — Berserk personnel and contractors under NDA); Confidential (production credentials, employee personal data, customer-support correspondence — need-to-know, no plaintext on personal devices); Customer data under DPA (logs/traces/metrics/configs a customer shares for support — highest restriction, not retained beyond the engagement).
DSP-02	Data inventory?	Yes. Public summary in GDPR Compliance §"Records of processing (Article 30)" and the DPA Annex A — TOM. Full asset register available under NDA on request to paying customers.
DSP-03	Data flows mapped?	Yes. Security Whitepaper §"Data handling at the architecture level" (with wire-level summary) and §"Trust boundary". The deployment model is largely inspectable through the Helm chart, rendered manifests, and operator documentation; additional engineering walkthroughs are available on request.
DSP-04	Data ownership?	Yes. Customer owns telemetry; Berserk owns operational data — restated in Pre-release License Terms §4 and the DPA.
DSP-05	Data retention policy?	Yes. See GDPR Compliance §"Retention" and Privacy Notice §"What we collect, why, and how long we keep it". Customer telemetry is customer-controlled (self-hosted).
DSP-06	Data deletion verifiable?	Yes for engagement data — deletion confirmed to customer per DPA §"Term and termination". For customer-deployed data: customer-controlled.
DSP-07	Personal data identified?	Yes. Categories listed in GDPR Compliance §"Records of processing (Article 30)" and Privacy Notice §"What we collect, why, and how long we keep it".
DSP-08	Data privacy program?	Yes. GDPR-based — see GDPR Compliance.
DSP-09	Data subject rights handled?	Yes. 30-day SLA — see GDPR Compliance §"Data-subject rights" and Privacy Notice §"Your rights". Customer-side requests are passed back to the customer (controller).
DSP-10	Data transferred internationally?	No without explicit customer instruction. EU/EEA-default — see Sub-processors and Privacy Notice §"International transfers".
DSP-11	Data minimization?	Yes. Self-hosted product transmits no telemetry to Berserk in normal operation — see Pre-release License Terms §4.
DSP-12	Privacy by design?	Yes. Pre-release License Terms §4 documents the "no telemetry to Berserk" baseline.
DSP-13	Privacy impact assessment?	N/A — Stage. No high-risk processing within Berserk ApS today. PIA mandatory before managed offering.
DSP-14	Privacy notice published?	Yes. Privacy Notice; product privacy baseline in Pre-release License Terms §4.
DSP-15	Privacy training?	Partial. Onboarding briefing; annual session on roadmap.
DSP-16	DPO appointed?	No. Not required at current size and risk profile — see GDPR Compliance §"Data Protection Officer". Will appoint before managed offering.
DSP-17	Sub-processor disclosure?	Yes. Sub-processors.
DSP-18	Sub-processor change notice?	Yes. 30 days — see DPA §"Sub-processors".
DSP-19	Customer audit rights?	Yes. See DPA §"Audit".

GRC — Governance, Risk, and Compliance

ID	Question	Answer
GRC-01	Information security policy?	Yes. Information Security Policy.
GRC-02	Policy owner?	Yes. CEO.
GRC-03	Policy review cadence?	Yes. Annual.
GRC-04	Risk management program?	Yes. Risk Management Policy + risk register.
GRC-05	Risk assessment cadence?	Yes. Quarterly.
GRC-06	Compliance program?	Yes. GDPR-compliant; NIS2 buyer-readiness pack mapped to Article 21(2); NIST CSF 2.0 target profile maintained across all six functions.
GRC-07	Compliance monitoring?	Partial. Quarterly review of control matrix.

HRS — Human Resources Security

Berserk does not have a dedicated HR function at current size; the policies below are CEO-owned and apply to all personnel and contractors. They are written to scale to a managed-offering team without rework.

ID	Question	Answer
HRS-01	HR security policy?	Yes. Documented HR Security Policy (CEO-owned at current size); covers joiner / mover / leaver, acceptable use, training, confidentiality. Available under NDA on request to paying customers.
HRS-02	Background checks?	No. Not at current size and risk profile; reconsidered for managed-offering roles with administrator access to customer environments.
HRS-03	Confidentiality agreements?	Yes. Confidentiality and IP-assignment terms are part of every employment and contractor agreement; signed before first access to source code or production.
HRS-04	Acceptable use?	Yes. Defined in the HR Security Policy.
HRS-05	Security training?	Partial. Onboarding briefing on the policy set, security FAQ, and incident-response policy; annual refresher on the roadmap.
HRS-06	Joiner/mover/leaver?	Yes. Documented in the Access Provisioning Procedure (every standing access re-evaluated on role change; full revocation checklist on the leaver's last day).
HRS-07	Termination procedures?	Yes. Access Provisioning Procedure §Leaver: revoke SaaS accounts, remove SSH keys, rotate shared credentials, reclaim hardware.

IAM — Identity and Access Management

ID	Question	Answer
IAM-01	IAM policy?	Yes. Access Control Policy.
IAM-02	Account provisioning?	Yes. Joiner checklist.
IAM-03	Account deprovisioning?	Yes. Leaver checklist with shared-credential rotation.
IAM-04	Access review cadence?	Yes. Quarterly.
IAM-05	Least privilege?	Yes by policy. Partial in execution — root on dev/prod machines is a known gap.
IAM-06	Multi-factor authentication?	Partial. MFA in force on the higher-risk SaaS providers; broader MFA enforcement and extending SSO use for internal services is on the roadmap.
IAM-07	Privileged access management?	Partial. Privileged operations announced in on-call channel + two-person rule for irreversible production-data ops.
IAM-08	Single sign-on?	Partial. Proton-based for the SaaS that supports it.
IAM-09	Customer IAM (in their deployment)?	N/A — Customer. Customer operates auth at the ingress. Recommend OAuth2 proxy or service mesh.
IAM-10	Access logging?	Partial. Per-host SSH logs; aggregated logging on roadmap.

IPY — Interoperability and Portability

IPY-01..05 — Open formats; portability; vendor lock-in. Yes. Open OTLP ingest (OpenTelemetry); KQL query language; CycloneDX SBOMs; THIRD_PARTY_LICENSES.txt; standard S3/PostgreSQL backends. The customer can extract their own data at any time.

Berserk's on-disk segment format is proprietary, but it is not a lock-in surface: telemetry is queryable through the standard KQL interface, and a customer can export their data at any time and migrate to another vendor without dependency on Berserk. The object store and Postgres are customer-controlled.

IVS — Infrastructure and Virtualization Security

ID	Question	Answer
IVS-01	Network security policy?	Yes. Reflected in the access control policy and infra/docs/deployment-architecture.md.
IVS-02	Network segmentation?	Partial. Internal Netbird overlay separates dev/prod traffic from public. Per-tenant segmentation in our internal cluster does not yet exist (all customers run their own clusters today).
IVS-03	Network monitoring?	Partial. Service-level metrics. SIEM is roadmap.
IVS-04	Hypervisor security?	N/A — Sub-processor. Hetzner-managed.
IVS-05	Container security?	Yes. Distroless images; Bazel-built; SBOM in image; license bundle in image.
IVS-06	Container image scanning?	Yes. Every shipped image carries a CycloneDX 1.6 SBOM at /sbom.cdx.json; any compatible scanner can audit the image. Dependency-advisory scanning runs daily in CI.
IVS-07	Wireless security?	N/A — Stage. No corporate wireless network we operate.
IVS-08	Customer network isolation?	N/A — Customer. Customer operates the deployment.
IVS-09	Mobile device management?	Partial. Personnel laptops are full-disk encrypted and password-locked. Centralised MDM-class enforcement is deployed via self-hosted endpoint-management tooling; rollout to every existing laptop and host is tracked under Security Roadmap R-PROD-06.

LOG — Logging and Monitoring

ID	Question	Answer
LOG-01	Logging policy?	Yes. Logging-relevant controls are split across the Data Handling Policy (retention), Incident Response Policy (review during incidents), and Access Control Policy (personnel-access logging). A consolidated logging policy is not maintained as a separate document at current scale.
LOG-02	Centralized logging?	Partial. Service logs aggregated for our own internal infra; aggregated audit logging across personnel access (SSH, cloud consoles, SaaS) is roadmap — see Security Roadmap (R-ACCESS-02).
LOG-03	Log retention?	Yes. Per the data handling policy; public retention disclosure in GDPR Compliance §"Retention" and Privacy Notice §"What we collect, why, and how long we keep it".
LOG-04	Log integrity?	Partial. Append-only at the host. Immutable storage / log-integrity is roadmap — see Security Roadmap (R-DETECT-04).
LOG-05	Log review cadence?	Yes for incident-relevant logs — driven by the Incident Response Policy. Routine periodic review across non-incident logs is in scope of the aggregated audit-logging roadmap item (R-ACCESS-02).
LOG-06	Customer log access?	N/A — Customer. Customer operates the deployment and controls log access in their own environment.

SEF — Security Incident Management, E-Discovery, and Cloud Forensics

ID	Question	Answer
SEF-01	Incident response policy?	Yes. Documented Incident Response Policy (six standard phases, severity matrix, roles, reporting commitments) plus a separate operational runbook. Public commitments are summarised in Trust §"Incident response and breach notification"; full policy and runbook available under NDA on request to paying customers.
SEF-02	Incident classification?	Yes. S1–S4 severity matrix in the Incident Response Policy. A personal-data breach is always at least S2 until ruled out.
SEF-03	Incident response team?	Yes. Four named roles: Incident Commander (first responder, owns the timeline), Communications Lead (CEO or delegate, owns external notifications), Technical Lead (engineering lead nearest the affected component), Scribe. At current headcount these roles are typically held by 1–2 people during a single incident.
SEF-04	Incident response testing?	Partial. Annual breach-notification tabletop and annual recovery rehearsal are scheduled in the Incident Response Policy; first end-to-end rehearsal is Q3 2026 (see Security Roadmap).
SEF-05	Customer incident notification?	Yes. Without undue delay, target ≤24h from awareness — restated in the DPA and Trust §"Incident response and breach notification".
SEF-06	Regulator notification?	Yes. NIS2 Art.23 staged reporting (24h early warning, 72h notification, 1-month final report) when in scope; GDPR Art.33 within 72h to Datatilsynet. Full timeline in Trust §"Incident response and breach notification" and GDPR Compliance §"Personal-data breach notification".
SEF-07	Forensics capability?	Scoped to Berserk's own operations (the shipped product runs in the customer's environment, where forensics is the customer's responsibility). Partial. Hetzner snapshot supports disk imaging for evidence preservation on our own infra (referenced in the internal incident-response runbook); personnel laptops preserved before factory-reset. No dedicated forensics tooling or third-party DFIR retainer at current scale. Product-side: tamper-evident segment files (signed-hash chain over chunks) are on the Security Roadmap (R-DETECT-05); today CRC-32 chunk checksums detect bit-rot but are not sufficient for tamper-detection.
SEF-08	Lessons learned?	Yes. RCA written within 5 business days of resolution; findings feed the internal risk register and any relevant policy. Defined in the Incident Response Policy §Phases (step 6).

STA — Supply Chain Management, Transparency, and Accountability

ID	Question	Answer
STA-01	Supply chain risk management policy?	Yes. Supply Chain Security Policy.
STA-02	Sub-processor inventory?	Yes. Sub-processors.
STA-03	Sub-processor due diligence?	Yes. Permissive-license stance + checksum/SHA pinning + vendoring.
STA-04	Sub-processor SLA?	Inherited from each sub-processor's SLA.
STA-05	Sub-processor monitoring?	Partial. Manual; formal supplier-register on roadmap.
STA-06	SBOM available?	Yes. /sbom.cdx.json in every container image (CycloneDX 1.6, pkg:cargo/ purls, SPDX license IDs). SBOMs for CI / build-time tools are available on request and not bundled with images.
STA-07	Vulnerability disclosure to suppliers?	Yes. When we discover a vulnerability in a dependency we report upstream and track in our advisory-exception register if a reach-around is required.
STA-08	Customer notification of supplier change?	Yes. 30-day notice under DPA.

TVM — Threat and Vulnerability Management

ID	Question	Answer
TVM-01	Vulnerability management policy?	Yes. See Security Whitepaper §"Vulnerability management". Full policy under NDA on request.
TVM-02	Scanning frequency?	Yes. Daily across every ecosystem.
TVM-03	Penetration testing?	No. Not yet performed. Roadmap before managed-offering production launch.
TVM-04	Patch SLAs?	Yes. Critical 7 d / High 30 d / Medium 90 d (see CCC-09).
TVM-05	Vulnerability disclosure?	Yes. Coordinated Vulnerability Disclosure Policy.
TVM-06	Threat intelligence?	Partial. Manual review of CFCS / ENISA bulletins.
TVM-07	Web application firewall?	Partial. Rate limiting and admission control implemented in the ingest service; no separate WAF.
TVM-08	DDoS protection?	N/A — Sub-processor. Hetzner-level.
TVM-09	Endpoint detection on workstations?	Partial. OS-level only at this stage.

UEM — Universal Endpoint Management

ID	Question	Answer
UEM-01..10	Endpoint management.	Partial. Personnel laptops full-disk encrypted and password-locked. Centralised MDM-class enforcement is deployed via self-hosted endpoint-management tooling; rollout to every existing laptop and host is tracked under R-PROD-06.

---

How to use this self-assessment

This document is the input we offer to enterprise procurement reviews that ask for a CAIQ. We update it on every material change.

For follow-up questions, contact security@bzrk.dev.