Short answer: No BI tool is "HIPAA certified," because no such certification exists. A cloud BI vendor can be used with protected health information if it will sign a Business Associate Agreement, keeps your PHI off shared infrastructure or can show you exactly how tenants are isolated, encrypts data at rest and in transit, retains audit logs for six years, has BAAs with its own hosting and backup providers, and can pass your security review with documentation rather than assurances. Most vendors fail on the second, fourth, or fifth of those, and the ones that pass usually put it all behind an enterprise tier. This post lists the compliance requirements that apply to a BI tool, why each item matters for data privacy, and what to ask.
Why "HIPAA compliant" on a vendor's website means very little
HIPAA regulates covered entities and their business associates. It does not certify software. When a vendor says its product is HIPAA compliant, the claim can only mean one of two things: the vendor operates its service in a way that lets a covered entity use it without breaching the rules, or the vendor is repeating a phrase it has seen on competitor websites. You cannot tell which from the marketing page.
What you can verify is the vendor's willingness to become a business associate. Under the Privacy Rule, a covered entity may share PHI with a vendor only under a written agreement that binds the vendor to HIPAA's safeguards, and that agreement makes the vendor directly liable to regulators for its own failures. A vendor that will not sign a BAA is telling you it is not prepared to carry that liability, whatever its website says. That is the first filter, and it removes most of the market. (We keep a vendor-by-vendor check of who signs one, on which plans, and with what exclusions, in Which BI Tools Are HIPAA Compliant?)
What HIPAA actually requires of a BI tool handling healthcare data
A dashboard tool sits in an unusual position. It usually does not own the health records; it queries the systems that do. But if it connects to a database containing PHI, displays PHI to users, caches query results, emails scheduled reports, or writes audit logs that contain patient identifiers, it is handling PHI and the vendor is a business associate. The requirements that follow are the ones that bear on that position. Most come from the HIPAA Security Rule's technical safeguards; the BAA and minimum-necessary obligations come from the Privacy Rule.
| Requirement | Where it comes from | What it means for a BI vendor |
| Business Associate Agreement | Privacy Rule, 45 CFR 164.502(e) and 164.504(e) | The vendor signs a BAA before any PHI is provisioned, and has its own BAAs with every subcontractor that touches PHI, including hosting and backup providers |
| Access controls and unique user identification | Security Rule, 164.312(a) | Named accounts, role-based access controls, and a way to limit each user to the rows and fields they are entitled to see |
| Audit controls | Security Rule, 164.312(b) | Logs of who ran which report, when, against which data source, and what they exported |
| Encryption in transit and at rest | Security Rule, 164.312(a)(2)(iv) and (e)(2)(ii) | Currently "addressable," meaning required unless the entity documents why an alternative is reasonable. In practice every reviewer expects both. |
| Documentation retention | Security Rule, 164.316(b)(2) | Policies, procedures, and records of security activity kept for six years from creation or last effective date. Vendors should retain audit records on the same schedule. |
| Breach notification | Breach Notification Rule, 164.404 and 164.410 | A business associate must notify the covered entity of a breach without unreasonable delay and within 60 days of discovery, so the covered entity can meet its own deadline |
| Minimum necessary | Privacy Rule, 164.502(b) | The tool should let you expose only the fields a role needs, not the whole table |
Two things about this table. First, the Security Rule is under revision. HHS published a proposed update in January 2025 that would remove the "addressable" category and make encryption, multi-factor authentication, asset inventories, and regular penetration testing mandatory for everyone. As of this writing it is still a proposal, and HHS has signaled that a final rule is not expected before 2027. Treat the proposed items as the direction of travel: a vendor that already meets them will not need to scramble when the rule lands. Second, none of these requirements say anything about where the software runs. Cloud is permitted. What matters is whether the vendor can demonstrate the controls.
Six things to require from a cloud BI vendor
1. A signed business associate agreement, and BAAs behind it
Ask for the business associate agreement before the demo. Read it for two things: whether it covers the vendor's subcontractors, and whether it lists them. A vendor whose hosting provider has not signed a BAA cannot lawfully hold your PHI there, no matter what the vendor's own agreement says. Ask directly: "Which of your providers store or process our data, and do you have a BAA with each?" The answer should be a list, not a shrug.
2. Isolation you can describe on a diagram
Most cloud BI products are multi-tenant: many customers on the same application servers and often the same database, separated by software logic. That is not forbidden by HIPAA, but it puts the entire burden of isolation on the vendor's code being correct, and cross-tenant access-control bugs are among the most common findings in web application testing. For PHI, prefer one of two stronger arrangements: a dedicated server and database that serve your organization alone, or self-hosted software on your own infrastructure. If you accept multi-tenant, get the vendor to draw the data path and show you the test results that cover cross-tenant access.
3. Query in place instead of copying
Some BI tools import your data into their own storage to make it fast to chart. Every copy is another place PHI lives, another backup set, another breach surface, and another thing to delete when the contract ends. Tools that query your database live and hold only report definitions and metadata keep the PHI where it already is, under controls you already audit. Ask where query results are cached, for how long, and whether cached data is encrypted.
4. Row-level and field-level security that is enforced, not filtered
Clinical and operational reporting almost always needs the same report to show different rows to different people: a clinic manager sees their clinic, a payer sees their members, a physician sees their panel. Many tools handle this with per-user filters that a determined user can bypass by editing a URL or opening the underlying dataset. What you want is a policy applied by the server to every query for that user, with no way to remove it from the report side. Ask the vendor to show you a user attempting to remove the filter, and what happens.
5. Audit logs you own, retained for six years
The audit log is your evidence in an investigation. It should record logins, report executions, data source access, permission changes, exports, and prints. Two details matter: retention, which should match HIPAA's six-year documentation period, and ownership. If the vendor ingests your activity logs into its own analytics systems, that is another flow of PHI-adjacent data to account for. Better vendors keep the audit trail in your own database, queryable by you, and stay out of it.
6. Evidence for the security review
Your security team will send a questionnaire. What separates a vendor that passes from one that stalls is having the answers already written: an architecture summary, a data-flow diagram, policies for access control, incident response, business continuity, change management, vendor management, recent penetration test results, the sub-processor list, and a certificate of insurance. SOC 2 is a convenient package for all of that, but it is not a HIPAA requirement, and a vendor without SOC 2 can still pass if it can produce the underlying documentation. A vendor with SOC 2 but no BAA cannot.
Cloud, dedicated, or self-hosted: which fits PHI
Healthcare BI projects often start by ruling out cloud. That instinct is reasonable but usually solves the wrong problem, and it can add months to implementation. The issue with cloud BI for PHI is shared infrastructure and vendor access, not the cloud itself. There are three arrangements worth comparing. (For the self-hosted case in depth, see On-Premise BI Software for HIPAA Compliance.)
| Arrangement | Isolation | Who runs it | BAA needed from the BI vendor? | Best for |
| Shared cloud (multi-tenant) | Software-level separation on shared servers | Vendor | Yes, and many vendors will not sign one for this tier | Non-PHI reporting, or PHI only with a vendor whose isolation you have tested |
| Dedicated cloud (single-tenant) | Your own server and database, no other customer on the machine | Vendor | Yes | PHI workloads without the time or staff to provision servers internally |
| Self-hosted | Your infrastructure, your network | You | No, because the vendor never has access to the data | Air-gapped environments, strict on-premise policy, or when internal IT can provision and patch servers promptly |
The dedicated option deserves more attention than it usually gets. In our experience, healthcare teams frequently arrive wanting self-hosted, then discover that getting a server approved, provisioned, hardened, and patched through internal IT takes longer than the reporting project itself. Vetting one cloud vendor is often faster. A dedicated server gives the same single-tenant isolation with the vendor doing the operations work, and the vendor signs a BAA because it is the one with access.
Questions to put in your RFP
These are the questions that separate vendors quickly. Most of them have one-word answers, which is the point.
| Question | The answer you want |
| Will you sign a BAA, and on which plans? | Yes, with the plan named |
| Do your hosting and backup providers have BAAs with you? | Yes, executed before PHI is provisioned |
| Is our data on shared or dedicated infrastructure? | Dedicated, or a clear description of shared-tenant isolation with test evidence |
| Do you copy our data into your platform, or query it in place? | Query in place; caches described and encrypted |
| How is row-level security enforced? | Server-side policy per user, not a report-side filter |
| How long are audit logs retained, and who can read them? | Six years; the customer owns and queries them |
| Which staff can access our environment, and how? | A small number of named people, key-based access, logged and rotated elevated credentials |
| What penetration testing do you do, and can we see results? | Recurring third-party testing, results shared under NDA |
| What cyber liability insurance stands behind the BAA? | A specific policy and limit |
| What happens to our data when we leave? | Returned or destroyed on a stated schedule, with backups purged |
How DashboardFox handles PHI
DashboardFox is our product, so weigh this section accordingly. We built it to answer the questions above the way we would want them answered.
We sign a Business Associate Agreement on Enterprise Dedicated Cloud with the Compliance Tier, where PHI runs on a server and a PostgreSQL database that serve your organization alone, in a US region that is a HIPAA/HITECH-attested facility. BAAs with our hosting and encrypted-backup providers are executed before any PHI is provisioned. Data is encrypted with AES-256 at rest and TLS 1.2 or higher in transit, backups are encrypted before they leave the server, and the decryption key is held offline. Row-level and field-level security are enforced by the server on every query and are included on every plan. The audit trail lives in your own DashboardFox database, is queryable by you, is not ingested into our systems, and database audit logs are retained for six years. Production access is limited to a small number of named personnel over key-based connections, with elevated credentials that require a logged reason and are rotated after each use. The work is backed by a standalone $5 million cyber liability policy. A healthcare organization runs PHI on this arrangement in production today, under a signed BAA, after passing its own security review.
We do not offer a BAA on our shared Starter, Growth, or Scale plans, because a BAA makes us responsible for your PHI and we are not willing to carry that responsibility on shared infrastructure. Self-hosted customers do not need a BAA from us, because we never have access to their data. SOC 2 Type II is on our roadmap; in the meantime our controls are documented in a policy set mapped to standard questionnaire items, and we complete security reviews directly.
Compare deployment options → · Security review kit → · Business Associate Agreement → · Talk to an engineer about your healthcare reporting →
Frequently asked questions
Is there such a thing as HIPAA-certified BI software?
No. HHS does not certify software or vendors. A vendor can operate in a way that lets a covered entity use it lawfully, and can document that with a BAA, policies, and test results, but "certified" is a marketing word.
Can a cloud BI tool be used with PHI at all?
Yes. HIPAA does not prohibit cloud services. It requires a BAA with the vendor, appropriate safeguards, and a risk analysis that considers where the data lives. Dedicated single-tenant hosting makes that analysis much easier than shared multi-tenant hosting.
Does a BI tool need a BAA if it only displays PHI and doesn't store it?
If the vendor can access PHI in the course of providing the service, which includes querying it, caching results, or logging report activity, it is a business associate and needs a BAA. "We only display it" is not an exception under the rule.
Is SOC 2 required for HIPAA?
No. SOC 2 is a voluntary attestation. Many reviewers ask for it because it is a convenient package of evidence, but the requirement is the safeguards themselves and a BAA. A vendor without SOC 2 can pass a security review with the underlying documentation.
How long should a BI vendor keep audit logs for PHI?
HIPAA's documentation requirement is six years. Vendors that retain audit records for shorter periods leave the covered entity to fill the gap, so ask for six years or export the logs yourself on a schedule.
Is self-hosted BI safer for PHI than cloud?
It keeps healthcare data entirely on your own infrastructure and removes the vendor from the picture, which simplifies the risk analysis and eliminates the BAA. But security then depends entirely on your own patching, backups, access control, and monitoring. For organizations with a strong IT function that is the safest option. For those without, a dedicated cloud server run by a vendor under a BAA is often more secure in practice than a self-hosted server nobody has time to maintain.
This post describes what to require from a vendor. It is not legal advice; your compliance officer and counsel decide what your organization needs.
