Privacy policy — rinkats

Effective 15 October 2026. This page is versioned: the version and the date it came into force are shown above.

1. Who we are, and who decides

rinkats is recruitment software for agencies, operated by [[LEGAL ENTITY]], [[ADDRESS]] ("rinkats", "we", "us"). This is our one privacy policy, for everyone rinkats handles data about: visitors to our website, people looking for work (candidates), the people who work for an organisation on rinkats (recruiters, leads, administrators and billing staff), interviewers, and the contacts at an organisation's clients and partner agencies. It explains what personal data the rinkats service handles, why, who else touches it, how long it is kept, and what you can do about it. It covers the website, the public jobs board, the recruiter, candidate and interviewer portals, the API and agent interfaces, and the rinkats browser assistant.

Who decides what happens to the data. The law gives the party that decides why and how personal data is used the main responsibility for it (in India the "data fiduciary", in Europe the "controller"); the party that handles it on someone else's instructions is the "processor".

The organisation decides for the records it keeps in rinkats — its candidates, client and agency contacts, interviewers, requirements, interviews, notes, placements and invoices. For that data the organisation (the recruitment agency) is the data fiduciary and rinkats is its processor.
rinkats decides for the accounts people hold with us, for candidates' own accounts on the candidate portal and what they put there, for visitors to our website, for billing, and for running, securing and improving the service. For that data rinkats is the data fiduciary.

2. The short version

Every organisation's data is its own. Every record in rinkats belongs to exactly one organisation and is never shown to another organisation.
Candidates do not see your data; you see the candidate data you hold. An organisation sees what it has collected about a candidate. A candidate sees only their own profile and applications, and what an organisation chooses to send them.
Sign-in details and candidates' own accounts are encrypted. The email address and phone number you sign in with, and everything a candidate puts in their own rinkats account, are stored encrypted, and every stored file is encrypted (section 17). An organisation's own candidate records are not encrypted, so its recruiters can search them.
Opening a candidate record is recorded. Every time someone in an organisation opens a candidate's record or resume, or searches or exports candidates, we record who did it and when, and the organisation's administrators can see that record at any time (section 13).
Candidates can delete their own account at any time. Recruiters who already hold a copy keep it (section 16).
Your emails are kept, and only you can open them. A copy of each email rinkats sends for your organisation is stored so your administrators can see what went out. No other organisation can see it.
rinkats uses the data on the platform to run, secure and improve the service. We do not sell it, and we do not share it with anyone for their own purposes. We do use service providers to deliver the service (section 12), and they act only on our instructions.
rinkats staff can see your data, and sometimes read it. Our superadmins and developers can access every organisation's data, and from time to time read it to improve the quality of the application or to give support — debugging a problem, or reviewing a record directly at your request. We do not share it with anyone else unless law enforcement or a court order requires us to (section 13).
Deleting means removing from the service. A candidate's own account is deleted; an organisation's records are anonymised rather than physically erased from every copy (section 16).

3. If you work for an organisation (recruiters, leads, admins, billing)

What we collect

Your account: name, email address, phone number if you add one, profile photo if you upload one, time zone, password (stored only in a scrambled, one-way form), your roles and the organisations you belong to. Where we offer sign-in with another account (Google, Microsoft, LinkedIn or GitHub) and you use it, that provider tells us your name, email address and profile picture, and we keep the link to that account.
Your organisation's records: clients, agencies and their contact people, requirements and contracts, candidates, resumes and attachments, pipeline stages, notes, comments, interviews, meetings, scorecards, skill test results, offer letters, placements, fees, commissions and invoices — everything your team enters, uploads or imports. Candidate records can include salary, expected salary, offers in hand, notice period, location, education, work history and links to online profiles.
Spreadsheets you import: the file, a copy of its rows while the import runs and afterwards (so you can see what was read and why), and the column choices you made, remembered for your organisation.
Email: for each email rinkats sends for your organisation, a log entry (recipient, template, subject, delivery status and the mail service's reply) and a stored copy of the message itself — the HTML, the text, the sender line and the attachments. A file you attach to an email you write in rinkats is checked for malware first and stored only when it is clean; a file the check suspects is refused and nothing of it is kept. Emails that carry a sign-in code or a one-use link are logged but never copied. Email rinkats sends on its own behalf rather than an organisation's — sign-in codes, account set-up links, the notice that an account was deleted — is logged with the recipient's address encrypted and only a masked form shown, such as the first letter and the domain.
AI work: the inputs sent to an AI model for a task you ran (for example a resume, a job description or a set of notes), the output, and a record of the call — feature, model, tokens, cost, time, and who started it. Your conversations with the in-app assistant are kept, together with short notes the assistant saves so it can remember your preferences. So that you can find a conversation again by its subject, a short summary of each exchange is also kept in a form that can be searched by meaning. Files you give the assistant — a resume, a set of resumes, a spreadsheet, a document — are checked for viruses, stored encrypted and kept with that conversation, where only you can open them again. When the assistant reads candidates' details out of resumes for you to review, that draft is kept, encrypted, with the conversation; nothing in it becomes a candidate record until you save it.
Agents and the API: the keys your organisation creates (stored only in a scrambled form), the outside applications you authorise to act for you, and a record of each call they make — which action, what was asked, the result and how long it took.
The browser assistant: see section 9.
Identity verification: a recruiter who wants to see the contact details rinkats holds for candidates (section 4) verifies their identity once, by a short video check run by our verification provider, Cashfree. We keep Cashfree's reference for the check, whether the name it verified matched the name on your account, and the dates it was approved and is due again (every 24 months by default). We do not keep your identity document, its number, a photo or the recording; those stay with Cashfree under its own terms. The check is done once for you across every organisation you work in, and organisation administrators and rinkats can see whether you are verified and when.
Candidate access records: every time you open a candidate's record, view or download a resume or a formatted resume, export candidates, or read candidates through the API or an agent, we record who you are, your role, which candidate, where in the product, and when, with your IP address and browser where we have them. A search or a list records one entry with the number of candidates it showed rather than one per candidate. These records are written at the moment of the read, cannot be changed or deleted by anyone in your organisation, and your organisation's administrators can see them live, filter them and download them. rinkats sees counts per organisation.
Contact access records: every time you open contact details rinkats holds for a candidate, or the original resume file of such a candidate, we record who opened it, for which candidate, where in the product and when. Your organisation's administrators can see these records for their organisation; rinkats sees counts per organisation.
Reports and reviews: a candidate can report a message you sent; your organisation's administrator or rinkats can flag your account for review; and rinkats flags an account automatically when it opens unusually many held contacts in an hour or receives several candidate reports in a month. While a review is open, held contact stays hidden and your messages to candidates are paused; everything else works. We keep the reason, any note the reporter wrote, and the outcome. You are told that your account is under review, but not who reported it. Only rinkats closes a review.
Usage and security data: sign-in sessions with IP address and browser, your acceptance of legal documents with IP address and browser, an activity history of changes to records (who changed what, and when), which records you have read, errors, and feature usage. If a stored file fails its integrity check while you are opening it, the security alert our team receives records which file it was, your account, IP address and browser.
Billing: plan, payments and refunds; the billing address, billing contact (name, email, phone) and tax number your organisation gives us; and the notifications our payment provider sends about each payment, which carry the payer's name, email address and phone number, the kind of payment method and the masked details the provider includes. Card and UPI details are entered on the payment provider's own form; we never receive a full card number.

Where candidate data comes from. Candidates you add yourselves; resumes you upload (one at a time, in bulk, or through the API and agent interfaces); spreadsheets you import; profiles you capture from job portals with the browser assistant while you are signed in to that portal (section 9); and applications candidates send to your published jobs. Your organisation is responsible for having a lawful reason to hold the candidate data it brings in and for telling candidates about it where the law requires.

Who in your organisation sees what. Access follows the roles your administrator assigns, and your administrator can hide fee details from some roles. Stored email copies are opened from the organisation's email log, which only administrators can open. Interviewers see only the interviews assigned to them (section 5).

4. If you are a candidate

You may be in rinkats in two ways, and they are kept apart.

You use the candidate portal or apply to a job. Applying needs no account: your name, email address and resume are the application. If you upload a resume before you create an account, we keep it for up to 48 hours and a cookie in your browser remembers it, so it can be attached when you finish. With an account we hold your name, email address, phone number if you give it, your location, the resumes you upload and what we read from them, the applications you make, your messages with recruiting teams, interview times, your availability, your skill test results, and whether you have chosen to let recruiters find you and when. All of this is stored encrypted (section 17). You can upload up to 4 resumes every 2 hours; uploading a file identical to your current resume changes nothing, and a newer upload stops the reading of the previous one. When you move one of your candidate profiles to another email, we keep the address you asked to move a profile to until the code sent to it is used or expires.

Reading your resume. When you upload a resume we read it into a short searchable profile — skills with years, roles, education, location, notice period and expected pay if you give them. Depending on how rinkats is set up at the time, that read is done without AI, or by an AI model whose result reaches you first as a draft: you check it, correct anything that is wrong and confirm it. Nothing the AI read reaches recruiters until you confirm it. When you ask the AI to fill in your profile from a resume, that too is a draft you review before it is saved. Your resume is data to the AI model, never instructions, and we do not train models on it. To suggest roles, we compare your profile with the text of public job descriptions; this is a similarity measure, not a judgement of you, and no agency sees it.

Being found by recruiters — only if you choose. Your portal account has a box, Let recruiters find me, unticked until you tick it. While it is unticked, recruiters cannot find you in search on rinkats. While it is ticked, recruiters on rinkats can find your profile when they search for skills, experience or a role — never by part of your name, email or phone. They see your first name and the initial of your last name, your skills, experience, education, location and a formatted copy of your resume with your contact details removed; they never see your email address, phone number or original resume file unless they have verified their identity with us. Search is limited on purpose: nothing is shown before a recruiter searches, results come 10 at a time (50 at most per request), results below a relevance level are not shown at all, and each recruiter has an hourly and a daily limit. Every search, every profile opened and every original file opened is recorded, and a recruiter whose searching looks like an attempt to copy the pool in bulk is paused while we review their account. Untick the box and you leave search at once. If a recruiter adds you to their candidates, you are told inside rinkats and by email — the email names the role at most, never the agency or the recruiter — and that agency gets its own copy of your profile and resume, with your contact details held by rinkats.

When you apply to a role, the organisation behind it receives your application and the resume and profile you send with it. Each application is a separate, private thread with that one organisation; no organisation can see your applications to another. The jobs board and your portal do not name the agency behind a role. When you upload a newer resume, it is offered to every organisation you have applied to; if an organisation has not responded to the offer within 60 days, the newer resume is passed to it automatically. A resume a recruiter uploaded about you is never shown in your portal, and what you upload is not shown to an organisation until you apply to it.

Deleting your account. You can delete your rinkats account yourself, from your profile, at any time. Before you confirm, we tell you how many active applications you have. Deleting removes your profile, your resumes and your sign-in, and takes you out of recruiter search at once; recruiters who already added you or received your application keep their own copy. Section 16 says exactly what is removed and what remains.

A recruitment agency holds your details. An agency using rinkats may hold your resume and contact details, salary details, notes, interview feedback, skill test results and the stage of your candidacy — collected from you, from a job portal, from a referral or from a file it imported. The agency may send your profile to the employers it recruits for. rinkats may use AI to read your resume, to assess how well it fits a role, and to look for signs of fraud (for example a degree from an institution on a public list of unrecognised universities); the result is advice to the agency's recruiters, and a person decides what happens (section 11). That agency decides how it uses your data; rinkats stores and processes it for the agency. An agency's own records are not encrypted field by field, so its recruiters can search them by part of a name or an address; every time someone there opens your record or resume, it is recorded (section 13). Questions or requests about that data go first to the agency; we will help it answer, and you may also contact us (section 23).

Your email address and phone number are held by rinkats. When you apply through rinkats — on a job page or from your candidate account — or a recruiter adds you from search, your email address and phone number are given to rinkats, not to the recruiter. Its recruiters see that rinkats holds them and talk to you through messages in rinkats; the emails telling you a message is waiting carry a general notice and a link, never the message itself, and never the name of the agency. A recruiter can see your contact details only after verifying their identity with us, while their organisation is on a paid plan, and while their account is not under review — and every time they open them we record it. Recruiters who are not verified can still read your profile and a formatted copy of your resume with your contact details removed, but not your original resume file. Interview invitations to you come from rinkats's own address. If you applied without an account and a recruiter writes to you, we email you a link to create your free account with that address so you can read the message. If a message from a recruiter is abusive, spam or asks you for money or personal documents, use Report on the message; rinkats reviews every report and the recruiter is not told who reported them. A recruiter under review cannot see candidate contact details or send messages to candidates. Contact details an organisation already had or collected itself are its own, as described above.

What you see, and what you don't. You see the status of your applications in plain candidate-facing words, never the agency's internal stage names, internal notes, scores or scorecards. The agency's other data is never visible to you.

Email. Emails about your applications come from the agency through rinkats. The links in them pass through rinkats first: when you follow one we record that a link from that organisation's email of that kind was followed, with a scrambled form of your email address rather than the address itself, and set a cookie that lets us count a sign-up that follows. These links stop working after 90 days. Automated emails sent to a list carry an unsubscribe link and the one-click unsubscribe button mail apps show; using it stops that kind of email from that organisation. Emails a person sends you directly are not on a list and carry no such link — reply to the sender.

5. If you are an interviewer

We hold your account (or, if you interview without one, your name and email address), your availability, the interviews and meetings assigned to you, the clients and agencies you interview for, and the scorecards, comments and attachments you submit. Meeting invitations are emailed to you with a calendar file attached. You see the candidate context for interviews assigned to you — profile and the latest skill-test score per skill — and never the candidate's salary, notice period or offer. Your feedback is visible to the organisation that asked you to interview, not to the candidate.

6. If you are a contact at a client or agency

An organisation may record the name, email address, phone number and job title of the people it works with at its clients and partner agencies, along with contracts, notes and invoices. Those people may receive emails from the organisation through rinkats — for example candidate profiles and invoices. The organisation decides how it uses this data; rinkats processes it for the organisation.

7. If you visit our website

Contact form and invite requests: the name, email address, phone number, team size and message you send us, and, on an invite request, whether you agreed to marketing email and to the data-use commitment.
Ask rinkats: the questions you type into the site's answering assistant are sent to an AI model to answer from our own published pages. Questions it cannot answer, or that we mark as worth reading, are kept with the answer and a scrambled form of your IP address so we can improve the site; we never keep the IP address itself.
Browsing: our pages carry no advertising or analytics trackers. Our network provider sees the requests your browser makes, as any website host does.

8. What is public

The jobs board publishes the roles organisations choose to publish: the title, description, location, work mode, skills, industry, experience and, where the organisation shows it, the salary range. The name of the client and of the agency is not shown; the listing names rinkats as the hiring organisation. Published roles appear in our sitemap and machine-readable listings and carry the structured job data search engines read, and we may tell search engines when a role is published or closed (only the page address is sent). An organisation writes its own job descriptions and is responsible for not putting personal data in them. Nothing about candidates is ever public.

9. The rinkats browser assistant

The browser assistant is an extension a recruiter installs in their own browser. It works on the job portals it supports (Naukri, LinkedIn, Indeed, foundit, Monster India, Shine, hirist, Instahyre, Cutshort and iimjobs) and, only if the recruiter switches it on, on other sites too.

What it reads: the pages the recruiter opens or asks it to work on — search results, candidate profiles and job postings — using the recruiter's own account on that portal. When the recruiter adds a profile, imports a job posting or runs a search task, what it read is sent to rinkats: the profile (name, headline, company, role, location, experience, salary, notice period, education, skills, summary), contact details the recruiter can see or chooses to reveal, a downloaded CV, or the text of the job posting. On portals where contact details are free to read (such as LinkedIn's contact overlay) it reads them by default; on portals where revealing contact costs a credit, it reveals only when the recruiter presses the button or turns on automatic reveal. It never types a password.
What it keeps on the computer: the recruiter's sign-in to rinkats, their settings, a copy of the open requirements they can see, and a debug log that stays on the computer unless the recruiter copies or downloads it.
Usage diagnostics: on by default and switchable off in its settings. They carry counts and timings per task, the extension version, the browser and the website's host name — never page text, names, contact details, full web addresses or anything typed.

The people whose profiles are captured this way become part of the organisation's candidate records (section 4); the organisation is responsible for its lawful use of them and for following each portal's terms.

10. How we use data, and on what basis

To provide the service — store records, run the features you use, send the emails you or your organisation trigger, schedule interviews and meetings — under our contract with the organisation and with you.
To secure it — authenticate sign-ins, limit repeated attempts, scan uploaded files for malware, screen documents for hidden instructions, detect abuse, keep activity records.
To improve it — rinkats can use data on the platform to understand how the product is used, measure quality, fix errors and build better features. How this is done is set out in full below.
To bill and keep accounting records, and to meet legal obligations.

How we improve the resume reader, exactly. For organisations that agreed to take part when the organisation was opened (the person who opens it ticks a box; it can be turned off on request, and the demo workspace never takes part), we regularly copy resumes, the text our reader took from them and the reading results to a computer rinkats controls, to measure how well the reader works and to reproduce its failures. A resume used to fix a failure is turned into a synthetic test with invented people, and the original is then deleted. Resumes not yet used for a fix stay on that computer, under our control, until the work no longer needs them; there is no fixed deletion date today. Each resume taken this way is recorded with the organisation it came from.

Copies of the service for fixing problems. To reproduce and fix a problem safely, our developers may make a copy of the production database and files on a computer rinkats controls, or a test copy with the same providers in which every email address and phone number is replaced with an invented one. These copies are used only by our developers, never shown to another organisation, and replaced or deleted when they are refreshed or no longer needed.

Legal bases. In India we process personal data under the Digital Personal Data Protection Act, 2023 — on consent, or for the legitimate uses the Act permits, with the organisation as the data fiduciary for the candidate data it brings in. Where the EU or UK GDPR applies, our bases are performance of a contract, our legitimate interests in running, securing and improving the service, legal obligation, and consent where we ask for it.

We do not sell personal data, show advertising, or use advertising trackers.

11. AI assists; people decide

rinkats uses AI to read resumes and spreadsheets, draft messages, summaries and job descriptions, answer questions in the assistant, assess how well a candidate fits a role, and flag signs of fraud. AI output is a draft or advice. A model's assessment of a candidate is shown to the organisation's recruiters, but nothing a candidate sees, and no change to a candidate's stage, takes effect until a person makes or accepts it, and that decision is recorded. No hiring decision is made by automated means alone. When the reader takes a name and email address from a resume for a record that does not have them yet, it fills them in, and a recruiter can correct them. Text inside resumes and other uploaded documents is treated strictly as data — it cannot instruct the AI — and it is first screened for injected instructions by a model that runs on our own server.

12. Who else handles the data

We share data only to deliver the service, with providers acting on our instructions under their own security and confidentiality commitments:

Oracle Cloud — the application servers (Ashburn, Virginia, United States).
Neon — the database, including its backups (Ohio, United States). What we encrypt in the database (section 17) reaches Neon only in encrypted form.
Cloudflare — the network in front of the site (worldwide), encrypted connections, and file storage for resumes, attachments, imported spreadsheets, stored email copies, and the files and drafts kept with assistant conversations ([[FILE STORAGE LOCATION]]). Files are encrypted by rinkats before they are stored, so Cloudflare holds only encrypted copies.
Amazon Web Services — sending email and receiving delivery and bounce reports (Mumbai, India).
Google Cloud (Vertex AI / Gemini) — the AI models rinkats uses by default to read resumes, draft text, answer questions and compute search embeddings. Google routes these requests to its data centres worldwide.
AI providers your organisation chooses. An organisation may connect its own key for a provider (for example Anthropic, OpenAI, Google, Mistral, xAI, Voyage or a compatible service of its choice). When it does, the data for those tasks is sent to that provider under the organisation's own agreement with it. Some providers' free tiers let the provider use what is sent to improve its own models; choosing such a key is the organisation's decision.
Cashfree — payments, and (through its Secure ID service) the video identity check for recruiters who want to see the contact details rinkats holds for candidates (India).
Outside applications you connect. When you or your organisation connect an AI agent or another application through the API or agent interfaces, it receives whatever its calls ask for, within your permissions, under its own terms.
The people your organisation sends to. Emails, candidate profiles and invoices your organisation sends through rinkats go to the recipients it chooses.

AI providers receive only what a task needs, and are used to do your work; we do not contribute your data to any provider's training.

Beyond these we disclose data only when law enforcement or a court order requires it (section 13), or to a successor if the business is transferred, under this policy.

13. Keeping organisations apart, and who can see what

Every business record carries the organisation it belongs to, and every query the application makes is limited to the signed-in organisation. Recruiters who work for more than one organisation see each one separately. One technical note: search embeddings (lists of numbers that describe a piece of text so similar texts can be found) are computed once per unique piece of text and reused, but an embedding carries no text, no organisation and no person, and every search is filtered to your organisation's own records before it looks at one.

Inside an organisation, every look at a candidate is recorded. The only way to a candidate's record is through the application, and staff access to candidate records is recorded: which user opened which candidate, from which part of the product, and when — the candidate's page, a card on the pipeline, a resume viewed or downloaded, a formatted resume, an export, a read through the API or an agent tool, and every search or list (one entry with what was asked and how many candidates it returned). Each entry is written at the moment of the read; where the read is a file download or a record read through the API and the entry cannot be written, the read is refused rather than left unrecorded. The organisation's administrators see these records live — new entries appear without reloading — and can filter them to the second and download them on demand; the download is itself recorded. Nobody in the organisation can change or delete an entry. rinkats sees only counts per organisation. Contact details rinkats holds for a candidate, and the talent pool, have their own records of the same kind (section 4).

Who at rinkats can see your data. The separation above is between organisations, not between you and rinkats. rinkats' superadmins and developers can access every organisation's data, and may from time to time read it for two purposes only: to improve the quality of the application (reproducing a failure, checking how a feature behaved on real records, measuring quality), and to provide support — debugging a problem you have reported, or reviewing a record directly when you ask us to. Such access is by named staff over their own authenticated accounts; the superadmin console itself shows organisations' activity as counts, not their records. Changes staff make to an organisation's account are recorded with who made them, when, and from which IP address and browser; a developer reading the database directly is not separately recorded today, and what we encrypt (section 17) cannot be read that way without rinkats' keys. We do not share what we see with anyone else, and we do not disclose your data to any third party, unless a request from law enforcement or a court order requires us to; where the law allows, we will tell the organisation concerned.

14. International transfers

rinkats is run from India, and our servers and database are in the United States. Some providers process data in other countries, including providers based in the United States, Europe and China that an organisation may choose for AI. Where the law requires safeguards for such transfers, we rely on them; we will not transfer personal data to a country the Government of India has restricted.

15. How long we keep data

Organisation records — everything in section 3, including email logs and copies, AI usage records, assistant conversations, agent call records and the activity history — are kept while the organisation's account is active. Closing an organisation suspends all access at once; thirty days later its people's personal data is anonymised as described in section 16, unless the organisation is reopened before then. When we delete an organisation outright, the anonymising happens straight away. Accounting records (invoices, placements, payments) are kept with their amounts and dates so that legal and financial obligations can still be honoured; invoices stay complete as issued — the organisation's name, address and tax identifier, the client billed and each invoice line — because tax law requires invoices to be kept intact for years.
Sign-in sessions end after seven days without use; the record of a session, with its IP address and browser, stays with the account. Sign-in codes expire after five minutes.
Records that expire on a schedule: progress messages from AI tasks after 30 days, records of AI spending checks after 90 days, quality measurements after one year, and live-update messages seven days after delivery.
Links in candidate emails stop working after 90 days; the count of followed links is kept.
Contact messages, invite requests and saved Ask rinkats questions are kept until we no longer need them; there is no automatic expiry today.
Records of who opened a candidate (section 13), of contact reveals and of talent pool searches are kept while the organisation's account is active, like its other records.
A deleted candidate account leaves only a deletion record with no name, contact detail or account behind it: when it happened and how many of each kind of item were removed. It is kept so we can show deletions were done.
Security alerts about a stored file that failed its check are kept for our security team, with the file, the account that was opening it, the IP address and the browser.
Payment and tax records are kept for as long as tax and accounting law requires.
Files (resumes, attachments, imported spreadsheets, email copies, an organisation's logo and the pictures in its email signatures) are kept in write-once storage that protects them against loss and tampering. When a file is removed from the service, it is detached from every record and can no longer be reached through rinkats, and it is marked for purging; until it is purged, the stored object remains as encrypted bytes that cannot be read without rinkats' key.
Database backups allow restoring the database to an earlier point for [[BACKUP WINDOW]].
Server logs may contain email addresses and IP addresses; they are kept on our server and overwritten automatically as they grow.
Resumes taken to improve the reader and development copies are kept as described in section 10.

16. What deletion means here

Deleting your candidate account. A candidate can delete their own rinkats account at any time from their profile. Before confirming, they are told how many active applications they have, what will be removed and what recruiters keep, and they confirm with their password and their sign-in email. Deleting removes, at once and for good:

the candidate portal profile — name, email address, phone number, location — and the searchable profile, so recruiters can no longer find them in search;
every resume they uploaded, what we read from them and the links to the files; the files are detached and marked for purging, and until they are purged the stored bytes stay encrypted and unreadable without rinkats' key;
their side of each application, their private notes, the notifications addressed to them and the record of their activity in the portal (the messages they already sent an organisation stay in that organisation's conversation, like the rest of its records);
their sign-in: the account, the password, every signed-in session (they are signed out everywhere immediately) and any sign-in codes or links. The same email address can be used to sign up again later as a new account. If the same sign-in is also used to work for an organisation as staff or as an interviewer, only the candidate side is deleted and the sign-in stays; they are told this before confirming.

We send one last email to the address before the sign-in is removed, saying the account was deleted, what was removed and what recruiters keep. We keep a deletion record with no name, contact detail or account in it — only when it happened and how many items of each kind were removed.

What recruiters keep. Deleting your rinkats account does not delete the copies organisations already hold: an organisation that added you from the talent pool or received your application keeps its own candidate record, its cards, notes and copy of your resume, and the contact details rinkats holds for it. rinkats does not delete those; they are that organisation's records (section 1). The organisation can no longer message you through rinkats, and its recruiters see that you have left rinkats. To have an organisation's copy deleted, ask that organisation; we will help it answer, and it can ask us to anonymise it as described below.

Other deletion — anonymising. If you ask us to delete your personal data held by an organisation, or an organisation is deleted or has been closed for thirty days, we remove the data from the service by anonymising it, not by physically erasing every copy: names, contact details, free text and other identifying fields are replaced or blanked, to the best of our ability, so that what remains can no longer be traced back to you or the organisation, and the links to files are dropped so resumes, attachments and email copies can no longer be reached from rinkats. The stored file objects and database backups are not rewritten; they expire on their own schedule (section 15). Records we must keep for a legal or accounting reason stay, and we tell you what remains and why: payment and billing records keep their amounts and dates but lose people's names, email addresses and phone numbers, while invoices are kept complete as issued, so an invoice line can still name the person a fee was charged for. During the thirty days after an organisation is closed nothing is anonymised yet, so it can still be reopened as it was. These requests, and deleting a staff or interviewer account, are handled by our team on request.

17. Security

All traffic is encrypted in transit. Passwords, sign-in codes, API keys and the secrets of connected applications are stored only in a scrambled, one-way form, and the AI provider keys organisations connect are encrypted at rest.

What is encrypted at rest.

Every stored file — resumes, attachments, documents, imported spreadsheets and copies of sent emails — is encrypted by rinkats before it is stored. Two fingerprints are recorded when a file is saved, one of the encrypted file and one of the original, and both are checked each time it is opened; a file that fails the check is not shown, and our security team is alerted at once by an alert only rinkats staff can see and by email.
Sign-in details: the email address and phone number you sign in with, and the sign-in codes and links sent to them.
A candidate's own account: their name, email address, phone number and location, the text of the resumes they upload and what we read from them, and the files' names.
Contact details rinkats holds for candidates on an organisation's behalf (section 4).
The recipient of email rinkats sends on its own behalf (section 3).

Addresses and numbers that must be looked up are encrypted so that only the complete value finds a match — a candidate's contact details in their own account can be found by the complete address, never by part of it.

What is not encrypted, and why. An organisation's own records — including its candidate records and its copy of a candidate's details once it has added them — are kept readable in the database, protected by access controls rather than field-by-field encryption, because its recruiters need to search them by part of a name, an address, a skill or a company. The names of the people who work for organisations are readable for the same reason. Every look at an organisation's candidate records is recorded (section 13).

Other protections. Repeated sign-in and code attempts are limited; uploaded files are scanned for malware before any processing; the application server has no open inbound connections from the internet; files are reached only through signed-in, checked pages; the application connects to the database with a role that cannot change its structure; the records of who opened a candidate, of contact reveals and of security alerts cannot be changed or deleted by the application; and changes staff make on an organisation's account are recorded. No system is perfectly secure.

18. If there is a breach

If a breach affects personal data, we will contain it, investigate it, and notify the Data Protection Board of India and each person affected, without delay and in the form the Digital Personal Data Protection Act requires — what happened, what data was involved, what we are doing and what you can do. Where other laws apply (for example the GDPR's 72-hour rule) we follow them too. Where an organisation is the data fiduciary, we tell the organisation promptly so it can meet its own duties, and help it do so.

19. Your rights

Depending on where you live, you can ask to access your data, correct it, delete it, withdraw consent, object to or restrict a use, receive a copy, or nominate someone to act for you. You can change much of your own account and profile yourself, and a candidate can delete their own account (section 16); other requests are handled by our team by hand. Candidates whose details an agency holds should normally ask that agency, which controls that data; we will support it. Withdrawing consent does not undo what was lawfully done before. To reach us, use the address on our contact page. You can also complain to your data protection authority (in India, the Data Protection Board of India).

20. Children

rinkats is for businesses and for adults looking for work. It is not meant for anyone under 18, and we do not knowingly collect a child's personal data. We do not check ages. If you believe a child's data is in rinkats, tell us and we will remove it as described in section 16.

21. Cookies and local storage

We use only the cookies the service needs:

a sign-in session cookie (valid up to seven days, renewed while you are active), a short-lived copy that saves looking up the session on every page, and short-lived cookies for the sign-in process;
a resume hand-over cookie (48 hours) when you upload a resume before creating an account, so it can be attached to the account you create;
an email arrival cookie (30 days) when you follow a link in an email, so a sign-up that follows can be counted; it holds only a link reference.
a candidates list sort cookie (one year) for recruiters, which remembers how you last sorted the candidates list; it holds only the sort order.
a shared job link cookie (this browser session) when you open a job from a link a recruiter shared with you, so an application you make can be credited to that recruiter; it holds a signed reference to who shared the link and which roles it covered, nothing about you.
an active profile cookie (a year) when your candidate login holds more than one profile — it only remembers which of your own profiles the portal shows; it is checked against your profiles on every page and never names anyone else's

Your browser's local storage keeps interface preferences such as theme, board view and collapsed panels. The browser assistant keeps its sign-in, settings, a copy of open requirements and its debug log in the browser's extension storage (section 9). Our network provider, Cloudflare, may set a cookie to protect the site from bots. There are no advertising, analytics or cross-site tracking cookies.

22. Changes to this policy

This policy is versioned. A new version is published here with its date, and people it applies to are told the next time they sign in. We keep a record of who saw and accepted each version, with the time, IP address and browser.

23. Contact and grievance officer

[[LEGAL ENTITY]], [[ADDRESS]]. Questions about this policy or your data: the address on our contact page. Our grievance officer for India is [[GRIEVANCE OFFICER]]; we will acknowledge a grievance promptly and answer it within the time the law sets.