Where responsibility sits for every regime that touches recruitment

Two rows sit in progress, and both are stated as programmes rather than as achievements. Neither will be upgraded on this page before the artefact exists.

The SOC 2 row is the one procurement teams read first, so the wording is deliberately narrow. A Type I report describes control design at a point in time; a Type II report describes operating effectiveness over a period. Only the first is being pursued now, and the second is not claimed until it is issued.

Every data protection regime that applies to a recruitment database sits in shared responsibility, and that is not an evasion. You decide which candidates to hold, why, and for how long; you are the controller. The product supplies consent records, retention windows, export and erasure so that those decisions can be evidenced and acted on rather than argued about.

The practical consequence is that a subject access request is answerable from the record instead of assembled by hand across a database, an inbox and a shared drive. That is the part most firms fail on, and it is a systems problem rather than a policy problem.

Outbound is where recruitment firms take on the most regulatory risk and where vendors are most tempted to write a compliance declaration. The rows below say what the product does and then say plainly which part of the exposure remains yours.

The 10DLC row is the clearest example. US SMS sending requires brand and campaign registration with the carriers under your own name. No vendor can register on your behalf and any that implies otherwise is describing a workflow it does not control.

Automated scoring in hiring is regulated in a way that most software categories are not, and the regulation is arriving unevenly by city and state. The product's job is to record what happened in enough structure that an independent audit can be run and a decision can be reconstructed. Commissioning that audit, issuing candidate notice and defending the decision remain the employer's obligations.

The design consequence runs through the whole product: demographic data is stored away from the hiring record so it cannot influence a decision it exists to measure, and dispositions are a fixed list rather than free text so a reviewer sees a decision code instead of a recruiter's shorthand.

The primary region is AWS us-east-1, with encrypted backups. That is the honest current state and it is written here rather than left for a security review to discover.

If your organisation requires that candidate data remain in the European Union, the United Kingdom or Australia, raise it before contract. Regional residency is a scoping conversation, not a settings toggle, and it interacts with the subprocessor list: a model provider, a transcription service or a messaging gateway may operate in a different region from the database, and a residency assessment that ignores those is incomplete.

Where a regional requirement cannot be met, the answer will be that it cannot be met. That is more useful to a data protection officer than a qualified yes.

Surhires relies on other providers to send messages, post jobs, place and transcribe calls, run model inference and take payment. Each of those processes some category of customer data, and each is named in the published subprocessor register with what it handles and where it operates.

Additions are notified rather than absorbed into a terms update. The register is the document to attach to a data protection impact assessment, and it is written to be usable for that purpose: one row per provider, the processing purpose, the data categories and the operating region, without marketing language in between.

A candidate has the right to ask what you hold, to receive it in a portable form and, in most cases, to have it deleted. In a typical agency those requests are answered by hand and answered badly, because the data is spread across a database, an email client, a spreadsheet and a folder of attachments.

In Surhires, access, export and erasure are workflows rather than support tickets. An export produces the full record - profile, structured fields, parsed resume text, uploaded files, messages and activity - as CSV or JSON. An erasure removes the profile, the parsed text, the files and the messages and records that the request was fulfilled and when. Financial records tied to a completed placement are retained where law requires it, and the workflow says so rather than quietly keeping everything.

The data processing agreement, the privacy notice, the cookie policy and the subprocessor register are published under the legal section and can be attached to a procurement file without asking anyone. Regime-specific notes for GDPR, CCPA, the DPDP Act, EEO and OFCCP reporting, and TCPA and CAN-SPAM are published alongside them.

Anything not published - security questionnaire responses, entity documentation, the penetration test summary once it exists - is sent on request through the sales address. Questionnaires are answered directly, including where a control is not yet in place, in which case the response says so and gives a timeline. A questionnaire answered optimistically becomes a contract dispute later, which serves nobody.