What GDPR, HIPAA, and PCI-DSS Actually Demand From Your Infrastructure — And Why Most Hosts Fall Short

Compliance has become a selling point. Browse any major hosting provider's website and you'll find badges, whitepapers, and landing pages promising HIPAA-eligible infrastructure, GDPR-ready data centers, and PCI-DSS compliance. It sounds reassuring. It often isn't.

The gap between "compliance-ready" marketing language and what these regulations actually require at the infrastructure level is enormous — and most developers and business owners don't have the time or background to interrogate it properly. That gap is where liability hides.

This isn't a legal guide. Talk to an attorney for that. This is an infrastructure guide — a look at what these frameworks actually demand technically, where hosting providers commonly fall short, and how to run a credible audit of your own setup.

The Fundamental Misunderstanding About Compliance

Here's the thing most hosts won't tell you clearly: a compliant host does not make your application compliant. Compliance is a shared responsibility. Your host might provide the physical and network controls required by a given framework, but your application architecture, data handling practices, access controls, and logging are almost always your responsibility.

AWS calls this the Shared Responsibility Model. Every major cloud provider has a version of it. The host secures the infrastructure. You secure what runs on it.

When a host says "HIPAA-eligible," they mean they've implemented the infrastructure controls required to run HIPAA workloads — but you still need a Business Associate Agreement (BAA), you still need to configure encryption correctly, you still need audit logging, and you still need to enforce access controls. The host can't do that for you.

With that baseline established, let's look at what each major framework actually demands.

HIPAA: It's Not Just About Encryption

The Health Insurance Portability and Accountability Act applies to any organization handling Protected Health Information (PHI) in the US. If you're building healthcare software, patient portals, telehealth platforms, or anything that touches medical records, you're likely in scope.

At the infrastructure level, HIPAA's Security Rule requires:

• Encryption of PHI at rest and in transit. This means TLS 1.2+ for data in motion and AES-256 (or equivalent) for data at rest. Most modern hosts support this, but you need to verify it's actually enabled — not just available.
• Access controls and audit logging. Every access to PHI needs to be logged. Who accessed what, when, and from where. Your host needs to provide infrastructure-level logging (VPC flow logs, access logs), but your application also needs its own audit trail.
• Business Associate Agreements. Any vendor that handles PHI on your behalf — including your host — must sign a BAA. AWS, Google Cloud, and Azure all offer BAAs. Many smaller hosts don't, which means you legally cannot store PHI with them regardless of their technical capabilities.
• Breach notification infrastructure. You need to be able to detect unauthorized access and report breaches within 60 days. Your monitoring and alerting setup is part of this.

Where hosts commonly fall short: they offer BAAs but don't support the specific services you need under that agreement. AWS's BAA covers a long list of services, but not all of them — and if you use a non-covered service to process PHI, you're out of compliance even though you signed the paperwork.

GDPR: The Data Residency Problem

The General Data Protection Regulation applies to any organization that processes personal data of EU residents, regardless of where the organization is based. If you're a US company with European customers, GDPR applies to you.

The infrastructure requirements that catch people off guard:

• Data residency and transfer restrictions. GDPR restricts transferring personal data outside the EU without specific legal mechanisms in place (Standard Contractual Clauses, adequacy decisions, etc.). If your US-based host stores EU customer data on US servers without the right contractual framework, that's a violation. Many hosts don't make their data residency options clear, and the default region for most US-based providers is — surprise — the US.
• Right to erasure. You need to be able to permanently delete a specific user's data across all systems, including backups. This is technically harder than it sounds. If your backups are encrypted snapshots, can you actually identify and remove a single user's records from them? Most backup architectures can't do this without significant custom tooling.
• Data processing agreements. Similar to HIPAA's BAA, GDPR requires Data Processing Agreements (DPAs) with any vendor that processes personal data on your behalf. Your host, your CDN, your logging service — all of them.
• Breach notification within 72 hours. Faster than HIPAA's 60 days. Your monitoring infrastructure needs to be able to detect breaches quickly enough to meet this window.

PCI-DSS: The Most Technically Prescriptive

If you process, store, or transmit cardholder data — credit card numbers, CVVs, expiration dates — you're subject to the Payment Card Industry Data Security Standard. PCI-DSS is the most technically specific of the major frameworks, with 12 requirements that translate directly into infrastructure controls.

Key infrastructure demands:

• Network segmentation. Cardholder data environments must be isolated from the rest of your infrastructure. This means VPCs, security groups, and firewall rules configured specifically to limit access to cardholder data. A host that doesn't support proper network segmentation can't support PCI compliance.
• Vulnerability scanning and penetration testing. PCI-DSS requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) and annual penetration tests. Your host needs to permit these — some don't without prior approval, and some actively block scanning tools.
• Log retention. Audit logs must be retained for at least one year, with three months immediately available. This has specific implications for your logging infrastructure and storage costs.
• No storage of sensitive authentication data. Full magnetic stripe data, CVVs, and PINs cannot be stored after authorization — ever. This is an application-level requirement, but your host's database and storage configuration affects whether you can enforce it.

How to Actually Audit Your Current Setup

Stop relying on your host's compliance marketing page. Here's a more reliable approach:

Request documentation, not badges. Ask your host for their current SOC 2 Type II report, their PCI-DSS Attestation of Compliance (AOC), or their HIPAA BAA. If they can't produce these documents, the badges on their website are decorative.

Map your data flows. Before you can assess compliance, you need to know where your regulated data actually lives — which databases, which services, which third-party integrations. Most organizations discover data in unexpected places during this exercise.

Check your DPAs and BAAs. Make a list of every vendor that touches your regulated data and verify you have signed agreements with each of them. This includes your CDN, your logging service, your error tracking tool, your email provider.

Test your deletion capabilities. If you're subject to GDPR, actually try to delete a test user's data from all systems, including backups. Document what you can and can't do. The gaps you find are your liability exposure.

Verify encryption is actually enabled. Don't assume. Check that encryption at rest is turned on for your databases and storage volumes. Check that your TLS configuration is current (TLS 1.0 and 1.1 are deprecated and non-compliant under most frameworks). Tools like SSL Labs and testssl.sh can help.

The Bottom Line on Compliance Infrastructure

Compliance is expensive because it should be. The frameworks exist because the cost of mishandling sensitive data — to individuals, not just organizations — is real. But a lot of what you're paying for in "compliance-ready" hosting is access to the right controls, not a guarantee that those controls are properly configured.

The hosts that genuinely support compliance workloads are the ones that provide detailed documentation, sign the necessary agreements, offer the right network controls, and give you the logging infrastructure to prove you're meeting requirements. The ones that don't are the ones that put a SOC 2 badge on their pricing page and hope you don't ask follow-up questions.

Ask the follow-up questions. Your auditor will.