A Small Commercial Printer Runs PHI Mail Production on Files.com and Meets Enterprise SOC 2 Requirements

A US commercial printing, direct-mail and fulfillment company operates two customer-facing brands. The work spans prepress, print-on-demand storefronts, variable-data printing, direct mail and mail-house fulfillment for customers including healthcare and pharmaceutical companies. The regulated end of the business sits largely under the second brand, which serves healthcare and pharmaceutical clients.

That mix has one consequence that shapes everything else. A mail house's raw material is other people's data. Every direct-mail job begins with a mailing list, and the medical, pharmacy and political lists the printer prints from contain PII and PHI. The place where those lists arrive, get processed and become print output is the file layer, and in this business the file layer is not a side channel. It is the front door of production.

Files.com became two things at once for the printer: the compliance boundary its clients audit, and the staging layer its production pipeline runs on. They are the same surface, which is the point.

The Mailing List Is the Regulated Asset

The printer's clients treat it accordingly. At least three or four of its customers contractually require that it use a SOC 2 provider. Its top clients send security assessments, and most of the questions concern hosted services. Clients ask to see current audit reports, and one asked for the data-breach-notification policy of the platform holding its lists.

The cost of a wrong answer is not one job. A printer that cannot pass a client's security questionnaire loses the whole class of work that questionnaire guards, and regulated mail work is the spine of this business.

Compliance Scales With the Data, Not the Headcount

The printer is a company of a few dozen people. Building HIPAA-capable file infrastructure in-house, carrying it through a SOC 2 Type 2 audit, and re-earning that audit every year is a burden sized for an IT organization many times larger. The demand does not shrink to fit: a mailing list of protected health information carries the same obligations whether the company handling it employs a few dozen people or five thousand.

The audited surface also could not be a vault off to the side of production, because production is what touches the data. Client systems push list files in automatically. The variable-data team reads and writes those files continuously as it builds personalized pieces. The direct-mail pipeline pulls files and writes output as jobs run. Two brands serve two separate client populations, each expecting to deal with the company it hired. Whatever held the regulated data had to be the same surface the whole pipeline reads and writes, over every protocol the pipeline speaks.

So the requirement was specific. The printer needed a platform that carried its own audit posture, spoke SFTP with key authentication for machine feeds, WebDAV for in-place processing, and plain web upload for people, and could run two branded identities from one operation. The earliest version of that requirement was on the table from the start: customers required HIPAA and PCI compliance, and a small printer needed a cloud platform that could stand behind both. The printer selected Files.com to be that surface.

One Audited Surface, From Inbound Feed to Print Output

Data comes in by machine and by hand. Client systems push mailing-list files over automated SFTP feeds, and one client's automation authenticates with an SSH key rather than a password. Clients who send files themselves upload over HTTPS to their own folders on a branded site.

The variable-data team works the files where they land. The Variable/Mailing department mounts its client data folders over WebDAV and reads and writes the .csv, .xlsx and .txt files in place, feeding XMPie directly. That detail carries the workflow: downloading a file, processing it and re-uploading it adds time the production schedule does not account for, so the platform had to support live read and write access, not just transfer.

The direct-mail pipeline treats Files.com as its file system. The automation stack built on PostalOne, Accuzip, XChange-US and Switch pulls files from the platform and creates directories as jobs run, and print-on-demand and direct-mail jobs write their output automatically to designated folders.

Nobody watches folders. Files.com upload notifications fire when client files arrive and route the alert to the staff who own that job, with rules that cover whole subfolder trees. Before that, people checked folders throughout the day to see whether new files had come in.

Two Brands, One Account

The two brands serve distinct client populations, and each population sees only its own brand. Using Files.com Child Sites, each brand runs on its own branded domain with its own SSL certificate, its own users and its own client folders, while both sit under one parent account that the printer administers centrally. A client of either brand logs in to the company it hired. The audited platform underneath is the same one.

The Audit Answer Is a Current Report

With production staged on Files.com, the printer gained a compliance posture it can prove.

• The SOC 2 requirement its customers impose is satisfied by the platform's own audit. When a client asks for evidence, the printer pulls a current SOC 2 Type 2 report from Files.com and sends it, down to the breach-notification policy one client asked to review.
• PHI and PII mailing lists for medical, pharmacy and political mailers are staged on an audited platform from the inbound client feed through the print output folder.
• Production runs on notifications instead of manual watching, and large PDF/ZIP archives move as a matter of routine.

The compounding result is the one the business grows on. A new regulated client means a new security questionnaire, and the answer is already written: the same platform, the same current report, the same posture. Taking on the next healthcare or pharmacy account adds folders and credentials, not infrastructure.