CVD Policy – Coordinated Vulnerability Disclosure Policy

1. Preamble

1.1. General principles

This policy describes our process for the Coordinated Disclosure of Vulnerabilities (Coordinated Vulnerability Disclosure, CVD). It sets out how vulnerabilities may be reported, which timelines apply and what reporters can expect from us.

What you can expect from us:

• We treat every vulnerability report confidentially.
• We disclose personal data to third parties only with your explicit consent.
• We acknowledge receipt of your report within a defined period and respond within 5 working days.
• We will support you as a trusted point of contact throughout the entire process.
• We will not initiate legal action against you provided the conditions set forth in Section 6 of this CVD policy are met.

What we expect from you:

• You do not exploit the discovered vulnerability maliciously and cause no damage beyond the report itself.
• You do not conduct attacks such as social engineering (e.g. phishing), (distributed) denial-of-service, brute-force attacks or physical attacks.
• You do not manipulate, compromise or alter third-party systems or data.
• You do not offer tools for vulnerability exploitation.
• You do not submit results of automated scans without explanatory documentation – such submissions do not constitute valid vulnerability reports.
• The absence of contact data does not prevent processing but may affect prioritisation. The use of an anonymous reporting channel does not per se justify an assumption of a lack of good faith.
• You provide valid contact details (e-mail address) or use a suitable anonymous reporting channel (e.g. disposable e-mail address, encrypted channel) so that we can communicate with you regarding queries.
• You do not disclose the vulnerability to third parties or the public prior to coordinated disclosure.

Non-compliance with these expectations may result in restriction or termination of further processing within the coordinated disclosure process. Regardless of compliance with these expectations, incoming reports are reviewed for security relevance. Even in case of formal violations, an initial assessment of the substance and severity of the reported vulnerability is generally provided within 10 working days.

1.2. Definitions

Working days – For the purposes of this policy, working days are Monday to Friday, excluding the public holidays of the relevant federal state as well as 24 and 31 December. The registered office of DIAL GmbH is determinative. Deadlines falling on a Saturday, Sunday or public holiday expire at the end of the next working day.

Vulnerability – A weakness, susceptibility or malfunction of a product with digital elements that can be exploited in a cyber threat.

Exploitable vulnerability – A vulnerability that can be effectively exploited by an unauthorised third party under practical operating conditions.

Exploited vulnerability – A vulnerability that is being or has been exploited by an unauthorised third party in a production system.

2. Scope

2.1 Covered products and services

This policy applies to all products with digital elements, software, services and systems of DIAL GmbH, unless otherwise specified in Section 2.2.

2.2 Products and activities not covered

Products and components not covered

The following products and components fall outside the scope of this policy:

• End-of-life product versions

Activities not covered

The following activities are not subject to this policy and shall not be conducted:

• Social engineering (e.g. phishing)
• Physical attacks
• (Distributed) Denial-of-Service (DoS/DDoS)
• Brute-force attacks
• Automated scans without explanatory documentation

3. Reporting vulnerabilities

3.1 Contact

Please submit vulnerability reports to:

We recommend PGP-encrypted submissions where possible. Alternatively, our web form at /en/vulnerability-report-form.html may be used.

Communication occurs via the functional mailboxes listed above. Processing is conducted in German or English. Queries regarding the processing status of your report are welcome at any time – send an e-mail to the functional mailbox with your incident ID. Status updates are provided on a regular basis at least every 10 working days (Section 4). Contact options (e-mail addresses, PGP keys, web form) are regularly reviewed for currency and renewed before expiry. The expiry date is visible in the security.txt (RFC 9116).

3.2 Required information

To enable efficient processing, we request the following information. The more detailed your report, the faster we can reproduce and remediate the vulnerability:

• Vulnerability designation – with reference to the CWE (vulnerability type) and/or a specific identifier such as CVE, OSV or GHSA if the vulnerability is already known.
• Affected product / component with exact version number
• Comprehensive description of the vulnerability including technical details
• Step-by-step reproduction instructions
• Proof-of-Concept (PoC) (code, screenshots, network traces)
• Severity assessment (low / medium / high / critical) – optional; the final assessment is made by our security team
• Assessment of potential impact
• Contact details for queries (optional; anonymous reporting is possible – anonymous reports are assessed by the same criteria as non-anonymous reports; feedback is only possible if a suitable anonymous communication channel is provided)

3.3 Confidentiality

We treat every report confidentially to the extent permitted by law. Personal data is disclosed to third parties only with explicit consent, unless statutory reporting obligations (e.g. CRA Art. 14, GDPR Art. 33) require otherwise. In particular, we are legally obliged to report actively exploited vulnerabilities to the competent CSIRT and ENISA without undue delay (CRA Art. 14). In individual cases this may include the disclosure of vulnerability information, but not of personal data beyond the necessary extent. Reporting to the competent national CSIRT (CERT-Bund) remains unaffected.

If you have provided personal data, please refer to the privacy information: /en/cvd-privacy-information.html

4. Process

Upon receipt, a report follows this process:

4.1 Status updates

We inform the reporter of the current processing status at least every 10 working days throughout the process. If no contact is desired or possible (anonymous report), no updates are provided.

4.2 No single-analyst closure

Reports cannot be closed by a single person. Each closure requires approval by a second authorised person to prevent overlooking valid vulnerabilities.

5. Timelines

5.1 Remediation timelines by severity

Target remediation times are based on the severity of the vulnerability. The final classification is made by our security team:

5.2 Disclosure timeline

Validated and verified vulnerabilities are publicly disclosed within 90 days. The reporter is informed prior to publication. Advisories are published at minimum on our security page: /en/security-advisories.html . Publication may additionally occur in the European Vulnerability Database (EUVD).

5.3 Extension

Timeline extensions are possible by mutual agreement, particularly for complex vulnerabilities or product-specific particularities. Communication regarding this occurs directly with the reporter.

5.4 Termination of CVD process

The CVD process is deemed complete when one of the following occurs:

• The vulnerability has been remediated and disclosed in coordinated manner (security advisory, EUVD/CVE entry where applicable).
• The report has been classified as invalid following review (e.g. no security-relevant product behaviour, no reproducible proof-of-concept).
• The reporter fails to respond within 30 calendar days to materially necessary queries regarding reproduction or validation of the vulnerability (e.g. missing version information, incomplete PoC) – the report is then deemed moot. The period commences upon receipt of the last materially necessary query by the reporter.
• The vulnerability has been publicly disclosed and – in consultation with the competent national CSIRT – it can no longer be assumed that the vulnerability will be mitigated or remediated.

In all cases, closure is documented and communicated to the reporter if contact exists. Renewed contact by the reporter after the report has become moot is treated as a new report, provided the vulnerability has not yet been remediated at that time.

If the remediation timeline under Section 5.1 of the CVD policy is exceeded by more than 50%, the reporter is informed and an appropriate extension is agreed jointly pursuant to Section 5.3.

6. Safe Harbor (legal certainty)

We will not initiate legal action against reporters, provided that:

• The report is made within the scope of this policy.
• The vulnerability was not exploited maliciously.
• No data was read, manipulated, downloaded or deleted beyond what is necessary to validate the vulnerability – access to the reporter’s own test data for proof-of-concept creation remains unaffected.
• No damage was caused beyond the reported vulnerability.
• No attacks were conducted against third parties or our infrastructure.
• The vulnerability was not disclosed to third parties or the public prior to coordinated disclosure.
• The reporting person does not require an NDA (Non-Disclosure Agreement) as a condition for reporting.

An unintentional exceedance of the measures required for validation does not result in loss of safe harbor, provided the reporter acted in good faith, no data beyond the necessary extent was extracted or disclosed to third parties, and no intent to cause damage is evident. This does not apply in case of evidently criminal intent or intentional harm.

7. Effective date

This policy enters into force on 11 September 2026 and applies indefinitely.

Annex 1 – Version history

This policy is updated as needed and adapted to new legal requirements (e.g. CRA, NIS-2, BSI TR-03183-3). It is reviewed for currency at least annually. The current version is available via the security.txt and on our website.

Annex 2 – Examples

In scope (exemplary vulnerability types):

• Exploitable buffer overflows, injection vulnerabilities (SQL, OS command, LDAP)
• Authentication or authorisation flaws
• Insecure data storage (e.g. plain-text passwords in logs)
• Side-channel attacks
• Security gaps in API endpoints (e.g. missing rate limiting with transaction data leakage)

Not considered exploitable vulnerabilities:

• Results from automated scans without validated analysis
• Configuration weaknesses without security-relevant impact
• Malfunctions that do not constitute a security-relevant threat
• Self-XSS (exploitation only by the attacker themselves)
• Missing security headers outside critical APIs
• Theoretical or non-reproducible risks
• Existing public vulnerabilities that have been fully and demonstrably remediated

Thank you for helping to make our products more secure.