⚠️ Requires legal review before production release.

This page explains our approach to security and privacy incidents, including breach reporting and regulatory notifications. It is not legal advice.

Incident Response (Security & Privacy)

Last updated: 2026-07-20

What we mean by “incident”

An incident is an event that could affect:

• the confidentiality of your personal data (for example, an accidental leak)
• the integrity of the system (for example, unauthorized changes)
• the availability of the service (for example, an outage)

How we respond (engineering overview)

When we discover a potential incident, we aim to:

1. confirm what happened and what systems were affected
2. contain the problem to limit further impact
3. assess the scope and whether personal data may be involved
4. fix the root cause to prevent recurrence

We use the engineering runbooks and playbooks in this repository to guide incident response steps.

Regulatory notification and breach reporting

If an incident is likely to affect individuals’ rights and freedoms, we will follow applicable privacy and security notification requirements.

This section requires legal review and may be updated once we confirm the final regulatory approach with qualified legal counsel.

We aim to:

• determine whether notice to supervisory authorities is required
• determine whether affected users must be notified
• document decision-making and evidence used in the risk assessment
• provide clear and calm communication when updates are needed

Customer communication

When we need to update customers, we aim for:

• clear facts (what we know vs what we are investigating)
• practical next steps for users (for example, password resets if required)
• responsible timing and updates without speculation

Contact and reporting a concern

If you believe you found a security vulnerability or a privacy issue, contact us at:

hello@klugliv.com

Please include enough detail to reproduce or understand the issue (without sharing secrets).

Lessons learned and improvements

After an incident, we aim to update:

• internal procedures (runbooks and automation)
• the relevant documentation when it improves user transparency