Legal
CISPE Annex A — Security Responsibilities
Mapping of each CISPE Code of Conduct Annex A security responsibility to the corresponding DanubeData control, configuration, or operational practice.
Last updated: July 3, 2026
1. Purpose
This document maps every security responsibility set out in Annex A of the CISPE Code of Conduct for Cloud Infrastructure Service Providers to the specific technical and organisational control implemented by DanubeData. It serves as evidence for Section 4.3 (Security) and Section 4.6 (Demonstrating Compliance) of the Code, and supports the Monitoring Body's verification activities.
This document complements (and does not replace) the Security Program, the Shared Responsibility Model, the Risk Management & Business Continuity framework, and the Information Security Program. The control responsibilities marked "Customer" in Annex A are addressed in the Shared Responsibility Model.
Where a control is implemented through a sub-processor, the relevant sub-processor and its certifications are identified in the Sub-Processors list. The principal infrastructure provider, Hetzner Online GmbH, holds ISO/IEC 27001 certification for the Falkenstein and Nuremberg data centres used by DanubeData.
2. Security Domains Covered
CISPE Annex A organises security responsibilities into the following domains. Each is addressed in the corresponding section of this document:
- Physical and environmental security (Section 3)
- Network security (Section 4)
- Access management (Section 5)
- Personnel security (Section 6)
- Operational security (Section 7)
- Cryptography and key management (Section 8)
- Data isolation and multi-tenancy (Section 9)
- Incident management (Section 10)
- Change management (Section 11)
- Business continuity and disaster recovery (Section 12)
- Logging, monitoring, and auditability (Section 13)
- Vulnerability and patch management (Section 14)
3. Physical and Environmental Security
Physical security is delivered by Hetzner Online GmbH, who operate the Falkenstein and Nuremberg data centres housing all DanubeData production infrastructure. DanubeData has no physical premises that store customer data.
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Restricted physical access to facilities | Hetzner DC: 24/7 security staff, biometric access, video surveillance, mantraps, undisclosed addresses | Hetzner ISO/IEC 27001 certification; Hetzner DSGVO statement |
| Environmental controls (power, cooling, fire) | Redundant UPS + diesel generators; N+1 cooling; VESDA fire detection; pre-action sprinklers | Hetzner facility specification; ISO 50001 (energy management) |
| Secure media disposal | Cryptographic erasure of LVM volumes on customer deletion; physical disk destruction by Hetzner per their procedure | Hetzner data deletion policy; DanubeData wipe procedure (internal) |
4. Network Security
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Perimeter firewalling around the cloud infrastructure | Hetzner upstream filtering + per-host iptables/nftables; Cilium eBPF datapath at the cluster perimeter; default-deny ingress | Cilium policy manifests (GitOps); host firewall configuration scripts |
| Per-instance / per-service firewall available to customers | Per-VPS firewall via the dashboard (Cilium NetworkPolicy / nftables); per-database/cache IP allowlist; per-bucket access policy | Customer dashboard — Firewall section; Firewalls docs |
| DDoS protection | Hetzner volumetric DDoS scrubbing at the network edge; in-cluster rate limits at ingress | Hetzner DDoS Protection product page; nginx-ingress rate-limit annotations |
| Network segmentation between tenants | Per-tenant Kubernetes namespace (tenant-{team_id}); Cilium L3-L7 NetworkPolicies enforcing default-deny between namespaces; per-VPS NetworkAttachmentDefinition with dedicated IP | GitOps Cilium policy YAML; Kubernetes namespace audit |
| Encryption in transit | TLS 1.2 / 1.3 enforced on all customer-facing endpoints; Let's Encrypt automatic certificates; HSTS; mTLS for inter-cluster control plane | cert-manager Issuer manifests; nginx config; SSL Labs A+ rating |
5. Access Management
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Strong authentication for customer accounts | Email + password (Argon2id); TOTP 2FA; WebAuthn passkey support; password complexity enforced | Laravel Fortify config; PasskeyController; user settings UI |
| Strong authentication for administrator/admin accounts | 2FA/passkeys mandatory for the administrator account; SSH key + signed CA for server access; jump host with logged access (SSH logs) | Internal SSH CA configuration; onboarding checklist for any future contractor |
| Role-based access control | Per-team RBAC (owner, admin, member); Kubernetes RBAC scoped to tenant namespaces; least-privilege ServiceAccounts | Jetstream team policies; Kubernetes Role/RoleBinding manifests |
| Restricted administrator access to customer data | No standing access to customer workloads; just-in-time elevation logged; administrator actions on customer resources written to audit_logs with IP and request ID | app/Models/AuditLog.php; CLAUDE.md kubectl safety rules |
| Prompt revocation on personnel offboarding | Offboarding checklist: revoke SSO, rotate Vault root token, remove SSH CA principals, rotate shared secrets, audit log review | Internal personnel offboarding SOP |
| API access control | Sanctum bearer tokens; per-token scoped abilities; rotation supported; rate limiting per token | API Token settings UI; Laravel Sanctum config |
6. Personnel Security
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Confidentiality obligations on personnel | The administrator is bound by statutory and contractual confidentiality duties; any future contractor with access to customer data signs a confidentiality/NDA clause in their engagement contract before access is granted, with obligations surviving termination | Contractor NDA/MSA template; ISMS people security policy |
| Background screening proportional to role | The administrator's identity and directorship are matters of Romanian public record; any future hire or contractor with production access completes identity verification, a professional reference check, and a clean criminal record check (Romanian "cazier") before access is granted | Trade Register entry (J30/870/2022); ISMS people security policy |
| Security awareness training | Recorded, self-directed annual training programme covering data protection, phishing, secret hygiene, incident reporting; any future contractor completes an equivalent briefing before access is granted | records/trainings.md |
7. Operational Security
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Hardened operating system baseline | Minimal Debian/AlmaLinux base; SSH password auth disabled; root login disabled; unnecessary services removed; CIS-aligned sysctl | Node provisioning Ansible/cloud-init; sysctl files in /etc/sysctl.d/ |
| Anti-malware on customer-facing services | ClamAV on Storage Share (Nextcloud); container image scanning prior to deploy | Storage Share Helm values; CI image scan reports |
| Secrets management | HashiCorp Vault (auto-unseal via a Transit-backed seal Vault); ExternalSecret CRDs reference Vault paths rather than embedding secrets in manifests | Vault deployment manifests; Vault Secret Migration Plan |
8. Cryptography and Key Management
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Encryption at rest | LUKS-encrypted host volumes; SSE-S3 / SSE-KMS for object storage backed by Vault Transit; TopoLVM volumes on encrypted PVs | Node provisioning scripts; CephObjectStore SSE config; Vault Transit policy |
| Strong cryptographic algorithms | AES-256-GCM for data at rest; TLS 1.2 / 1.3 with PFS cipher suites; Argon2id for password hashing; Ed25519 for SSH | nginx config; Laravel hash config |
| Key management lifecycle | Keys generated and stored in Vault; periodic rotation; cert-manager rotates TLS certs ~60 days before expiry; Vault CA rotation procedure documented | cert-manager Certificate manifests; Vault TLS Certificate Rotation runbook |
| Customer-controlled encryption | Customers may bring their own encryption (BYOE) at the application or filesystem layer within their VPS / containers; SSE-C supported on object storage | Object storage docs; VPS LUKS guide |
9. Data Isolation and Multi-Tenancy
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Logical isolation of customer data | Per-team Kubernetes namespace; per-team object-storage bucket prefix (dd-{team_id}-{name}); per-team Vault path; per-team database credentials | TenantResourceQuotaService; bucket naming code; Vault per-tenant policy |
| Compute isolation | VPS instances run in KubeVirt VMs (KVM / QEMU); managed services run in containers with cgroup isolation, seccomp, no privileged escalation; dedicated CPU plans available | VirtualMachine manifests; Pod SecurityContext defaults |
| Storage isolation | Per-PVC TopoLVM volumes on dedicated logical volumes; Ceph RGW per-tenant access keys; no shared mount points across tenants | TopoLVM StorageClass; Ceph RGW user policy |
10. Incident Management
See the Incident Response Policy for the full process. Annex A specifically requires:
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Documented incident response policy | Published Incident Response Policy with severity classes P1/P2/P3, timelines, communication SOP | Legal/IncidentResponse.vue |
| Customer breach notification | Customer notified without undue delay (within 24 hours of confirmation) via email and status page; notification covers nature, consequences, remediation, contact | DPA Section 8; Incident Response policy |
| Cooperation with controllers under GDPR Art. 33-34 | DPO is the named point of contact (dpo@danubedata.ro); we provide the customer with all preliminary information available to support their notification to the supervisory authority | DPA Section 8 |
11. Change Management
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Controlled deployment of changes | All infrastructure changes via GitOps (ArgoCD); every change goes through a recorded self-review checklist with an automated CI test run (paratest) before merge; staged rollout. Making this a mechanically enforced branch-protection gate is planned for July 2026. | GitOps repository; ArgoCD Application manifests; commit/PR history |
| Maintenance window communication | Planned maintenance announced on status.danubedata.ro at least 72 hours in advance; email to affected customers | Status page; SLA document |
| Customer notification of material security changes | Email + dashboard banner notification at least 30 days in advance for any change that materially reduces security posture; immediate retroactive notification if change was urgent (e.g., to mitigate active vulnerability) | Notification SOP; banner:create artisan command |
12. Business Continuity and Disaster Recovery
Detailed in the Risk Management & Business Continuity document. Annex A requires:
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Documented BCP/DR plan | Published Risk Management & Business Continuity document with per-service RTO/RPO matrix | Legal/RiskManagement.vue |
| Backup strategy (3-2-1) | Local NVMe + LVM/Ceph snapshots + Velero offsite backups to S3 | Velero schedule manifests; snapshot schedule config |
| BCP testing | Continuity testing programme — annual DR exercise, quarterly restore verification and tabletop exercises; first recorded cycle scheduled for 2026 | DR exercise records (internal), once the first cycle is complete |
13. Logging, Monitoring, and Auditability
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Audit logging of customer-facing actions | All user actions on resources written to audit_logs: actor, action, resource, before/after, IP, user agent, request ID | app/Models/AuditLog.php; customer Audit Logs UI |
| Audit logging of administrator access to customer data | Administrator actions on customer resources logged with the same schema, marked source=staff; SSH access via signed CA produces session log on jump host | AuditLog source field; SSH CA session logs |
| Centralised log collection | Loki + Alloy collects all platform logs; Prometheus + Alertmanager + Grafana for metrics and alerting; 30-day retention default | Loki/Alloy Helm values; Grafana dashboards |
| Customer-accessible audit log | Audit Logs UI in the customer dashboard surfaces all actions on the team's resources | resources/js/Pages/AuditLogs/Index.vue |
14. Vulnerability and Patch Management
| Annex A Requirement | DanubeData Control | Evidence |
|---|---|---|
| Continuous vulnerability scanning | Container image CVE scanning at build time; OS package scanning on production nodes; Composer/npm dependency audit in CI | CI scan reports; node patch reports |
| Patch SLA by severity | Critical (internet-facing): 72h of disclosure; all other Critical/High: 30d; Medium: 30d; Low: next release window | Security policy; /.well-known/security.txt |
| Vulnerability disclosure programme | Public reporting via security@danubedata.ro; RFC 9116 security.txt published; safe-harbour for good-faith research | /.well-known/security.txt |
| Independent penetration testing | Independent third-party security testing, including penetration testing, is commissioned when risk warrants; continuous image and dependency CVE scanning and OS patch monitoring provide ongoing coverage between engagements. Findings are shared with customers on request under NDA. | CVE/advisory triage log; pentest engagement and report once commissioned (available on request to customers) |
15. Verification
DanubeData submits its services to verification by the official CISPE Monitoring Body. The Monitoring Body uses this Annex A mapping, together with the supporting evidence referenced above, to verify the operational effectiveness of the controls. Verification reports are made available to customers on request, subject to the confidentiality terms in the Service Contract.
Customers wishing to request the most recent verification report or to discuss audit arrangements should contact dpo@danubedata.ro.
16. Document Control
This Annex A mapping is reviewed at least once per year and following any material change to the platform, the threat landscape, or the CISPE Code of Conduct. The "Last updated" date at the top of this page reflects the most recent revision.
Owner: DanubeData Security Lead. Approval: IFAS Consult SRL management. Distribution: public.
Questions about this policy?
If you have any questions or concerns, please contact our legal team.
Contact Us