Overview & Posture
Regulated complaint operations need an honest answer to one question above all others: what happens if something goes wrong. This article documents the current incident response posture of Complaint Analyst. It covers the full lifecycle from detection through regulator notification, and is grounded in the workflow, tooling, and obligations that actually exist today.
Every claim in this document is tied to an auditable behaviour in the platform or to a documented regulatory expectation. If your procurement review needs additional artefacts — an incident response runbook, a transfer impact assessment, or a signed sub-processor list — use the diligence request form at the bottom of this page.
Detection & Monitoring
The production environment runs on Hetzner Cloud in the EU, fronted by Cloudflare for TLS termination and edge protection, with PostgreSQL managed by Supabase. Application health, database connectivity, and queue depth are monitored as part of the deployment process, and the analyst product exposes application logs through the standard deployment pipeline rather than through a bespoke telemetry stack.
Authentication events, role changes, ticket mutations, and sensitive administrator actions are written to an immutable audit trail by `audit_log_service`. Detection is therefore not only a matter of infrastructure metrics — it is also driven by reviewing the audit trail when a report suggests that a human or automated action does not match the expected pattern.
Triage & Classification
When a report or alert is received, the first step is triage against a simple severity rubric: whether customer data is potentially affected, whether the issue is ongoing, whether there is a regulatory clock running, and which tenants are in scope. Triage is owned by the on-call engineer, with escalation to the security lead for anything that touches personal data or regulated workflows.
Classification is deliberately conservative. If there is any realistic possibility that personal data has been accessed, copied, modified, or made unavailable in a way that could harm a data subject, the event is treated as a suspected personal data breach until the investigation shows otherwise. This avoids the anti-pattern of reclassifying an incident downward after the fact.
Containment & Remediation
Containment prioritises stopping the impact before investigating the cause. Typical containment actions include revoking exposed credentials, forcing session re-authentication, disabling a compromised integration, rotating API keys, or pausing an intake channel such as the public complaint form or the IMAP connector. Containment actions are recorded in the audit trail so that the sequence of events is reconstructible later.
Remediation then addresses the underlying issue — a code change, a configuration change, a database migration, or a vendor-side fix — and is shipped through the normal deployment pipeline with the usual CI gates. The team does not hot-patch production outside the standard release workflow except in the narrow case where not doing so would prolong customer harm.
Customer Notification
Where a security incident affects a specific customer tenant, that customer is notified directly using the contact details on file for their administrator users. Notification is handled by a human rather than by an automated status page, because a regulated customer usually needs context — what happened, what data was in scope, what we did, and what they need to do — rather than a generic outage message.
For incidents with broad platform impact the team will also publish a written update so that all affected customers receive the same baseline information. Updates follow the incident until it is resolved, and a final message closes the loop with the outcome of the post-incident review. Where we do not yet have an answer, we say so explicitly rather than speculating.
Regulator Notification
For personal data breaches Complaint Analyst works to the 72-hour notification expectation from the UK GDPR and EU GDPR. The clock starts when the incident is reasonably believed to be a personal data breach, which is the same conservative classification described in the triage section. The data controller of the affected records retains the statutory obligation to notify the supervisory authority; Complaint Analyst acts in a processor role and supports that notification with evidence and timestamps from the audit trail.
For FCA-regulated customers, the product is used for DISP complaint handling. A security incident that disrupts the ability to meet DISP timing obligations — for example the 5-day acknowledgement or the 8-week final response — is treated as material, and customer communications make that risk explicit so the customer can decide whether to notify the FCA under their own operational resilience obligations. Payment services customers operating under PSD2 are likewise supported with the evidence they need for any major incident reporting they are required to perform.
Post-Incident Review
Every material incident is followed by a written post-incident review. The review documents the timeline, the contributing factors, the containment actions, the remediation work, and the follow-up items that came out of the investigation. The goal is the blameless review standard used in modern engineering practice: the output is a prioritised list of changes, not a search for a single person to hold responsible.
Follow-up items from a review are tracked in the normal engineering backlog so that there is an auditable trail from the incident to the change that prevents a recurrence. Where a review produces a change to a security control or a documented procedure, that change flows back into this trust documentation the next time the affected article is updated.
Reporting a Suspected Incident
If you are a customer, a security researcher, or anyone else who believes you have seen a security issue in Complaint Analyst, please report it using the diligence request form at the bottom of this page with the subject set to a security contact. Include the page or workflow where the issue appears, the account or tenant context if you have one, and enough detail to reproduce the behaviour.
Reports are triaged alongside production incidents rather than being routed through a generic feedback queue. We do not currently run a paid bug bounty programme, but we acknowledge reports from external researchers and credit them in the post-incident review where they ask to be credited.