Trust Centre

1. How a payslip check moves through our systems

When you paste payslip figures into the checker, the request follows a short, well-defined path. We describe each hop below so you can see exactly which parties see which fields.

1. 1. Browser. You enter gross pay, tax code, NI letter, period and any deductions. Nothing is sent until you press “Check my payslip”. Form state lives only in your tab.
2. 2. Edge function. The form is posted over TLS 1.3 to a Vercel Edge Function in the London (lhr1) region. The function strips any obvious personal identifiers (name, employer name, NI number) before any downstream call.
3. 3. Rate-limit and abuse check. The request hits an Upstash Redis instance (eu-west-1) that enforces per-IP and per-session ceilings. No payslip content is stored in Redis — only counters and short-lived tokens.
4. 4. Deterministic engine. The numbers are first run through our own HMRC/Revenue tax-tables engine. For the majority of straightforward payslips, this returns a verdict without any external LLM call.
5. 5. Anthropic Claude (only if needed). If the deterministic engine flags ambiguity (unusual tax code, salary-sacrifice interaction, mid-year code change), the redacted numeric payload is sent to Anthropic’s API for a structured second opinion. No name, employer or NI number is included.
6. 6. Response and discard. The verdict is returned to your browser and rendered. The server-side request and response are not written to any application database. Standard Vercel and Upstash operational logs are retained for the periods listed in the sub-processor table below.

2. Sub-processors

We use the following sub-processors. We notify users on this page before adding new ones. UK data is processed in the UK or EEA except where noted; transfers outside the UK rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses.

3. Anthropic data retention

Anthropic processes API inputs and outputs under its commercial terms. By default, Anthropic may retain prompts and completions for up to 30 days for trust-and-safety review, and may retain flagged material for longer where required by law. Anthropic does not train its public models on our API traffic. We are on Anthropic’s roadmap for zero data retention (ZDR); once enabled on our account this page will be updated to reflect the shorter retention window. Because we redact identifiers before calling the API, the payload Anthropic receives is a numeric payslip skeleton rather than a named record.

4. Security posture

• TLS 1.3 enforced end-to-end; HTTP requests are 308-redirected to HTTPS.
• HSTS with a one-year max-age and includeSubDomains; preload submission pending after stability window.
• Strict Content Security Policy with per-request nonces; no inline event handlers; script-src limited to first-party and named analytics origins.
• Daily ceiling on Anthropic API spend and request count enforced at the edge to cap blast radius from any single-account compromise.
• No payslip content is persisted to any application database. Logs that may incidentally contain numeric payload are redacted at the edge before write.
• GitHub repository under branch protection: signed commits, required PR review, required status checks, force-push disabled on main.
• Dependency updates via Dependabot; weekly review of security advisories on first-party and transitive packages.

5. Data Protection Impact Assessment (DPIA)

We carried out a DPIA before launch and refresh it whenever the data flow changes materially. The headline risks and mitigations are below. The full DPIA document is available on request to dpo@payslipiq.co.uk.

6. Transfer Impact Assessment (TIA)

Because Anthropic processes API traffic in the United States and Vercel’s control plane is US-headquartered, we conducted a transfer impact assessment in line with ICO guidance and the EDPB Recommendations 01/2020. We concluded that, taking into account (a) the narrow numeric nature of the payload sent to Anthropic, (b) the absence of identifiers, (c) Anthropic’s public commitments on government data requests and (d) the technical measures listed in section 4, the transfer offers a level of protection essentially equivalent to that required under UK GDPR. The TIA is reviewed whenever a sub-processor materially changes its terms or sub-region footprint.

7. Certifications and assurance

• Cyber Essentials — application in progress (target Q3 2026).
• ISO/IEC 27001 — not currently certified; controls modelled on Annex A. Certification will be reassessed once headcount justifies the scope.
• SOC 2 — not currently in scope; we rely on the SOC 2 reports of our sub-processors (available under NDA on request).
• Penetration testing — external CREST-accredited test scheduled annually, with a re-test after any material change to the data flow.
• Internal review cadence — this Trust Centre and the underlying DPIA/TIA are reviewed quarterly.

8. Data Processing Agreement

A Data Processing Agreement is available for organisational users and partners. The DPA incorporates the UK International Data Transfer Addendum and the EU Standard Contractual Clauses where relevant. Email dpo@payslipiq.co.uk to request a copy.

9. Reporting a vulnerability

If you believe you have found a security issue, please email security@payslipiq.co.uk with a description of the issue, steps to reproduce and your preferred contact. We will acknowledge within two working days. We will not pursue legal action against good-faith researchers who avoid privacy violations, service disruption and data destruction. Public disclosure is welcomed once the issue is fixed and we have confirmed the timing with you.