How Berserk approaches security, privacy, and compliance — and how to get the artifacts your procurement team needs.
Berserk is a self-hosted observability platform, currently in beta. You run the software in your own infrastructure. Berserk ApS — the company, a Danish private limited company with operations in Denmark and Sweden — distributes the software deliverables. Customer telemetry stays in your environment. Berserk personnel access customer environments only when invited under a Data Processing Agreement.
At current company size we have neither a CISO nor a DPO; the CEO holds the equivalent responsibility. We will appoint a DPO before any managed offering ships, and otherwise on legal/regulatory requirement.
The legal terms governing the software are at Pre-release License Terms.
| If you are… | Read |
|---|---|
| Evaluating Berserk for procurement | This page, then the Security Whitepaper and the filled CAIQ v4. |
| Filling out a vendor risk questionnaire | The filled CAIQ v4 — most questions are pre-answered. |
| Drafting a Data Processing Agreement | The DPA template we use as a starting point. |
| Auditing our supplier chain | The sub-processor list. |
| Reporting a vulnerability | The Coordinated Vulnerability Disclosure policy. |
| Reviewing shipped artifacts | The Security Whitepaper explains the assurance package we ship with the product, including software bill of materials and third-party licensing transparency. |
The shipped product does not transmit telemetry, diagnostic data, or personal data to Berserk. It runs entirely in your environment. This is documented in our Pre-release License Terms §4 and is the central principle of our data-handling approach.
Telemetry stored by Berserk is bound to a cryptographic digest at creation, and queries verify that binding before returning rows. Modifications to either the stored data or the metadata that describes it surface at query time as a clear integrity failure rather than silently producing wrong answers — what your auditors and downstream consumers see is either an authentic result or a named integrity event they can act on.
Lifecycle events for stored segments (creation, merge, deletion) are recorded in an append-only audit chain inside the metadata layer, so the history of what was written and removed is retained alongside the data itself.
In practice this is sufficient to detect a compromise of storage credentials or of metadata credentials on its own. A periodic chain verifier inside the product walks the audit record on a configurable cadence (default 24 hours) and refuses to attest the chain when it finds an inconsistency. Off-system anchoring of the attestations — the final step that closes the door on a coordinated cross-domain rewrite — is on the Security Roadmap.
Disaster recovery from the storage bucket — used when the metadata layer is lost — is an exceptional operator-driven procedure, not a normal-operation property. By construction it rebuilds the metadata from durable storage and trusts those inputs as the source of truth, so its tamper-resistance is bounded by what cross-source verification is available, not by the in-product detection layer. With an external audit-stream configured, two independent sources (the bucket and the off-system archive) can be cross-checked during recovery; without it, the bucket is trusted on its own. The residual gap in either case is a property of the inputs available at recovery time, addressed by operator process (multi-party sign-off, external attestation, evidence preservation) rather than internally by the system.
The control mappings (GDPR Art. 32(1)(b) integrity, NIS2 Art. 21(2)(h) cryptography, NIST CSF PR.DS-06, ISO 27001 Annex A.8.24) are expanded in the Security Whitepaper.
We treat software integrity as a core part of the product. Buyers typically want three things here: confidence that shipped artifacts are produced through controlled processes, visibility into dependencies, and clarity on how vulnerabilities are handled. The technical controls that back those assurances are covered in the Security Whitepaper.
We publish the materials buyers usually ask for during review:
We maintain an incident-response process and distinguish clearly between Berserk acting as controller and Berserk acting as processor under customer instructions. The GDPR-specific notification model and role split are documented in GDPR Compliance. The technical and operational security-response detail lives in the Security Whitepaper.
We publish a vulnerability disclosure policy
and accept reports at security@bzrk.dev. We acknowledge within 2
business days and triage within 5. Default embargo is 90 days.
We keep the detailed public list of in-flight security and compliance work on the Security Roadmap, rather than duplicating it across pages. One point we name plainly here because buyers ask about it directly: we do not operate a 24×7 SOC today; incident response runs through the engineering on-call rota. Managed- offering prerequisites and other control gaps are tracked on the roadmap.
| Framework | Status |
|---|---|
| GDPR | Compliant. Data flows are documented; the product is self-hosted so customer telemetry stays in customer infrastructure. See GDPR Compliance for the controller/processor split, data-subject rights, and breach-notification model. |
| NIS2 (EU Directive 2022/2555) | Compatibility pack mapped to Article 21(2) — see NIS2 Compatibility. Relevant primarily for customers that are themselves in scope and need supplier-assurance material. |
| NIST CSF 2.0 | We maintain a target profile across all six functions. See the Security Whitepaper for the detailed mapping. |
| ISO 27001 | Buyer-facing readiness pack mapped against the ISMS clauses (4–10) and all 93 Annex A controls — see ISO 27001 Readiness. Formal certification will be pursued when customer requirements and company stage make it proportionate. |
| SOC 2 | Not audited. |
| Roadmap | Single consolidated public list of compliance items in flight at Security Roadmap, grouped by trigger. |
| Need | Answer |
|---|---|
| SIG / CAIQ / custom questionnaires | The pre-filled CSA CAIQ v4 plus the Security Whitepaper cover most of what bespoke questionnaires ask. We respond to bespoke questionnaires; turnaround scales with length. Additional internal materials are available to enterprise customers under NDA on request. |
| Data Processing Agreement | We start from our own DPA template as the cleanest path through. We accept standard customer DPAs with minor edits; material edits trigger an internal legal review on our side. |
| NDA before sharing internal documents | Yes — we have a standard mutual NDA. Request from hello@bzrk.dev. |
| Right to audit | Available under the audit clause in our DPA. Default is a remote audit or written attestation; bespoke audit work may incur reasonable costs. |
| SLA | The beta software is not under an uptime SLA — see Pre-release License Terms §9. Specific SLAs apply only under contracted engagements. |
security@bzrk.dev (also via /.well-known/security.txt)hello@bzrk.dev