Security & data protection pack

• Access limited to what your role needs, and removed the day it stops being needed.
• No blame for reporting a mistake — including your own. The only unrecoverable error here is a delayed one.
• This briefing kept current, and re-read annually.

All personal data of UK data subjects is stored in the UK or EEA. It is processed in the US when it is sent to an AI vendor, as below. *(Corrected 2026-10-03, CHG-2026-1720: this section previously said only non-personal content went to Anthropic, which was not true.)*

AI vendors: what each receives, and the transfer basis

Anthropic (Claude). Receives personal data in these cases:

• Images: trader credential card photos (extraction); receipt and invoice images (trader expenses, home inventory, Passport service entries); images sent in messages (screening for contact details); job-lead photos.
• Transcripts: call transcripts, for AI-10 call summaries.
• Property facts: these feed market-readiness reports, maintenance predictions (AI-05), and the Passport, guide and golden-thread assistants, together with the question the user asks.

Inputs are minimised to what each task needs. Anthropic does not train on API content by default.

• Contract: Art. 28 DPA, identified 2026-08-05.
• Transfer mechanism: EU Standard Contractual Clauses with the UK Addendum (compliance/registers/processor-register.md; DPIA G8).
• Open items: confirming that the commercial terms are in force, a zero-retention decision, and the transfer risk assessment, all tracked in governance/OUTSTANDING.md (G7/G8).

OpenAI. Receives trader verification documents for the AI-01 pre-screen (vision); a human makes every decision.

It also runs search-visibility checks, whose prompts are about Tradelynx only and carry no personal data.

• Contract: Art. 28 DPA, identified 2026-08-05.
• Transfer mechanism: EU Standard Contractual Clauses under that DPA. The UK transfer mechanism (IDTA or UK Addendum) and the training/retention posture are not yet confirmed (processor register).

0. Start the clock and write it down (minute 0)

Open an incident record from governance/templates/incident-template.md immediately — before investigating. Fill in Detected to the minute, and answer the regulatory-notification block at the top. The record is the clock: both deadlines are computed from that timestamp.

Do not wait for certainty to open the record. An incident that turns out to be nothing is closed in a line; an incident opened three hours late has burned three hours of a 72-hour budget.

1. Contain, then preserve (first hour)

Stop the bleeding, then stop destroying evidence. Revoke the credential, disable the route, take the surface down. Do not delete logs, rotate away the affected keys' audit trail, or clean up the data before it has been captured — both regulators will ask what was accessed and by whom, and the audit tables (property_data_access_log, data_disclosure_log, audit_events) are the answer.

2. Establish the four facts both regulators ask for

1. What happened — plain sentences, no speculation about cause. 2. What data, and whose — categories and approximate numbers of people. Never the data itself: the ICO explicitly says not to include personal data in the report form. 3. Likely consequences for the people affected. 4. What you have done and will do — containment already applied, and the remediation planned.

If you do not have all four at 71 hours, report anyway. Both regulators accept a partial report followed by an update; neither accepts silence.

3. Notify HMRC

Log the Developer Hub support ticket. Include: application name (Tradelynx Books), the four facts above, and the breach contact name and telephone number — that is a stated requirement, not a courtesy. Record the ticket reference in the incident record.

4. Notify the ICO

Complete the online form. Allow about 30 minutes. The ICO responds within seven calendar days with next steps. Record the reference in the incident record.

5. Tell the people affected, if the risk is high

Where the breach is likely to result in a high risk to people's rights and freedoms, they must be told directly and without undue delay, in plain language. This is a separate duty from notifying the ICO, and it is the one most often missed.

6. Close it honestly

The incident record's regulatory block must carry both references and both timestamps before the record moves to Resolved. A guard enforces this: tests/unit/breachNotification.spec.ts fails the build if an incident marked as a breach reaches Resolved without them.

PITR — deliberate deferral

Point-in-Time Recovery is a documented and ready follow-up, not an oversight. It is not enabled today because the cost (~£150–250/mo including the required compute upgrade) is not justified by the current data-at-risk profile: pre-revenue, 4 verified traders, no paying enterprise customers, and a daily-snapshot RPO that loses at most a small number of leads and messages in a worst-case 24-hour window. The procedure to enable PITR is a single dashboard action (Settings → Add-ons → Point-in-Time Recovery) that takes effect within minutes.

Reaffirmed 2026-08-31 by the founder, on the back of the first restore drill (CHG-2026-1269): *"Not yet. I'll wait until the project is making money."* That is trigger 1 and trigger 4 below, stated as a revenue test rather than a date, and it is the right shape: the cost is certain today and the exposure is not. The drill was run under this posture and does not change it. What the drill DID establish is that the procedure works, so when a trigger fires the only thing changing is the RPO, not our familiarity with the recovery path.

Trigger conditions for enabling PITR. Any of:

1. First paying enterprise customer signed (any tier — validates the pricing infrastructure and changes the data-at-risk profile) 2. First insurer or lender in active sales conversation (regulated buyers will require shorter RPO commitments in their procurement review) 3. Database size exceeds 4 GB (Supabase's own production checklist recommends PITR above this threshold) 4. Daily Stripe completion-fee volume exceeds £500 (i.e. 24 hours of lost data starts representing material financial reconciliation work)

Compensating controls in the absence of PITR. Daily Supabase snapshots cover the database. External systems (Stripe events, Telnyx call records, Resend email log, Sentry events) provide a secondary recovery surface for the 24-hour worst-case window — the "Reconcile against external sources" step in the restore procedure below documents how. That step has not yet been exercised in a drill: the 2026-08-31 drill had no scratch equivalent of it (see "Last tested").

What was tested: the Tradelynx web application, running locally from the current main, exercised over HTTP with automated templates and manual probes. 6,384 requests.

What was NOT tested:

• A third-party engagement has not happened. This is tool-assisted in-house testing. Tools and an independent tester are not the same thing, and the answer to HMRC should say "tooling", not "we passed a penetration test".
• The deployed edge — the WAF, TLS termination and CDN behaviour — was not scanned, for the reason in the incident note below. Production security headers were verified by inspection, not by attack.
• Authenticated attack surface was not driven by the scanner. Gated routes were confirmed to refuse anonymous callers, but post-authentication testing (privilege escalation between real roles) rests on the standing test suite rather than on this scan.

Automated templates: 2 informational results, both triaged to nothing. No exposures, misconfigurations, default credentials, injection points or known-CVE matches.

Triaging both rather than reporting "0 findings" matters: the SNMP line would look alarming in a report and dismissing it silently would be indistinguishable from missing it.

Manual probes

Production security headers (verified 2026-08-05, live)

Standing security suite

39 checks across 11 files pass: OTP verification policy, org authorisation, tenant access-token validation, invoice-token validation, signup upload guards, Turnstile, property-contribute consent, an IDOR heuristic, an SSRF fetch guard and the API scope registry.

Complementing them nightly against production: a sweep asserting 96 gated routes × 2 verbs refuse anonymous callers, and a check that every admin page refuses an anonymous visitor.