Service Catalog

1. Purpose

This Service Catalog satisfies Section 4.1 of the CISPE Code of Conduct, which requires that processing of personal data on behalf of a customer be either (i) governed by specific written instructions in the Service Contract, or (ii) governed by generic instructions documented by the processor in a predefined catalogue of services.

For each DanubeData service, this catalogue documents the categories of processing performed on Customer Data when the customer activates and uses the service in its default configuration. The customer's act of provisioning a service in the dashboard or via the API constitutes the customer's documented instruction to DanubeData to perform the processing described here. Specific deviations or additional instructions may be agreed in writing between the customer and DanubeData and recorded as an addendum to the Data Processing Agreement.

This catalogue is updated whenever a service is added, retired, or materially changed. The "Last updated" date at the top of this page reflects the most recent revision.

2. Common Properties (apply to all services)

• Processing role: DanubeData (IFAS Consult SRL) acts as a processor for Customer Data. The customer is the controller.
• Data location: All payload data is stored and processed in Hetzner data centres in Falkenstein and Nuremberg, Germany (EEA). Supporting services that may transfer data outside the EEA are listed in /sub-processors with the applicable safeguards.
• Sub-processors: Hetzner Online GmbH (infrastructure). Service-specific additional sub-processors are listed under each service below. The complete list with transfer mechanisms is at /sub-processors.
• Security baseline: Encryption in transit (TLS 1.2/1.3) and at rest (AES-256), per-tenant logical isolation, audit logging, default-deny network policies. Service-specific security features are listed under each service below. See the CISPE Annex A mapping for detail.
• Retention: Data retained while the service is active. On service deletion, data is deleted within 30 days (DPA Section 11). Backup/snapshot retention follows the customer's configured policy (default 30 days).
• What DanubeData does NOT do with Customer Data: DanubeData does not access, mine, profile, sell, share with advertisers, or use Customer Data for its own purposes. Access by DanubeData personnel occurs only as necessary to operate the service or in response to a customer support request, and is logged.

3. VPS Instances

• Description: KubeVirt-based virtual machines with dedicated or shared CPU, NVMe storage, public IPv4 and IPv6.
• Default processing on Customer Data: storage on encrypted volumes; transmission via the customer's chosen network configuration; virtualised CPU/memory execution; on-demand and scheduled snapshot; offsite backup (Velero) where the customer enables it.
• Default access pattern: the customer holds the SSH credentials and operates the VM. DanubeData personnel do not log in to customer VMs except at the customer's express request (e.g., a support ticket explicitly granting access).
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: firewall rules, VPC private networking, snapshot schedule, swap-disk encryption, BYOE via LUKS inside the VM.

4. Managed Databases (MySQL, PostgreSQL, MariaDB)

• Description: Managed relational database engines with optional read replicas, automated snapshots, and a separate reader endpoint.
• Default processing on Customer Data: storage on encrypted persistent volumes; transmission over TLS-enforced connections; query execution by the database engine; replication to customer-configured replicas; periodic snapshot for restore.
• Default access pattern: the customer holds the database admin credentials. DanubeData personnel do not connect to customer databases as the data plane administrator except at the customer's express request.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: IP allowlist, TLS certificate (auto or BYO), parameter group, replica topology, snapshot schedule.

5. Cache Instances (Redis, Valkey, Dragonfly)

• Description: Managed in-memory data stores with optional read replicas.
• Default processing on Customer Data: in-memory storage with optional disk persistence; transmission over TLS; replication to read replicas if configured.
• Default access pattern: the customer holds the AUTH password. DanubeData personnel do not connect to customer cache instances except at the customer's express request.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: IP allowlist, TLS, persistence options, parameter group, eviction policy.

6. Object Storage (S3-compatible)

• Description: S3-compatible object storage (Ceph RGW or Hetzner Object Storage), per-team buckets, lifecycle rules, versioning, object lock.
• Default processing on Customer Data: storage with erasure coding or replication; transmission over TLS; lifecycle and versioning operations as configured by the customer; cross-region copy where the customer requests it.
• Default access pattern: the customer issues per-team access keys and grants programmatic access. DanubeData personnel do not access bucket contents.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: bucket policy, ACL, versioning, lifecycle rules, object lock (legal hold and retention), SSE-S3 / SSE-KMS / SSE-C.

7. Serverless Containers (Rapids)

• Description: Knative-based scale-to-zero container deployments. Three deploy modes: pre-built Docker image, Git repository (build with buildpacks or Dockerfile), or ZIP upload.
• Default processing on Customer Data: container image build and storage in the platform registry; storage of source from the customer's Git repository when that mode is selected; autoscaled execution; HTTPS request routing; access-log retention.
• Default access pattern: the customer's container processes its own data. DanubeData personnel do not exec into customer containers except at the customer's express request.
• Service-specific sub-processors: none beyond the common baseline. If the customer connects an external Git repository hosted on GitHub or another provider, that provider remains a controller for the source code stored on its platform.
• Customer-controlled features: environment variables, secrets, scaling bounds, custom domain with TLS, build retry, port restrictions.

8. Static Sites

• Description: Build and host static websites from a Git repository or ZIP upload. Custom domain with TLS.
• Default processing on Customer Data: source build (Kaniko); asset storage in object storage; HTTPS delivery; access-log retention with visitor IP and request metadata.
• Default access pattern: deployment is automated from the customer's source. DanubeData personnel do not modify deployed assets except for emergency content takedown in response to a verified abuse complaint.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: custom domain, build commands, environment variables, publish directory, redirect rules.

9. Managed Applications

• Description: Pre-configured deployments of selected open-source applications (e.g., n8n, WordPress, Ghost) on managed infrastructure with in-place upgrades and pre-upgrade snapshots.
• Default processing on Customer Data: storage of application data on encrypted volumes; transmission over TLS; periodic snapshot for restore; pre-upgrade snapshot retained for the rollback window (default 7 days).
• Default access pattern: the customer is the application administrator. DanubeData personnel do not log in to the customer's application except at the customer's express request.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: application version selection, in-place upgrade timing, rollback within the rollback window, custom domain, snapshot schedule.

10. Storage Share (Nextcloud)

• Description: Managed file storage and collaboration suite based on Nextcloud, with file sharing, calendaring, contacts, and optional collaborative document editing.
• Default processing on Customer Data: storage of files, calendar entries, contacts, and shared metadata on encrypted volumes; transmission over TLS; anti-malware scanning of uploaded files (ClamAV); periodic backup.
• Default access pattern: the customer is the Nextcloud administrator. DanubeData personnel do not access user files or messages except at the customer's express request or as required to remediate a confirmed security incident.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: users, groups, sharing policy, app catalogue, custom domain, two-factor authentication for end users.

11. Queue Instances (RabbitMQ)

• Description: Managed message queue / broker supporting AMQP 0-9-1, MQTT, and STOMP protocols.
• Default processing on Customer Data: in-memory and on-disk message queueing; transmission over TLS; routing and brokering as configured by the customer.
• Default access pattern: the customer holds the broker credentials and the management UI password. DanubeData personnel do not consume customer messages.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: exchanges, queues, bindings, virtual hosts, users and permissions, TLS configuration.

12. Volumes & Snapshots

• Description: Persistent block storage attached to VPS instances. Manual and scheduled snapshots.
• Default processing on Customer Data: storage on encrypted persistent volumes; snapshot to point-in-time copies retained per the customer's policy.
• Default access pattern: volume contents are accessed only by the attached VM. DanubeData personnel do not mount customer volumes outside the VM.
• Service-specific sub-processors: none beyond the common baseline.
• Customer-controlled features: volume size, attachment, snapshot schedule, manual snapshot, snapshot deletion.

13. Supporting Customer-Account Services

The following processing activities support the customer relationship itself rather than the customer's workloads. For these, DanubeData acts as a controller, not a processor. They are described in the Privacy Policy and listed here for completeness:

• Account registration and authentication (email, password hash, optional 2FA / passkey, optional OAuth identifiers).
• Billing and invoicing (Stripe sub-processor for payment processing).
• Customer support tickets.
• Transactional email (MailerSend sub-processor).
• Service announcements and security alerts.
• Aggregate, non-identifying usage analytics for capacity planning.

14. Customisation and Specific Instructions

Where a customer requires processing that deviates from the default scope described above (for example, restricted personnel access, additional encryption, custom retention, exclusion of a specific sub-processor, or a customer-specified data-handling protocol), the customer may submit specific written instructions to dpo@danubedata.ro. Accepted specific instructions are recorded as a written addendum to the DPA. DanubeData reserves the right to charge for the implementation of specific instructions that materially differ from the default Service Catalogue.

15. Updates to the Service Catalog

Material changes to the Service Catalogue (addition or retirement of services, changes to default processing scope, addition of sub-processors, changes affecting transfer mechanisms) are communicated to customers by email and dashboard banner at least 30 days in advance, in line with the sub-processor change-notification commitment. Non-material editorial changes are reflected in the "Last updated" date.

16. Contact

For questions about this Service Catalogue, including specific-instruction requests, please contact dpo@danubedata.ro.