Data processing agreement
Last reviewed 26 September 2026. Version 3.7+1.5-6ab85176b5c5.
This is the agreement that governs any personal data Second Lens processes for you when you use the checker. It takes effect when you start using it and lasts as long as you do.
It is short because there is very little to govern. Nothing about a check is stored, so most of what a processing agreement usually has to describe does not arise here. What is held is listed in full on What is held, and for how long, and this document does not add anything to that list.
Who is who
You are the controller. You decide what goes into an advert and whether to publish it.
Second Lens is the processor, acting on your instructions, which are: read this advert against the rule set and give the answer back.
What is processed, and why
| Category | Why | Where it goes |
|---|---|---|
| The text of a job advert, and the details written into it | To check it | Your browser; our server function while the check runs; and a model API for the wording check. None of it is stored |
| A connecting IP address | To meter the allowance, and to see overuse | An operations log, 30 days; and a one way digest in the allowance ledger |
| A connecting IP address and the browser's own description of itself, where a licence key is in use | To count a licence's checks against the key rather than the person, and to give whoever bought it an audit trail of what was run on it | A per licence record, kept as long as the licence and deleted with it |
| A name, an email address and, if you give it, your organisation's name, with your answers, if you answer the questionnaire; and, recorded with them, which allowance tier you were on and how many checks you had used, which screen you opened the form from, and whether it was a phone or a desktop | To reply to you, and to understand how adverts are checked today so the product can be improved | A store an operator reads, deleted on request |
| If you press Report: the reason you pick, a short note if you write one, where on the screen you pressed it, the size of your browser window, the application version and the reference on your advert; and, on a flag, the passage it fired on, the rule and what it suggested | To correct the product and the rule set | A store an operator reads, deleted once acted on |
| A 64 character fingerprint of a check record, when you download the PDF | To sign the record, so it can be shown later to be unaltered | Our signing endpoint, which returns a signature and keeps nothing |
An advert should not contain personal data. Where a contact name and a work telephone number or address appear in one, as they routinely do, those are processed as part of the advert and are subject to everything on this page.
Signing a record
When you download the PDF, your browser sends us one thing: a SHA-256 fingerprint of the fields printed on the face of that record. Sixty-four characters. No advert text, no reference number, no account value, and nothing that can be turned back into any of them.
We stamp our own UTC time on it, sign the two together, and send the signature back for your browser to print. Nothing is written down at either end. There is no row, no counter and no log line carrying that fingerprint, which is why this could be added without changing anything on "What is held, and for how long".
The signature lets anybody check that the document has not been altered, offline, using a public key we publish. It does not prove the time independently of us: the clock is ours and we use no third party timestamping authority. The record says so on its own face.
No candidate data is accepted at any point. There is nowhere in this product to put information about an applicant, and doing so would be a breach of the terms of use.
Where inference happens
This is the part most buyers want in writing, so it is here rather than in a footnote.
A check runs in a server function, not in your browser. When you press the button, the advert and the details it needs (whose jobs they are, and the organisation, contact and privacy link that go into the advert) are sent to that function. It reads the advert against the rule set first, which calls no model, and then sends the advert to Anthropic's model API for the wording check. The answer comes straight back to the tab that asked for it. Nothing is written to any store on the way past.
We send the advert, the rule the model is being asked about, and the standing instructions that go with it. We do not send your name, your address, your allowance, or anything else about you. The API key is held in the deployment's environment and never reaches a browser.
Anthropic's own terms for API traffic apply to what we send. As at the date this page was last reviewed, Anthropic's commercial terms say it may not train models on what API customers send or receive. That is their commitment rather than ours, and it is worth confirming against their current terms rather than taking it from here.
Where the model runs. Anthropic lets a customer pin the model to the United States, at a higher price, or leave it free to run in whichever country Anthropic chooses. We have left it free, so the wording check may be read in any country Anthropic uses. There is no option to keep it in the United Kingdom or the EU. The server functions and the stores run in the United States.
Sub-processors
| Who | What for | Where |
|---|---|---|
| Netlify | Hosting, the server functions, and the stores listed in the retention page | United States |
| Anthropic | The model that reads the wording | Wherever Anthropic runs the model, which may be any country it uses; what it stores is held in the United States |
We will tell you before adding another, and you may object.
International transfers
Both sub-processors are outside the United Kingdom, and Anthropic may run the model in countries other than the United States. Transfers are made under the UK International Data Transfer Addendum to the European Commission's standard contractual clauses, which both hold in their data processing terms, and Anthropic's apply wherever it runs the model. The Information Commissioner's Office revised its guidance on international transfers on 15 January 2026, for the test that took effect on 5 February 2026. Given what is actually sent, a job advert that is about to be published, the transfer risk assessment is short, and we will share it on request.
Security
- Every stored thing is rebuilt field by field from a list of allowed fields, so a field nobody designed for cannot be stored.
- The operations log has no field for an advert, an excerpt or a job title.
- The allowance ledger holds a one way digest of a connection, never the connection.
- A licence key is stored as a digest, so a leaked store hands nobody a working key.
- A strict Content Security Policy with no inline script or style, so a single injection bug does not become a running script.
- The admin console is behind a password held in the environment, with the session as a signed HttpOnly cookie the page cannot read, and guessing is throttled.
Your people's rights
Because nothing about a check is stored, most requests resolve to "there is nothing held". For the three stores that do hold something, a request reaches us at hello@secondlens.co.uk and we act on it within five working days. A questionnaire entry is deleted with one press.
A complaint about how we handle personal data has its own process, on What is held, and for how long.
A breach
If personal data we hold for you is lost or exposed, we will tell you within 24 hours of knowing, with what we know at the time rather than waiting until we know everything, and we will keep telling you as we find out more. You are the controller, so notifying the Information Commissioner is yours to do, and we will give you what you need to do it.
When you stop
There is nothing to return, because there is nothing held about your checks. The stores listed in the retention page expire on their own schedules, and we will delete anything still in them on request.
Getting in touch
Second Lens, by email at hello@secondlens.co.uk.