Security
Incident Response Plan
Version 1.0 · Last updated 7 July 2026 · Next review July 2027
This Incident Response Plan describes how LeakIQ Ltd (company number 17311148, registered at 195 Wood Street, London E17 3NU, ICO registration ZC187738) detects, responds to, recovers from and reports on security incidents affecting the LeakIQ platform and the data it processes. It is maintained by LeakIQ management and reviewed at least annually.
1. Purpose and scope
The purpose of this plan is to ensure that security incidents are handled consistently, quickly and in a way that limits harm to customers, meets LeakIQ's legal obligations, and preserves the evidence needed to understand what happened.
This plan applies to any actual or suspected incident affecting:
- the LeakIQ application, APIs and serverless infrastructure;
- customer data processed by LeakIQ (financial records read from connected systems, recovery case data and audit logs);
- connector credentials (API keys and OAuth tokens) held by LeakIQ;
- the accounts, devices or access of LeakIQ staff and contractors;
- LeakIQ's sub-processors (Vercel, Neon, Resend, Stripe) where they affect LeakIQ customers.
It applies to all LeakIQ personnel, contractors and anyone acting on LeakIQ's behalf. Every person who becomes aware of a potential incident is responsible for reporting it immediately (see section 11).
2. Definitions
- Security event — any observable occurrence in a system or network. Most events are routine and require no response.
- Security incident — an event, or series of events, that compromises or threatens the confidentiality, integrity or availability of the platform or customer data.
- Personal data breach — as defined in the UK GDPR: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
- Data controller / data processor — LeakIQ acts as a data processor on behalf of its customers, who are the data controllers of the personal data contained in their connected systems.
3. Severity classification
On detection, an incident is assigned a severity by the Incident Lead. Severity drives response timelines and who is involved, and may be revised as more is learned.
| Severity | Definition | Target initial response |
|---|---|---|
| SEV1 — Critical | Confirmed unauthorised access to, or loss of, customer data; credential compromise; or complete platform outage. | Immediate — within 1 hour of confirmation, 24/7 |
| SEV2 — High | Suspected data exposure, an actively exploited vulnerability, or a major feature outage with no workaround. | Within 4 business hours |
| SEV3 — Medium | Contained security issue with no evidence of data exposure; degraded but functioning service. | Within 1 business day |
| SEV4 — Low | Minor issue with no customer impact (e.g. a low-risk finding from monitoring or disclosure). | Within 5 business days |
4. Response team and roles
LeakIQ operates a lightweight response structure appropriate to its size. One person may hold more than one role, and external specialists are engaged where needed.
| Role | Responsibility |
|---|---|
| Incident Lead | Owns the incident end to end: declares it, sets severity, coordinates the response, and decides on containment and notification. Default: a LeakIQ director. |
| Technical responder(s) | Investigates, contains and remediates: isolates systems, rotates secrets, applies fixes and restores service. |
| Communications owner | Drafts and sends customer and internal updates and is the single source of truth for status. May be the Incident Lead. |
| Data protection liaison | Assesses whether a personal data breach has occurred, manages notification obligations and liaises with the ICO. Engages external legal counsel where required. |
5. Response lifecycle
LeakIQ follows a standard six-phase lifecycle (aligned with NIST SP 800-61):
| Phase | What happens |
|---|---|
| 1. Detect & report | Incidents are detected via the platform's security event log, infrastructure and sub-processor alerts, or reports from staff, customers or security researchers. Anyone can report to security@leakiq.io. The report is acknowledged and an incident record with a timeline is opened. |
| 2. Triage & classify | The Incident Lead confirms the incident, assigns a severity, identifies affected systems and data, and mobilises the response team. |
| 3. Contain | Short-term containment limits the blast radius: isolating affected components, revoking or rotating credentials, disabling affected connectors or accounts, and blocking malicious activity — while preserving evidence. |
| 4. Eradicate | The root cause is removed: vulnerabilities are patched, malicious artefacts removed, and any potentially exposed secrets rotated in full. |
| 5. Recover | Service is restored and validated. Data integrity is verified against the append-only, hash-chained audit log. Affected systems are monitored closely for recurrence before the incident is closed. |
| 6. Post-incident review | Within 5 business days of closure, a blameless review documents the root cause, timeline, impact and corrective actions. Actions are tracked to completion and this plan is updated with any lessons learned. |
6. Breach notification and regulatory obligations
Where an incident involves, or is reasonably likely to involve, a personal data breach affecting customer data, LeakIQ acts on its obligations as a data processor under the UK GDPR:
- Notify affected customers without undue delay — and in any event within 72 hours of confirming a personal data breach — so that each customer, as data controller, can meet its own regulatory obligations.
- Provide the information required under UK GDPR Article 33(3): the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed.
- Cooperate with customers and, where relevant, with the Information Commissioner's Office (ICO). LeakIQ is registered with the ICO under ZC187738.
As data controllers, customers are responsible for notifying their supervisory authority (in the UK, the ICO) within 72 hours where required, and for notifying affected data subjects where the breach is likely to result in a high risk to their rights and freedoms. LeakIQ provides the information and support needed for customers to do so.
7. Communication
During an active incident, the Communications owner is the single source of truth. Internal coordination happens on a dedicated channel; customer notifications are sent by email to each affected workspace's named contacts.
- Customers receive a clear description of what happened, what data was affected, what LeakIQ is doing, and what (if anything) they need to do.
- Updates are provided at a cadence matched to severity until the incident is resolved.
- A factual post-incident summary is made available to affected customers once the review is complete.
- LeakIQ does not speculate publicly during an active incident; external statements are made only when facts are confirmed.
8. Evidence preservation
Preserving evidence is a priority throughout the response, and containment steps are taken in a way that does not destroy it. LeakIQ relies on:
- the append-only, hash-chained audit log, which makes retrospective tampering detectable and provides an authoritative record of platform actions;
- infrastructure and sub-processor logs (Vercel, Neon) captured for the incident window;
- a maintained incident timeline recording decisions, actions and their timestamps.
Evidence is retained for as long as necessary to complete the investigation, any post-incident review and any regulatory process.
9. Sub-processor coordination
LeakIQ's infrastructure is delivered through a small set of sub-processors. Where an incident originates with or affects a sub-processor, LeakIQ incorporates their notifications and status into its own response and keeps affected customers informed.
| Sub-processor | Role | Incident dependency |
|---|---|---|
| Vercel | Application hosting and serverless runtime | Platform availability; monitored via Vercel status and alerts |
| Neon | PostgreSQL database (EU, AWS eu-west-1, Ireland) | Data durability and availability; database-level incidents |
| Resend | Transactional email delivery | Notification delivery |
| Stripe | Billing and payment processing | Billing data only; no revenue-recovery data |
10. Testing, review and training
- This plan is reviewed and updated at least annually, and after any SEV1 or SEV2 incident. Next scheduled review: July 2027.
- LeakIQ runs a tabletop incident exercise at least annually to validate the plan and team readiness.
- LeakIQ commissions an annual independent penetration test of the platform. The next test is scheduled for 14 June 2027; an executive summary is available under NDA.
- All LeakIQ personnel are briefed on how to recognise and report a security incident as part of onboarding and on an ongoing basis.
11. Reporting an incident
To report a security incident, suspected breach or vulnerability, contact security@leakiq.io. We acknowledge reports within one business day. LeakIQ welcomes responsible disclosure from security researchers and will not pursue action against good-faith research that respects customer data and this process.
Need this for a vendor review?
We are happy to walk your security team through this plan, complete a security questionnaire or provide a Data Processing Agreement. See the technical documentation or email security@leakiq.io.