HIPAA, SOC 2, PCI DSS, and GDPR: Which Applies to Your App

These four are routinely discussed as a single category called compliance, and they are four different kinds of thing. One is a law with mandatory safeguards. One is a voluntary audit your customers ask for. One is a contractual standard imposed by an industry. One is a regulation with extraterritorial reach and a different underlying philosophy.

Confusing them produces two expensive errors: building for an obligation that does not apply, and discovering one that does during a sales process.

What each one is

The column that matters most is the third. HIPAA and GDPR apply because of what you do, whether you like it or not. PCI DSS applies because of a contract you signed with a payment provider. SOC 2 applies because a customer asked, which means it is a revenue question rather than a legal one.

HIPAA, in practical terms

Applies to covered entities, principally healthcare providers, health plans, and clearinghouses, and to business associates handling protected health information on their behalf.

The critical distinction most founders get wrong: a wellness app selling directly to consumers with no provider relationship is frequently outside HIPAA. The same app sold to a hospital is inside it as a business associate. The software barely changes and the obligation set changes entirely.

What it adds to a build: access control with unique identification and role-based permissions enforced in queries, audit logging of every access to patient data retained for years, integrity controls with append-only clinical history, encryption in transit and at rest, and business associate agreements with every third party touching the data including your cloud provider, error monitoring, analytics, and any AI provider.

Typically 30 to 60 percent added to a comparable non-regulated build, and four to eight weeks. Note that there is no HIPAA certification. It is a set of safeguards you implement and document.

SOC 2, in practical terms

A voluntary audit against the AICPA Trust Services Criteria, producing a report you show customers. Type I assesses controls at a point in time; Type II assesses their operation over a period, commonly three to twelve months, and Type II is what enterprise buyers actually want.

What triggers it is a customer asking, which for enterprise-focused products happens earlier than founders expect, frequently during the first serious deal.

What it requires is less about code than the others. Documented policies, access management with reviews, change management, vendor management, incident response, employee onboarding and training, and evidence that all of it operated over the audit window. Engineering contributes logging, access controls, and monitoring; the rest is organisational.

Realistically $25,000 to $80,000 in the first year including tooling, audit fees, and internal time, plus a Type II observation period that cannot be compressed. Do not start speculatively. Start when a deal requires it.

‍

‍

PCI DSS, in practical terms

A contractual standard applying to anyone handling payment card data, and its burden varies enormously with architecture. The strategic objective is to minimise scope rather than to comply with the maximum version.

The mechanism is ensuring card data never reaches your servers. Hosted payment fields or a provider SDK collect the card, tokenise it, and return a token your systems store instead. Your obligation reduces to the lightest self-assessment tier.

Building your own card capture form that posts to your backend expands scope enormously, requiring network segmentation, formal vulnerability management, and in many cases external audit. Almost no early-stage product should do this, and any partner proposing it should justify the decision explicitly.

With tokenisation, the added build cost is modest. Without it, it is transformative.

GDPR, in practical terms

Applies to processing personal data of people in the EU regardless of where your company is, which makes it broader in reach than the others and different in philosophy: it is about lawful basis and individual rights rather than about a control checklist.

What it adds to a build: a lawful basis for each processing purpose, consent management where consent is the basis, data subject rights meaning access, correction, deletion, and portability, which are engineering features rather than policies, data minimisation, records of processing, breach notification within tight timeframes, and controls on international transfers.

The rights are the part that surprises teams. A user requesting deletion means deletion across your database, your backups policy, your analytics, your email provider, and your logs. Designing for that from the start is far cheaper than retrofitting it.

Note also that several US states now have comparable privacy laws with similar rights, so building these capabilities is increasingly useful regardless of EU exposure.

In practice, the four overlap heavily at the engineering layer. Access control enforced in queries, comprehensive audit logging, encryption at rest and in transit, secrets management, and a documented deletion and retention policy satisfy a large share of all four. Build those well and each subsequent obligation becomes a documentation exercise rather than a rebuild.

What they share, and what to build once

Six capabilities appear in all or most of the four, and building them properly in a first version is the single most cost-effective compliance decision available.

Access control enforced server-side in the query by authenticated identity, never by hiding interface elements. Audit logging as a distinct, queryable, retained record of who accessed what and when, separate from application logging. Encryption in transit throughout and at rest across database, files, and backups. Secrets in a managed vault rather than in configuration. A documented and implemented retention and deletion policy. And scrubbing of sensitive data at the boundary so it does not leak into logs, error reports, or analytics.

That last one deserves emphasis, because the most frequent real-world compliance failure across all four regimes is not weak encryption. It is regulated data appearing somewhere nobody intended: in an application log, in an error report sent to a third-party monitoring service, or in an analytics event.

Bolder Apps deploys to AWS, Azure, Google Cloud, and Firebase, builds backends in Laravel, Yii2, and Node.js, and sells paid discovery as a standalone engagement. In regulated categories the discovery deliverable that matters most is the boundary decision: which part of your system holds regulated data, so that the majority of it sits outside scope and only a defined component carries the obligation.

‍

‍

Sequencing, when more than one applies

Address them in order of what forces your hand.

First, anything legally mandatory for what you already do. HIPAA if you handle protected health information. GDPR if you have EU users. These are not optional and non-compliance carries penalties independent of whether a customer asks.

Second, PCI DSS scope minimisation, because it is architectural and cheap if decided early and expensive if decided late.

Third, the shared engineering capabilities above, which serve everything and are cheapest to build during the initial build.

Fourth, SOC 2, when a deal requires it. It is the only one of the four that is purely a revenue unlock, and starting it before a customer asks is spending money to remove a blocker you do not yet have.

Common misreadings, corrected

Five beliefs that cost money.

That HIPAA applies to any health-related app. It applies to covered entities and their business associates. A direct-to-consumer wellness app with no provider relationship is frequently outside it, and still subject to state privacy law and the FTC Health Breach Notification Rule.

That SOC 2 is required by law. It is entirely voluntary. It is required by customers, which for enterprise-focused products amounts to the same thing commercially and means the timing is a sales decision rather than a legal one.

That PCI DSS is unavoidable if you take payments. It applies, and its scope collapses to the lightest tier if card data never touches your systems. Architecture determines the burden.

That GDPR only matters if you have an EU office. It follows the data subject, not the company. Processing personal data of people in the EU brings you in scope regardless of where you are incorporated.

That certification exists for HIPAA. It does not. Third-party attestations are available and useful for demonstrating diligence, and no body certifies HIPAA compliance.

What to establish before the build starts

Five questions, answered in discovery rather than during a security review.

Which regimes apply, confirmed with counsel rather than assumed from a blog post including this one.

Where the regulated data boundary sits, so most of your system stays outside scope and only a defined component carries the obligation. This is an architecture decision and it is the highest-leverage one available.

Which third-party services will touch regulated data, and whether each will sign the necessary agreement. Error monitoring and analytics are the two most commonly overlooked.

What your retention and deletion policy is, since it affects the data model, the backup strategy, and the logging design simultaneously.

Who owns the documentation, and what the division of responsibility with your development partner is. Bolder Apps sells paid discovery as a standalone engagement, and in regulated categories that division of responsibility belongs in writing before anyone writes code.

What a development partner can and cannot do

Worth stating plainly, because agencies advertise otherwise. A development partner can build technical safeguards, help select services that will sign the necessary agreements, produce technical documentation, and prepare you for a security review.

A development partner cannot make you compliant. HIPAA compliance includes organisational policies, risk assessment, training, and incident response. SOC 2 requires evidence that your own processes operated. GDPR requires a lawful basis you determine. Any firm claiming to deliver a compliant app is describing something that does not exist as a deliverable.

What to request in writing is the division of responsibility: which safeguards they build, which remain yours, and which documentation they produce.

Sources

• US Department of Health and Human Services, HIPAA Security Rule and Privacy Rule guidance, hhs.gov/hipaa
• AICPA SOC 2 Trust Services Criteria, aicpa.org
• PCI Security Standards Council, PCI DSS v4 and self-assessment questionnaire guidance, pcisecuritystandards.org
• European Commission and European Data Protection Board GDPR guidance
• NIST Special Publication 800-53 and 800-66
• Federal Trade Commission Health Breach Notification Rule, ftc.gov