Security at Lexradar

1. Security overview

Lexradar is built and operated by TITADE Ltd (UK Companies House 17106008, ICO registration ZC109721). The product handles regulatory intelligence — not financial transactions or special-category personal data — and our controls are calibrated accordingly. We follow the principle of least privilege, encrypt data in transit and at rest, and operate a documented vulnerability disclosure process.

2. Architecture and data residency

Lexradar is a multi-tenant SaaS running on Supabase (UK region) and a FastAPI backend deployed on Railway. The database and object storage are resident in eu-west-2 (London) for all paying customers; the Insight (free) tier may use eu-west-1 (Ireland) for cost-driven capacity reasons. Customer data is never replicated outside the EEA.

The frontend is a Next.js application deployed to Vercel. The backend is a FastAPI service deployed to Railway. All inter-service traffic is encrypted in transit with TLS 1.2+ (HSTS enabled in production). Customer-facing traffic is served over HTTPS with a 1-year HSTS window.

3. Encryption in transit and at rest

• In transit. All customer traffic is served over HTTPS. The backend enforces TLS 1.2+ on every API endpoint; cleartext HTTP is redirected to HTTPS. Database connections from the backend use TLS to the Supabase pooler.
• At rest. All customer data is stored in Supabase Postgres, which encrypts all data at rest with AES-256. Supabase Storage (used for evidence files) is encrypted with AES-256. Database backups are encrypted by the underlying cloud provider (AWS RDS-style encryption).
• Application-layer. Lexradar does not store raw payment card data; payment is handled entirely by Stripe. We store a Stripe customer ID and subscription ID only. Refresh tokens issued by Supabase are rotated on every use; we use the SSR cookie helpers and applyhttpOnly,secure, andsameSite=strictcookie attributes regardless of the Supabase project defaults.

4. Supabase Row Level Security (RLS)

Every table that holds customer data has a Row Level Security policy enabled. A user can only read or write rows that belong to their own account. Policies are written as immutable SQL (see supabase/policies/) and reviewed at every schema migration.

The backend uses the user's Supabase access token (not a service role key) on every request. There is no service-role-as-user escape hatch in production.

5. Audit log access and export

The Health Score page records every state change on every customer account. Customers on Starter, Professional, and Team tiers can read their own audit log via the API. Team customers can also export the log as CSV atGET /api/v1/health-score/audit/export?format=csv. Audit rows are append-only — there is no UPDATE/DELETE codepath in production.

6. Data Processing Addendum (DPA)

Our standard DPA is appended to every paid-tier Terms of Service. It covers (i) the categories of data processed, (ii) the lawful basis, (iii) sub-processor commitments, (iv) breach-notification timelines (72 hours), and (v) the data-subject rights assistance we provide. EmailAdmin@lexradar.co to receive the DPA in counter-signable form before procurement review.

7. Sub-processors

Lexradar uses the following sub-processors to deliver the service. Each is bound by a data-processing agreement that mirrors our own commitments.

We will provide 30 days' notice before adding a new sub-processor that processes customer content. Subscribe via the in-app settings to receive these notifications.

8. AI provider data handling

Lexradar uses Anthropic Claude (Haiku 4-5 and Sonnet 4-6) for AI features. We use the zero-retention / zero-training commercial API tier: prompts and outputs are not stored by Anthropic, are not used for training, and are deleted from inference infrastructure after the response is returned. Customer data is sent to the LLM only when the user explicitly invokes an AI feature (assistant question, policy draft, impact analysis, framework comparison). The AI service is described in full at /disclaimer.

9. Vulnerability disclosure

We welcome reports from security researchers and customers. If you have found a vulnerability, please emailAdmin@lexradar.co with a description, reproduction steps, and impact assessment. We commit to:

• Acknowledgement within 2 business days.
• An initial assessment within 5 business days.
• Coordinated disclosure: we ask that you do not publicly disclose the issue until we have shipped a fix or 90 days have passed, whichever is sooner.
• Credit on our public thanks page (with your consent).

We do not run a paid bug-bounty programme at this time. We do not pursue legal action against good-faith researchers who comply with this policy.

10. Uptime, incidents, and status

Our public status page is at /status. Past incidents and post-mortems are published there. We commit to notifying paying customers by email of any incident that lasts more than 30 minutes and to publishing a post-mortem within 5 business days of resolution.

11. Compliance posture

• UK GDPR / Data Protection Act 2018. Lexradar is a controller for billing data and a processor for the customer content you upload (regulation summaries, evidence files, policy drafts).
• ICO registration.TITADE Ltd is registered with the Information Commissioner's Office (registration ZC109721). The public register entry is available at ico.org.uk.
• Cyber Essentials. Roadmap (not yet certified). The submission window opens with the launch.
• ISO 27001 / SOC 2. On the roadmap. We are committed to achieving ISO 27001 certification within 12 months and SOC 2 Type II within 18 months of launch.