Industry-specific rules that lock SaaS out of regulated markets

A 12-person SaaS startup builds a beautiful scheduling tool for medical clinics, signs three pilot customers, and then discovers it needs a Business Associate Agreement, encrypted data storage, audit logging, and a breach notification plan before it can invoice anyone. Six months and a compliance consultant later, the founders wonder if they should have stayed in the restaurant-booking niche. This scenario plays out constantly in SaaS, and it explains why entire categories of startups deliberately avoid healthcare, payments, and financial services no matter how big the market looks.

This lesson covers the three regulatory regimes that most often make or break a SaaS company's ability to sell into a regulated vertical: HIPAA, PCI DSS, and GLBA. Each one imposes real engineering and operational costs, not just legal paperwork.

HIPAA: the healthcare gatekeeper

HIPAA (Health Insurance Portability and Accountability Act, US federal law passed in 1996) governs how PHI (Protected Health Information, meaning any individually identifiable health data) is stored, transmitted, and accessed.

HIPAA does not just apply to hospitals. Any SaaS company that touches PHI on behalf of a healthcare provider or insurer becomes a Business Associate, and must sign a BAA (Business Associate Agreement) with each covered customer. The BAA is a legal contract making the vendor liable for specific safeguards.

In practice, HIPAA compliance requires:

• Encryption of PHI at rest and in transit
• Access controls with unique user IDs, automatic logoff, and audit trails showing who viewed what data and when
• Breach notification: if PHI is exposed, affected individuals must be notified, and breaches affecting 500+ people must be reported to the HHS Office for Civil Rights (OCR), the enforcement body, within 60 days
• Vendor risk management: if the SaaS company uses subcontractors (cloud hosting, analytics tools), those subcontractors need their own BAAs too

Penalties range from roughly $100 to over $50,000 per violation category, with annual caps in the low millions of dollars (figures per HHS's published penalty tiers, periodically adjusted for inflation; treat exact numbers as estimates and check HHS.gov for current figures). More damaging than the fine is the reputational hit and the loss of enterprise healthcare contracts, which typically include HIPAA compliance as a hard requirement in procurement.

This is why many horizontal SaaS tools (project management, CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →, analytics) explicitly market themselves as "not for PHI" and refuse to sign BAAs. Signing one means rearchitecting infrastructure and accepting new liability.

PCI DSS: the price of touching card data

PCI DSS (Payment Card Industry Data Security Standard) is not a government law but an industry-mandated standard, enforced through contracts between merchants, payment processors, and the major card networks (Visa, Mastercard, Amex, Discover, JCB), coordinated by the PCI Security Standards Council.

Any SaaS product that stores, processes, or transmits credit card numbers falls under PCI DSS. The standard has 12 core requirements, including:

• Firewalls and network segmentationsegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition → isolating cardholder data
• Never storing the full card verification code (CVV) after authorization
• Strong access control and unique credentials per user
• Regular vulnerability scanning and penetration testing
• Maintaining an information security policy

Compliance is tiered into four merchant levels based on transaction volume, with Level 1 (over 6 million transactions/year, per Visa's public thresholds, figures as of recent published guidance) requiring an annual on-site audit by a Qualified Security Assessor (QSA).

Here is the strategic decision most SaaS companies actually make: avoid touching card data at all. Instead of building PCI-compliant infrastructure, they integrate with Stripe, Adyen, or Braintree, which handle card storage and processing. The SaaS company never sees the raw card number; it uses tokenization (a tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → replaces the card number in the SaaS company's database) and iframe/hosted-field checkout widgets. This shrinks the SaaS company's PCI scope down to the simplest self-assessment questionnaire (SAQ-A), instead of the full standard.

This "avoid, don't build" pattern is the single most common compliance strategy in SaaS, and it is worth internalizing as a template for how founders think about all three regimes in this lesson.

GLBA and the fintech build-vs-avoid decision

GLBA (Gramm-Leach-Bliley Act, US federal law from 1999) regulates how financial institutions handle nonpublic personal information (NPI) of consumers, things like account numbers, income, credit history, and Social Security numbers.

GLBA's reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → extends to SaaS companies that provide services to banks, lenders, or fintechs, because the law's Safeguards Rule (updated by the FTC, Federal Trade Commission, with amendments effective 2022 to 2023) requires covered entities to ensure their service providers also implement adequate safeguards. That flows downstream contractually: a bank using a SaaS vendor for loan processing will require the vendor to meet Safeguards Rule expectations, including:

• A written information security program
• Designated qualified individual overseeing security
• Encryption of NPI at rest and in transit
• Multi-factor authentication for anyone accessing customer data
• Incident response plan and regular testing

Fintech SaaS also often intersects with additional regulators depending on the product: the CFPB (Consumer Financial Protection Bureau) for consumer lending and servicing tools, FinCEN for anti-money-laundering (AML) related products, and state-level money transmitter licensing if the SaaS platform ever touches fund flows. For EU-facing fintech SaaS, the relevant framework shifts toward PSD2 (Payment Services Directive 2) and GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → for personal data, both enforced by national regulators and the European Banking Authority (EBA) for PSD2 specifically.

The build-vs-avoid decision here is stark. A SaaS company building expense management software can either:

1. Avoid: never hold funds, never issue cards directly, and partner with a licensed Banking-as-a-Service (BaaS) provider (like Unit or Synctera) or issuing bank that absorbs the regulatory license burden, or
2. Build: pursue money transmitter licenses state by state (a process that can take over a year and cost hundreds of thousands of dollars in legal and compliance fees, as an order-of-magnitude estimate), hire a compliance officer, and build AML/KYC (Know Your Customer) infrastructure in-house.

Most startups choose door one. This is why so many "fintech" SaaS products are really software layers sitting on top of a chartered bank's rails.

Reading the pattern across all three

HIPAA, PCI DSS, and GLBA look different on paper, but they impose a similar strategic fork:

• Encrypt and control access to sensitive data as a baseline, non-negotiable cost of entry
• Push liability outward where possible (payment processors absorb PCI scope, BaaS providers absorb banking licenses) rather than internalizing it
• Contract flows-down compliance: enterprise customers in regulated industries will demand BAAs, security questionnaires, and audit rights as standard parts of procurement, regardless of company size
• Non-compliance kills deals, not just invites fines. Enterprise healthcare and finance buyers routinely eliminate vendors during procurement for lacking a SOC 2 report or a signed BAA, long before any regulator gets involved

For a broader primer on the interlocking privacy and security standards referenced here, the FTC's business guidance hub is a solid, free, regularly updated resource.

🎬 [VIDEO: "HIPAA Compliance Explained for SaaS Companies" - youtube.com - search for recent HIPAA/SaaS compliance explainer videos from established compliance or legal channels to see how BAAs and audit requirements get implemented in real product architecture]

Key Takeaways

• HIPAA forces any SaaS company touching health data to sign Business Associate Agreements and build encryption, access logging, and breach notification into their product, or refuse healthcare customers entirely.
• PCI DSS is industry-enforced, not government law, and most SaaS companies avoid its full burden by outsourcing card handling to processors like Stripe, keeping only minimal compliance scope.
• GLBA's Safeguards Rule pushes financial-grade security requirements down to SaaS vendors serving banks and fintechs, which is why many fintech SaaS products partner with a licensed bank instead of becoming one.
• Across all three regimes, the recurring strategic choice is build the compliance infrastructure or avoid touching the regulated data entirely, and avoidance is usually cheaper for early-stage companies.
• Enterprise procurement in regulated industries treats compliance certifications (BAAs, SOC 2, PCI attestation) as deal-breakers, so the real cost of non-compliance is lost revenue, not just regulatory fines.