The single consolidated public view of security and compliance items
Berserk ApS has named openly and is working through. Each row links to the
internal risk-register ID where applicable; the full risk register
itself is available to enterprise customers under NDA on request to
security@bzrk.dev.
We name these openly because procurement teams ask, and because naming a gap in writing is the lightest-weight commitment to closing it. Items are grouped into work with fixed target quarters and work that becomes a prerequisite at managed-offering launch.
For the buyer-readiness summary see the Trust Overview. For the framework-by-framework position see GDPR, NIS2, ISO 27001 Readiness, and the filled CAIQ v4.
Open risks/gaps with named target deadlines. The recurring-meeting cadence (annual security awareness, DR rehearsal, internal audit, management review) lives on our internal compliance calendar and isn't roadmap material — only the control gaps that need engineering or governance work to close are listed here.
| Item | Why it matters | Target | Risk ID |
|---|---|---|---|
| Enforce MFA for SaaS providers and extend SSO use for internal services | Annex A.5.17 / NIS2 Art. 21(2)(j); SSH access is gated by VPN + key-based auth + FDE on the originating laptop, so the residual control gap is on web-admin surfaces, not SSH. | Q3 2026 | R-ACCESS-01 |
| On-board existing inventory to MDM | Annex A.8.1 / IVS-09 / UEM; the MDM tooling is operational, but enrolment of every existing laptop and host is the remaining rollout step. | Q3 2026 | R-PROD-06 |
| Database password rotation cadence | Annex A.8.24; closes a documented credential-hygiene gap. | Q4 2026 | R-CRYPTO-01 |
These items become prerequisites the moment we ship the planned managed offering. They do not have fixed dates today; target dates will be set as managed-offering launch sequencing firms up.
| Item | Why it matters | Risk ID |
|---|---|---|
| Native authn/authz across the product API surfaces (ingest + query + CLI transport) | Annex A.5.16–A.5.18 / A.8.5 / NIS2 Art. 21(2)(i)(j); today the self-hosted product expects the customer to terminate at an authenticated ingress, which is a viable answer for self-hosted but not for the managed offering. Native authn/authz becomes the default at managed launch. | R-AUTH-01 |
| K8s control-plane encryption-at-rest | Annex A.8.13; expected of cloud-service providers under NIS2 Annex I §8. | R-PROD-01 |
| Per-user accounts on dev/prod machines | Annex A.5.16 / A.8.2; eliminates shared-root admin path. | R-PROD-02 |
| Configuration drift detection | Annex A.8.9; complements Terraform + Helm baselines. | R-PROD-03 |
| SOPS for secret encryption at rest in git | Annex A.8.24; complements the ProtonPass + sealed-secrets path. | R-PROD-04 |
| Aggregated audit logging across personnel access | Annex A.8.15–A.8.16; converts per-host SSH logs into a reviewable audit trail. | R-ACCESS-02 |
| Automated threat-intelligence feed | Annex A.5.7; replaces manual review of CFCS / CERT-SE / ENISA bulletins. | R-DETECT-01 |
| SIEM / network-event correlation (host-event collection done; correlation layer outstanding) | Annex A.8.15–A.8.16; host-event collection is already in place via centralised endpoint monitoring on personnel laptops and production hosts; outstanding work is the cross-system correlation layer. | R-DETECT-03 |
| Log integrity / immutable storage | Annex A.8.15. | R-DETECT-04 |
| Tamper-evident segment files (cryptographic chunk hashing + signed segment index) | Today CRC-32 chunk checksums detect bit-rot but are not sufficient for tamper-detection. A signed-hash chain over segment chunks lets a customer (and us, during a forensic engagement) prove the on-disk telemetry has not been altered after write. | R-DETECT-05 |
| Cross-region replication for storage | Annex A.8.14; required redundancy for managed-offering durability claims. | R-RECOVERY-02 |
| Per-service authentication on the customer-data plane (mTLS, SPIFFE/SPIRE, scoped service tokens, or equivalent) — managed-offering only | Lateral-movement hardening for managed prod; today's self-hosted product is operated by the customer over their own cluster network and does not carry this risk. NIS2 Article 21 is risk-based and proportional — it does not name mTLS specifically — but a managed telemetry service is expected by buyers + auditors to carry an east-west service-authentication story. | R-NET-01 |
| External penetration test | Annex A.8.29; expected by buyers once the managed offering is live. | R-TVM-01 |
| Background screening on personnel with standing customer-environment access | Annex A.6.1; required before standing administrator access under the managed offering. | R-PEOPLE-02 |
| Sub-processor list re-evaluation at managed-offering launch | Annex A.5.19–A.5.21; reflects the new supply chain. | R-SUPPLY-02 |