Incident Response and Customer Notification
Contractual template — applies when accepted in the service order. Use your browser’s print command to save this complete version as PDF.
This procedure defines customer communication and operational handling of service incidents and personal data breaches. Incident lead: Ovidiu Robotin, through office@qedara.com. A separately staffed deputy/on-call rotation is not represented as verified. The customer security and fallback contacts are recorded in the service order. Contractual commitments take effect with the approved order and DPA. The DPA breach-notification obligation applies independently of ordinary support hours.
1 Classification and ownership
| Class | Examples | Required handling |
|---|---|---|
| Critical | Suspected cross-tenant access, exposed credentials, ransomware or loss of production data. | Immediate triage, containment and evidence preservation; assess personal data breach without waiting for full root cause. |
| Major | Core service unavailable, signing blocked, significant provider degradation. | Assign incident lead; verify scope; publish a service update when confirmed. |
| Minor | Limited feature issue with a safe workaround and no indication of data compromise. | Track impact and fix; escalate if scope or privacy impact increases. |
The incident lead coordinates containment and recovery. The privacy lead assesses affected data and notices; the service owner approves customer communication. One person may hold several roles, but a named deputy and reachable contact must exist before the 24-hour commitment becomes effective. All times are recorded in UTC.
2 Notification to affected customers
For a personal data breach, notify without undue delay and no later than 24 hours after awareness. Send an initial notice even if facts remain incomplete. Include incident reference, awareness time, affected service, known data categories and approximate scope, likely impact, containment, recommended customer steps, contact and next update time. Do not include other customers’ identities or exploitable details.
Provide material new facts without undue delay and updates at least every 24 hours during an active material investigation. Preserve delivery evidence and use the fallback contact if delivery fails. A public status update does not replace direct notice to affected customers.
3 Service updates and closure
For a confirmed material availability incident, aim to post an initial public update within 60 minutes of triage and subsequent updates at least every four hours during active handling. These are operational targets, not a guaranteed staffed response SLA. Publish impact and workarounds without sensitive forensic details. Mark resolved only after recovery checks; issue a customer-facing explanation within five business days where practicable, or give a dated follow-up commitment.
4 Response sequence
Record detection, awareness and affected environments. Preserve relevant logs and identifiers; restrict access to evidence. Stop the affected operation, revoke compromised sessions or credentials and isolate affected components as appropriate. Avoid broad process-kill commands, unscoped restarts and deletion of evidence.
Assess confidentiality, integrity and availability for each affected customer. Request supplier facts where relevant. Start customer notice preparation in parallel with containment. Determine whether data has been read, changed, lost or disclosed, including incidents involving backups or processors. Do not infer absence of compromise from an HTTP health check.
Recover using a reviewed release or a verified backup. Validate database and attachment consistency, membership boundaries, signing access, exports and relevant AI or email functions. Reapply deletion and legal hold records after restoration. Record the decision to resume service and the person responsible.
Complete root cause analysis, corrective actions, owners and due dates. Review evidence access and retention; preserve only necessary records under a documented incident hold. Test the notification procedure and fallback contact at least twice a year and after material responsibility changes.
5 Initial customer notice template
Subject: QCM security incident [reference] — initial notification We became aware at [UTC time] of an incident affecting [service and known scope]. The facts currently confirmed are [facts]. Personal data potentially affected includes [categories and approximate scale, or not yet determined]. Likely consequences are [assessment or pending]. We have taken [containment measures]. We recommend [customer action, if any]. Our next update will be by [UTC time, within 24 hours]. Contact [named incident contact and secure reply channel]. This notice is preliminary; we will provide material updates as the investigation progresses.
6 Initial incident history
21 September 2026, approximately 22:00 UTC: an internal engineering record describes an unintended restart of production and staging during development process cleanup. It reports recovery in about 20 seconds, unchanged code and no data loss. Corrective action recorded: stop development processes by their specific scope or identity, not a shared process-name pattern.
This entry is a retrospective summary of that record, not an independently measured outage duration. The supplied status-page data labels it accordingly. No complete historical incident register or uninterrupted uptime measurement has been verified for earlier periods. Do not publish “zero incidents” or historical uptime percentages from this limited record.
7 Public status and measurement start
Live status: https://qcm-status.qedara.com. Monitoring began on 19 October 2026 at 08:13 UTC and runs outside the QCM application server every minute. The sign-in page and API/database health are checked. Two consecutive failed samples open an automated incident; the next successful sample closes it. Data older than three minutes is shown as unknown. AI, email delivery and signing transactions are explicitly not independently monitored by these probes. An automated status incident is not a personal-data-breach determination or direct customer notification.