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 hops below cover both, and say where the two differ.

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. Server function. The form is posted over TLS 1.3 to /api/analyse, a Node.js serverless function that names London (lhr1) as its preferred region. It is not an Edge function, and a preferred region is a preference rather than a guarantee: Vercel may place an invocation elsewhere. Nothing is stripped at this hop, because there is nothing to strip. The manual form has no field for your name, your employer or your National Insurance number, so none of the three is ever collected.
3. 3. Rate-limit and abuse check. The request hits an Upstash Redis instance (eu-west-1). There is no per-session ceiling: the limits are three analyses an hour per hashed IP, and a global ceiling on AI calls across the whole site (300 a day unless we raise it). No payslip content is stored in Redis. What is stored is counters, and — so that a tripped daily ceiling can be told apart from ordinary demand — a per-day tally of calls against each hashed caller. Everything in that store expires within 26 hours. The identifier is a peppered SHA-256 digest truncated to 64 bits, never an address.
4. 4. Anthropic Claude. Every check, not some of them. On the manual path the figures are first put through our own deterministic anomaly pass, but its output is sent to Claude as part of the prompt rather than used to avoid the call. There is no route through the checker that produces a verdict without contacting Anthropic. On the manual path the payload is the numbers you typed plus those flags, with no name, employer or NI number, because the form does not collect them. On the photo path the payload is the image, and whatever is still legible in it goes with it. Our own tax tables do answer without an LLM in the take-home and tax-code calculators — those are different tools, and they are not this one.
5. 5. 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

• Every response is served over HTTPS and plain HTTP is 308-redirected. Current browsers negotiate TLS 1.3. The minimum version accepted is set by our host rather than by us, and we do not claim that TLS 1.2 is refused.
• 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 the number of Anthropic API calls — 300 a day unless we raise it — enforced inside the analysis route itself, to cap the blast radius of a traffic spike or a compromised key. There is no spend ceiling in our code: the call count is the control, with the provider’s own billing limits behind it.
• 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 on the manual path, (b) the absence of identifiers on that path — the form collects no name, employer or National Insurance number — weighed against a photo carrying whatever the reader did not redact, (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

PayslipIQ holds no security certification at present. Where a control is modelled on a standard rather than certified against it, we say so.

• Cyber Essentials Basic — Application in progress. Not yet awarded, and no award date is committed here, because the date an assessment completes is the certifying body’s to set rather than ours. This line will name the certificate number and the date of issue on the day one is issued.
• ISO/IEC 27001 — Not certified. Controls are modelled on Annex A, and certification is under evaluation rather than under way: no scope has been agreed and no auditor has been engaged. We are targeting a decision on whether to seek certification, once headcount justifies the scope by December 2027.
• SOC 2 — Not in scope for PayslipIQ, which is too small to be an audited service organisation. Our sub-processors maintain their own SOC 2 reports and release them directly to the parties they contract with; we are not licensed to pass a copy on. Ask us which sub-processor holds the report you need and we will tell you who to approach and for which report.
• Independent penetration testing — Intended annually, with a re-test after any material change to the data flow. No test has been completed and none is currently booked, so there is no report to share. This line will name the date and the tester of the first one.
• Internal review cadence — This Trust Centre, the DPIA and the Transfer Impact Assessment are reviewed quarterly. The dates of the last and next review are in the document control block at the foot of the Trust Centre.

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. Reports are acknowledged before any fix is scoped, and a critical issue is worked ahead of everything else on the site. 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.

10. Everything else in the Trust Centre

• Editorial policy

  Who writes and reviews the site, where every figure comes from, how often pages are re-checked, and what is deliberately not claimed.

• Correction policy

  How to report an error, who reads it, how reports are ranked, and what gets published when a figure changes.

• Who writes PayslipIQ

  The named editor of record, and the profile page behind the byline on every guide.

• Calculation methodology

  The rules the checker applies to tax, National Insurance, pension and student-loan lines.

• Extended worked examples

  A full month reconciled line by line, including net pay against salary sacrifice, and the cases the calculator does not model.

• AI limitations

  What the model reads reliably, where it fails, and when to escalate to payroll or HMRC instead.

• Payslip redaction guide

  Which fields to cover before you upload, which the check actually needs, and three ways to do it.

• Security posture

  Transport, payslip handling, access control, vulnerability disclosure and the certification position.

• Data processing

  What is processed, the lawful basis for each purpose, who else touches it and for how long.

• Data deletion policy

  What is held by default, what is never stored, and how to exercise the right to erasure.

• When to contact HMRC

  Where this site stops being useful and HMRC, payroll or an adviser has to take over.

• Accessibility statement

  A per-criterion WCAG 2.2 AA conformance register, with the evidence behind each claim and the open issues named.