Candidate Data Protection: Sending Offer Letters and Background Checks Without Email

Candidate data protection has to work for a recipient who has no account with your systems yet, which is the constraint that makes this vertical genuinely different.

At a Glance

Why Every Hire Generates a Document-Security Problem

Candidate data protection carries a constraint no other industry on this list shares, and it shows up on the very first hire. Every hire, regardless of company size, produces a predictable trail of sensitive documents: an offer letter naming a salary, a background check report containing a candidate's criminal history and Social Security number, and onboarding paperwork moving between the company, the candidate, and often a third-party screening vendor, all before the candidate has any formal relationship with the company's internal systems. That last detail is what makes this vertical distinct from most others on this list: the recipient is frequently someone with no company email address, no established login, and no existing trust relationship with your systems at all.

Option 1: Buying a Purpose-Built Platform

Several vendors address this exact gap. FileOrbis uses content-aware classification to automatically detect and protect employee and candidate PII wherever it lives, restricts personnel files to authorized HR roles through granular access control, and replaces email attachments with revocable, time-bound secure links for exactly the handoff between a company and a candidate. Turn leads with AES-256 encryption across all PII at rest and in transit, built specifically for high-volume hiring screening. HYPR Affirm focuses on candidate and onboarding identity verification, pairing advanced encryption with the specific problem of confirming a candidate is who they claim to be before sensitive documents ever reach them.

The pattern across all three: encryption alone isn't the differentiator buyers evaluate first. It's how well the tool handles a recipient who has no prior account, prior login, or established identity with the company, which is a meaningfully different problem than sending a document to an existing employee or client.

Pricing across this category tends to follow company headcount or hiring volume rather than a flat per-seat fee, since the actual usage driver is candidates processed, not internal employees with logins. That makes a direct dollar comparison harder to generalize than in a market like tax preparation, and it's worth getting a volume-based quote directly from any vendor rather than assuming a per-user SaaS model applies the same way it would for internal collaboration software.

Option 2: Building It In-House

The underlying mechanism these vendors rely on is the same envelope-encryption pattern used across every regulated industry facing this problem: a unique key generated for each document, sealed separately to the sender and recipient so only they can unlock it, delivered as a link rather than an attachment, and permanently destroyed on deletion by destroying every sealed copy of the key rather than just removing a file.

We built and tested this architecture directly, in a system called Sealwax, specifically to understand what it takes rather than take a vendor's description at face value. Eighty-two automated tests back the core claims, including a scenario confirming that a third party with no relationship to a specific hire has no way to decrypt a document sent to someone else, and that a sender's decision to delete a document is permanent rather than merely hiding a file that technically still exists. The test suite ended up larger than the application code itself, and for a system holding candidate Social Security numbers before that candidate has even accepted an offer, that's the ratio worth insisting on rather than trimming for speed.

Where this vertical adds a genuine wrinkle beyond the core mechanism: recruiting's recipients are frequently first-time users with no pre-existing account. A build that assumes every recipient already has credentials doesn't fit an HR workflow without adding email-based identity and a frictionless first-time login, exactly the kind of onboarding challenge the commercial platforms above have already solved through repeated iteration with real candidates.

Option 3: Custom Integration With Private AI

AI is already a standard part of high-volume hiring, and Turn is explicit about building specifically for AI-powered screening at scale, parsing resumes, validating background check data, and flagging discrepancies faster than manual review allows. That's a real, shipping capability, not a speculative one.

The caveat that applies here as strongly as anywhere else: a resume, a background check report, and onboarding paperwork all routinely contain Social Security numbers and criminal history, exactly the kind of data that should never reach a public AI API for parsing or summarization, regardless of how convenient that would be. The same resolution applies: run the model on infrastructure your organization controls, whether that's an on-premises deployment or a private cloud tenant, so candidate PII never leaves your environment by design rather than by policy alone. The infrastructure for this is smaller than most HR teams assume. From our directory of 24 openly licensed models, with VRAM measured at 4-bit and 8-bit quantisation, resume and document parsing runs in about 0.5 GB of VRAM for the retrieval layer, with a guardrail model filtering what reaches a reviewer in about 2 GB. Unlike the seasonal patterns in tax or the bursty ones in litigation, hiring volume tends to be steady, which is the one profile where a dedicated monthly machine genuinely beats hourly rental: a Hetzner GEX45 at about EUR 214 a month works out near EUR 0.29 an hour run continuously, against roughly $0.805 for a comparable AWS g6.xlarge.

For a company hiring at high volume, this combination, encrypted delivery for the documents themselves, plus a private model handling resume parsing and background check review, addresses both halves of the problem: the document never travels unprotected, and the AI reviewing it never sends candidate data anywhere outside the company's own control.

There's a legal dimension to this specific vertical worth naming directly: several jurisdictions now regulate the use of automated tools in hiring decisions themselves, separate from data privacy law entirely, requiring disclosure to candidates that an automated tool played a role in screening and, in some cases, an independent bias audit of the tool. That's a reason to keep any AI screening step advisory rather than determinative, flagging candidates for human review rather than auto-rejecting them, which happens to align with the same caution that applies to using AI for privilege review in legal work: a model that assists a human decision-maker carries a different risk profile than one that replaces the decision entirely.

A Concrete Scenario: Sending an Offer With a Background Check

Picture a company extending an offer to a candidate who has never had an account with the company's systems before. Under a properly built system, the offer letter and the background check results arrive as one secure link rather than two separate email attachments, one from HR and one from a third-party screening vendor the candidate has to trust independently. The candidate verifies their identity, often through a lightweight method like a one-time code sent to the email address the offer was addressed to, and views both documents in one place. If the offer is later rescinded before the candidate accepts, revoking that link removes access to the compensation details entirely, closing a specific, recurring HR liability: a rescinded offer whose salary figure remains sitting in a candidate's inbox indefinitely.

Where This Goes Wrong

The most common mistake in this vertical is assuming a background check vendor's own portal is sufficient on its own, without considering what happens to the same data once it's downloaded and forwarded internally, say, to a hiring manager who isn't authorized to see the full report, only a summary recommendation. A candidate's background check often contains far more detail than a hiring manager needs to make a decision, and forwarding the full report internally, even within the company, expands the exposure well beyond what the candidate consented to when they authorized the check.

A second common mistake is applying the same access model to every candidate regardless of role. A background check for an entry-level retail position and one for a role with access to financial systems carry meaningfully different sensitivity, and a one-size-fits-all retention and access policy either over-protects the low-risk case at the cost of hiring speed, or under-protects the high-risk one.

Integration Realities Worth Planning For

A secure delivery tool that sits outside the recruiter's normal workflow, requiring a separate login and a manual step to move a candidate's documents into it, faces the same adoption problem every industry on this list runs into: the busiest people in the process default back to whatever's fastest, usually email, unless the secure option is genuinely no slower. That's why the ATS and HRIS integration matters as much as the encryption itself; a recruiter moving through 40 candidates a week won't reliably use a tool that adds friction to each one, however strong its security model is on paper.

A Decision Framework for HR and Recruiting Teams

Buy makes sense when your recruiting volume doesn't justify dedicated engineering investment, and you need a platform that's already solved the first-time-candidate-login problem through real-world iteration, one that's been refined against actual candidates rather than internal testers who already know how to use it.

Build makes sense when you have specific ATS or HRIS integration requirements a commercial platform doesn't meet, and engineering capacity to also solve the candidate-onboarding experience a purpose-built vendor has already refined.

Add private AI when you're hiring at a volume where manual resume parsing or background check review has become a genuine bottleneck, and you can commit to running that model entirely within infrastructure you control.

What This Means for Your Organization

The distinguishing challenge in this vertical isn't the encryption, it's the candidate experience for someone with no prior relationship to your systems. Whatever path you choose, the test that actually matters is whether a candidate who has never interacted with your company before can open a secure document without friction, because a security model that assumes an existing account doesn't survive contact with real hiring.

That's also the strongest argument for buying rather than building for most organizations in this space: the first-time-user problem is genuinely hard to get right, and the vendors who've solved it have done so against thousands of real candidates across many different companies, feedback a single organization's own hiring pipeline, however large, is unlikely to generate on its own in a comparable timeframe.

Volume changes the calculation here more sharply than in most other verticals on this list. A company hiring a handful of people a year gets little practical benefit from a dedicated platform beyond what its existing ATS already provides for encryption in transit. A company hiring hundreds of people a month, the exact profile Turn's AI-powered screening is built for, faces a genuinely different problem: manual review at that scale isn't just slower, it becomes the point where sensitive candidate data actually starts leaking into ad hoc spreadsheets and email threads because the formal system can't keep pace.

For most HR teams the honest answer is buy, because the first-time-candidate experience is genuinely hard and the vendors have refined it against thousands of real candidates. Where a build earns its place is ATS or HRIS integration that no platform covers, and that is the piece we would scope.

Book a strategy session if that is your situation, or price it with the automation quote generator first. Integration work sits under our AI automation development service, with tiers on the pricing page.

Related reading: AI document processing covers resume and document parsing, and will AI replace my employees covers the question HR teams field most often once automation enters the conversation.

Where This Sits in the Wider Picture

The architecture described here is not specific to HR and recruiting. The same four properties, a unique key per document, a link rather than an attachment, sender-controlled revocation, and a complete access log, show up independently across every regulated industry facing this problem, each for a different regulator and a different worst case.

We built a working system to understand it from the inside rather than from vendor documentation, and published what it cost, what it proved, and what it did not, in secure document delivery across six regulated industries. The healthcare version of the build-versus-buy decision, including the gap list we published rather than hid, is in HIPAA secure messaging: build vs buy.

For the same decision in a different vertical, see law firms and title and escrow.

Frequently Asked Questions

What makes secure document sharing for HR different from other industries?

The recipient is frequently a candidate with no pre-existing account, login, or trust relationship with the company's systems. Purpose-built vendors like FileOrbis and HYPR Affirm have specifically engineered around that first-time-user problem, which a generic secure-messaging build has to solve separately.

Is it safe to use AI to screen resumes and background checks?

Only if the model runs on infrastructure your organization controls entirely. Public AI APIs used for parsing resumes or background checks would expose candidate Social Security numbers and criminal history to a third party, which defeats the purpose of encrypting those same documents in the first place.

What systems does a secure delivery layer need to integrate with for recruiting specifically?

The ATS or HRIS your company already runs, such as Workday, BambooHR, or Greenhouse, and the background screening vendor on the other side, such as Checkr or HireRight. A tool that sits outside both, requiring manual document transfer, adds friction rather than removing it.

How much would it cost to build a custom secure delivery system for HR use?

The core encryption mechanism is buildable in roughly one engineering sprint. The larger cost is solving the candidate-onboarding experience, letting a first-time candidate access a document without a pre-existing account, which purpose-built vendors have already refined through real-world use.

Which named tool handles high-volume AI-powered screening specifically?

Turn is built specifically for AI-powered screening at high hiring volume, alongside AES-256 encryption of all PII. FileOrbis and HYPR Affirm focus more on document classification and identity verification respectively.

Does encrypting offer letters and background checks actually reduce legal risk?

Yes, materially. A candidate's Social Security number and background check results are exactly the kind of data a data-protection regulator or plaintiff's attorney would scrutinize after any breach. Demonstrating that this specific data category was encrypted, access-logged, and delivered through revocable links is a meaningfully stronger position than relying on standard email.

Do we need to disclose to candidates that AI is involved in reviewing their background check or resume?

Increasingly, yes, depending on jurisdiction. Several states and cities now require disclosure when an automated tool plays a role in a hiring decision, and some require an independent bias audit of the tool itself. This is a separate legal requirement from data privacy protections, and applies regardless of whether the AI model is hosted publicly or run privately on infrastructure your company controls.

What happens to a background check report after a hiring decision is made?

That depends on your retention policy, but the safest default is treating it the same way you'd treat any other sensitive document: encrypted, access-logged, and deleted, key destroyed rather than just the file removed, once it's no longer needed for the specific purpose it was collected for. Several state laws impose specific retention limits on background check data, which is worth confirming against your own jurisdiction rather than assuming indefinite retention is acceptable.