ProService Hawaii Takes Social Security Numbers Out of Email With a Files.com Inbox—Without Replacing Its Applicant System

ProService Hawaii is a professional employer organization, and Hawaii's largest local HR partner. Since 1994 it has run payroll, benefits, onboarding, and HR compliance on behalf of the businesses it serves, and its family of companies, including AdvanStaff HR in Nevada, now supports more than 3,000 client businesses representing over 70,000 employees across Hawaii, the mainland, and the care industry nationwide.

That model has a consequence built into it. When one of those 3,000 businesses hires someone, the hire runs through ProService: the paperwork, the payroll setup, the benefits enrollment, the compliance record. Collecting sensitive personal data from other companies' employees is not a side effect of the business. It is the business. And no piece of that data is more sensitive, or more unavoidable, than the Social Security number. Payroll does not run without one.

The One Field the Applicant System Couldn't Ask For

ProService had already moved much of its document intake into governed channels. Client businesses upload new-hire paperwork and benefits documents into a siloed folder per client on ProService's own branded Files.com domain, and processing staff pull from there instead of from attachments.

“That's what we're looking to accomplish: risk reduction.”

A Social Security number, though, is not a document. The natural place to capture it was the applicant tracking software that manages applicants, and that system cannot request Social Security numbers securely. One required field, needed for every single hire, had no compliant home. The fallback was the exact channel the company was working to eliminate: an applicant at one of ProService's client companies typing their Social Security number into an email, where it then sat in a mailbox outside any control ProService could enforce.

The gap was not going to close itself. The applicant tracking system remained the system of record for applicant management, and nobody replaces a system of record over one field. Building custom software to capture a single sensitive value per hire was a disproportionate project for what is a structural, recurring obligation. And the people supplying the number are outsiders. They are employees of thousands of different client businesses who cannot be provisioned accounts or told to install anything.

A Registration Form Inside a Governed Platform

Whatever collected the number had to be reachable with nothing but a link. It had to capture the value inside a governed system rather than in a message body or an attachment. It had to keep each person's submission invisible to every other person. And it had to give staff a way to review and process submissions in bulk.

ProService built it on the platform already carrying its paperwork: a Files.com Inbox.

ProService configured a permanent, branded Inbox with required registration and a custom form field for the Social Security number. Applicants need only a link, with no Files.com account or signup. The number is captured as a form field inside Files.com rather than becoming an email or a loose file. Each submission remains invisible to every other applicant, while staff can review the registration record and export it to Excel for processing.

Nothing was installed at any client. No accounts were created. The applicant tracking system was not touched.

Social Security Numbers, Off Email and On the Record

With the Inbox in production, ProService replaced an intake path it could not control with one it fully governs, and gained a capability it previously did not have at all.

• Compliant Social Security number collection became possible: the per-hire obligation the applicant system could not serve now runs through a governed form instead of a mailbox.
• Applicants need nothing but the link. There is no account, no software, and no visibility into anyone else's submission.
• Every number arrives on the record, in a registration log staff review and export for processing.
• The applicant tracking system stayed exactly where it was. The gap closed with a configured form, not a replacement project or custom code.

Closing a Gap Without Replacing the System

A security gap in an entrenched system of record does not require a new system of record. It requires a governed channel that can ask the question and keep the answer, and for ProService that channel was already running its file exchange.