Overview
Complaint Analyst is built for regulated complaint operations where data protection is a business requirement, not an afterthought. This document covers the security controls, encryption practices, and data handling policies that protect complaint data throughout the platform.
Every claim in this document is verifiable against the production codebase. If you need additional detail for your vendor evaluation, use the diligence request form at the bottom of this page.
Data Encryption
Data at rest is encrypted via AES-256 through the Supabase-managed PostgreSQL database. All stored credentials (such as IMAP passwords for email ingest data sources) receive an additional layer of Fernet symmetric encryption before database storage, using per-deployment encryption keys.
Data in transit is protected by TLS 1.3 between the client browser and the Nginx reverse proxy, and between the proxy and the application server. API tokens are transmitted exclusively over HTTPS and stored as httpOnly cookies to prevent client-side script access.
Data Residency & Hosting
The production environment is hosted on Hetzner Cloud in the EU (Frankfurt region). Complaint data, user accounts, and all application state reside in EU-hosted PostgreSQL managed by Supabase.
Encrypted backups are managed by the database provider with point-in-time recovery capability. No complaint data is replicated outside the EU unless explicitly configured by the tenant.
Access Controls & Authentication
Authentication uses JWT tokens with bcrypt-hashed passwords. Sessions are managed via httpOnly cookies with configurable expiry. Optional TOTP-based two-factor authentication is available for all user accounts.
The platform enforces role-based access controls with three primary roles: admin, senior_analyst, and analyst. Each API endpoint declares its required role, and the middleware validates the caller's role before processing the request. Admin endpoints are gated behind a separate dependency that rejects non-admin callers.
Password complexity requirements are enforced at account creation. Failed login attempts are logged for audit purposes.
PII Protection & AI Safety
Before any complaint text is sent to an AI provider for analysis, the PII masking service strips personal identifiers from the text. This means the AI model (Claude) receives masked text rather than raw customer data. The masking covers names, email addresses, phone numbers, account numbers, and other identifiable information.
AI analysis results are streamed back to the analyst via server-sent events (SSE) and grounded in the tenant's Knowledge Base. The AI does not make autonomous decisions. Every AI-generated analysis, draft response, and recommendation requires human review and approval before any action is taken.
Prompt versions are tracked as part of the audit trail, ensuring that the exact prompt and model configuration used for each analysis can be reconstructed for compliance review.
Immutable Audit Trail
Every material change to a complaint record is logged with the acting user, timestamp, previous value, and new value. This includes status changes, outcome edits, assignment changes, draft approvals, and AI analysis triggers.
Audit records are append-only. Once written, they cannot be modified or deleted through the application. This design supports the FCA's expectation that complaint handling decisions are traceable and reviewable.
The audit trail captures the full lifecycle of a complaint from intake through resolution, including which analyst handled each step, what AI analysis was requested, and what the final outcome was.
Automated Compliance Testing
The codebase includes over 30 automated compliance tests that run in the CI pipeline on every release path. These tests cover FCA DISP deadline enforcement, audit trail integrity, GDPR data handling, encryption verification, and tenant isolation.
Compliance tests are not deferred to manual QA. They execute automatically alongside unit and integration tests, and a failing compliance test blocks the release.
Incident Response
Operational incidents are handled through the same audit-oriented workflow the platform uses for complaint operations: clear ownership, timestamped actions, and escalation paths. The team monitors application health and database connectivity as part of the deployment process.
For security incidents affecting customer data, the response includes immediate containment, impact assessment, customer notification within regulatory timelines, and a documented post-incident review.
Certifications & Roadmap
SOC 2 Type II certification is in progress and is not presented as achieved. The platform's security controls are designed with SOC 2 Trust Service Criteria in mind, and the team is working toward formal attestation.
ISO 27001 certification is on the roadmap. The current security posture reflects the intent to meet ISO 27001 requirements, but formal certification has not been initiated.
In the interim, this trust center and the associated diligence materials provide transparent documentation of actual security practices rather than aspirational claims.