LEGAL
Incident Communication Policy
For a product built on reproducibility and auditability, you deserve to know exactly how we communicate when something goes wrong. This policy describes what triggers a notification, when, and through which channel.
1. Definitions
- Service incident - degradation or unavailability of the API or portal (e.g. elevated error rates, latency, downtime)
- Data incident - unauthorized access to, or loss/alteration of, customer data
- Security event - a confirmed vulnerability or intrusion affecting the service
2. Notification triggers
We notify affected customers when an incident materially impacts service availability, data integrity, or the confidentiality of customer data. Routine, non-impacting events are logged internally and summarized on the status page.
3. Notification timeline
| Event type | Initial notice | Channel |
|---|---|---|
| Service incident (customer-impacting) | Within 1 hour of confirmation | Status page + subscriber email + in-app banner |
| Data incident (personal-data breach) | Preliminary notice without undue delay - internal target ≤ 24 hours of confirmed awareness | Email to security contact (fallback: primary account contact) + status page |
| Security event | Within 24 hours of confirmation | Email to security contact + status page |
4. What we share
Each notification includes, as known: scope and affected services, impact assessment, current status, remediation steps underway, and next-update time. We update at least every 24 hours until resolution. A preliminary notice is sent even when the full picture is not yet confirmed - it states what is known, what is not yet known, and when the next update will arrive. Further information follows as it becomes available.
4.1 Who we notify and who sends it
Data-incident notices are owned by the on-call incident commander (a named role in our internal incident system). Notices go to your account's security contact if one is configured, falling back to the primary account contact and billing email. Account owners and admins can set a dedicated security contact under Settings → Security contact.
If you believe you have detected an incident affecting Sentiqra before we have notified you, report it to security@sentiqra.tech - the report pages the on-call rotation.
4.2 Escalation
A suspected personal-data breach is escalated internally the moment it is triaged: the on-call incident commander declares severity, assembles the response, and owns the notification timeline above. Legal/privacy reviews content before send where time permits; a preliminary notice is never delayed awaiting legal review.
5. Post-incident review
For incidents meeting our severity threshold we publish a root-cause analysis on the status page. Enterprise customers may request the full RCA under NDA. Data incidents include a description of measures taken to prevent recurrence.
6. Incident history for due diligence
Prospective and current customers can review our public status page for availability history and subscribe there to incident-update emails, or request an incident-history summary as part of a security review via security@sentiqra.tech.
7. Related
Personal-data breach obligations are also defined in the Data Processing Agreement. To report a security vulnerability, see Report a Security Issue.