Is PGx Software HIPAA Compliant? Security, BAAs, SOC 2, and What to Require of a Vendor

Is PGx software HIPAA compliant? There is no government "HIPAA certification," so the real test is whether the vendor will sign a Business Associate Agreement and implement HIPAA's required safeguards: encryption, role-based access, audit trails, and tenant isolation. SignalPGx is HIPAA- and GDPR-aligned, with SOC 2 and ISO 27001 readiness in progress.

Is PGx software HIPAA compliant, and what does that actually require?

The precise answer surprises many buyers: there is no such thing as a government-issued "HIPAA certification." No federal agency, including HHS's Office for Civil Rights, certifies any product or company as HIPAA compliant. A vendor advertising a "HIPAA certified" seal is describing a self-assessment or a private third-party audit against HIPAA controls, not a federal credential.

What actually matters is whether the vendor meets the HIPAA Security Rule, which requires covered entities and their business associates to implement administrative, physical, and technical safeguards protecting the confidentiality, integrity, and availability of electronic PHI (ePHI).

Those safeguards fall into three families. Administrative safeguards are policies and workforce controls: risk assessments, training, and access management. Physical safeguards protect the facilities and hardware where ePHI lives. Technical safeguards are the software-level protections: access controls, audit controls, integrity controls, and transmission security. So the right question for a PGx software vendor is not "are you certified?" but "will you sign a BAA, and can you show the safeguards behind it?"

Raise these questions early. Security and BAA review usually runs in parallel with legal and clinical evaluation, and a vendor that cannot produce a BAA or safeguards documentation on request will stall your entire onboarding timeline, no matter how strong the clinical content is.

Why PGx reports are PHI and why the vendor needs a BAA

A pharmacogenomic report is unambiguously protected health information. It links an identifiable patient to genotype data and medication-specific guidance, among the most sensitive data a lab handles. Any software that creates, receives, maintains, or transmits that data on the lab's behalf is a business associate under HIPAA.

HIPAA requires the covered entity to have a written Business Associate Agreement (BAA) with every such vendor. The BAA must require the vendor to safeguard PHI, use and disclose it only as permitted, and report breaches. If a PGx software vendor will not sign a BAA, that is a disqualifying answer, full stop.

This holds even for downstream tools. SignalPGx sits after variant and star-allele calling and intakes already-called genotypes, but it still processes patient-linked data, so the BAA and safeguards apply the same way any PHI does in your PGx reporting workflow.

Two related principles belong in diligence. The minimum-necessary standard means the software should expose only the PHI each user needs to do their job. And if the vendor uses any data for analytics, benchmarking, or model tuning, ask whether it is properly de-identified and what contractual limits govern secondary use. The BAA should constrain use and disclosure strictly to what you permit.

The security controls to require: encryption, RBAC, tenant isolation, audit trails

Beyond the BAA, ask the vendor to demonstrate the specific technical controls. At minimum:

• Encryption in transit and at rest. Under the current Security Rule, encryption is technically an "addressable" specification rather than an absolute mandate (see HHS's encryption FAQ), but it is the near-universal, expected way to protect ePHI, and a 2025 HHS proposed rule would make it explicitly mandatory. Treat it as table stakes.
• Role-based access control (RBAC). Users should see only what their role requires. A lab tech, a medical director, and a billing user are not the same, and least privilege should be enforceable.
• Tenant isolation. In multi-tenant, white-label platforms, each lab's data must be logically walled off so one customer can never reach another's PHI.
• Audit trails and access logging. Every read, edit, and export of a report should be attributable to a user and timestamped, and you should be able to export those logs.
• Availability and recovery. The "A" in the confidentiality-integrity-availability triad is easy to overlook. Ask about encrypted backups, tested restore procedures, and a recovery objective, so a report signed out today is still retrievable and intact months later.

Also ask about multi-factor authentication for privileged access, session controls, and how the vendor manages workforce access, including prompt deprovisioning when an employee leaves. Data integrity controls matter too: a signed-out report must not be alterable undetectably between sign-out and delivery. SignalPGx implements these controls, and you can review the specifics on our platform and security pages.

SOC 2 and ISO 27001: what they mean and how to ask about them

SOC 2 and ISO 27001 are the two signals buyers use to verify security maturity independently, and the vocabulary matters.

SOC 2 is an attestation defined by the AICPA, not a certificate. An independent auditor evaluates a company's controls against the Trust Services Criteria and issues a report. A Type I report assesses control design at a single point in time; a Type II report additionally verifies that those controls operated effectively over an observation period, commonly six to twelve months. Ask which type, the report date, and the scope.

ISO 27001 is different: it is a formal certification issued by an accredited certification body against an international information-security-management standard. The two frameworks overlap heavily but are not interchangeable, and a vendor may pursue one, both, or neither.

When a vendor claims either, request the actual report or certificate, its scope, and its date. "We're compliant" is not the same as a current, in-scope attestation you can read. A genuine readiness or in-progress status is legitimate for a newer vendor; what matters is honesty, a credible roadmap, and compensating controls you can inspect today.

When a formal attestation is not yet available, ask for the evidence that fills the gap: a recent third-party penetration-test summary, vulnerability-scanning cadence, a security whitepaper, and a completed standardized questionnaire such as a SIG or CAIQ. These let your security team judge maturity on their own terms rather than taking a badge at face value, and they are exactly what a diligent buyer should request whether or not a SOC 2 report exists.

Data residency, breach response, and subprocessors

Three procurement questions round out a serious security review.

Data residency. Ask where PHI is stored and processed, and whether that meets your jurisdictional obligations. For labs serving international patients, GDPR and regional rules may apply alongside HIPAA, and residency commitments should be in writing.

Breach response. Ask for the vendor's documented incident-response and breach-notification process. As buyer context, note that under GDPR data controllers are generally expected to notify regulators of a qualifying personal-data breach within 72 hours of becoming aware of it. That is a useful benchmark for what "timely" should look like, even where it is not your specific legal standard, rather than a contractual promise any given vendor makes.

Subprocessors. Any cloud or service provider the vendor relies on to handle PHI is a subprocessor, and each one needs its own BAA. Ask for the current subprocessor list and confirmation that agreements are in place. If your PGx software connects to your EHR, review those integrations through the same lens: HL7, FHIR, SMART, and CDS Hooks are the open standards that keep data exchange auditable and under your control.

Data retention and deletion. Confirm how long the vendor retains PHI, whether retention aligns with your lab's own record-keeping obligations, and how data is securely deleted at the end of the relationship. Contract termination should trigger return or documented destruction of your data, not indefinite storage on someone else's systems.

How SignalPGx approaches security and compliance

Here is SignalPGx's honest posture. The platform is HIPAA- and GDPR-aligned, with encryption in transit and at rest, role-based access control, tenant isolation, and complete audit trails, all designed to fit within your CLIA lab's workflow. We will sign a BAA, and the details live on our security page.

That discipline has to scale with the data the platform touches. SignalPGx draws on 16 evidence sources and spans 50+ pharmacogenes, 950+ medications, and 7,700+ drugs with drug-drug interactions, so tenant isolation, access control, and audit logging are structural parts of how the system is built, not features bolted on afterward.

On the third-party frameworks: SOC 2 and ISO 27001 readiness are in progress. We are transparent that SignalPGx is not currently SOC 2 attested or ISO 27001 certified, and we will not claim otherwise. An honest "readiness underway" is worth more to a compliance officer than an overstated badge.

Two design points reinforce the security story. Your lab's own licensed medical director reviews and signs out every report; the software supports the reviewer rather than interpreting or signing out as a service, and it never replaces the treating physician's prescribing decision. And SignalAI, our reviewer assistant, is guardrailed to cite-or-refuse instead of acting autonomously. SignalPGx is not a diagnostic test and is not FDA-cleared. For how that human-in-the-loop model produces clinically defensible reports, see our detailed write-up.

A vendor security checklist for PGx software

Use this list to evaluate any PGx software vendor. A confident vendor answers all of it without friction.

1. Will you sign a Business Associate Agreement, and can we see your template?
2. Is PHI encrypted in transit and at rest, and how are keys managed?
3. How is access controlled by role, and can you enforce least privilege?
4. In a multi-tenant deployment, how is our data isolated from other customers?
5. Do you maintain immutable audit trails and access logs, and can we export them?
6. Do you hold a SOC 2 attestation (Type I or II) or ISO 27001 certification, or, if not, what is your readiness status and timeline?
7. Where is our data stored and processed, and does that meet our residency requirements?
8. What is your documented breach-response and notification process?
9. Who are your subprocessors, and is a BAA in place with each?
10. How does the software fit our CLIA workflow while keeping our medical director's sign-out authority intact?

You can put every one of these questions to SignalPGx through our contacts page.

The bottom line: security is a procurement gate, not a box to tick

For a CLIA lab, PGx software security is not a nice-to-have appended after the clinical evaluation; it is a gate the vendor either clears or does not. The decisive signals are concrete: a signed BAA, demonstrable encryption, RBAC, tenant isolation, and audit trails, backed by honest answers on SOC 2, ISO 27001, data residency, breach response, and subprocessors.

Be skeptical of anyone advertising a "HIPAA certified" seal that does not exist, and equally skeptical of a claimed SOC 2 or ISO status no one will let you read. The vendors worth trusting are the ones whose answers are specific, current, and verifiable, and who tell you plainly what is finished and what is still in progress.

This article is general information for procurement teams and is not legal, billing, or regulatory advice; confirm your specific obligations with your own compliance counsel.