Skip to content
← Back to home

Incident and Breach Response Policy

Last updated: 24 April 2026 — Draft pending solicitor review

This policy describes how Rubo Ltd (“Rubo”) detects, triages, assesses, contains, and reports security incidents and personal data breaches. It supports our Terms of Service, DPA, and Privacy Policy, and aligns with ICO guidance under the UK GDPR, the Data Protection Act 2018, and PECR.

1. Scope

This policy applies to any event that compromises — or is reasonably suspected to compromise — the confidentiality, integrity, or availability of Rubo systems or Customer Data, including:

  • Unauthorised access to the console, API, database, or storage.
  • Accidental disclosure, loss, or destruction of data.
  • Malware, ransomware, phishing, and social engineering.
  • Denial-of-service attacks with data-integrity impact.
  • Sub-processor or vendor-side incidents affecting Rubo data.
  • Insider incidents (malicious or accidental).

2. Detection

Rubo uses layered detection:

  • Application and error monitoring via Sentry, with alert thresholds for unusual error rates and auth failures.
  • Platform monitoring via Supabase and Cloudflare dashboards and alerts.
  • Audit logs covering admin actions, access events, and data-export events.
  • Sub-processor notifications (Anthropic, Stripe, SendGrid, Together.ai) of their own incidents that may affect us.
  • Customer reports to security@askrubo.ai.
  • Responsible-disclosure reports via security@askrubo.ai.

3. Triage — within 4 hours of detection

On detection of a suspected incident, the on-call engineer (currently the founder as solo operator, with an escalation path documented in the runbook) will:

  • Acknowledge the alert within the on-call window.
  • Record the time of detection in the incident log.
  • Open an incident ticket with a unique ID and severity provisional rating (S1/S2/S3/S4).
  • Notify back-up / co-responder where severity ≥ S2.
  • Begin initial containment (revoke keys, block IPs, rotate credentials) where the issue is clearly malicious.
  • Preserve evidence (logs, snapshots) before any destructive remediation.

4. Assessment — within 24 hours

Within 24 hours of triage, Rubo will complete an initial assessment documenting:

  • Nature of the incident (what happened, suspected cause).
  • Systems and data types affected.
  • Approximate number of data subjects and records affected.
  • Likely consequences for data subjects (confidentiality, integrity, availability impacts; risk of identity theft, fraud, discrimination, reputational damage, financial loss).
  • Whether the incident meets the threshold for a personal data breach under UK GDPR Art. 4(12) and Art. 33.
  • Whether the risk to rights and freedoms is “high” (triggering data subject notification under Art. 34).

5. ICO notification — within 72 hours (if required)

Where the incident is a personal data breach unlikely to result in a low risk to rights and freedoms, Rubo will notify the Information Commissioner’s Office within 72 hours of becoming aware, using the ICO breach-reporting portal.

  • Prepare notification containing: nature of breach; categories and approximate number of data subjects / records; contact details of DPO (privacy@askrubo.ai); likely consequences; measures taken or proposed.
  • Where information is not yet complete, notify in phases and mark the report as such.
  • Record the notification in the breach log.

Where Rubo is a processor and the incident affects Customer Data, Rubo will notify the affected Customer (Controller) without undue delay and in any event within 72 hours, with enough information for the Customer to meet its own ICO obligations.

6. Affected user notification — within 72 hours (if high risk)

Where the breach is likely to result in a high risk to data subjects’ rights and freedoms, Rubo will (or, where Rubo is processor, will support the Customer to) notify affected individuals without undue delay — targeting 72 hours from awareness.

  • Prepare clear, plain-English notification describing the breach, likely consequences, and measures taken or recommended.
  • Include contact point for questions (privacy@askrubo.ai).
  • Use direct communication channels (email) where feasible; broad public communication where direct contact is disproportionate.

7. Containment and recovery

In parallel with notification:

  • Contain — isolate affected systems, revoke compromised credentials, block malicious IPs, apply hotfixes.
  • Eradicate — remove the root cause (malware, vulnerable code, misconfiguration).
  • Recover — restore services from known-good state; validate data integrity.
  • Verify — confirm with logs and monitoring that the threat is gone and services are healthy.

8. Breach log

Rubo maintains an internal breach log per ICO guidance, regardless of whether the breach is notifiable. Each entry records:

  • Incident ID, detection time, closure time.
  • Nature, cause, and affected data.
  • Whether ICO and/or data subjects were notified, and dates.
  • Remediation actions and lessons learned.

The breach log is retained for at least 5 years.

9. Post-incident review

Within 10 business days of closure, Rubo will conduct a post-incident review covering:

  • Timeline and root cause.
  • What worked and what did not in detection, triage, and response.
  • Concrete remediation items with owners and due dates.
  • Update to runbooks, code, or training where relevant.
  • Whether the incident indicates a need to revise our DPIA or security measures.

Outputs are tracked to completion.

10. Customer communications during incidents

For incidents that affect Customer Data or Service availability, Rubo will:

  • Maintain a live incident page where material.
  • Send updates to affected Customer admins at least every 4 hours during an active S1/S2 incident.
  • Publish a post-mortem within 14 days, summarising cause, impact, and remediation (sanitised where security requires).

11. Regulatory and third-party cooperation

Rubo will cooperate with the ICO, other relevant regulators, law enforcement, sub-processors, and Customer auditors in investigations, subject to legal constraints and confidentiality obligations.

12. Responsible disclosure

Security researchers are encouraged to report suspected vulnerabilities to security@askrubo.ai. We commit to:

  • Acknowledging within 2 business days.
  • Not pursuing legal action against good-faith researchers acting within the scope of our responsible-disclosure guidelines.
  • Crediting researchers publicly where they wish.

Contact


Draft pending solicitor review. Rubo is a software tool, not a law firm.