Two sets of people, two different roles, one privacy position

Most software processes personal data about its own users. Recruitment software processes personal data about its users and, separately, about a much larger population who have no relationship with the software vendor at all: candidates. Some of them applied to one of your jobs. Many of them were sourced from a public profile, forwarded by a colleague, uploaded by a client or imported from a job board account you pay for.

The two populations are not interchangeable and cannot be governed by one paragraph. The recruiter logging in has a contract with you and, through you, a relationship with the vendor. The candidate has a relationship with you and, usually, has never heard of the vendor. Their expectations, their rights and the routes those rights travel are different.

That is why the privacy position has to be stated twice, once for each population, rather than folded into a single statement about how much everyone values privacy. The second statement is the one that matters in recruitment, and it is the one most vendor policies handle thinly.

Account data, authentication data, billing details, support correspondence and the operational telemetry that shows the service is working are processed by Soor LLC as controller. That means Soor LLC decides why and how those are processed, and answers directly to the person concerned. A recruiter who wants to know what account data is held about them can ask the vendor, and the vendor answers.

The categories are ordinary: name, work email, role, tenant, authentication events, IP and device information tied to sessions, plan and billing records, and the content of support tickets somebody chose to send. Usage telemetry is counted at the level of features and errors rather than at the level of what a named recruiter typed into a note.

The lawful bases are the ordinary ones too: performance of the contract for account and billing data, legitimate interests for security, abuse prevention and service improvement, and consent where consent is the right basis, such as marketing email to a person who asked for it.

Every candidate record inside your tenant is there because you decided to put it there. You chose to source that person, to accept that application, to import that spreadsheet, to keep that record for another year. Those are controller decisions, and they are yours. Soor LLC hosts, processes and returns that data on your documented instructions, which is the definition of a processor.

What follows from that is practical rather than theoretical. Soor LLC does not decide your retention periods, does not decide your lawful basis, does not decide whether to keep a record after somebody asks you to delete it, and does not contact candidates on its own account. Those levers exist in the product and you pull them.

It also follows that no vendor can be compliant on your behalf. You are the controller of the candidate data you hold, and the outcome depends on your policies, your training and the decisions your recruiters make every day. What the product does is make the controller's job possible: record the basis, run the retention clock, produce the export, complete the erasure and keep the evidence.

The common misreading runs like this: the data is in the vendor's system, so the vendor is responsible for it. That is intuitive and wrong. Possession of infrastructure is not control of purpose. The party that decides why the data exists and how long it stays is the controller, and in recruitment that party is almost always the agency or the employer.

The cost of getting it wrong is concrete. A candidate emails the vendor demanding erasure. The vendor cannot lawfully act on that request against a customer tenant without instruction, so it forwards it, and the statutory clock has already been running. Meanwhile the customer believed the vendor was handling it. Two parties, one assumption each, and a deadline missed between them.

The fix is a routing decision made in advance rather than discovered under pressure. Candidate-facing notices should name your firm as the controller and give a contact route into your firm. Requests that nonetheless arrive at the vendor are forwarded to the tenant contact promptly rather than answered independently.

Primary data residency is on AWS in the us-east-1 region, with encrypted backups. Data is encrypted in transit and at rest. Tenancy separation is enforced in the data layer rather than at the presentation layer, so one customer's query cannot reach another customer's records even where a mistake is made higher up the stack.

Access by Soor LLC staff is limited to what is needed to run the service and to answer support requests, granted through named roles rather than shared credentials, and logged. Support access to a tenant is a granted action with a record attached, not an ambient capability every engineer carries.

Where a support engineer needs to see production data to resolve a problem, the sensible position is that you can see that they did. The audit record exists for the same reason audit records exist anywhere: not because anyone is assumed to be acting badly, but because a claim nobody can check is worth very little during a security review.

A recruiter asking about their own account data asks Soor LLC. A candidate asking about their record asks the firm that holds it, because that firm is the controller. The product exists to make the second one answerable: a subject access export assembles the structured record, the parsed resume text, the custom fields, the notes, the message history, the call and interview records and the consent events, and it runs from the record itself rather than through a support queue.

That last detail matters more than it sounds. A request that carries a statutory deadline should not depend on a vendor's response time, and a design that routes every candidate request through a support ticket has quietly made the vendor a bottleneck in the customer's legal obligation.

Erasure works the same way and is described in detail on the consent and retention feature page: the profile, the custom fields, the notes, the messages, the original uploaded file, the extracted text and the search representation are removed together, and a fulfilment record is kept, which is the fact of the request rather than the data it concerned.

Your clock governs candidate data and is configured by you: retention windows per record type and per market, measured from the last meaningful contact rather than from record creation, with expiry raising a review queue rather than deleting silently. Soor LLC does not set those numbers and will not choose them for you, because the right number depends on obligations you hold and we do not.

The vendor clock governs account, billing and support data and runs on ordinary business and statutory periods: billing records kept for the period accounting rules require, support correspondence kept while it is useful and then removed, security logs kept for a defined window and then rotated.

Those clocks touch at exactly one point, termination. After termination the tenant remains retrievable for the window stated in your agreement, then deletion runs across the tenant regardless of the per-record windows you configured, because the instruction to process has ended.

This marketing website uses Google Analytics 4, provided by Google, to count page views and clicks on buttons and links, and to record when a form is started or submitted. It never records what you type into a form. This section covers this website only.

Google Analytics sets two first-party cookies, _ga and _ga_ followed by the property ID, which by default last up to two years. Google states that Google Analytics 4 does not log or store IP addresses. Advertising storage, ad user data and ad personalisation are always set to denied, so no advertising features are used.

The site also uses Microsoft Clarity, provided by Microsoft, for session replay and heatmaps: it records how pages are scrolled and clicked so layout problems can be seen. When analytics cookies are allowed it sets its own first-party cookies, _clck and _clsk. Clarity masks the text typed into form fields by default, and that masking is left on.

Visitors in the European Economic Area, the United Kingdom and Switzerland start with analytics cookies off until they choose Accept. Elsewhere they start on, and Decline turns them off. A Global Privacy Control signal from your browser is treated as Decline unless you choose Accept. The same choice applies to Google Analytics and Microsoft Clarity. While analytics cookies are off, Google Analytics sets no cookies but may still receive cookieless measurement pings with no identifier, and Clarity runs without cookies.

Your choice is kept in your browser's local storage on this site. To change it, use the Cookie settings link at the bottom of any page. Clearing this site's data in your browser removes the choice and shows the banner again.