The phrase “HIPAA-compliant” appears on the marketing pages of nearly every hosting provider serving the healthcare industry. It is a reassuring claim and one of the easiest to make in the industry. It is also one of the hardest to verify from the outside.

Two providers can display the same compliance language, while the work behind the scenes couldn’t be more different. One has commissioned an independent auditor to spend weeks testing controls, sampling a year of operating evidence, and verifying physical safeguards on the data center floor. The other has paid a fraction of the price for a document-only review that confirmed a folder of policies looked complete, without testing whether any of it reflected in what the environment actually does. , from the outside, the two badges are indistinguishable.

For any organization that places electronic Protected Health Information (ePHI) on that infrastructure, the difference remains invisible right up until the moment it matters: during a breach investigation, a customer’s due diligence audit, or a cyber insurance claim. By then, the compliance badge has already done its job of winning the business.

The distinction that counts comes down to who audited the provider, how recently, and what that auditor actually examined. A real audit and a paper audit produce the same badge by completely different means, and the gap between them is where compliance either holds up or falls apart.

What “HIPAA-compliant” Actually Means

No government agency issues a HIPAA compliance certificate. The Department of Health and Human Services does not certify hosting providers, software vendors, or any other covered entity or business associate. When a provider displays a “HIPAA-compliant” badge, that badge is a claim, and the weight behind it comes entirely from the independent audit that produced it.

HIPAA compliance is the organization’s own legal obligation, and no government body will grade it with a pass or fail. What a provider can actually give a customer is independent evidence that its controls were tested, most often an examination performed by a qualified, independent CPA firm under the American Institute of Certified Public Accountants (AICPA) attestation standards AT-C 105 and AT-C 205. These are general attestation standards rather than anything HIPAA itself prescribes. Still, an examination under them means a CPA firm tested the provider’s controls against HIPAA’s technical, administrative, and physical safeguard requirements and issued a formal opinion. It is the strongest independent verification a provider can show to a customer. A provider who says “HIPAA-compliant” is either misstating their situation or describing a third-party badge program with no regulatory standing.

The second thing the badge does not tell you is scope. HIPAA-compliant hosting establishes a compliant infrastructure foundation. The controls at the data center level, at the network perimeter, and in the managed environment are the provider’s responsibility to maintain and verify. The customer’s application code, database configurations, access controls, staff training, and operational policies sit on the customer side of the shared-responsibility line. A provider can hold a thoroughly audited environment, and a customer’s insecure application can still expose ePHI in a way that constitutes a HIPAA violation. The audit is a necessary condition, but it is not the whole picture.

Understanding this separation matters before you evaluate any provider’s claim of compliance. The questions worth asking are straightforward: who audited you, when, and what did they actually examine?

Real Audits vs Paper Audits

Not every hosting provider that claims to support HIPAA-regulated workloads undergoes the same level of independent auditing.

At one end is an independent, qualified auditor performing hands-on fieldwork: examining evidence in place, testing whether controls operate as described, observing system configurations, and verifying on-site physical access controls.

At the other end is what the industry sometimes calls a paper audit or checkbox review, a cheap, document-only exercise in which an auditor collects policies from the provider, reads them, and confirms they appear to say the right things, without ever verifying that those policies reflect what the environment actually does.

A paper audit is not always easy to identify from a distance. It typically looks like a compliance report. It may reference the same regulatory frameworks. The difference is in what the auditor did to reach their conclusions. Did they visit the facility? Did they observe access controls in operation? Did they sample logs, interview staff, and test configurations, or did they accept a folder of documents at face value? Document-only reviews are frequently completed remotely and at considerably lower cost than fieldwork-based audits. Lower cost is a signal worth paying attention to: a rigorous annual audit across multiple frameworks costs meaningfully more than a checkbox review assembled from submitted paperwork.

The problem with a paper audit is methodological, not geographic. Where the auditor sits matters far less than whether they actually tested anything. Plenty of logical controls can be verified remotely from system-generated evidence: an auditor can pull live configurations, sample access logs, and interview operators over video. What a document-only review skips is the testing itself. It accepts that a backup runs nightly because a policy says so, and that physical access controls work because a procedure document lists them, neither of which is the same as confirming they operate. Those are the gaps that surface during a breach investigation, a customer due diligence audit, or a cyber-insurance claim. Signed policies cannot substitute for real-world, evidence-based testing.

What a Real Auditor Does That a Paper Audit Skips

A qualified independent auditor does not accept a policy document about physical access controls as evidence that those controls exist. They visit the facility, walk through the environment, observe the controls in operation, and document their findings.

For Atlantic.Net’s Orlando data center, that means an auditor verifying a physical security configuration that includes biometric palm scanners and proximity card readers at access points, a man-trap entry vestibule, closed-circuit television with 24-hour recording and 30-day retention, and VESDA (very early smoke detection apparatus) air-sampling fire detection supported by dry-pipe pre-action suppression. No document review can confirm a palm scanner is operational. The auditor has to be there.

This is the kind of verification A-LIGN, Atlantic.Net’s independent US-based CPA firm, performs in each engagement: directly examining the physical and administrative environment, with eyes on the controls and the operations behind them.

The same fieldwork discipline applies to logical controls. Walkthroughs of system configurations, evidence sampling from access logs and change records, interviews with operations staff, and verification of monitoring procedures are all part of a SOC 2 Type II engagement. Each of these requires access to the live environment and the people who run it.

Why SOC 2 Type II and PCI DSS Raise the Bar

Some audit frameworks make a paper-only review structurally impossible, which is part of why they carry more weight than a self-attestation or a checkbox report.

SOC 2 Type II is one of them. A Type I report is a point-in-time examination: the auditor evaluates whether a provider’s controls are designed appropriately as of a specific date. A Type II report is different in kind. The auditor observes whether those controls operated effectively over an observation period, typically three to twelve months. To produce a Type II opinion, the auditor must examine evidence that controls functioned during that window, rather than a snapshot of their configuration on the day of the visit. You cannot manufacture twelve months of consistent operational evidence from documents assembled the week before an audit.

PCI DSS Level 1 service providers face an even more explicit requirement. At Level 1, which applies to organizations processing the highest volumes of payment card transactions, an annual assessment by a Qualified Security Assessor (QSA) is required, and the QSA produces a Report on Compliance (ROC) documenting the findings. The self-assessment questionnaire (SAQ) pathway used by lower-volume merchants is not available to Level 1 service providers. A QSA-led examination with independent testing, not a self-attestation, is what validates compliance at this level.

Atlantic.Net’s annual audit scope covers HIPAA/HITECH AT-C 105/205, SOC 2 Type II, SOC 3 Type II, and PCI DSS 4.0. Each of those engagements involves substantive independent examination rather than self-attestation, so the compliance posture is tested every year, and the evidence of that examination is maintained in a formal record.

For customers evaluating PCI-compliant hosting options, the ROC is the document to ask for. A provider who cannot produce one or who offers a self-assessment questionnaire as an equivalent is operating at a different level of verification.

The Hidden Cost of a Weak Audit

A compliance badge backed by a paper audit looks identical to one backed by a rigorous annual fieldwork engagement, until something goes wrong. Three specific situations tend to surface the difference.

A cyber-insurance claim. Cyber liability applications increasingly ask the insured to represent that specific controls are in place and independently verified. Those representations carry weight: insurers have moved to deny or rescind coverage when a post-breach forensic review finds that a control the policyholder attested to was not operating as represented. A compliance posture that was never independently tested is harder to stand behind on that application, and a misrepresentation there, even an unintentional one, can put a claim at risk.

A downstream audit. Healthcare SaaS vendors, medical billing platforms, and telehealth providers are regularly audited by the hospital systems and covered entities that use them. Those upstream customers request their vendors’ compliance documentation as part of the procurement or contract renewal process. A vendor whose hosting provider’s compliance rests on a paper review may find that the covered entity’s compliance team does not accept it. The weak foundation at the infrastructure level propagates upward through the supply chain.

Liability under the BAA. Atlantic.Net provides a HIPAA Business Associate Agreement (BAA) as standard with all HIPAA hosting plans. The BAA defines what the hosting provider is responsible for and what remains the customer’s responsibility. Liability flows in both directions: the provider is accountable for the infrastructure controls they have committed to maintaining, and the customer is accountable for the application, access policies, and operational practices on their side of the line. A provider whose compliance was never independently verified in depth has, in practice, made commitments the audit cannot support.

The pragmatic point worth stating plainly is this: the hosting provider’s audit is necessary, but the customer still owns their application security, staff access controls, and operational procedures. A well-audited host does not make a poorly secured application compliant. Both sides of the shared-responsibility line need to be in order.

How to Vet a Hosting Provider’s Compliance

Asking whether a provider is “HIPAA-compliant” is a reasonable place to start, though it rarely tells you enough on its own. The following questions will help to gather more useful information.

Who is the auditor, and are they independent? The auditor should be an independent firm without business ties to the provider that would compromise its objectivity. An internal team, or a firm that also sells the provider the controls it audits, constitutes a conflict of interest that undermines the value of the report.

Is the SOC 2 report a Type II? Ask specifically. A Type I report confirms controls were designed appropriately at a point in time. A Type II report confirms that they operated effectively during the observation period. These are materially different assurances, and the Type II is the one worth asking for.

Does an actual report exist, or is this a self-attestation? A legitimate SOC 2 engagement produces a formal report. A provider who describes their compliance in marketing materials but cannot produce an NDA-protected report on request has not completed an independent audit in the standard sense.

When was the most recent audit completed? Annual cadence is the standard across SOC 2, HIPAA/HITECH AT-C 105/205, and PCI DSS. An audit more than 12 months old may no longer reflect the current environment.

Is a BAA offered as standard for HIPAA workloads? A legally binding BAA must be in place before any hosting provider creates, receives, stores, or transmits ePHI on behalf of a covered entity. The law requires that an adequate agreement exist, not that it be free or bundled into every plan, so a provider that treats the BAA as an obstacle, or will not commit to one as standard, is worth scrutinizing.

Are physical and environmental controls within the audit scope? Ask the provider to confirm that physical access controls, environmental monitoring, and facility security are addressed in their audit report. A report scoped only to logical controls leaves a material gap in the evidence base.

How Atlantic.Net Approaches Compliance Audits

Atlantic.Net commissions A-LIGN, a US-based independent CPA firm, to perform its annual compliance audits. Each engagement covers HIPAA/HITECH AT-C 105/205, SOC 2 Type II, SOC 3 Type II, and PCI DSS 4.0, with A-LIGN conducting the fieldwork required by each standard.

For HIPAA and SOC 2 Type II, A-LIGN auditors verify physical and environmental controls at the facility level, review operating evidence across the observation period, and examine the managed services and administrative controls that support the hosted environment. The PCI DSS 4.0 assessment follows the Level 1 QSA pathway, producing a Report on Compliance instead of a self-assessment questionnaire.

“Compliance built-in, not bolt-on” describes the operational reality that the compliance infrastructure at Atlantic.Net, the physical access controls, the managed FortiGate firewalls with intrusion prevention, the encrypted VPN, the bi-weekly vulnerability scanning, the 24/7 SOC monitoring, and the audit trail through the Log Management System, are standard components of HIPAA-compliant hosting plans, not features a customer needs to request or add. A legally binding BAA is standard with every HIPAA plan.

Where the shared-responsibility line sits is worth making clear. Atlantic.Net’s audited controls cover the physical environment, the network perimeter, the hypervisor layer, and the managed platform components. The customer’s application code, database security configurations, internal user access policies, and staff training are the customer’s responsibility. A well-audited hosting environment provides a verified foundation; building on it correctly is the customer’s part of the arrangement. (Atlantic.Net will, of course, offer assistance on request) The SOC 3 Type II report is publicly available; the full SOC 2 Type II report is available under NDA for customers who want to review the details of what was examined and what A-LIGN found.

Compliance You Can Verify

A compliance badge is the beginning of a conversation, not the end of one. The question that actually protects a healthcare or payments workload is who audited the provider, how recently, and what the auditor examined in person. Atlantic.Net built its compliance program around answers it can demonstrate: a named US-based independent auditor, A-LIGN; annual engagements across HIPAA/HITECH AT-C 105/205, SOC 2 Type II, SOC 3 Type II, and PCI DSS 4.0; and fieldwork that verifies controls in operation, not on paper.

If you are evaluating a hosting provider for a HIPAA or PCI-regulated workload and want to separate a verifiable compliance posture, contact the Atlantic.Net solutions team. We will walk through your compliance requirements, where the shared-responsibility line falls for your application, and what our audit reports actually cover.