Berserk

ISO 27001 Readiness

Status — readiness pack mapped to ISO/IEC 27001:2022. Berserk ApS is not currently ISO/IEC 27001:2022 certified, but we do maintain a mapped readiness posture against both the management-system clauses (4–10) and all 93 Annex A controls. This page is the buyer-facing ISO 27001 readiness extract: it shows what is already in place, where the deliberate gaps are, and how the current control set maps to the standard. We will pursue formal certification when customer requirements and company stage make it proportionate.

This page tells a buyer:

  • which Annex A controls already have evidence on this site,
  • where there are deliberate gaps and how we mitigate them, and
  • how to obtain the deeper artifacts (Statement of Applicability, control mapping, internal policies) under NDA.

For the procurement-friendly summary see the Trust Overview. For the framework-mapped controls in detail see the Security Whitepaper and the filled CAIQ v4.

How to read this page

  • Yes — implemented; evidence on this site or in shipped artifacts.
  • Partial — partially implemented; the gap is named.
  • Planned — planned; tracked as a remediation item.
  • NDA — implemented but evidence available under NDA only.
  • Inherited — inherited from a sub-processor with its own ISO 27001 certification (Hetzner, Proton, GitHub).

ISMS — Clauses 4 to 10 (mandatory)

These are the management-system clauses an auditor opens first. They cover the governance scaffolding around the technical controls.

ClauseTopicStatusWhere it lives
4Organizational context, interested partiesPartialScope and interested parties documented in our internal Information Security Policy. Formal "interested parties" register on the roadmap.
5Leadership, policy, rolesYesCEO ownership stated across every internal policy header; this trust pack is the public expression of the policy.
6Risk assessment, risk treatment, Statement of ApplicabilityPartialQuarterly risk register and a control matrix mapping every NIS2 / NIST CSF / Annex A control to a policy and an evidence file. SoA in NDA-share form (NDA).
7Resources, competence, awareness, document controlPartialOnboarding briefing covers core policies; competence matrix and document-control procedure are roadmap items.
8Operational planning and controlYesRunbooks under the internal procedures pack: incident response, breach notification, backup/restore, access provisioning, vulnerability disclosure.
9Monitoring, internal audit, management reviewPlannedInternal-audit procedure and management-review cadence are roadmap items before any Stage 1 audit.
10Nonconformity, corrective action, continual improvementPartialLessons-learned process documented in the incident response runbook; generalised continual-improvement procedure is a roadmap item.

Annex A controls

Annex A of ISO 27001:2022 organises 93 controls into four themes.

A.5 — Organizational controls (37)

Policy, supplier and customer relationships, classification, threat intelligence, identity, contracts, evidence, monitoring, intelligence-driven response.

Control areaStatusWhere it lives
A.5.1 Information-security policy and topic-specific policiesYesTwelve internal policies covering the full Article 21(2) measure set; this trust pack is the publicly-stated extract.
A.5.7 Threat intelligencePartialManual review of CFCS / CERT-SE / ENISA bulletins; no automated TI feed yet.
A.5.9 Inventory of information and other associated assetsYesCodebase + dependency + service inventory shipped per-image at /sbom.cdx.json.
A.5.10 Acceptable useYesHR Security Policy §"Acceptable use" (internal).
A.5.12 Classification of informationYesPublic / Internal / Confidential / Customer-data classes named in the data-handling policy.
A.5.14 Information transferYesCustomer-data transfer rules in the DPA template; transit encryption documented in the Security Whitepaper.
A.5.15–A.5.18 Access control, identity, authentication, access rightsPartialPer-user accounts on SaaS; SSH-key authentication. Open: 2FA on SSH and every cloud console (R-ACCESS-01); per-user accounts on dev/prod hosts (R-PROD-02); aggregated audit logging (R-ACCESS-02).
A.5.19–A.5.23 Supplier and cloud-services relationshipsYesSub-processors list, DPA, supply-chain security policy (internal).
A.5.24–A.5.28 Incident managementYesCoordinated Vulnerability Disclosure + internal incident response policy + breach notification procedure with NIS2 Art.23 timing.
A.5.30 ICT readiness for business continuityPartialBusiness-continuity policy in place; first end-to-end recovery rehearsal scheduled (R-RECOVERY-01).
A.5.31–A.5.34 Legal, IP, privacy, identification of recordsYesPre-release License Terms, DPA, licence-policy (permissive-only) and data-handling policy (internal).
A.5.36–A.5.37 Compliance and documented operating proceduresYesControl matrix maps every applicable Annex A control to a policy + evidence reference; full matrix available under NDA.

A.6 — People controls (8)

Screening, terms, awareness, disciplinary, remote working, reporting.

ControlStatusWhere
A.6.1 Screening (background checks)PlannedOpen gap. Not done at current size; required before personnel hold standing administrator access to customer environments under the managed offering.
A.6.2 Terms and conditions of employmentYesConfidentiality + IP-assignment in every employment / contractor agreement (HR Security Policy).
A.6.3 Awareness, education, trainingPartialOnboarding briefing exists; annual refresher session is roadmap (R-PEOPLE-01).
A.6.4 Disciplinary processYesPer Danish labour law and the employment agreement.
A.6.5 Responsibilities after terminationYesLeaver checklist in the access-provisioning procedure: revoke SSH key, rotate shared credentials, close SaaS accounts.
A.6.6 Confidentiality / NDAYesConfidentiality clause in every employment / contractor agreement; mutual NDA available to enterprise customers on request.
A.6.7 Remote workingYesPersonnel laptops are full-disk encrypted and password-locked; access via Netbird overlay.
A.6.8 Information-security event reportingYesOn-call channel + security@bzrk.dev for personnel and external reporters.

A.7 — Physical controls (14)

Mostly inherited from suppliers with their own ISO 27001 / 27017 / 27018 certifications.

Control areaStatusWhere
A.7.1–A.7.4 Secure areas, perimeter, entry, monitoringInheritedInherited from Hetzner (ISO 27001, ISO 9001, ISO 14001, ISO 50001) for our datacenter and from Proton, GitHub for SaaS.
A.7.5–A.7.6 Protection from environmental threats / working in secure areasInheritedInherited from Hetzner.
A.7.7 Clear desk / clear screenYesPersonnel laptops auto-lock; HR Security Policy's acceptable-use clause.
A.7.8–A.7.14 Equipment siting, supporting utilities, cabling, maintenance, off-site, secure disposal, unattended user equipment, off-premisesInherited + YesDatacentre items inherited from Hetzner; personnel-equipment items in HR Security Policy and asset-management policy.

A.8 — Technological controls (34)

Endpoints, network, crypto, dev, monitoring, vulnerability management, backup, logging.

Control areaStatusWhere
A.8.1 User endpoint devicesPartialFull-disk encrypted, 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.
A.8.2 Privileged access rightsPartialOn-call announce-before-action; two-person rule for irreversible production-data ops. Per-user prod accounts open (R-PROD-02).
A.8.3–A.8.4 Information access restriction / source codeYesGitHub team-based RBAC; K8s ServiceAccount-per-service.
A.8.5 Secure authenticationPartialSSH-key + 2FA on Proton + GitHub. SSH 2FA enforcement is roadmap (R-ACCESS-01).
A.8.6 Capacity managementYesService-level metrics, alerting, admission control documented in the architecture docs.
A.8.7 Protection against malwareYesVendored toolchain neutralises registry-poisoning class; CI runs without public-network access; TruffleHog runs on the daily master security scan.
A.8.8 Management of technical vulnerabilitiesYesDaily dependency-advisory scanning across every ecosystem plus per-image SBOM scanning; a single advisory-exception register feeds all of them for consistency.
A.8.9 Configuration managementPartialTerraform + Helm baselines for VMs and K8s. Drift detection is roadmap.
A.8.10 Information deletionYesCustomer-data deletion at engagement end is documented in the data-handling policy and the DPA.
A.8.11 Data maskingN/ACustomer telemetry stays in customer environment; we do not mask, the customer chooses what to share.
A.8.12 Data leakage preventionPartialTruffleHog secrets detection on the daily master scan; standard egress monitoring on production.
A.8.13 Information backupPartialS3-as-trust-root model documented; first end-to-end recovery rehearsal scheduled (R-RECOVERY-01).
A.8.14 RedundancyInherited + PlannedInherited at the storage layer; cross-region replication on roadmap.
A.8.15–A.8.16 Logging / monitoring activitiesPartialPer-service logs; aggregated audit logging is roadmap (R-ACCESS-02).
A.8.17 Clock synchronizationYesNTP across the cluster.
A.8.18–A.8.19 Privileged utility programs / installation of software on operational systemsYesProduction access is gated; software installation on production hosts is via Bazel-built images, not interactive.
A.8.20–A.8.22 Network controls / network services / segregationYesNetbird overlay; per-service ServiceAccount; IP plan documented in deployment-architecture.
A.8.23 Web filteringN/ANot applicable at our scale.
A.8.24 Use of cryptographyYesCryptography policy with approved primitives (rustls + aws-lc-rs for TLS; AES-256-GCM / ChaCha20-Poly1305 for symmetric; Ed25519 / ECDSA P-256 for signatures).
A.8.25–A.8.31 Secure development, separation, change, test, outsourcedPartialSecure-development policy: compiler-enforced lints (no unwrap/panic/silent fallback in production), AI-agent secure-baseline guardrails, threat modelling on new external surfaces.
A.8.32 Change managementPartialPR-based with required automated CI checks; production change tracking via Helm + Terraform.
A.8.33 Test informationYesTest fixtures use synthetic data; the engineering rule against mock-database tests in production-divergent paths reduces the test-info risk.
A.8.34 Protection of information systems during auditYesAudits are remote-attestation-based at present; no production instrumentation by external auditors.

Statement of Applicability

We maintain an internal SoA: a row per Annex A control, marked applicable Y/N, with a justification and a reference to the implementing policy or evidence. The SoA is NDA available to enterprise customers under NDA on request to security@bzrk.dev.

The summary table on this page is not the SoA — it is a public extract for procurement reviewers. The SoA is the document an auditor opens first; it carries every control with its applicability decision and rationale.

Supplier inheritance

Several Annex A controls are satisfied through ISO-certified suppliers. Material inheritances:

SupplierTheir certificationsControls we inherit
Hetzner Online GmbHISO 27001, ISO 9001, ISO 14001, ISO 50001A.7 (physical) for our internal cluster
Proton AGISO 27001, SOC 2 Type II, GDPR-alignedA.5.14 / A.5.23 for email + credentials
GitHub, Inc. (Microsoft)ISO 27001, SOC 2 Type IIA.5.23 for source-code hosting

Their certificates are linkable from each provider's trust page; we keep the verified copies for buyer review on request.

Roadmap

Approximate sequencing if we elect to pursue certification, aligned with the planned managed-offering launch:

PhaseDurationOutput
Internal audit programme stand-up1 monthR-ISMS-01 (audit + review cadence), R-ISMS-02 (document control + competence matrix), R-ISMS-03 (continual improvement), R-ISMS-04 (interested-parties register), information-security objectives
Close roadmap items2–3 monthsItems still showing Partial or Planned in the clause and Annex A tables above, plus the "Planned for Managed Offering" grouping on the Security Roadmap.
First internal audit1 monthFindings register; close findings
Pre-audit readiness pack1 monthFinal SoA, management-review minutes
Stage 1 + Stage 2 with accredited body2–3 monthsCertificate

For the full per-item view across every framework — not only the ISO 27001 audit path — see the consolidated Security Roadmap. We have not booked an auditor. When we do, the typical accredited bodies for Nordic SaaS are BSI, DNV, A-LIGN, and Schellman.

How to ask for more

  • Public artifacts: this page, the Trust Overview, the Security Whitepaper, the filled CAIQ v4, and the DPA template.
  • Under NDA: the Statement of Applicability, the full control matrix, the internal policies (twelve of them) and procedures (five of them), the risk register, the supplier register, and the supplier-certificate copies.

Email security@bzrk.dev with what your procurement team needs and we will share what's appropriate under NDA.

Last reviewed

2026-05-05.