A Health Insurance Software Company Hands Client Evidence to Engineering Through Ticket-Scoped Files.com Folders

A US health insurance software company builds the software that carriers, brokers, and third-party administrators run their business on. Carriers use it to underwrite and administer policies, brokers use it to shop and place coverage, and third-party administrators use it to file and track claims against those policies. Its whole pitch to that market is connection: keeping carriers, brokers, and TPAs in sync through software, so member data moves between counterparties on a governed path.

Everything in that market is claims data, and a claim is a person: a name, an employer, a diagnosis, a dollar amount. Dozens of client organizations, including some of the largest health insurers in the country, run their business through the company's products. So when one of those clients hits a problem in the software, the evidence of the problem is usually an image of exactly that data.

A Bug Report That Contains a Diagnosis

Client issues arrive through HubSpot, the company's client-facing support system, and they arrive with attachments. Reproducing what a client saw usually means looking at the claim the client was looking at, and a claim identifies a person. A single screenshot can carry a member's name, their employer, and their diagnosis. That is PHI, and it arrives in the support system by design.

The people who fix those issues work in a different system. Engineering runs in Jira, an ALM that the company deliberately keeps outside HIPAA scope, so its engineering toolchain never has to be defended as a system that holds member health data. HubSpot and Jira are integrated so that tickets can become engineering work, and the company wanted every attachment to stop short of that integration. The one path between support and engineering is the one path the data must never take.

That put the customer solutions team in a bind on every ticket that needed an engineer. Hold the material back, and the engineer cannot reproduce the issue while a payer client waits on the fix. Pass it along through the integration, and it would land in a system never meant to hold it.

Two Boundaries That Both Had to Hold

Both boundaries around the handoff were correct, and that is what made it hard. Bringing Jira into HIPAA scope would drag the entire engineering toolchain into compliance audits for the sake of ticket attachments. Opening the support system to engineers was ruled out just as firmly.

What the fix had to do was clear. It had to sit between the two systems while changing neither. It had to work per ticket rather than per client, a requirement the company's CTO set on containment grounds. And it had to carry the compliance answer itself: HIPAA with a signed BAA, SOC 2, and a record of who put each file in and who took it out.

The company selected Files.com to be that channel, the compliant layer between its ticketing system and its ALM.

Files.com Between the Ticket and the Fix

Files.com became the place where the regulated payload actually lives. The systems on either side carry only references to it.

When a ticket needs engineering, the customer solutions team moves its screenshots and videos out of HubSpot and into a Files.com folder scoped to that ticket. The Jira issue references the folder instead of holding attachments. Engineers open the material in Files.com, reproduce what the client reported, and work the fix in Jira, which never touches the data. Because each handoff gets its own folder, an exposed link would expose one ticket's files, not a client's history. That is the CTO's containment requirement, built directly into the folder structure.

The channel also carries the compliance load neither endpoint could. Files.com runs under HIPAA with a BAA and SOC 2, group permissions decide who can read and write each folder, and every upload and download is written to an audit log. Access follows identity the company already manages: employee accounts are provisioned into Files.com automatically from Microsoft Entra ID, so an engineer's access to the channel tracks the directory rather than a list somebody maintains.

Reproducible Issues, Jira Outside Scope, on Every Ticket

With the handoff in production, regulated evidence reaches engineers without ever entering the engineering system, and neither boundary moved.

• Jira carries a reference to the regulated material, never the material itself, and stays outside HIPAA scope as a matter of architecture rather than vigilance.
• Engineers reproduce client issues from the actual screenshots and videos without ever entering the client-facing support system.
• Moving regulated troubleshooting material is routine workflow rather than exception handling, with the same per-ticket pattern applied every time.
• Every movement of that material is on the record. Uploads and downloads land in the Files.com audit log under a HIPAA BAA and SOC 2, the kind of answer the company's payer clients ask for in security reviews.

The pattern also costs nothing to extend. A new client or a busier support queue adds no new compliance surface, because the next handoff is one more folder in the same channel, governed by the same permissions and the same log.

Two Boundaries, Kept

The company never brought Jira into HIPAA scope, and never opened HubSpot to engineering. The regulated payload got its own compliant channel in Files.com, and everything else moves by reference. For a company that sells the health-insurance market on moving member data between counterparties through governed software, the handoff between its own support and engineering teams runs on the same principle its products do.