Information Security, Governance & Compliance Overview

1. Executive Summary

CaseFlow Automation Ltd provides a SaaS platform that helps UK credit hire professionals analyse insurer correspondence, draft responses, and receive strategic case guidance, all supported by AI cross-referenced against a curated legal knowledge base.

Security and privacy are built into the platform's architecture, not bolted on. Our approach is grounded in data minimisation, privacy by design, and honest framing of what our controls achieve and where their limits lie.

2. About CaseFlow & Scope

Service Description

CaseFlow Automation (CreditHire Assist) is a browser-based SaaS platform for UK credit hire professionals. Core features include:

• Correspondence analysis: identifying insurer arguments and cited authorities
• AI-assisted reply generation, cross-referenced against curated case law
• Live case advice with conditional strategic guidance
• Basic Hire Rate (BHR) challenge support with locality-based availability analysis
• Case law library, guidance notes, liability assessment, and response templates

Service Boundary

Hosting Region

The platform is hosted in the European Union via managed cloud infrastructure. Data residency is EU-based.

3. Trust Model & Security Principles

• Privacy by Design & Default: Data minimisation is architectural. PDFs are processed locally, PII is masked before AI processing, and retention is purpose-limited.
• Least Privilege: Row-Level Security (RLS) enforces per-company data isolation at the database level. Users can only access their own company's data.
• Defence in Depth: Controls operate at multiple layers: browser, network, application, database, and AI prompt level.
• Transparency: We use honest language about what our controls achieve. We say "attempts to mask" rather than "guarantees removal". We document limitations alongside capabilities.

4. Data Governance & Privacy (UK GDPR)

4.1 Controller / Processor Roles

Lawful basis: Contractual necessity for providing the Service; legitimate interest in providing efficient legal support tools.

4.2 Data Classification

4.3 Three-Layer Privacy Architecture

Layer 1: Local PDF Processing. Text-based PDF files are processed entirely in the user's browser using Mozilla's PDF.js (the same library used by Firefox). No PDF file is uploaded to any server. The user reviews extracted text before choosing to submit it for analysis. Exception: a scanned (image-only) PDF cannot be read by the browser; in that narrow case the file is uploaded to a private temporary storage bucket so it can be OCR'd, then deleted immediately after processing. A scheduled daily job removes any object older than 24 hours as a safety net.

Layer 2: PII Masking Gateway (in transit). Before any text is sent to the AI model, it passes through a mandatory server-side masking gateway that uses pattern-based rules tuned for UK claims data. Detected identifiers (titled names, bare/untitled names in labelled or salutation/sign-off contexts, emails, phone numbers, VRMs, NI numbers, driving licence numbers, IBAN, card numbers, sort codes, account numbers, policy/claim references such as POL, CLM, REF, CLAIM, POLICY, FILE, BHR, CHR, CHO, TPI and structured formats like 24-ABC-123456, street addresses) are replaced with neutral placeholders such as [NAME_REDACTED] or [VRM_REDACTED]. UK postcodes are deliberately preserved because they are material to basic-hire-rate and locality arguments; a separate output-side scrubber removes any postcode the AI introduces that was not present in the original input.

Layer 3: At-Rest Masking (in storage). The same masking patterns are reapplied via PostgreSQL BEFORE INSERT/UPDATE triggers using the database function public.mask_pii(). Records persisted to correspondence, ai_replies, case_advice, preemptive_letters and taxi_risk_assessments contain placeholders rather than raw identifiers, so saved history is masked even in the event of unauthorised database access.

The masking gateway is a mandatory processing step. There is no bypass path. Each invocation logs the count and categories of items masked. Original values are never logged.

4.4 Data Retention & Deletion

CreditHire Assist is designed not to retain personal case data. Uploaded text and the outputs the tool generates are deleted immediately when the user is finished, on session close. A continuous scheduled purge runs as a backstop, so nothing is ever retained beyond 24 hours. Users save anything they need to keep to their own systems (a copy button is provided in-app) and re-run the task if required.

We do not use client data to train AI models. Data is used solely to generate the specific output requested by the user.

Special category data: The Service is not intended for special-category data and users are asked not to submit it. We recognise that in credit hire work, health, injury or vulnerability information can incidentally appear in free-text correspondence. Where it does, the same safeguards apply (masking, data minimisation, encryption and immediate deletion), and as data controller the customer remains responsible for the Article 9 lawful basis.

4.5 Post-Upload Scrubbing of Residual PII

If, after upload, a user identifies that personal data slipped past the masking gateway, the affected record can be:

• Re-masked in place — the same record is updated, the at-rest trigger re-applies mask_pii(), and the previous unmasked text is overwritten in place (no historical row is retained for masked tables).
• Deleted entirely by the user from their history (correspondence, replies, advice, letters).
• Deleted from the AI provider — the AI provider operates under a zero-data-retention contract path: prompts and outputs are not stored beyond inference, so there is no model-side record to delete. We will provide written confirmation on request.

To request a bulk scrub or audit, contact info@caseflowautomation.co.uk; we aim to action within 5 working days.

4.6 Data Subject Rights

The platform supports the exercise of data subject rights including access, rectification, erasure, and portability. Users can delete their own correspondence and AI outputs. Company-level data deletion is supported on contract termination.

4.7 International Transfers

Platform data is hosted in the EU. Where AI model inference involves processing outside the UK/EEA, this occurs under the provider's enterprise data processing terms which include Standard Contractual Clauses (SCCs) and prohibit the use of input/output data for model training.

5. Security Architecture

5.1 Hosting & Infrastructure

• Hosted on managed cloud infrastructure with EU data residency
• TLS encryption for all data in transit
• AES-256 encryption for data at rest
• Managed database with automatic backups, point-in-time recovery, and encrypted backup storage
• Infrastructure managed by established cloud providers with SOC 2 Type II and ISO 27001 certifications

5.2 Application Security

• All AI interactions are mediated through server-side functions. Users never interact with the AI model directly.
• System prompts and knowledge base content are injected server-side; users cannot modify or view underlying instructions
• Input validation and sanitisation on all user-submitted data
• No API endpoint allows arbitrary prompts to the AI model
• Content Security Policy headers, HTTPS-only access

5.3 Network Security

• HTTPS (TLS) enforced for all connections
• API rate limiting on authentication and AI endpoints
• Server-side functions operate in isolated execution environments with no persistent state between invocations

6. Identity & Access Management

6.1 Authentication

6.2 Role-Based Access Control (RBAC)

Roles are stored in a dedicated user_roles table, separate from user profiles, and enforced via database-level security functions.

6.3 Data Isolation

Every database table containing client data enforces Row-Level Security (RLS) policies. These policies are evaluated at the database level on every query and cannot be bypassed by the application layer. A user from Company A cannot access, view, or modify data belonging to Company B, even if they manipulate API requests.

7. AI Governance & Model Risk Management

7.1 AI Use Cases & Human Oversight

AI is used exclusively for decision-support. It drafts, analyses, and suggests. It never makes legal decisions, sends correspondence, or takes autonomous action.

Every AI output is presented as a draft requiring human review. Users must explicitly accept a disclaimer acknowledging this before accessing AI features.

7.2 Anti-Hallucination Controls

7.3 Data Controls for AI

• PII masking before transmission: All text passes through the mandatory masking gateway before reaching the AI model
• No training on client data: Client correspondence and case details are never used to train or fine-tune AI models
• Prompt minimisation: System prompts include only the knowledge necessary for the specific task
• No persistent context: AI prompts are transient and are not stored or reused across sessions
• Server-side only: Users never interact with the AI model directly. All prompts are constructed and transmitted server-side.

7.4 Model Selection & Governance

• Models are selected centrally for their suitability for legal text analysis and are not configurable by end users
• AI model providers process data under enterprise data processing terms that prohibit training on input/output data
• Model changes are tested and validated before deployment

8. Monitoring, Logging & Incident Response

8.1 Logging & Audit Trail

8.2 Monitoring

• Server-side function execution is monitored via managed cloud logging
• Usage dashboards available to company managers (team activity) and platform administrators (aggregate metrics)
• Automated health checks on AI inference endpoints

8.3 Incident Response

In the event of a suspected security or AI safety incident:

1. Detect and Triage: Identify the scope and severity of the incident using available logs and monitoring
2. Contain: Affected AI features can be disabled immediately at the platform level. User sessions can be terminated. API keys can be rotated.
3. Investigate: Audit logs allow identification of affected outputs, users, and timeframes
4. Notify: Affected clients are notified with details of the issue and recommended actions. Regulatory notification (ICO) within 72 hours where required under UK GDPR Article 33.
5. Remediate: Root cause analysis conducted; controls updated and tested before re-enabling affected features
6. Review: Post-incident review to update procedures and controls

8.4 AI-Specific Incident Actions

• Identify event type (fabricated case law, data leakage in output, unexpected model behaviour)
• Disable affected AI feature(s) at platform level
• Review prompt and masking logs to assess exposure
• Update system prompts, knowledge base, or masking rules as required
• Validate fix before re-enabling

9. Business Continuity & Disaster Recovery

10. Third-Party Risk & Sub-Processors

We engage the following sub-processors to deliver CreditHire-Assist. Their processing is governed by data processing terms no less protective than those we owe our customers. The list is reviewed regularly and updated on material change.

Lovable's published Data Processing Agreement, including the published sub-processor list, is available at trust.lovable.dev and is incorporated by reference. The hosting region for our project is EU (Europe, Ireland), evidenced at platform level. Transfers outside the EU at the AI inference layer are safeguarded through Standard Contractual Clauses at the Lovable-to-Google contractual layer, with the formal IDTA / UK Addendum to the EU SCCs and Transfer Impact Assessment documentation available via Lovable's Trust Center on B2B compliance request.

11. Compliance & Control Mapping

11.1 Regulatory Alignment

11.2 Control Mapping (Against ISO 27001 Domains)

12. Shared Responsibility

13. Appendices

Appendix A: Related Documents

Appendix B: Glossary

Appendix C: Contact and Enquiries

For security-related enquiries, DPIA collaboration, or to request further technical detail: