Incident Response & Data Breach Policy

1. Introduction & Purpose

This Incident Response & Data Breach Policy describes the procedures DanubeData follows to identify, classify, respond to, and recover from security incidents, including personal data breaches as defined under the General Data Protection Regulation (GDPR). It forms part of DanubeData's broader information security management system and is designed to satisfy the requirements of CISPE Code of Conduct Section 4.9 (Security Incident Management).

The purpose of this policy is to:

• Establish a structured and repeatable process for managing security incidents across all DanubeData services and infrastructure
• Ensure timely detection, containment, and resolution of security incidents to minimise impact on customers and their data
• Define clear notification obligations and timelines in compliance with GDPR Articles 33 and 34
• Provide transparency to customers regarding how DanubeData handles incidents that may affect the confidentiality, integrity, or availability of their data
• Support continuous improvement of security posture through systematic post-incident analysis

This policy applies to all DanubeData services, including VPS Instances, Managed Databases, Cache Instances, Object Storage, Serverless Containers (Rapids), Static Sites, Managed Applications, and Storage Share, as well as the underlying Kubernetes-based infrastructure, control plane components, and administrative systems on which they operate.

DanubeData implements a comprehensive security incident management policy covering the full incident lifecycle: identification, classification, response, notification, remediation, and post-incident review. All DanubeData personnel, contractors, and third parties with access to DanubeData systems are bound by this policy.

2. Incident Classification

Security incidents are classified according to their severity and potential impact on service availability, customer data, and infrastructure integrity. The classification determines the response priority, escalation path, and notification requirements.

Incident classification may be escalated or de-escalated as additional information becomes available during the investigation. Any incident initially classified as P3 or P4 that is subsequently determined to involve personal data is immediately escalated to P1 or P2 as appropriate.

3. Incident Response Phases

DanubeData follows a structured incident response process comprising five phases. Each phase has defined objectives, activities, and outputs to ensure consistent and effective incident handling.

3.1 Detection & Identification

The detection phase aims to identify security incidents as early as possible through a combination of automated and manual mechanisms:

• Automated monitoring: Prometheus-based metrics collection with threshold-based alerting across all infrastructure components, including CPU, memory, disk, network, and application-level health indicators
• Real-time health checks: Continuous health probes on all customer-facing service components, with automated escalation when checks fail repeatedly
• Application error monitoring: Bugsnag integration for real-time detection and alerting of application-level errors and exceptions across all platform services
• Customer reports: Security incidents reported by customers via support tickets are triaged and escalated according to the classification framework above
• Third-party notifications: Threat intelligence feeds, vendor security advisories, and notifications from upstream providers (e.g., Hetzner) are monitored and assessed for relevance
• Anomaly detection: Analysis of audit logs, access patterns, and network flows to identify deviations from established baselines that may indicate a security event

3.2 Containment

Once an incident is confirmed, immediate containment measures are enacted to prevent further damage and limit the scope of impact:

• Immediate threat containment: Network isolation of affected systems, revocation of compromised credentials, and blocking of malicious IP addresses or traffic patterns
• Service isolation: If necessary, affected services or tenant namespaces are isolated to prevent lateral movement or propagation to other customers or infrastructure components
• Evidence preservation: System state, logs, network captures, and other forensic artefacts are preserved before any remediation actions that could alter evidence
• Initial status communication: The incident response team and affected internal stakeholders are briefed on the nature, scope, and current status of the incident

3.3 Investigation & Analysis

A thorough investigation is conducted to determine the root cause, full scope, and impact of the incident:

• Root cause analysis: Systematic identification of the underlying vulnerability, misconfiguration, or attack vector that enabled the incident
• Impact assessment: Determination of the full scope of affected systems, services, and data, including whether customer data or personal data was compromised
• Affected customer identification: Identification of all customers whose services or data may have been affected by the incident
• Timeline reconstruction: Reconstruction of the incident timeline from audit logs, monitoring data, and forensic evidence to understand the sequence of events
• Personal data assessment: Specific determination of whether personal data was affected, and if so, the nature, volume, and sensitivity of the data involved, to inform GDPR notification obligations

3.4 Remediation & Recovery

The remediation phase focuses on eliminating the root cause and restoring normal service operations:

• Vulnerability remediation: Patching of identified vulnerabilities, correction of misconfigurations, and implementation of additional controls to address the root cause
• Service restoration: Systematic restoration and verification of affected services, including integrity checks to confirm that systems are clean and operating correctly
• Enhanced monitoring: Elevated monitoring thresholds and additional alerting during the recovery period to detect any recurrence or related activity
• Customer communication: Proactive status updates to affected customers throughout the recovery process, including expected timelines and any actions required on their part

3.5 Post-Incident Review

Every incident classified as P1 or P2 undergoes a formal post-incident review. P3 incidents are reviewed at the discretion of the security team:

• Post-mortem: Conducted within 5 business days of incident resolution, documenting the timeline, root cause, impact, response effectiveness, and lessons learned
• Root cause documentation: A permanent record of the root cause and contributing factors is maintained in the incident register
• Corrective actions: Specific, measurable corrective actions are identified, assigned, and tracked to completion
• Preventive measures: Systemic improvements to infrastructure, processes, or monitoring are implemented to prevent recurrence of similar incidents
• Policy updates: Security policies, procedures, and response playbooks are updated as needed to reflect lessons learned

4. Data Breach Response (GDPR-Specific)

4.1 What Constitutes a Personal Data Breach

Under GDPR Article 4(12), a personal data breach is defined as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed. This encompasses three categories:

• Confidentiality breach: Unauthorised or accidental disclosure of, or access to, personal data
• Integrity breach: Unauthorised or accidental alteration of personal data
• Availability breach: Accidental or unauthorised loss of access to, or destruction of, personal data

As an infrastructure provider, DanubeData processes customer data in its capacity as a data processor. Customers (data controllers) determine the nature and categories of personal data stored within their DanubeData services. DanubeData does not routinely inspect, access, or classify the content stored by customers.

4.2 Breach Notification Timeline

DanubeData is committed to prompt notification in the event of a confirmed or suspected personal data breach. The following timeline governs our notification process:

Where the full scope of a breach cannot be determined within the initial notification timeframe, DanubeData will provide preliminary information and supplement it with additional details as the investigation progresses, in accordance with GDPR Article 33(4).

4.3 Breach Notification Content

When notifying customers of a personal data breach, DanubeData will provide the following information to the extent known at the time of notification:

• Nature of the breach: A clear description of what occurred, including the type of security incident and the attack vector or cause (where determined)
• Categories and volume of data affected: The categories and approximate number of data records concerned, to the extent that DanubeData can determine this from the infrastructure and logs available
• Likely consequences: An assessment of the likely consequences of the breach for affected data subjects, based on the nature and sensitivity of the data involved
• Measures taken: A description of the measures taken or proposed by DanubeData to address the breach, including measures to mitigate its possible adverse effects
• Contact point: The name and contact details of the Data Protection Officer or other contact point from whom further information can be obtained
• Customer recommendations: Specific recommendations for customers to mitigate potential impact on their end users and data subjects, including credential rotation, access review, or data subject notification guidance

4.4 Breach Documentation

DanubeData maintains comprehensive documentation of all security incidents in accordance with GDPR Article 33(5):

• Incident register: All incidents, regardless of severity, are documented in the centralised incident register, recording the facts of the breach, its effects, and the remedial actions taken
• Evidence chain: A complete chain of evidence is maintained for each incident, including preserved logs, forensic artefacts, and communications, suitable for regulatory and legal purposes
• Retention: Incident documentation is retained in accordance with GDPR requirements and applicable data retention policies, for a minimum period sufficient to support any regulatory investigation or legal proceedings
• Regulatory availability: Incident documentation is available to competent supervisory authorities upon lawful request, enabling them to verify compliance with GDPR obligations

5. Customer Communication

DanubeData maintains multiple communication channels to ensure customers are informed promptly and effectively during and after security incidents:

• Real-time status page: The public status page at status.danubedata.ro provides real-time information on service availability, ongoing incidents, and scheduled maintenance windows
• Email notifications: Account owners and team administrators receive email notifications for incidents affecting their services, delivered via the platform notification system
• In-platform notification centre: The DanubeData dashboard displays active incident notifications and historical alerts within the notification centre
• Support ticket updates: For incidents reported via support tickets, customers receive ongoing updates within the ticket thread until resolution
• Post-incident reports: Detailed post-incident reports are made available upon request to affected customers, documenting the timeline, root cause, impact, and corrective actions
• Notification preferences: Customers can configure their preferred notification channels (email, in-app, webhook) through the platform settings to ensure they receive incident communications via the channels most appropriate for their operational needs

6. Roles & Responsibilities

The following roles are defined within DanubeData's incident response structure. Each role carries specific responsibilities to ensure a coordinated and effective response:

Role assignments are documented and reviewed regularly. Backup personnel are designated for each role to ensure coverage during absences. All incident response team members receive role-specific training.

7. Cooperation with Customers

DanubeData recognises its obligations as a data processor to assist customers in fulfilling their own security incident and data breach obligations. We commit to the following cooperation measures:

• Mutual incident reporting: DanubeData will cooperate with customers who inform us of a data breach originating from their use of our services, assisting in containment and investigation to the extent that DanubeData infrastructure is involved
• GDPR Article 33 support: DanubeData provides preliminary information to affected customers within the timelines specified in Section 4.2 of this policy, enabling customers to meet their obligation to notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach
• Log and audit trail access: Subject to applicable access controls and the terms of the Data Processing Agreement, DanubeData supports customer investigations by providing relevant log data, audit trails, and infrastructure-level information that may assist in determining the scope and impact of an incident
• Coordinated remediation: Where an incident requires remediation actions on both the DanubeData infrastructure and the customer's application layer, DanubeData coordinates with the customer to ensure that remediation activities are aligned and effective
• Regulatory cooperation: DanubeData assists customers in responding to inquiries from supervisory authorities related to incidents affecting DanubeData infrastructure, providing factual information and documentation as appropriate

8. Testing & Continuous Improvement

DanubeData is committed to ensuring the ongoing effectiveness of its incident response capabilities through regular testing, review, and improvement:

• Annual incident response drills: Full-scale incident response exercises are conducted annually, including tabletop exercises that simulate realistic security scenarios and technical simulations that test the end-to-end response process
• Quarterly procedure reviews: Incident response procedures, playbooks, and escalation paths are reviewed quarterly to ensure they remain current and effective in light of infrastructure changes, new services, and evolving threats
• Lessons learned integration: Findings and corrective actions from actual incidents are systematically integrated into response procedures, monitoring configurations, and preventive controls
• Threat landscape updates: Response playbooks are regularly updated to address emerging threat categories, new attack techniques, and changes in the regulatory environment
• Team training: All incident response team members receive regular training updates, including scenario-based exercises, tool proficiency training, and updates on regulatory requirements

9. Contact

To report a security incident, suspected data breach, or for inquiries related to this policy:

Security Incidents: security@danubedata.ro
Data Breach Reports: dpo@danubedata.ro
General Support: support@danubedata.ro

IFAS Consult SRL
Satu Mare, Romania
CUI: RO46614360 | J30/870/2022

Security incidents should be reported to security@danubedata.ro as soon as possible. When reporting an incident, please include a description of the event, the time of discovery, affected services, and any actions already taken.