SOC 2, HIPAA, FERPA, PCI DSS, COPPA: Which Compliance Frameworks Actually Apply to You

A client came to me saying "we need to be HIPAA compliant." Their product was a scheduling tool for construction companies. No health data. No patient information. What they actually needed was SOC 2, because their enterprise prospects were asking for it during procurement. The word "HIPAA" came up because their CEO heard it at a conference and assumed it was a universal standard.

This confusion is incredibly common. Compliance frameworks aren't interchangeable labels — each one governs specific types of data in specific industries. Using the wrong framework wastes time and money. Missing the right framework blocks deals and creates liability.

SOC 2: The Universal SaaS Baseline

Who needs it: Any company that stores, processes, or transmits customer data as a service. In practice, every B2B SaaS company will eventually need SOC 2 because enterprise procurement teams require it.

What it covers: Five trust service criteria — security (required), availability, processing integrity, confidentiality, and privacy (optional but often included). SOC 2 doesn't prescribe specific technologies. It requires that you have controls in place and that you follow them consistently.

The two types: Type I says "you have the right controls in place right now" (point-in-time). Type II says "you've had the right controls in place consistently for 6-12 months" (period assessment). Type I is faster and cheaper — typically 3-4 months to achieve. Type II is what enterprise customers actually want, but you can sell on a Type I with a Type II in progress.

The real cost: $30K-$80K for the audit itself, plus $15K-$30K annually for compliance automation tooling (Vanta, Drata, Secureframe), plus the engineering time to implement and maintain controls. Total first-year cost for a 15-person company: $60K-$120K.

HIPAA: Healthcare Data Protection

Who needs it: Any company that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity (hospital, insurance company, healthcare provider). If a hospital uses your software and that software touches patient data, you need HIPAA.

What counts as PHI: Patient name, address, date of birth, Social Security number, medical record number, or any other identifier linked to health information. It's not just medical records — a scheduling system that stores patient names and appointment types handles PHI.

The Business Associate Agreement (BAA): Before any healthcare customer shares PHI with you, they'll require a BAA — a legal contract that obligates you to protect the data according to HIPAA standards. Every vendor in your supply chain that touches PHI also needs a BAA. Your cloud provider, your database host, your monitoring tool — if PHI passes through it, you need a BAA with that vendor.

Engineering implications: Encryption at rest and in transit (usually already done), access logging for all PHI access, minimum necessary access (users only see the PHI they need for their role), breach notification procedures (you have 60 days to notify affected individuals), and data disposal procedures (PHI must be securely destroyed when no longer needed).

FERPA: Student Education Records

Who needs it: Any company that handles student education records on behalf of educational institutions. If schools or universities use your product and it accesses student grades, attendance, disciplinary records, or other educational records, FERPA applies.

The key distinction: FERPA isn't just about student data — it's about data that's part of the education record and personally identifiable. A classroom engagement tool that records student participation data linked to student names falls under FERPA. An anonymous survey tool might not.

Engineering implications: Strict data isolation between school districts (one district must never access another's student data), parental consent mechanisms for students under 18, data deletion capabilities (schools must be able to request deletion of all student records), and restrictions on secondary use (you can't use student data for advertising or non-educational purposes).

The COPPA intersection: If your education product is used by children under 13, COPPA also applies. This adds requirements for verifiable parental consent before data collection, strict limits on data retention, and prohibitions on behavioral advertising.

PCI DSS: Payment Card Data

Who needs it: Any company that processes, stores, or transmits credit card data. If your application has a payment form where users enter card numbers, PCI DSS applies.

The practical advice: Don't handle card data directly. Use Stripe, Braintree, or a similar payment processor that's already PCI compliant. When the card number goes directly from the user's browser to Stripe's servers (Stripe Elements, Stripe.js), your PCI compliance scope drops dramatically. You still need to fill out a Self-Assessment Questionnaire (SAQ), but it's the simplest version (SAQ A) rather than the comprehensive assessment that direct card handling requires.

The mistake companies make: Building custom payment forms that send card data to their own servers before forwarding to a processor. This puts card data in your infrastructure, which means full PCI DSS scope — penetration testing, network segmentation, encryption key management, and a much more expensive audit. Use the processor's hosted payment fields and avoid this entirely.

COPPA: Children's Data Under 13

Who needs it: Any company that collects personal information from children under 13, or that operates a website or service directed at children under 13. This includes education technology, games, and any product that might be used by children.

What it requires: Verifiable parental consent before collecting personal information from children (a checkbox is not sufficient — FTC requires "more reliable" methods), a clear privacy policy describing data practices, limits on data collection to what's reasonably necessary, data security appropriate to the sensitivity of children's data, and parents' right to review, delete, and refuse further collection of their child's data.

The enforcement reality: The FTC actively enforces COPPA. Fines are significant — millions of dollars for companies that collect children's data without proper consent. If your product might be used by children under 13, even if it's not designed for them, consult with a lawyer who specializes in children's privacy.

The Compliance Stack for Growing Companies

Most companies don't need all of these. Here's how to determine your stack:

Selling to businesses? Start with SOC 2. Handling health data? Add HIPAA. Serving education? Add FERPA (and COPPA if K-8). Taking payments? Use a PCI-compliant processor and complete SAQ A. Serving children? Add COPPA.

Start with SOC 2 — it's the most commonly requested, the most broadly applicable, and the foundation that makes adding industry-specific frameworks easier. Many SOC 2 controls overlap with HIPAA, FERPA, and PCI requirements, so the incremental effort to add a second framework is smaller than starting from scratch.