Software companies

Vertical rules that limit software vendors' data reuse: a reference table

By SourceX Editorial · Reviewed by Noah Loul · October 9, 2026

Short answer

Regulations limiting software vendor data use differ by vertical: HIPAA for health data, GLBA for financial institutions, FCRA for screening, state insurance laws for carriers, professional confidentiality for legal work and export controls for defense data. Most reach vendors through customer contracts, so regulated customer data is usually excluded while vendor-created records stay reviewable.

Key takeaways

Vertical rules usually reach software vendors through customer contracts such as business associate agreements and service provider clauses.
Some rules follow the data itself wherever it sits, including biometric privacy laws and export controls on technical data.
De-identification standards differ by rule, so a dataset that meets one standard may fail another.
Vendor-created engineering and process records usually survive every vertical rule once regulated details are removed.
A product line that serves several verticals needs a separate rule check for each customer segment.

Why vertical rules matter more than general privacy law for vendors#

Vertical rules matter more for software vendors because they attach to the customer's industry and travel with the customer's data, often adding purpose limits that general privacy laws do not. A vendor serving clinics, lenders, screening companies or insurers inherits those limits through contracts even when the vendor itself is not regulated.

This page is a reference and general information, not legal advice. Each rule has exceptions, state versions and interpretive guidance, and whether a rule applies to a given dataset is assessed deal by deal with counsel. Use the table to know which questions to ask, not to answer them.

Reference table: vertical rules and typical exclusions#

The reference table lists the rules vendors meet most often, what each covers and what is typically excluded from any license. Exclusions describe common outcomes in practice, not legal requirements, and a customer contract can be stricter than the rule behind it.

Reference table: vertical rules and typical exclusions
Vertical	Rule that may apply	What it covers	Typical exclusion
Health care software	HIPAA and business associate agreements	Protected health information handled for covered entities	Patient records unless de-identified under HIPAA methods and allowed by the BAA
Banking, lending and fintech software	GLBA and bank vendor oversight terms	Nonpublic personal information of financial institution customers	Customer financial records and account data
Background, tenant and employment screening	FCRA and state screening laws	Consumer reports and the information used to build them	Report contents, applicant identities and adverse action records
Insurance software	State insurance data security laws based on the NAIC model	Licensees' nonpublic information held by service providers	Policy, claims and underwriting data
Legal practice software	Attorney-client privilege and professional confidentiality rules	Client communications and work product held by law firms	Matter content, documents and client identities
HR and recruiting software	Employment laws and state privacy laws covering applicants	Applicant and employee personal information	Candidate profiles, assessments and interview notes
Fleet and telematics software	FMCSA recordkeeping rules and state privacy laws	Driver records of duty status, location and video	Driver logs, location traces and camera footage
Education software	FERPA and state student privacy laws	Student education records	Student records and identifiable usage data
Defense and aerospace manufacturing software	ITAR and EAR export controls	Controlled technical data and technology	Drawings, specifications and controlled engineering files
Payments and commerce software	PCI DSS through card network contracts	Cardholder data	Card numbers and payment credentials

Three routes by which a rule reaches a vendor#

A rule reaches a vendor by one of three routes, and the route decides who you negotiate with. Knowing the route also tells you whether a customer's consent could ever change the answer.

Data-type rules carry the highest stakes because a customer's consent may not cure them. Export rules can treat the release of controlled technology or source code to a foreign person inside the United States as an export. Biometric claims are also hard to defend: in Rosenbach v. Six Flags, the Illinois Supreme Court held that a person need not show actual injury beyond a violation of BIPA rights to sue.

Direct coverage: the vendor itself is regulated, for example when it acts as a consumer reporting agency or holds a license.
Contract flow-down: the customer is regulated and passes duties on through a BAA, a service provider clause, a security exhibit or vendor oversight terms.
Data-type rules: the rule follows the data wherever it sits, as with export-controlled technical data or biometric identifiers under laws such as Illinois BIPA.

De-identification standards differ by rule#

De-identification standards differ by rule, so a dataset that qualifies under one may not qualify under another. Check which standard the contract and the applicable law name before relying on de-identification to bring any records into scope.

Where a rule names no standard, buyers and counsel usually look for recognized methods and a documented risk assessment. Keep the method, the reviewer and the date with the dataset so the choice can be explained later.

De-identification standards differ by rule
Standard	What it requires
HIPAA Privacy Rule	Either Expert Determination that re-identification risk is very small, or Safe Harbor removal of 18 specified identifiers with no actual knowledge that the rest could identify someone
California law as amended by the CPRA	Information that cannot reasonably be linked to a consumer, plus reasonable measures, a public commitment not to reidentify, and contracts binding recipients to the same terms
Customer contracts	Whatever the agreement defines, which may be stricter than any statute or may forbid de-identified use altogether

Records that usually survive every vertical rule#

The records that usually survive every vertical rule are the ones your company creates about building and running the product rather than about the customer's regulated subjects. Engineering issues, code reviews, release notes, architecture decisions, incident postmortems and internal product discussions rarely contain regulated content by design.

Support and implementation records sit in between. They are company records, but agents paste patient names, loan numbers, policy screens and driver logs into tickets. Those records stay reviewable only after regulated details are removed and the removal is checked by sampling.

Test data is the trap most vendors miss. Fixtures copied from production, sample files attached to bug reports and seeded demo tenants can carry regulated content into otherwise clean engineering systems, so search for them before calling a repository or tracker safe.

Illustrative example: one holding company, three rule sets#

Illustrative: a fictional vertical software holding company owns three products: dispatch software for regional trucking fleets, an onboarding tool for staffing agencies, and a resident portal for apartment operators. Its general counsel is asked whether the group's records could be licensed as one package.

The answer is no single package. Driver logs, location history and camera footage are excluded under the fleet contracts and the driver privacy concerns attached to them. Candidate profiles in the onboarding tool are excluded as applicant personal data. Screening results in the resident portal are excluded as consumer report content.

Across all three products, engineering issues, code reviews and support tickets with regulated details removed stay in review. The group scopes and approves each product separately, with a different rights memo for each customer segment.

How SourceX applies vertical rules#

SourceX applies vertical rules in the Rights step of the SourceX five-step transaction, working with the supplier's counsel before any records are prepared. Regulated customer data is generally excluded, and the assessment centers on vendor-created records, which the fit check identifies from metadata alone.

For packages that proceed, the SourceX Evidence Packet records which rules were considered, what was excluded, the de-identification method used and who authorized the release, so a buyer or a regulated customer can follow the reasoning.

Frequently asked questions

If our customer is regulated but we are not, do the rules still apply to us?

Often yes, through the contract. A business associate agreement, service provider clause or vendor oversight addendum can bind you to many of the customer's obligations, and breaching it creates contract liability even where the statute does not reach you directly. Read every regulated customer's paper before scoping any records.

Does de-identified data escape these rules?

Sometimes, but only when it meets the standard the rule or contract names, and some contracts forbid de-identified use entirely. De-identifying free text, such as support tickets, is harder than de-identifying structured fields, so plan for human review and sampling rather than relying on automated removal alone.

Do these rules cover our internal engineering records?

Rarely, because engineering issues, code reviews and release notes are created by your team about the product. They come into scope when regulated content has been pasted in, such as test fixtures built from production data or screenshots in bug reports. Check for those before treating engineering records as clean.

What if one product serves customers in several verticals?

Check the rules segment by segment rather than product by product. The same ticketing system may hold records from a clinic, a lender and a retailer, each under different contract terms. Tag records by customer segment early, so a regulated segment can be excluded without discarding the rest of the history.

How often should a vendor revisit this table?

Whenever you enter a new vertical, sign a new type of regulated customer or consider a licensing project. Privacy and AI rules change often, and state laws keep adding protected data categories. Treat the table as a starting checklist and confirm current requirements with counsel each time.

Sources

Under the HIPAA Privacy Rule at 45 CFR 164.514(b), protected health information can be de-identified in one of two ways. The first is Expert Determination, in which a qualified expert finds the re-identification risk very small. The second is Safe Harbor, which requires removing 18 specified identifiers and having no actual knowledge that the remaining information could identify the individual. Source
Under Cal. Civ. Code § 1798.140(m), as amended by the CPRA, information is 'deidentified' only if it cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer. The business holding it must also (1) take reasonable measures to ensure it cannot be associated with a consumer or household, (2) publicly commit to keep and use it only in deidentified form and not try to reidentify it, and (3) contractually obligate any recipients to comply with all of these provisions. Source
In Rosenbach v. Six Flags Entertainment Corp., 2019 IL 123186, decided January 25, 2019, the Illinois Supreme Court held that a person need not allege actual injury beyond a violation of their BIPA rights to be an 'aggrieved' party entitled to sue. Source
Under 15 CFR 734.13, export includes the release or transfer of technology or source code (but not object code) to a foreign person in the United States, and any such release is a deemed export to the foreign person's most recent country of citizenship or permanent residency. Source

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

Check which of your records fall outside these rules Talk to SourceX