Privacy Policy

This policy covers the personal data Candrecovia holds about you, why we hold it, who else sees it, how long we keep it and what you can ask us to do about it. It is written for the three groups of people the platform serves: candidates, recruiters and HR staff, and the companies that run a workspace, which is a company's own separate area on the platform. It is governed by the UK GDPR, the Data Protection Act 2018 and the law of England and Wales.

Some parts of the platform are not built yet. Where this policy mentions one, it says so.

The short version

• What we hold. Your email address, an optional name, security data such as a password hash and two-factor state, your IP address on certain records, and a record of what happened on your account. For a candidate, also your profile, the CVs you upload, your applications, your messages and interviews with companies, and your privacy settings.
• Why. To run your account and sign you in, to let candidates and companies compare, find and contact each other, to take payment for a paid plan, to protect the platform from attack and abuse, and to keep an audit trail.
• Who else sees it. Our hosting provider, our deployment pipeline and our mail relay. Also Stripe when a company buys a plan, a company member's own calendar if they connect one, and your employer's identity provider if your company has connected one. A company sees a candidate only as far as the employer-blind rules below allow. No analytics, no advertising, no data broker.
• Where it is. One rented server in Singapore, outside the UK. The safeguard for that transfer is still being confirmed. See International transfers.
• How long. Four kinds of record are deleted on a schedule, and How long we keep your data gives each period. Everything else stays until it is removed by hand or by an erasure.
• Backups. Every night and before each release, we copy the database and archive the platform's keys and stored documents. The copies stay on the same server.
• Sealed at rest. Your name, email address, profile, CVs and messages are encrypted in the database under a key held for you alone. That key is destroyed when your account is erased.
• What we never do. We do not sell your data. We do not use it to train an AI model, and we do not let a vendor train one on it.
• What you can do. Ask for a copy, a correction or a deletion, or object to processing based on our legitimate interests. When you are signed in, you can ask for a copy on the Your data screen, and a candidate can ask for removal there too. Otherwise, write to privacy@candrecovia.mehedihassan.top. We answer within one month.
• Scores. Fit scores are live. A score helps a person decide. Nothing on the platform rejects, shortlists or hires anyone by itself.
• If you are unhappy. Complain to the Information Commissioner's Office at any time.

Who we are and how to contact us

Candrecovia is a multi-tenant hiring platform operated by [OPERATOR LEGAL NAME], trading as Candrecovia, registered in England and Wales under company number [COMPANY REGISTRATION NUMBER].

• Data protection enquiries and rights requests: privacy@candrecovia.mehedihassan.top
• Legal and contractual matters: legal@candrecovia.mehedihassan.top
• General support: support@candrecovia.mehedihassan.top
• Postal address: [REGISTERED ADDRESS]
• ICO registration number: [ICO REGISTRATION NUMBER]
• Data Protection Officer: [DATA PROTECTION OFFICER, IF APPOINTED]
• Representative in the EU: [EU REPRESENTATIVE, IF REQUIRED]

Who is the controller for what

Two organisations can hold data about you here: us, and the company running a workspace you belong to or have applied to. Which of us is the controller depends on the processing.

Where a company is the controller and we are the processor, we act on its documented instructions and it decides what happens to those records. We are separate controllers rather than joint controllers: each of us decides its own purposes, and neither decides for the other. The processor terms required by Article 28(3) of the UK GDPR are in the Terms of Service. The written contracts with our own processors are not in place yet.

If your employer runs a workspace, or you have applied to a company, ask that company for its own privacy notice. It is the controller for the recruiting decisions it makes and for the records it holds inside its workspace.

What the platform can do today

What the software can do limits what can happen to your data, so it is set out here as fact rather than as a roadmap.

• The platform is deployed and publicly reachable. Its front page and these documents can be read without signing in. There is no public page for registering a company or a candidate.
• There are three sign-in pages: one for the platform operator, one for company staff and one for candidates.
• A candidate account is one with no active company membership. You cannot register one yourself. The platform operator creates it, or an account becomes one when its last company membership ends.
• Candidates keep a profile, upload CVs, compare themselves with jobs, apply, and exchange messages with companies, in the product or by email.
• Companies post vacancies, decide on applications, keep shortlists and arrange interviews. On the Team and Business plans they can also search for candidates who allow it.
• Fit scores and skill-gap reports come from fixed arithmetic. No model is called and nothing is trained.
• Paid plans exist and are charged through Stripe. Payments are switched off unless we switch them on.
• When you are signed in, you can ask for a copy of your data on the Your data screen, and a candidate can ask for removal there too. Notification preferences have a screen. There is no screen for reviewing what you have accepted.

The personal data we hold

Account and identity

The platform has no field for a phone number, a postal address, a date of birth, an age, a gender, a nationality, a photograph or an avatar, and it asks for none of them. The world region and time zone above are the only facts about where you are that it asks for, and neither is a nationality. A CV you upload, and anything you type into a free-text field, can contain any of them, because it holds whatever you put in it. That is covered under Special category data.

Authentication and security data

• Password hash. Your password is stored only as an Argon2id hash. We never hold the password itself. Accounts created by invitation or through company single sign-on have no local password at all.
• Password history. Hashes of passwords you previously used, so a password cannot be rotated back to one it replaced. This list is trimmed to a configured depth when you change your password.
• Multi-factor authentication state. A reference to your encrypted authenticator secret, when you confirmed it, hashes of your recovery codes including any you have already spent, and a marker that stops the same one-time code being replayed. We do not collect a mobile number for security.
• Passkeys. For each passkey you register, its public key, its identifier, the name you gave it and when it was last used. The private key never leaves your device.
• Codes sent by email. Where the platform operator allows a code by email in place of an authenticator app, we store a hash of the code and when it was sent and expires. The operator has to switch this on.
• Sign-in sessions. One record per sign-in, holding a hash of the session credential, the application you signed into, the session lifetime and when the session last proved a second factor. These records carry no IP address, no browser or device string and no location. Your IP address is still written to the audit record for the sign-in itself, described below, so a history of the networks you have signed in from does exist in the audit trail. The session record does not attach that history to a live session.
• Password reset and email verification requests. A hash of the emailed link, the address it was sent to, when it expires, whether it was used, and the IP address that asked for it.
• Rate limiting counters. Short-lived counters keyed on a hash of your IP address, or of the address typed into a sign-in form, so we can stop brute force and abuse. The raw address is never written to that store.

Your IP address

Your IP address is the only information about your device or network connection that we collect. We record no browser string, no device identifier, no screen size and no location. The address is stored in full and in readable form on audit and event records, on sign-in attempts through a company identity provider, on password reset and verification requests, on company signup records, on workspace invitations and on your acceptance of our legal documents. It is the most useful single field when investigating an account takeover, a fraudulent signup or an abuse complaint. When an account is erased, its IP address is cleared from its audit and acceptance records.

Activity and audit records

The platform keeps a durable audit trail. Every event the platform publishes becomes a record, rather than a chosen subset of security events. A record is written when, for example, you:

• sign in, fail to sign in, or are throttled;
• enrol a second factor, or fail one;
• sign out, or revoke a session;
• switch workspace;
• change your password;
• accept our terms or this policy;
• are added to or removed from a workspace;
• have a role or a permission changed;
• change your theme or accent colour;
• apply for a job, or have a decision recorded on your application;
• ask for a copy of your data or for its removal.

Each record holds the event type, its category, severity and outcome, the account identifier of the person who caused it, the actor type, the actor's IP address, the workspace it happened in, the entity it concerned, a correlation identifier, the event payload, a checksum of that payload and a list of any values that were redacted. Each record is also chained to the one before it by a hash.

Email addresses are kept out of these payloads. A failed sign-in and a password reset request store a one-way hash of the address instead, and a backstop redactor catches any address that reaches a payload by mistake and replaces it with a hash. The hash is not keyed, so someone who already holds a list of addresses could match one against it. The reason for hashing is specific to this product: on a hiring platform, being able to tell one refusal from another confirms that a named person is looking for work.

Messages we have sent you

When the platform sends you a message it stores the finished text, encrypted: the template it used, the subject, the rendered body, the structured values behind any link, whether and when it was emailed, and whether and when you opened it inside the platform. That last field is an in-app read marker, set when you open the message in the interface. It is not an email open. For each email we also record a hash and a masked copy of the address it went to, whether it was delivered, and any error.

The platform has 32 kinds of message. You can switch off 16 of them, in the app or by email: digests, announcements, alerts, notices about new messages and interviews, a job closing by itself, and being added to a workspace. The other 16 are how your account is operated, such as a password reset, a sign-in code or a notice about your data request, and they cannot be switched off. You change your preferences under notifications in your account settings, and every email you can switch off carries a link that does it in one step.

If an address bounces, or its owner asks not to be emailed, it goes on a do-not-send list as a hash and a masked copy, so it is not emailed again. That entry stays after an erasure, for the same reason.

Consent and acceptance records

When you accept our terms of service or this privacy policy we write an append-only record holding your account reference, which document you accepted, the exact version string, the URL the document was at, the workspace the acceptance was given in, how it was given, the IP address you accepted from and the time. Nothing updates one of these records, apart from an erasure clearing the IP address. If we publish a new version, that is a new record, and your earlier acceptance stays as it was.

An acceptance is written from three places only: completing a company signup, accepting a workspace invitation, and accepting a new version through the platform's own acceptance request. Today only company signup has a screen in the product. An account created through your employer's identity provider records no acceptance, because that route creates the account without presenting a document. If you hold one of those accounts, no acceptance record exists for you, and we will ask you to accept the first time the product is able to.

Workspace membership

If you work for a company that runs a workspace, we hold the link between your account and that workspace: when you joined, whether your membership is active or disabled, when it was disabled, which roles you hold, who granted them and when. Where an administrator grants or removes a specific permission, they must type a reason, and that reason is stored. It is written by one person about another, and it is disclosable to you if you ask for a copy of your data.

A candidate is an account with no active workspace membership. There is no separate candidate table: one account record serves candidates, recruiters and operators alike.

Signup and invitation records

Starting a company signup writes a pending record before any account exists. It holds the email address typed, the company name and the workspace handle, an expiry, whether it was redeemed, and the IP address of the person who filled the form in. No password is stored at that stage, because a credential for an account that does not exist would be left behind by every abandoned signup.

A workspace invitation record holds the email address of a person a company is recruiting to its workspace, who invited them, when it expires, whether it was accepted or revoked, and the administrator's IP address. That address can belong to a person who holds no account with us.

If a company invited you and you have no account here, the invitation email is our first communication with you. It names the workspace and the person who invited you. It does not link to this policy yet. Until it does, write to privacy@candrecovia.mehedihassan.top to ask who invited you and why. Your address did not come from any public source: a person at that company typed it. You can object to the record and ask us to delete it at the same address, and we will delete it.

Candidate profile and CV data

If you are a candidate, we hold what you put in your profile: a headline, a summary you write yourself, your years of experience, the role you want, when you could start, your skills with a level and years for each, and your employment and education history. A profile holds no address, no phone number and no date of birth. It asks for a count of years rather than the date of your first job, because a first-job date narrows down a date of birth.

• Your CVs. You can upload up to ten, each up to 5 MB by default, as PDF, Word, plain text or Markdown. Each is stored as an encrypted file on our own server, outside every web root, under a storage key that carries no user identifier and no filename. The database holds the original filename, the file type, size and checksum, the full text read out of the file, and the entries read from that text. An original filename often contains a person's full name, and the text contains whatever your CV contains.
• How a CV is read. By fixed rules. No AI model reads it. Each skill, employment and education entry is marked as declared by you or extracted from your CV. You can correct or delete an extracted employment or education entry, and keep an extracted skill as your own.
• Skills. Recorded against a controlled list rather than as free text, with your own level. For a skill read from your CV, a short quotation from the CV is kept as the evidence for it.
• Opening a stored CV. A stored document is handed out through a short-lived link this platform signs, rather than by signing in, so the link is the credential: anyone holding it can open that file until it expires. Every refusal answers the same "not found", so a link for a deleted file cannot be told apart from an invented one.

Applications, scores and your privacy settings

• Applications. When you apply for a job we hold the application: the job, the CV you chose, any cover note, its status, and when it was submitted and decided. Every change of status is kept in a history that names who made it and holds any note they wrote.
• Fit scores. For each comparison we store the score, whether an essential requirement was missed, a breakdown by requirement, the skill gap, and who asked for it. A newer comparison of the same profile and job replaces the older one.
• Shortlists and approaches. A company can keep shortlists of candidates, with a note against each. On the Team and Business plans it can send an approach, with a message, to a candidate who allows themselves to be found. We hold the approach, its status and when you answered it.
• Your privacy settings. Whether recruiters may find you, whether your name is hidden until you agree, how many open approaches and how many applications a week you allow, and the employers you have blocked, by name, email domain or company, with a note for yourself.
• Consent to reveal who you are. Applying to a company, or accepting its approach, records your consent to reveal your identity to that company, with when it was given and when it was withdrawn.
• Your pseudonyms. The token each company knows you by. It is a different random value for every company.

Interviews and messages

• Interviews. An interview a company arranges with you holds its format, its location or video link, its length, the times offered, its status, and a history of each change with who made it. The invitation we email you carries a calendar file naming you as the attendee.
• Messages. A conversation between you and a company holds its subject, each message and any files attached to it, up to five files of 5 MB each per message. A notice about a new message carries the message text.
• Replying by email. Each conversation has its own reply address. The mail server on our hosting account hands your reply to the platform, and it appears in the conversation within two minutes. We keep the words of your reply and any files we accept. We do not keep your sending address, the earlier messages quoted below it, your signature or the original email. While a company knows you only by its token for you, email addresses, web links, phone numbers and your name are removed from the words before the company sees them.
• The email itself. It is held on the server until it is processed, then deleted. An email that cannot be processed is kept for 14 days so it can be looked at, then deleted.

Billing for a paid plan

When a company buys a paid plan we hold its Stripe customer reference and the buyer's billing email, its plan and subscription, and for each invoice its number, amounts, dates and the address of Stripe's copy of it. Card details are entered on Stripe's own page and never reach us. Usage is counted per workspace, not per person.

Support views and data requests

If a platform operator opens a read-only support view of your account, we record who opened it, the reason they gave, and when it ended. A request you make for a copy of your data or for its removal is recorded with its kind, when it was received, its deadline and its outcome.

Digests and announcements

For each digest we record which period it covered and whether it was sent. For a candidate's monthly progress digest we keep a snapshot of your comparisons each month: how many, your best and median fit, and the skills you were missing. When an announcement is shown to you as a popup, we record the day and how long it stayed on screen, so it is not shown more often than its sender set.

Whether you have to give us your data

• Your email address is required. It is your sign-in identity and we cannot create or run an account without it. No law obliges you to give it to us. The consequence of withholding it is that you cannot hold an account.
• Everything in a candidate profile is optional, and so is a CV. A thinner profile means a score has less to go on, and nothing else follows.
• A display name, a theme and an accent colour are optional. Nothing follows from leaving them blank, apart from the interface showing your email address where a name would go.
• A second factor is required by default for a platform operator account, an account holding a platform role, and a Workspace Owner. The platform or a company can require one from everyone. For every other account it is optional.
• Where a company invited you, your email address came from that company rather than from you, and you gave us nothing.

Where your data comes from

• From you, when you fill in a form, upload a CV, apply, send a message, set a preference, accept a document or change a password.
• From your CV, read by fixed rules into skill, employment and education entries you can correct.
• From your browser and network connection, in the shape of your IP address, captured on the requests listed above.
• From a company, when an administrator invites you or changes your access and records a reason, and when the company decides on your application, writes a note, arranges an interview or messages you.
• From your employer's identity provider, if your company has connected Google Workspace, Microsoft Entra or another OpenID Connect provider, which the Team and Business plans include. We ask that provider for the narrowest scope it offers, "openid email", and nothing more. We do not ask for and do not receive your name, your photograph, your directory groups or any other profile claim. The only claim we store is your verified email address. We send no login hint, so we do not tell the provider who we think is signing in.
• From the platform itself, in the form of scores, hashes, timestamps, identifiers and audit records generated as you use it.

Why we use your data, and our lawful basis

Where we rely on legitimate interests we weigh our interest against your rights and freedoms first. The security and audit processing is narrow: an IP address, a hashed counter and a record of what happened. It does not build a profile of you, it is not used to make a decision about you, and it is not shared. We have not yet written a legitimate interests assessment for each of these purposes. Once one is written, ask us at privacy@candrecovia.mehedihassan.top for a copy of the one that concerns you.

Special category data and criminal offence data

We do not ask for special category data. There is no field anywhere in the platform for racial or ethnic origin, health or disability, religion or belief, trade union membership, sexual orientation, sex life, biometrics, genetic data, political opinion, criminal convictions, right-to-work status or salary. We do not collect it, and the matching design excludes age and every proxy for it.

The optional world region you may state about yourself is not special category data and we do not treat it as any. It is one of eight groupings covering the whole world, it is what you say it is rather than anything we work out, and you can clear it. A broad region is not an ethnicity, and we never use it as a stand-in for one. It changes no score, and no employer can search, filter or target on it. Where we count it, we count it only in groups of at least ten people. A smaller group is withheld, along with enough others that it cannot be worked out by subtraction. The component that works out the fairness measures receives those totals and nothing about any one person.

Three features accept free text you write yourself, and all three are live: the profile summary, messages, and an uploaded CV. A CV can mention a disability, a religious institution, a period of illness or a trade union role, even where you never meant to disclose any of it.

The platform does not ask for your explicit consent to any special category data a CV contains, and we have not yet written the appropriate policy document that Schedule 1 of the Data Protection Act 2018 requires. Leave out of your CV and your profile anything the platform does not need to match you to a job, such as your health, your religion or your ethnicity.

Who your data is shared with

Processors we use

A processor handles personal data on our instructions and cannot use it for its own purposes. These are the ones we use. The last three are used only in the cases each row names.

Each processor must be engaged under a written contract meeting Article 28(3) of the UK GDPR. Those contracts are not in place yet.

Inside the platform

Everything the platform holds sits on the one server we rent: a MySQL database, and stored files on that server's own filesystem outside every web root. The matching component runs on the same machine, listens only on the loopback interface and holds no database credentials at all. For talent search it keeps an index in memory, keyed by random references rather than by account. Nothing saves that index: the platform rebuilds it on a schedule.

What a platform operator can see

A platform operator account holds one or more of four roles:

• the Global System Administrator, who holds every permission;
• the Global Application Manager, who maintains the platform's catalogues, settings, billing records and email, and can also read accounts, workspace members, the audit trail and the application log, and work on data requests;
• the Global Support Engineer, who can read across workspaces to diagnose a fault and can change nothing without a time-limited grant;
• the Global Database Administrator, who inspects the database.

The operator console lists workspaces, their members, their roles and their pending invitations, and an invitation list is a list of addresses of people a company is recruiting.

Only the Global System Administrator can open a read-only support view of one person's account. It needs a written reason of at least ten characters, which is recorded. It lasts 15 minutes by default and never more than an hour, it can only read, and it hides your contact details. You can read a record of each support view of your account, with its reason, on your security screen and on Your data. You are not told while one is open.

The Global System Administrator can also give another operator a time-limited grant of a permission from a fixed list, for between 15 minutes and 8 hours, with a recorded reason. Queries run from the console's database screen are recorded in the audit trail, and statements run through the emergency database command are logged with the reason given. Access to the database from outside the platform, through the hosting account, leaves no record in the platform.

Your employer's identity provider

If your company has connected its own identity provider, signing in that way sends you to that provider and brings back a verified email address. Our outbound request to it carries no personal data: only single-use values and our own client credential. The company chooses the provider and controls which email domains may sign in. That provider is a controller in its own right and its own privacy notice applies to what it does.

We store no name from your provider, and we do not store the provider's own identifier for you. If an address arriving from a company's provider already belongs to an account here that is not a member of that workspace, the sign-in is refused rather than merged, and the refusal is audited at the highest severity. A company cannot take over a pre-existing personal account by asserting your address.

Our mail relay

Email leaves our server through an SMTP relay we configure. That relay sees the recipient address and the message text. Replies you send by email arrive at the mail server on our own hosting account, not at the relay.

Each message is sent as HTML with a plain-text copy. There is no tracking pixel, no click-tracking wrapper and no open-rate measurement, so we cannot tell whether you opened an email. The only image in a message is our logo, the same file for every recipient. It loads from our own site, or from an address the platform operator sets.

The application log does not hold the address an email went to or its body: an address written there is replaced with a hash or a marker.

Stripe

When payments are switched on and a company buys a paid plan, Stripe takes the payment. We send it the workspace name, the buyer's email address and a reference to the workspace, and the buyer enters card details on Stripe's own page. Stripe keeps its copy under its own terms, and an erasure here does not reach it.

A connected calendar

On the Team and Business plans, a company member can connect their own Google or Microsoft calendar. We keep only the credential that lets us add events, encrypted. A confirmed video interview is then created in that calendar with its title, which names the job, and its times. No one is added to the event.

AI vendors

No personal data of any candidate or recruiter is sent to an AI vendor. The platform has a catalogue in which an operator can configure a model as a plain HTTP request: a URL, headers, a body and a reference to an encrypted credential. Two things can send one of those requests.

• The Test button on the operator's own configuration screen. The console sends a fixed six-word string, "Reply with the single word: ready.", which is the default the endpoint falls back to. The endpoint accepts a prompt supplied by an operator calling it directly, so the fixed string is a default rather than a hard limit.
• Digest summaries, which are off unless the operator switches them on. When they are on, each company digest sends that company's figures for the period to the configured model: counts, skill names, its AI spend and short sentences about them. They name no candidate, company or person. A candidate's digest is never sent to a model.

The request builder can substitute exactly three values into a vendor request: the prompt, the API key and a named environment variable. It cannot substitute a database field, a user record or a configuration value, so there is no mechanism by which your profile, your email address or your CV could be placed into a call to a vendor. No AI model reads a CV, computes a score or ranks anyone.

What is retained from a test is the vendor's raw reply and a copy of the request as sent, both with the credential masked, plus an audit record holding the model name, whether it passed, the HTTP status, the duration, token counts and cost. No prompt text, no response content and no credential is written to the application log.

The vendor is chosen per model by whoever configures the catalogue, so there is no fixed list of AI vendors to publish, and we will not invent one. Whichever endpoint is configured receives only what this section describes. If that ever changes, this policy will name the vendor first.

No one else

There are no analytics providers, no advertising networks, no content delivery networks, no error-reporting services, no session replay tools and no third-party fonts. Loading a page of this platform contacts our own origin and nothing else. The pages we serve carry a Content Security Policy that restricts scripts, fonts and network connections to our own origin, permits images to be embedded inline in the page, and forbids the site being framed. An operator can fetch currency exchange rates from a public feed, and no personal data is sent to it. We send no event feed to partners.

Outside applications connecting to your account

A company on the Team or Business plan can register its own application, and the platform operator can register one from the command line on the server. An application can ask for sign-in, your profile and your email address, and to stay signed in. It receives your account identifier, your email address, whether it is verified, and your name. A token it obtains acts as you, with everything your account can reach.

There is no screen that asks for your agreement before an application reaches your account. An application can get access to an account only through a request made with that account's own signed-in session, and nothing in the product makes that request for an outside application today. A company that registers an application is responsible for how it uses what it receives.

Disclosures required by law

We will disclose personal data where the law requires it, for example in response to a valid court order or a lawful request from a regulator or law enforcement, and where necessary to establish, exercise or defend a legal claim.

The employer-blind identity firewall

The platform is designed so that matching happens without the matching component learning who you are, and so that a company learns who you are only when you let it. All of it is built.

The feature projection. What may cross to the matching component is a closed list of thirteen field names, enforced as an allow-list rather than as a filter. The list is: skills, skill levels, skill years, years of experience, education level, required skills, skill weights, required years, essential skills, minimum years, minimum education level, a pseudonym, and model hints. Every one is a taxonomy key or a number. There is no free text on that list, because a summary you wrote about yourself often opens with your name, names your employer and mentions the city you live in. Your headline, your summary, the quoted evidence for a skill and any employer name are excluded by construction.

That boundary is enforced three times over, in two languages. A deny-list of twenty-four field names, covering name, email, phone, address, postcode, date of birth, national insurance number, employer name, photograph, social profiles and more, is held on both sides. The sending half refuses to send them and the receiving half refuses to accept them, so a mistake on either side still fails closed. A third check inspects the finished payload by the shape of its values rather than by field name. The matching component refuses to start at all if it finds a database credential, because one there would mean the boundary no longer exists. The fairness measures reach the same component on a separate path, as totals per region and never per person.

The pseudonym. Each company knows you by a token issued for that company only, so two employers cannot join their records on the same person. It is random, not derived from your account identifier, which would be the same value everywhere.

Your settings. On your privacy screen you choose whether recruiters can find you, whether your name is hidden until you agree, and how many open approaches you allow. Both switches are on unless you turn them off. If you turn off hiding your name, you are named to every company the platform shows you to. You can also block an employer by name, by email domain or by company.

The order the platform applies. What a company sees of you follows a fixed order:

1. If you have blocked the company, it is never shown you, even if you applied to it before.
2. If you have turned off being found, or already hold as many open approaches as you allow, you are left out of that company's searches. You stay visible to a company you applied to.
3. If you applied to the company, or accepted its approach, it is shown your name while that consent stands.
4. Any other company is shown only its own token for you.

Withdrawing consent stops the platform showing your identity to that company from then on. It cannot take back what the company has already seen or recorded outside the platform. The firewall governs what the platform shows a company. It cannot stop you identifying yourself in what you write, and the security review in How we protect your data has not been completed for these controls either.

What the matching engine actually does

Matching is fixed arithmetic over skills, experience and education, with skills weighted most. No model is called, and nothing is trained on your data. For each comparison it gives a score, a breakdown by requirement and a skill-gap report that lists what is missing in order of priority. If you compare your own profile with a job, you see the same breakdown a company sees.

Talent search, on the Team and Business plans, ranks the candidates who allow themselves to be found against a role, using the same features. Each result is shown under the firewall order above.

Automated decision-making and profiling

Fit scoring is profiling, and it is live. For each candidate and role the platform computes a score, a breakdown and a skill-gap report. It ranks a role's applicants by score, and flags an applicant who misses an essential requirement as ruled out, listing them last.

No automated processing makes a decision about you. A person in the company records every decision on an application, and the history names who made it. Nothing on the platform shortlists, rejects or hires anyone by itself.

The platform also applies automated rules for security: a rate limiter that can temporarily block requests from an IP address, a sign-in throttle that can lock an account out for a window of minutes, and reuse detection that ends a session if a session credential is presented twice. These decide whether a request is served, not anything about you as a person, and a lockout expires by itself.

These commitments apply now:

• Ranking that hides a candidate from a recruiter's view is treated as within the scope of Article 22, whatever judgement the recruiter applies afterwards. A shortlist you never appear on is a decision about you.
• A person makes every decision, and a score is one input to it.
• Every decision on an application is recorded against the person who made it, so human involvement can be checked rather than assumed.
• Every score comes with a breakdown by requirement explaining how it was reached.
• You can obtain human intervention, express your point of view and contest the outcome. Write to privacy@candrecovia.mehedihassan.top. If the decision was made inside a company's workspace, that company is the controller and answers it, and we pass your request to it within 5 working days and tell you we have done so.
• Age, and every proxy for it, is excluded from the feature set.
• Systematic scoring of job applicants calls for a data protection impact assessment under Article 35. That assessment is not finished. What it finds may change how scoring works, and any change will be published in a new version of this policy. It is also where the Equality Act 2010 analysis of indirect discrimination in a skills model belongs.

International transfers

The platform's own components create no transfer between them. The database, the stored files, the queue, the audit trail, the backups and the matching component all sit on a single server.

That server is in Singapore, on a shared hosting account at [HOSTING PROVIDER]. Everything the platform stores is therefore held outside the United Kingdom. A transfer like that needs a safeguard under UK data protection law, and which one we rely on is still being confirmed. When it is, this policy will name it.

GitHub Actions runs our deployment pipeline and holds an SSH key to that server. Its own infrastructure sits outside the UK, so the same requirement applies to it.

Our mail relay is a genuine recipient of your email address and of the text of every message we send you. It is [SMTP PROVIDER / MAIL RELAY], located in [MAIL RELAY LOCATION]. Where it sits outside the UK, the same requirement applies.

Four further destinations can sit outside the UK:

• Stripe, which processes payment data wherever it operates, under its own terms.
• A connected calendar, wherever Google or Microsoft hosts that member's calendar. It receives a job title and times.
• Your employer's identity provider. Your company chooses it. Our outbound request carries no personal data about you.
• An AI vendor. Whoever configures a model chooses the URL. What is sent is a test string, an API key and, where digest summaries are on, a company's figures, so no personal data is transferred.

Once a safeguard is in place for any of these, ask privacy@candrecovia.mehedihassan.top for a copy and we will send it to you.

How long we keep your data

Four deletions run on a schedule: audit records, delivered event records, application log files, and copies of your data prepared for download. The table gives each one's default period and the range the platform operator can set it within. An erasure removes most of the rest, as Your rights describes. Everything else is kept until a person removes it by hand.

Where a period is not fixed, the criterion is that we keep a record no longer than is necessary for the purpose it was collected for, judged against the criteria in the third column.

If you want something removed sooner, ask us and we will do it by hand. See Your rights.

How we protect your data

These measures exist in the code today.

• Passwords. Argon2id, with 64 MB of memory, four passes and a single thread, taking roughly 180 milliseconds per hash. Not bcrypt, which silently truncates long passphrases at 72 bytes. Hashes are upgraded transparently when you next sign in if we raise the cost parameters. The plain password is never stored, and the application does not write it into any log.
• Two-factor authentication. Time-based authenticator codes, passkeys, and where the operator allows it a code sent by email, with single-use recovery codes stored only as hashes. Your authenticator secret has to be readable to verify a code, so it is encrypted at rest with AES-256-GCM under a per-secret data key, which is itself wrapped by a versioned master key held in a file outside the database. The enrolment QR code contains your email address, so scanning it puts that address into whichever authenticator app you use.
• Session credentials. Refresh credentials are 256 bits from the operating system's random generator, stored only as a SHA-256 hash, and rotated on every single use. Presenting one twice destroys the whole session family. That signs out the legitimate holder as well as a thief, so an unexpected sign-out is a safety measure working rather than a fault.
• Tokens in your browser. The access token is held in memory only. It is not in local storage, not in session storage and not in a cookie a script can read, because everything a browser can store is readable by any script that reaches the page. Access tokens last 15 minutes by default, capped at one hour. Every account except the platform operator's keeps its session in the open page only, so reloading or closing the page ends it.
• Transport and page security. Every connection between a browser and the platform uses TLS. The authentication cookie is marked Secure outside local development, is HttpOnly so no script can read it, is SameSite=Strict so it is never attached to a cross-site request, and is scoped to two narrow paths rather than the whole site. The pages we serve carry the Content Security Policy described above.
• Personal data sealed at rest. Personal data is encrypted field by field in the database with AES-256-GCM. A person's data is sealed under a key for that person, a company's records under a key for that company, and the records kept after an erasure under a platform key. Each key is wrapped by the master key. CV files, message attachments and copies of your data are encrypted on disk too. When you are erased, your key is destroyed, and what was sealed under it can no longer be read by the platform.
• What the sealing does not cover. IP addresses, timestamps and the application log are stored in readable form, and an emailed reply is held as received until it is processed. The backups are not encrypted as files, and the archive holding the master key sits in the same folder, which only the hosting account can read. A backup taken before an erasure can still be opened with that key until it rotates out.
• The secrets store. Authenticator secrets, a company's single sign-on secret, the mail password, AI credentials, calendar connections and the payment keys are each encrypted under their own data key, wrapped by the master key.
• The audit trail. Each record is chained to the one before it by a hash, and a signed summary of the chain is written outside the database every night, so a changed or deleted record can be detected. Operators with the right permission can read the trail in the console, and each reading is itself recorded.
• Minimisation in logs. Email addresses are hashed out of audit payloads. In the application log, an email address is hashed, and an address inside a message and anything shaped like a credential are replaced with a marker. The rate limiter and the sign-in throttle both hash their keys, so the counter store never accumulates a list of who has been trying to sign in. Sign-in throttling is keyed on the address as typed rather than on an account, so an outsider cannot learn which addresses exist here by watching which ones are throttled. On a hiring platform, whether a named person holds an account is itself sensitive.
• Isolation. Company data is scoped by workspace in the data layer with a fail-closed rule, and the invitation table, which is a list of people a company is recruiting, is scoped tightly for that reason.
• Backup and restore. A copy of the database, and an archive of the keys, stored documents and audit summaries, are taken every night and before each release. A release stops rather than proceeding if its copy fails. The backup folder and its files can be read only by the hosting account. Restore scripts exist for both.

The limits of those measures, stated as facts about what the platform can do today rather than as terms:

• Backups are held on the same server as the data they protect. There is no off-site copy and no measured recovery time. The operator console shows whether last night's backups exist, and offers no restore control.
• Revoking a session does not invalidate an access token that has already been issued. It stops working when it expires, within one hour at most and 15 minutes by default.
• The application log can still hold personal data that passed through a request, and removing it for an erasure is done by hand.
• The formal security hardening review has not yet been carried out.

If there is a data breach

If personal data we hold is lost, destroyed, altered, disclosed or accessed without authorisation, we will report it to the Information Commissioner's Office within 72 hours of becoming aware of it, where it is likely to result in a risk to your rights and freedoms, as Article 33 of the UK GDPR requires.

Where the risk to you is high, we will tell you without undue delay under Article 34, in plain language: what happened, which of your data was affected, what we are doing about it, and what you should do. We have not yet written a breach response procedure.

Your rights

You can object at any time to any processing we base on our legitimate interests, on grounds relating to your particular situation. Write to privacy@candrecovia.mehedihassan.top. We will stop that processing unless we can show compelling legitimate grounds that override your interests, rights and freedoms, or the processing is for the establishment, exercise or defence of a legal claim. Article 21 of the UK GDPR requires this right to be brought to your attention separately from everything else in this policy, which is why it is here rather than only in the list below.

Under the UK GDPR you also have the following rights. They apply whether or not you have an account with us, including where we hold your email address only because a company invited you to a workspace.

1. To be informed. This document, kept accurate and versioned.
2. Of access. A copy of the personal data we hold about you, and the supporting information.
3. To rectification. Correction of anything inaccurate, and completion of anything incomplete. Each employment, education and skill entry read from your CV is marked as extracted, so you can see which is which and correct it on your profile.
4. To erasure. Deletion of your data where one of the grounds in Article 17 applies, subject to the limits named below.
5. To restrict processing. To have us hold your data and stop using it while a dispute about accuracy or a legitimate interest is resolved.
6. To data portability. The data you gave us, in a structured, commonly used, machine-readable format, where processing is based on consent or contract and is automated.
7. To object. As set out above, including to the digests and announcements, which you can also switch off yourself.
8. Relating to automated decision-making and profiling. Not to be subject to a solely automated decision with legal or similarly significant effects. No such decision is made on the platform, and you can obtain human intervention, express your point of view and contest an outcome, as Automated decision-making describes.

You may also withdraw consent at any time where we rely on it, including your consent to reveal your identity to a company, which you withdraw on your privacy screen. Withdrawal does not affect processing carried out before you withdrew.

How to exercise them, and what happens

Write to privacy@candrecovia.mehedihassan.top. Tell us what you want and enough about your account for us to find it. We will respond without undue delay and in any event within one month, and we will tell you if we need to extend that by up to two further months because the request is complex. There is no charge unless a request is manifestly unfounded or excessive. We may ask you to confirm your identity, and where we do, the month starts when we have what we need.

How requests are handled today:

• If you have an account, you can do some of it yourself. Open Your data when you are signed in. From the candidate sign-in it has one button for a copy and one for removal, and it lists what we would keep before you press either. In the console it offers the copy only, and removal is by email. Writing to the address above reaches the same process.
• A copy is a file you download. We assemble it from every part of the platform as one JSON file, which is the structured, commonly used, machine-readable format Article 20 asks for. We tell you in the product and by email when it is ready. It is encrypted while it waits and is removed on the date shown beside it, 14 days after it is made by default, whether or not you have collected it. You can ask again at any time.
• A removal waits 14 days. You confirm your identity to ask for it, we tell you the date, and you can cancel it on the same screen until then.
• Erasure has limits we can name. Removing your data is carried out by the software and it does not delete your account row. It replaces your email address with one that can never receive mail and removes your name, your profile, your CVs, your applications, your messages and interviews, and every credential. It destroys the key your data was sealed under and marks the account permanently closed. Your IP address is cleared from your audit and acceptance records, and those records keep the account reference rather than being deleted, relying on Article 17(3)(b) for the accountability duty in Article 5(2) and Article 17(3)(e) for legal claims. A record treated that way is still personal data under the UK GDPR, and we do not present it as erased. The records of your data requests and of each support view of your account are kept too. Stripe's copy of a company's billing details is not reached. Anything you ask us to delete stays in a database backup until that copy is rotated out.
• What stays is listed for you, with the reason for each. The screen shows it before you ask, and afterwards your request shows what was removed. Every line names the ground we rely on, so you can check it.
• Some of it may be a company's. Where a company is the controller for a record, such as an application or a message in its workspace, we will pass your request to it and tell you which parts it answers.
• A few parts hold data only while they are working with it. Messages waiting to be sent, temporary caches, and sign-ins part way through. Nothing in them can be looked up by name, and each clears itself within minutes.

If you received a workspace invitation you never asked for and want the record removed, write to the same address. Tell us the invitation email you received and we will remove it.

If you signed in through your employer's identity provider, some of what you want may be held by your employer rather than by us. We will tell you which is which, and you should ask your employer for its own privacy notice.

Cookies and what we store on your device

The platform stores one cookie on your device, a few values in your browser's local and session storage, and an offline page in its cache. There are no analytics cookies, no advertising cookies, no third-party cookies and no tracking pixels anywhere, and no third-party script is loaded by any page. Reading this page stores nothing.

Regulation 6 of the Privacy and Electronic Communications Regulations covers any storage of information on your device, not only cookies, so everything is listed. Each item either is needed for a service you asked for or keeps a local copy of a choice you made in the interface, and we treat all of them as strictly necessary. That is why you are not shown a cookie banner. If a third-party script, font or analytics tool is ever added, this section changes and consent will be sought before it loads.

Apart from the offline page, nothing is written until you sign in or set a preference. Our framework includes a database-backed session store, but the interface issues no framework session cookie, because the API is stateless and authenticates with bearer tokens. If that changes, this policy and this table change with it.

Clearing your browser storage does not end a session. Signing out is a server call that revokes the session family and clears the cookie, and that is the way to end one.

Marketing, selling and AI training

Besides the email your account needs, we send digests to candidates and companies, and the platform operator can send announcements. Each of those can be switched off in your notification settings or from the link in the email.

We do not sell your personal data, and we do not share it for anyone else's marketing.

We do not use your personal data to train an AI model, and we do not permit a vendor to train a model on it. No candidate or recruiter personal data is sent to an AI vendor. If that changes, this policy will name the vendor and the terms before a single record is sent.

Children

Candrecovia is a hiring platform for people of working age and it is not directed at children. Our Terms of Service set a minimum age of 16 to hold an account.

That 16 is a contractual floor rather than a data protection one. Section 9 of the Data Protection Act 2018 sets 13 as the UK age at which a child can consent to an information society service, and it applies only where consent is the lawful basis, which is not the basis we rely on to create or run an account.

We hold no date of birth and no age, so we cannot verify what you tell us. If you believe a child has given us personal data, write to privacy@candrecovia.mehedihassan.top and we will remove it. We have not yet assessed against the ICO's Age Appropriate Design Code whether this service is likely to be accessed by children.

If the service is sold or closed

If the platform, or the business running it, is sold or transferred, your personal data may transfer with it. We will tell you before that happens and name the buyer, and the buyer will be bound by this policy until it publishes its own and gives you notice of the change.

If the service closes, we will tell you before it does, give you a window to ask for a copy of your data, and delete what we are not required by law to keep.

Changes to this policy

This is version 1.3, in force from 25 October 2026. It replaces version 1.2, which was in force from 14 September 2026. Version 1.2 described the platform as it stood then, and much of what the platform does now was built after it. What changed:

• candidate profiles, CV upload and reading, jobs, applications, fit scores, interviews and messages, including replies by email, are described as live, with the data each one holds;
• the employer-blind controls are described as built: the pseudonym, blocking, the consent to reveal your identity and the settings you choose;
• Stripe, the calendar providers and any configured AI model endpoint join the processors, and the server's country is named;
• personal data is sealed at rest under a key for each person, and that key is destroyed on erasure;
• each scheduled deletion has its default period and its range, and backups are taken every night;
• everything the platform stores on your device is listed, and so are the messages you can switch off;
• what a platform operator can see is described, including the read-only support view.

Version 1.0 was in force from 26 August 2026 and 1.1 from 1 September 2026. Version 1.1 added two optional preferences you set yourself: the currency amounts are shown in, and the world region you are from. Version 1.2 recorded that asking for a copy of your data and asking for its removal became things you do yourself in the product.

Every version is published at a stable URL and carries a version string, because the platform records which version you accepted, when, and from which IP address. Raising the version marks the new one outstanding against every earlier acceptance, and your earlier acceptance stays as it was recorded.

We will raise the version and tell you before we use your personal data for a new purpose, as Article 13(3) of the UK GDPR requires. Continuing to use the platform after a change does not remove your right to object or to withdraw consent.

The platform will not force you to re-accept before you can carry on using it. No screen yet shows you which version is outstanding or what you have already accepted. Ask us at privacy@candrecovia.mehedihassan.top and we will send you the record.

Complaining to the regulator

If you are unhappy with how we have handled your personal data, tell us first at privacy@candrecovia.mehedihassan.top so we can put it right. You also have the right to complain to the Information Commissioner's Office at any time.

Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF. Helpline 0303 123 1113. Online at ico.org.uk/make-a-complaint.

You may also seek a remedy through the courts.

Governing law

This policy, and any dispute arising out of it, are governed by the law of England and Wales. The courts of England and Wales have jurisdiction, except that if you are a consumer living in Scotland or Northern Ireland you may also bring proceedings in the courts of the country you live in, and you keep the benefit of any mandatory consumer protection in force there.