Purpose
This Data Breach Response Plan is the operating runbook EquestrianIQ follows when a security or privacy incident is suspected. It exists so that responders act quickly and consistently, and so that affected users and regulators are informed within the timeframes required by law.
What is a data breach?
A data breach is any event where personal information held by EquestrianIQ is lost, accessed without authorisation, disclosed without authorisation, altered, or otherwise compromised. Examples include credential compromise, misconfigured access controls, lost backups, malicious insider access, ransomware, and accidental disclosure of records to the wrong user.
Response team (on-call rota)
- Incident Commander — first responder on rota; owns the timeline and decisions.
- Privacy Lead — assesses notification obligations (GDPR/UK GDPR/Notifiable Data Breaches scheme) and drafts user/regulator notices.
- Security & Engineering Lead — contains the incident, preserves evidence, deploys fixes.
- Customer Communications Lead — owns user-facing messaging and the status page.
- Legal adviser — engaged for any incident assessed as likely notifiable.
- Executive decision-maker — approves external notifications and public statements.
Reach the response team at security@equestrianiq.app (24/7 monitored). Suspected incidents from any source — staff, users, security researchers, providers — are triaged within 1 hour of receipt.
Four-step response process
1. Contain (0–4 hours)
- Acknowledge the alert and open an incident ticket.
- Revoke compromised credentials, rotate keys, disable affected integrations.
- Isolate affected systems; preserve logs and forensic artefacts before remediation.
- Place a hold on automated jobs that could overwrite evidence (audit pruning, log rotation).
2. Assess (within 24 hours)
- Identify affected systems, records, users, and data categories (including sensitive horse-health, junior-rider, payment, or identity data).
- Quantify scope: number of users, time window, what was viewed/exfiltrated vs merely exposed.
- Assess likelihood and severity of harm (financial, safety, reputational, regulatory).
- Classify as: non-notifiable, notifiable to regulator, or notifiable to regulator and affected individuals.
3. Notify (within statutory windows)
- Regulators: where the incident is likely to result in a risk to individuals, notify the lead supervisory authority within 72 hours of becoming aware (GDPR Art. 33 / UK GDPR / equivalent local law).
- Affected individuals: where the incident is likely to result in a high risk to their rights and freedoms, notify without undue delay, in clear language, including: what happened, what data was involved, what we are doing, and what they should do (e.g. reset password, watch for phishing).
- Providers/partners: notify processors and connected services whose systems are involved or at risk.
- Paddle (Merchant of Record): notify immediately for any incident touching payment data.
4. Review (within 30 days of closure)
- Root-cause analysis with timeline, contributing factors, and detection gap.
- Remediation plan with owners and due dates; verify fixes in production.
- Update controls (RLS, audit coverage, secrets handling, on-call runbooks) and re-test.
- Document lessons learned in the incident register and share an internal post-mortem.
Incident register
Every suspected incident is recorded, even if later assessed as non-notifiable. The register captures: incident ID, date detected, source, systems and data affected, containment actions, assessment outcome, notifications sent (who, when, what), remediation, and verification. The register is reviewed quarterly.
User reporting channel
Users and security researchers can report suspected incidents to security@equestrianiq.app. We aim to acknowledge within 1 business day and do not pursue good-faith security research that follows responsible-disclosure practice.