Overview
Complaint operations handle some of the most sensitive personal data a regulated firm processes: identity details, financial history, dispute narratives, and medical or vulnerability disclosures attached to a complaint. This article documents how Complaint Analyst handles that data under the GDPR and how it reconciles erasure rights with FCA recordkeeping expectations.
Every claim in this document is grounded in the production codebase or the production deployment configuration. If your procurement review needs additional artefacts (signed Data Processing Agreement, transfer impact assessment, sub-processor list), use the diligence request form at the bottom of this page.
Controller & Processor Roles
When Complaint Analyst is used by an FCA-regulated firm to handle that firm's complaints, the customer is the data controller for the complaint records and Complaintlab acts as the data processor. The split is documented in the Data Processing Agreement that customers receive as part of contracting.
Processing instructions are limited to what the customer configures in the platform: ingesting complaints, generating analyst-facing analysis grounded in the customer's Knowledge Base, drafting responses, and producing audit trail records. There is no secondary use of complaint content for marketing, profiling, or model training.
Lawful Basis & Purpose Limitation
The processing of complaint data through Complaint Analyst is supported by the controller's own lawful basis under Article 6 of the GDPR: typically the legal obligation to handle complaints under FCA DISP, or the legitimate interest in resolving a customer dispute fairly. Complaintlab does not introduce a separate processing purpose on top of the controller's instructions.
Categories of personal data are limited to what is needed for complaint handling: contact details, complaint narrative, related transaction or product references, and analyst workflow metadata. Special category data is not solicited, but where a complainant volunteers it (for example, a vulnerability disclosure relevant to fair treatment), the same encryption, access control, and PII masking guarantees apply.
Data Subject Rights
Customers can satisfy GDPR data subject rights using the platform without leaving the audit trail. Access requests are answered by exporting the complaint record and its associated correspondence. Rectification is supported through the standard ticket edit flow, with every change captured in the immutable audit log.
Erasure requests are handled through the published data handling policy rather than as an ad-hoc database operation. The reconciliation between erasure rights and FCA recordkeeping is documented in the next section so that controllers can answer regulator questions with confidence.
Restriction and objection requests are supported by tagging the affected ticket so that automated workflows skip it until the controller resolves the request. Portability is supported by the same export path used for access requests, which produces a portable, machine-readable representation of the complaint record.
PII Masking Before AI Calls
Before any complaint text is sent to an AI model for analysis, drafting, or compliance copilot use, it is routed through the platform's PII masking service. Personal identifiers are replaced with stable placeholders so that the inference call carries the structure of the complaint without the underlying personal data.
The PII masking step is part of the standard analysis path, not an opt-in. The same masking pipeline is applied to drafts and to compliance copilot prompts so that the protection does not depend on which surface the analyst is working in.
Retention vs Erasure
Complaint records are subject to a long retention obligation under FCA expectations: typically several years from the date of final response. The retention policy service in the platform tracks the retention horizon for each tenant so that records are not deleted prematurely.
When a data subject erasure request reaches a record that is still inside the regulated retention window, the surviving record is reduced to the minimum information required to satisfy the obligation: the regulatory metadata is preserved, while identifying free-text fields and attachments are removed in line with the published data handling policy. The erasure decision and its scope are written to the audit trail.
Once the regulated retention window has expired, the record is fully removed by the standard erasure workflow rather than being kept indefinitely.
International Transfers
Complaint data is hosted in the EU and is not replicated outside the EU under normal operations. The detailed posture, including primary region, backup location, and disaster recovery, is documented in the Data Residency article.
The narrow international transfer that does occur is the AI inference call to Anthropic for complaint analysis. The request is sent over TLS, contains text that has already been routed through the PII masking service, and is governed by the inference provider's data processing terms with no training use of customer content under the production configuration.
Where a sub-processor is incorporated outside the EU but only processes metadata or transit-level information (for example, edge DNS and TLS termination), the relationship is governed by Standard Contractual Clauses and the supplier's published data processing addendum.
Access Controls & Audit Trail
Access to complaint data inside the platform is governed by role-based access controls across admin, senior analyst, analyst, and customer-facing flows. Tenant scoping is enforced on every domain query so that an analyst in one tenant cannot read another tenant's complaint records.
Every meaningful action a user takes — assignment, status change, draft generation, correction, deletion — is captured in an immutable audit trail. The audit trail is the primary evidence surface used to answer regulator and DSAR questions about who accessed which record and when.
Breach Notification Posture
Complaintlab maintains an incident response posture aligned with the GDPR's 72-hour notification expectation for personal data breaches. The internal workflow follows the same audit-oriented approach the product uses for complaint operations: clear ownership, evidence capture, and a documented escalation path during customer review.
If a breach affects a customer's data, the customer is notified directly with the facts that GDPR Article 33 requires controllers to share with their supervisory authority, so that the controller can meet its own notification deadlines without having to chase information.
Questions & Diligence Materials
If your review needs more detail than this page provides — for example a signed Data Processing Agreement, a transfer impact assessment, or a sub-processor list with current entities — request the trust packet using the form below. We will route the request to the right follow-up rather than dropping you into a generic sales pipeline.