How RoleDemand handles personal data

RoleDemand, operated from the United Kingdom by its founder, is the data controller for this website, the request form, client accounts and the job-posting pipeline. Questions, requests and complaints all go to prav@roledemand.com, and a person answers them.

There is no data protection officer, and UK law does not require one here: the processing this page describes is neither large-scale nor of special categories of data. What there is instead is one operator who can see the whole system, and an audit log that records what the operator does in it.

Almost nothing. These pages set no cookies, run no analytics and load nothing from anyone else: every script, style and font is served from this domain, and the security policy the site sends with every page forbids outside connections. There is no record that a given person read a given page.

Two honest qualifications. The platform the site runs on keeps short-lived infrastructure logs, as every web host does. And the site throttles abusive traffic by connecting address; that count lives in memory and is gone when the process recycles, so it never becomes a stored record of you.

If you switch the site between paper and dark, the choice is saved in your own browser's local storage. It never leaves your machine and we never see it.

The form asks for your agency's name, your name, a work email address, one or more markets from a list, which plan interests you, up to five employer names and an optional note. Submitting stores exactly that, once, in the control-plane database, where the founder reads it and replies to the address you gave within one working day. No account is created, no automated email is sent, and the address joins no marketing list.

Beside the row itself, RoleDemand stores a keyed one-way hash of the connecting address, so repeated abuse can be recognised without keeping anybody's IP address; the raw address is never stored. A hidden field on the form catches form-filling scripts, and a submission that fills it is discarded rather than stored.

Writing to prav@roledemand.com instead puts the same details in a mailbox rather than the database, and they are handled the same way: read by a person, answered by a person, added to nothing.

For each named user at a client agency: an email address, a name if one was given, a role, whether the account is active, and when it was created and last signed in. Around that sit the records that make access answerable: which modules and employers each account may see, and an audit log of every sign-in, every failed attempt and every change to that scope.

Sign-in works by single-use links rather than passwords, so there is no password to store or to lose. A link expires 15 minutes after it is issued, 7 days for a first invite, works exactly once, and is stored only as a hash, so even a copy of the database could not be replayed into a session. Links are sent one at a time and join no marketing list; during the founding period the founder may send them personally rather than by machine.

The audit log exists for the client as much as for us. It is the complete answer to "who could see what, and when", which is the question an agency asks after a consultant leaves. Entries carry the account, the action and a keyed hash of the connecting address, never the raw address.

RoleDemand reads the public careers pages and applicant-tracking endpoints of named employers, on a schedule and politely, and keeps what a posting says about the job: title, location, department, description, and a salary where the employer published one. A posting is an advertisement an employer wrote in order to be read. Most contain no personal data at all, and the pipeline is built to keep it that way.

Employers sometimes write a recruiter's email address or a direct phone number into the body of an advert. Those are removed as the posting is read, before anything is stored, and each removal leaves a visible marker in the text. What is not removed is a name used to describe the job itself, a role reporting to a named head of department for instance: that is the employer describing their own public structure, and cutting it would falsify the advert.

Never collected

• Candidate names, contact details, CVs or applications
• Anything behind a login, a paywall or an authenticated API
• Postings from job boards that aggregate other people's adverts
• Profiles of individuals, built, matched or enriched from any source

After that stripping, posting text is read by a language model to classify each role's function and seniority. An employer, or a person named in an advert, who wants the stored text corrected or removed can write to prav@roledemand.com and it will be done.

UK GDPR requires a lawful basis per purpose, and this table is the map. Where the basis is legitimate interests, the balancing assessment has been made and you have the right to object at any time; where it is contract, the processing is the service itself.

Eight providers, each doing one job, and this is all of them. None may use the data for purposes of their own, and nothing is sold or shared with anyone for advertising.

Some of it reaches the United States, because most of the providers above are American companies. The control-plane database itself sits in London, but Vercel, Cloudflare, GitHub and Porkbun operate US infrastructure, so a form submission, an email or a sign-in can be processed there.

Those transfers rest on the safeguards UK law provides for exactly this: the UK Extension to the EU-US Data Privacy Framework, called the UK-US data bridge, where the provider is certified under it, and otherwise the ICO's International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses, agreed as part of each provider's terms. The posting text sent to Cerebras has had contact details stripped before it leaves, so what crosses that particular border is written to contain no personal data at all.

For as long as the reason it was collected still stands, and no longer. The table below is the practice. If you want something about you gone sooner, ask, and unless a legal duty requires keeping it, it goes.

By keeping the attack surface small and the defaults closed. Everything moves over TLS, there are no passwords to steal, no third-party scripts to compromise, and one operator with one audited way in.

• Sign-in links and invites are stored only as hashes; a stolen database copy cannot become a session
• Session cookies are signed, HttpOnly and Secure, and the dashboard trusts only the signed claims, never anything typed into a request
• IP addresses are stored only as keyed one-way hashes, never raw
• Application logs censor email addresses, tokens and cookies before a line is written
• Each client's dashboard is built separately: data outside your scope is absent from your build, not hidden inside it
• Every sign-in, every failure and every change to access lands in the audit log

RoleDemand holds no security certification and does not claim one. What it has is the list above, a design small enough for one person to audit, and providers who publish their own certifications and are named in full on this page.

Two, both strictly necessary for signing in, which is why there is no cookie banner: UK law asks consent for optional cookies, and there are none here. Nothing on this site follows you around it, let alone around the web.

The paper-or-dark preference is not a cookie: it lives in your browser's local storage and is never sent to the server.

The UK GDPR ones, in full: to be told what is held about you, to have it corrected or deleted, to restrict or object to its processing, to take a copy elsewhere in a usable format, and not to be subject to automated decisions with legal or similarly significant effects, of which RoleDemand makes none.

To use any of them, write to prav@roledemand.com. Expect an answer within a month. Where it is not obvious that you are who the data is about, expect to be asked to show it: handing one person's data to another on a polite request is the exact failure these rights exist to prevent.

To RoleDemand first. Since June 2026, UK law expects complaints about data handling to go to the organisation before the regulator, and this one takes them at the same address as everything else, acknowledges them within 30 days, and answers without undue delay.

If the answer does not settle it, you have the right to complain to the Information Commissioner's Office, the UK regulator, at ico.org.uk.

On 13 August 2026. When the product changes in a way that changes any answer above, the words change here and the date moves with them. Clients are told directly when a change matters to them.

The plainer questions about where the data comes from and what is refused are answered on the answers page. Anything neither page answers, ask.