Incident management and personal data breaches

This page describes how Humind detects, classifies, and resolves incidents affecting its services, and the specific procedure applied when an incident qualifies as a personal data breach under Article 4(12) of the GDPR.

It presents Humind's operational procedure, kept up to date as it evolves. The contractual commitments applicable to a given merchant are defined in their service agreement and Data Processing Agreement (DPA), which prevail over this page in case of conflict.

At a glance

• Incidents are classified by severity from P1 (critical) to P4 (minor), with response targets per level.
• A suspected personal data breach is escalated immediately, whatever its initial severity.
• Humind acts as a processor: affected merchants are notified without undue delay, at the latest within 72 hours of Humind becoming aware of a breach, so that they can meet their own obligations as controllers.
• Every incident ends with a documented post-mortem; critical incidents receive a root cause analysis within 5 business days.
• All incidents and breaches are recorded in an internal register.

Scope and definitions

Term	Definition
Operational incident	Unplanned degradation or interruption of a Humind service (availability, performance, functional defect)
Security incident	Event that compromises, or could compromise, the confidentiality, integrity, or availability of Humind systems or data
Personal data breach	Security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data (GDPR Article 4(12))

Every personal data breach is a security incident, but the reverse is not true: a vulnerability detected and fixed before any unauthorized access involves no breach. The qualification is made during triage and re-evaluated as the investigation progresses.

Detection channels

Incidents can be detected through:

• automated monitoring and alerting on all production services (availability probes, error rates, telemetry);
• internal reporting by any Humind employee, with defined escalation paths;
• merchant reports through support channels;
• vulnerability reports from security researchers to security@thehumind.com, under Humind's responsible disclosure practice.

Severity classification

Level	Definition	Acknowledgment	Communication
P1 (critical)	Service unavailable, confirmed security compromise, or suspected personal data breach	Within 1 hour	Affected merchants informed, status page updated, root cause analysis within 5 business days
P2 (major)	Significant degradation of a core feature, or security event under investigation	Within 4 business hours	Affected merchants informed if impact is confirmed
P3 (moderate)	Limited functional impact with a workaround	Within 1 business day	Tracked in support channels
P4 (minor)	Cosmetic or negligible impact	Within 2 business days	Fixed in normal release cycle

Any incident suspected of involving personal data is escalated to P1 treatment for its data-protection track, regardless of its operational severity.

Incident lifecycle

1. Triage and classification. The on-call engineer confirms the incident, assigns a severity, and opens an incident record. The record tracks the timeline from detection to closure.
2. Containment. Immediate measures limit the impact: isolating a component, revoking credentials, disabling a feature, or blocking traffic. Containment takes priority over root cause analysis.
3. Investigation. Determination of the origin, the affected systems, the affected merchants, and, for security incidents, whether personal data was accessed, altered, or exfiltrated.
4. Remediation. Correction of the root cause, verification in production, and restoration of nominal service.
5. Post-mortem. Every P1 and P2 incident ends with a documented review: timeline, root cause, impact assessment, corrective and preventive actions. For critical incidents the root cause analysis is available to affected merchants within 5 business days.

Incident history for the service is published on the status page.

Personal data breach procedure

Humind processes end-user personal data as a processor on behalf of its merchants, who remain controllers. The breach procedure reflects that role split, in line with GDPR Articles 33 and 34.

Qualification and assessment

As soon as an incident is suspected to involve personal data, the investigation determines:

• the nature of the breach (confidentiality, integrity, availability);
• the categories of personal data concerned (for example conversation content, contact details voluntarily provided, pseudonymous identifiers);
• the categories and approximate number of data subjects and records concerned;
• the affected merchants;
• the likely consequences for data subjects.

Notification of affected merchants

Humind notifies each affected merchant without undue delay after becoming aware of the breach, and at the latest within 72 hours, at the security or technical contact designated in the merchant's account (or the DPA contact if one is designated). This deadline is Humind's own processor commitment; it is deliberately aligned on the 72-hour deadline that then applies to the merchant for notifying its supervisory authority.

The notification includes the information the merchant needs for its own Article 33 notification:

• the nature of the breach and the facts established at that point;
• the categories and approximate number of data subjects and records concerned, as known;
• the name and contact details of Humind's DPO;
• the likely consequences of the breach;
• the measures taken or proposed to address the breach and mitigate its effects.

If all information is not available within 72 hours, Humind notifies with the information available and completes it in phases as the investigation progresses, without waiting for the investigation to close.

Role split for regulatory notifications

Obligation	Responsible party
Notify the affected merchants (Article 33(2))	Humind
Notify the supervisory authority, for example the CNIL (Article 33(1))	The merchant, as controller
Communicate to data subjects when the breach is likely to result in a high risk (Article 34)	The merchant, as controller
Provide the merchant with the information and assistance needed for both notifications (Article 28(3)(f))	Humind
Document the breach in an internal register (Article 33(5))	Both, each for their own register

Humind does not notify a supervisory authority or end users directly on the merchant's behalf, unless the DPA explicitly instructs it to.

Register of breaches

Every personal data breach, including those assessed as unlikely to result in a risk and therefore not notifiable, is documented in Humind's internal breach register: facts, effects, remedial action taken, and the assessment justifying the notification decision. The register entry for a breach affecting a merchant is available to that merchant on request.

Contacts

Purpose	Contact
Report a security issue or vulnerability	security@thehumind.com
Data protection and breach questions	dpo@thehumind.com
Service availability	Status page

What the merchant should plan on its side

As controller, the merchant should:

1. designate in its Humind account (or in the DPA) the contact to be notified in case of a breach, and keep it current;
2. maintain its own procedure for notifying its supervisory authority within 72 hours and, where applicable, the data subjects;
3. keep its own breach register;
4. define in the DPA any specific instructions (notification format, additional deadlines, authority notification delegated to Humind).

Related pages

• Privacy and browser storage: what the widget stores on the visitor's device.
• Data retention and deletion: how long server-side data is kept and how it is deleted.