Help
App öffnenGespräch buchen
Erste SchritteAnleitungenComplianceSupportApp öffnenGespräch buchen

Incident management

How we detect, respond to, and report incidents.

Englische Version wird angezeigt

Cortena uses an incident management process to respond to any event that impacts service reliability, customer operations, or customer data. This includes security incidents, but also outages, degraded performance, failed integrations, data processing errors, and sub-processor disruptions.

This process exists to restore service quickly, communicate clearly, and prevent recurrence.

1. Purpose

To ensure incidents are:

  • detected and handled quickly
  • escalated to the right owners
  • communicated to affected customers when needed
  • documented with follow-up actions

2. Scope

This process applies to incidents affecting:

  • availability (outages, downtime, failed deployments)
  • performance (slow service, timeouts, scaling issues)
  • correctness (data processing errors, sync failures, automation mistakes)
  • integrations (DATEV, banking via Yapily, inbound email processing, other connectors)
  • security and privacy (unauthorized access, data leakage, suspicious activity)
  • third-party dependencies (hosting, LLM provider, email routing provider)

3. Definitions

Incident: Any unplanned event that impacts service quality, customer operations, or data.

Security / privacy incident: An incident that may affect confidentiality or integrity of customer data (for example unauthorized access, leakage, malware, compromised credentials).

Severity: A level used to prioritize response and communication.

4. Incident severity levels

4.1 SEV-1 (Critical)

Service is unavailable for many users, OR high risk to customer data, OR major business impact.

4.2 SEV-2 (High)

Major feature is broken or heavily degraded, OR significant customer impact, but partial service remains.

4.3 SEV-3 (Medium)

Limited impact, workaround exists, or affects a small set of users.

4.4 SEV-4 (Low)

Minor issue, no meaningful customer impact, handled in normal backlog.

5. Incident response process

5.1 Detect and triage

  1. Identify issue via monitoring, alerts, support reports, or internal detection.
  2. Confirm impact: who is affected, what functions are affected.
  3. Assign severity (SEV-1 to SEV-4).
  4. Assign an Incident Owner (single accountable person).

5.2 Contain and stabilize

  1. Stop the bleeding (rollback, disable feature, isolate component).
  2. Protect data and access where relevant (revoke keys, rotate secrets, restrict access).
  3. Confirm system stability before deeper changes.

5.3 Investigate and resolve

  1. Identify root cause and contributing factors.
  2. Apply fix (code, configuration, infrastructure, vendor coordination).
  3. Validate fix with checks and monitoring.

5.4 Recover and verify

  1. Confirm services are healthy.
  2. Confirm customer workflows are functioning.
  3. Confirm no unintended side effects.

5.5 Document and improve

  1. Record a short incident report (what happened, impact, timeline, fix).
  2. Define follow-up actions (prevention, monitoring improvements, tests, runbooks).
  3. Review in the weekly team sync.

6. Customer communication

6.1 When we notify customers

We communicate to customers when:

  • an incident causes material service disruption
  • an incident affects customer workflows (for example exports, bank sync, email intake)
  • an incident may affect customer data (security / privacy incidents)

6.2 What we communicate

When relevant, we provide:

  • a short summary of what happened
  • start time, detection time, and current status
  • which systems / features are affected
  • mitigation actions and expected next steps
  • any customer actions recommended (if applicable)

6.3 Security / privacy notification

If an incident may affect customer data, Cortena will notify affected customers in line with applicable law and contractual commitments.

Where a personal data breach occurs, Cortena will:

  • Notify the relevant supervisory authority within 72 hours of becoming aware, where feasible, in accordance with GDPR Article 33
  • Notify affected customers without undue delay where the breach is likely to result in a high risk to individuals, in accordance with GDPR Article 34
  • Record all breaches in an internal breach register, regardless of whether regulatory notification is required

7. Internal escalation

Incidents are escalated internally promptly (target: within 1 hour for high-impact incidents).

8. Roles during an incident

  • Incident Owner: coordinates response, makes decisions, provides updates
  • CTO / Engineering: leads technical mitigation and fix
  • CEO / Compliance: leads external communication if customers are impacted and handles contractual / privacy implications
  • Support: collects customer reports, shares workarounds, tracks affected accounts

9. Contact