Which Compliance Rules Apply to Your Software? A Map for Engineers
GDPR, CCPA, HIPAA, PCI DSS, SOC 2 and WCAG explained by the product decisions that trigger them, with the engineering controls they share.
· 6 min read
A product manager adds a "date of birth" field to the signup form so the onboarding email can say happy birthday. Six months later a lawyer asks why the app collects ages without a policy for users under 13, and the team discovers that one form field quietly put it in scope for COPPA. Compliance in software rarely starts with a regulation. It starts with a feature, a field, a script tag or a new market, and the regulation follows.
This guide maps the common regimes to the product decisions that trigger them, explains what kind of document each one is, and shows the engineering work they share. It is a map for engineers, not legal advice.
Start from what your product does
The quickest way to scope compliance is to list what the software touches, then see which rules attach to each.
| Product decision | Regime it pulls in | Applies to |
|---|---|---|
| Personal data of people in the EU | GDPR | Any company offering goods or services to, or monitoring, people in the EU |
| California consumers' personal data | CCPA as amended by CPRA | Businesses over the law's revenue or data-volume thresholds |
| Card numbers stored, processed or transmitted | PCI DSS | Anyone in the card data path, via contracts with card brands and acquirers |
| Health records for a US covered entity | HIPAA, HITECH | Covered entities and their business associates |
| Users under 13 in the US | COPPA | Services directed at children, or that know they collect from children |
| Public website or app | WCAG 2.2 via ADA, Section 508, EU accessibility law | Varies by sector and country |
| Selling to enterprises | SOC 2 or ISO 27001 | Required by customers, not by law |
| US federal customers | FedRAMP, FISMA | Cloud services and systems used by federal agencies |
The Software Compliance Checklist is built around this view. Filter by domain (Payments, Healthcare, Analytics, UI and others) and geography, open a card to see requirements, applicability, penalties and official links, and add the ones that apply to a checklist you can download as Markdown.
Laws, standards and attestations are different things
Treating everything as "a compliance" hides important differences in who enforces it and what happens if you fail.
Laws such as GDPR, CCPA, HIPAA and COPPA are enforced by regulators and courts. GDPR applied from 25 May 2018; its upper tier of fines is EUR 20 million or 4 percent of worldwide annual turnover, whichever is higher, and Article 33 requires notifying the supervisory authority of a personal data breach within 72 hours of becoming aware of it. HIPAA civil penalties are tiered by culpability and adjusted for inflation every year. The FTC adjusts COPPA penalties annually too; they are now above $50,000 per violation.
Industry standards such as PCI DSS are contractual. The card brands set them through the PCI Security Standards Council, and your acquiring bank enforces them through your merchant agreement. Version 4.0 became the only active version when 3.2.1 retired in March 2024, and its future-dated requirements became mandatory at the end of March 2025.
Attestations and certifications such as SOC 2 and ISO 27001 are about proving controls to customers. SOC 2 is a report from an independent CPA firm against the AICPA Trust Services Criteria; it is an attestation, not a certification. ISO 27001 is a certification of an information security management system by an accredited body. Neither is required by law, but either may be required to close an enterprise deal.
Technical guidelines such as WCAG are what laws point to. WCAG 2.2 became a W3C Recommendation in October 2023 and is backward compatible with 2.1, which many laws still cite.
Controls that satisfy many regimes at once
The frameworks read differently but ask engineers for overlapping things. Build these once and map them to each regime:
- Data inventory. Know which personal, payment and health data you hold, where, and why. GDPR's records of processing, HIPAA's risk analysis and SOC 2 scoping all start here.
- Access control and audit logs. Least privilege, MFA for administrators, and logs of who accessed what. Every framework on the list asks for some version of this.
- Encryption. TLS in transit and encryption at rest, with managed keys.
- Retention and deletion. A defined retention period per data type and a working deletion path, which also serves GDPR erasure and CCPA deletion requests.
- Incident response. A written plan, an on-call path and templates that meet the shortest clock you are subject to (72 hours under GDPR).
- Vendor management. Data processing agreements, business associate agreements, and a list of subprocessors.
- Accessible UI. Keyboard access, visible focus, text contrast of at least 4.5:1, labels and captions.
A shared control set also makes questionnaires faster: the same evidence answers the SOC 2 auditor, the HIPAA customer and the enterprise security review.
Worked example: scoping a telehealth MVP
A startup is building a video consultation app for US clinics, with card payments for co-pays and a plan to launch in Germany next year.
Open the checklist and filter Domain to Healthcare and Geography to US. HIPAA and HITECH come up first. The startup will be a business associate of the clinics, so it needs business associate agreements, a risk analysis, access logging and breach procedures. FDA 21 CFR Part 11 also appears; it only applies if the records support FDA-regulated activity such as a clinical trial, so the team notes it and moves on.
Switch Domain to Payments. PCI DSS applies, but its scope depends on architecture. Using the payment processor's hosted fields or a redirect means card numbers never touch the startup's servers, which shrinks the assessment to a short self-assessment questionnaire instead of a full audit. That is an engineering decision worth making on day one.
Filter Geography to EU for the German launch. GDPR adds a lawful basis for processing health data (a special category under Article 9), data protection impact assessments and transfer rules for data leaving the EU. Add WCAG for the patient-facing UI.
Add those items to My Checklist, rename it "Telehealth MVP", and click Download MD. Each requirement becomes a - [ ] line that can go straight into the repository or the issue tracker:
## 1. Health Insurance Portability and Accountability Act (HIPAA)
**Type:** Regulation
**Severity:** Critical
**Key Requirements:**
- [ ] Administrative safeguards
- [ ] Physical safeguards
- [ ] Technical safeguards
- [ ] Business associate agreements
- [ ] Risk assessments and management
Mistakes that cost the most
- Assuming location decides scope. GDPR follows the people whose data you process, not where your servers are.
- Letting card data touch your servers by accident. A logging middleware that records request bodies can put the whole stack in PCI scope.
- Calling SOC 2 a certification in sales material. Auditors and buyers notice.
- Quoting old penalty figures. Many are inflation-adjusted every year; check the regulator's current number.
- Treating accessibility as a final polish step. Retrofitting keyboard access and contrast into a finished design system is far more expensive than building it in.
- Forgetting newer rules. The checklist does not yet cover the EU AI Act, NIS2, DORA or the European Accessibility Act, which applies from June 2025, or US state privacy laws beyond California.
Turning the map into work
Use the checklist to find the regimes, the official links on each card to read the actual text, and a professional to confirm anything that affects launch. Then turn the shared controls into tickets. Pair it with the Security Checklist for hands-on application security items, the Contrast Checker for WCAG colour ratios, and the Risk Matrix to rank what to fix first. Revisit the list whenever the product adds a new data type, a new market or a new kind of customer, because that is when the scope changes.