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 rests in the UK or EEA.

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.

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. The 2026-05-03 restore drill exercised the clone-and-restore path and confirmed the procedure works.

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.