Trust Centre

1. How a payslip check moves through our systems

There are two paths. Manual entry sends only the numbers you type. Photo upload sends the image you choose (after in-browser downscale and EXIF strip) to Anthropic; anything still visible in that image is visible to the model. Automatic redaction is not implemented. The numbered hops below describe manual entry. Photo upload is described in section 3.

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. We do not redact your payslip for you. The image you upload is downscaled and re-encoded in your browser, which removes EXIF metadata such as camera location and device identifier, and it is then sent to Anthropic as an image. Anything still visible in that image — your name, your employer, your National Insurance number — is visible to the model. That is why the upload page asks you to cover those fields first: the check only needs the figures. If you would rather send nothing at all, use manual entry, which sends only the numbers you type.

4. Security posture

• TLS 1.3 enforced end-to-end; HTTP requests are 308-redirected to HTTPS.
• HSTS header on HTTPS responses: max-age=63072000; includeSubDomains; preload. That is the response header, not a claim that the domain is on the Chrome HSTS preload list.
• 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, and payslip figures are not written to application logs.
• 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 privacy@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 privacy@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.