Healthcare AI Vendor Security Review: What to Request Beyond a HIPAA Claim

Published: · Last Updated:

When to use this playbook

  • A phone, texting, scheduling, referral, or prior authorization vendor will create, receive, maintain, or transmit protected health information.
  • A vendor has supplied a HIPAA logo or questionnaire response, but your security team has not reviewed the underlying contracts, reports, and technical architecture.
  • A medical group is preparing a limited pilot before deployment across multiple sites or athenaOne practice IDs.
  • An incumbent answering service or voice AI vendor is approaching renewal, creating an opportunity to compare its security posture with alternatives.
  • A vendor uses external telephony, speech, large language model, cloud, analytics, or support providers that could become part of the PHI handling chain.

What success looks like

The reviewer can trace PHI from the patient interaction into the EHR, identify every organization that handles it, and match each material security claim to a current contract, audit report, certification letter, test result, or technical control. The final approval record should also state what the vendor may access, how that access is monitored, and how data and credentials are removed at termination.

The security review packet to request

Evidence What to inspect What should be clear before approval
Business Associate Agreement Permitted uses, subcontractors, incident reporting, retention, return or destruction, and termination rights The BAA is executed before production PHI moves
SOC 2 Type II report Auditor, review period, system scope, Trust Services Criteria, exceptions, subservice organizations, and customer responsibilities The product and infrastructure being purchased are in scope
HITRUST certification letter e1, i1, or r2 level, assessed environment, issue date, and expiration date The vendor is certified, not merely preparing for or undergoing an assessment
ISO/IEC 27001 evidence Standard version, certification scope, certification body, validity dates, and covered locations or systems The certificate covers the relevant information security management system
Penetration test summary Tester independence, date, assets tested, material findings, remediation, and retesting Critical findings are closed and high findings have documented treatment
Data lifecycle schedule Retention and deletion for audio, transcripts, texts, documents, logs, backups, and derived data Each data type has an owner, location, retention period, and deletion process
AI data-use terms Model training, product improvement, human review, de-identification, and downstream model provider use Permitted uses are explicit and consistent across the BAA, service agreement, and privacy terms
Subprocessor register Legal entity, service, data handled, hosting region, retention, and BAA or contractual coverage Telephony, transcription, LLM, hosting, analytics, and support providers are included
Technical security package Encryption, key management, role-based access, MFA, SSO, privileged access, logging, and incident response Controls apply to production systems, support access, and administrative tools
EHR integration design API identities, scopes, read and write actions, practice-ID isolation, audit logs, and access revocation Permissions are limited to documented workflows and can be independently audited

Step 1: Define the system and data flow before reviewing badges

Estimated reviewer time: 45 to 90 minutes

Action

Ask for a current architecture and data-flow diagram covering inbound calls, outbound calls, text messages, recordings, transcripts, fax or document intake, application servers, model providers, support tools, and EHR connections. Require the diagram to identify where PHI is created, transmitted, stored, transformed, logged, and deleted.

Map the diagram to the workflows in scope. A vendor that only answers calls has a smaller access footprint than an agent that schedules appointments, updates charts, processes referrals, checks insurance, or writes prior authorization status into the EHR.

Expected outcome

You have one authoritative inventory of systems, data types, vendors, and integration paths. Every later document can be checked against that inventory rather than reviewed as an isolated badge.

Gotchas

  • A diagram that stops at “AI platform” and omits telephony, transcription, model, analytics, and support providers.
  • A security report covering a corporate environment while excluding the production service handling patient data.
  • “No PHI stored” used to describe a system that temporarily buffers audio, produces transcripts, or retains diagnostic logs.

Step 2: Replace the HIPAA claim with an executed BAA review

Estimated reviewer time: 30 to 60 minutes, plus legal review

Action

Request the vendor’s BAA before transmitting production PHI. Confirm that it defines permitted uses and disclosures, requires appropriate safeguards, covers incident reporting, extends restrictions to subcontractors, and addresses PHI return or destruction at termination. Those elements align with the business associate contract requirements published by HHS.

Read the BAA alongside the main service agreement. Security obligations lose practical value when another contract grants broad data-use rights, weakens deletion commitments, or excludes key subprocessors.

Expected outcome

The vendor’s contractual authority to use PHI is limited to the services you are purchasing, and the downstream PHI chain is covered before go-live.

Gotchas

  • The BAA becomes effective after implementation or after the first live call.
  • The vendor will sign a BAA, but a model, telephony, or hosting provider handling PHI is excluded from the contractual chain.
  • Deletion is described as “commercially reasonable” without addressing backups, transcripts, recordings, support exports, or derived data.
  • Incident notification has no named contact, escalation process, or defined contractual deadline.

A HIPAA claim is not independently verifiable through a government certificate. HHS does not require HIPAA certification and does not endorse private Security Rule certifications, so buyers still need to inspect the safeguards, contracts, and assurance evidence behind the claim. HHS HIPAA certification guidance.

Step 3: Read the scope, dates, and findings in each assurance report

Estimated reviewer time: 60 to 120 minutes

Action

Obtain the actual SOC 2 Type II report rather than accepting a logo or sales-page statement. Check the auditor’s opinion, review period, covered service, infrastructure boundaries, Trust Services Criteria, test exceptions, complementary user entity controls, and any subservice organizations excluded through the carve-out method.

Type II matters because it adds an examination of operating effectiveness over a period. The system description and test results still determine whether the report answers your specific risk question, as explained in the AICPA’s SOC 2 overview.

Use the HITRUST level, not the word “HITRUST”

Assessment Assurance model Validity How to evaluate it
e1 Foundational assurance based on 43 core controls 1 year Useful for confirming essential security hygiene in lower-risk environments
i1 Threat-adaptive assurance based on 182 control requirements 1 year Provides broader implemented-control assurance against active cyber threats
r2 Tailored, risk-based assessment with the highest level of control requirements 2 years Designed for complex environments with greater risk exposure, regulatory obligations, or data volumes

Request the certification letter and verify the assessment type, assessed environment, dates, and external assessor. A readiness assessment, planned assessment, or assessment in progress is not a certification. HITRUST assessment definitions.

Check what ISO/IEC 27001 actually covers

ISO/IEC 27001 evaluates an information security management system and its risk-management processes. If the vendor claims certification, request the certificate, scope statement, standard version, certification body, issue date, and expiration date. Certification is optional, so distinguish a formal accredited certificate from a vendor that has only aligned its policies or completed an internal assessment. ISO/IEC 27001.

Expected outcome

The dates are current, the systems handling your data are in scope, and material exceptions have either been corrected or incorporated into the risk decision.

Gotchas

  • A Type I report offered when the questionnaire says Type II.
  • A current report whose review period predates a major platform or infrastructure change.
  • HITRUST marketing that omits whether the assessment is e1, i1, or r2.
  • An ISO certificate scoped only to a headquarters office or corporate IT function.
  • Customer responsibilities that your medical group cannot operationally meet.

As of September 2026, Pretty Good AI is one example of a vendor providing HIPAA safeguards with a BAA, SOC 2 Type II evidence, HITRUST i1 certification, and ISO/IEC 27001 materials for enterprise review. Pretty Good AI security documentation.

Step 4: Review penetration testing and remediation evidence

Estimated reviewer time: 30 to 45 minutes

Action

Request an executive summary or attestation from the most recent independent penetration test. Confirm the tester, test date, methodology, production-representative assets, findings by severity, remediation status, and retest results.

The scope should reflect the service you are purchasing, including public APIs, administrative portals, patient-facing web experiences, voice and texting infrastructure, authentication paths, and EHR integration components. NIST treats penetration testing as one component of a broader technical security testing and assessment process. NIST SP 800-115.

Expected outcome

Critical findings are closed, high-risk findings have documented remediation or formal treatment, and retesting confirms that material fixes worked.

Gotchas

  • A vulnerability scan presented as a penetration test.
  • A test limited to the marketing site while production APIs and administrative tools are excluded.
  • A clean executive summary that omits unresolved high-risk findings.
  • No evidence that remediated findings were retested.
  • A test completed before a major infrastructure migration or integration rewrite.

Step 5: Lock down retention, deletion, and AI model use

Estimated reviewer time: 45 to 60 minutes

Action

Build a data lifecycle table for call audio, transcripts, text threads, uploaded documents, extracted fields, model prompts and outputs, quality-review samples, application logs, support exports, analytics, and backups. For each category, record the system of storage, purpose, retention period, deletion method, backup treatment, and responsible party.

Ask separate yes-or-no questions about whether customer data, PHI, audio, transcripts, prompts, outputs, or derived data are used to train shared models, improve general products, train customer-specific models, or support human quality review. Match each answer against the BAA and service agreement. HHS requires the BAA to define permitted PHI uses, while the FTC has warned AI providers that undisclosed model-training uses can violate privacy and confidentiality commitments. FTC guidance on AI data commitments.

Expected outcome

No PHI use depends on ambiguous language such as “service improvement.” The medical group knows what is retained, why it is retained, who can access it, and what will be deleted when the relationship ends.

Gotchas

  • A training prohibition that applies to the vendor but not its model providers.
  • Audio deletion that leaves transcripts, summaries, embeddings, or quality-review copies intact.
  • “De-identified data” used without explaining the method, approval process, or downstream purpose.
  • Production retention terms that do not address backups and disaster recovery copies.
  • A deletion right that applies only after an annual contract ends, not when a pilot or workflow is discontinued.

Step 6: Trace every subprocessor, including LLM and speech providers

Estimated reviewer time: 30 to 60 minutes

Action

Request a current subprocessor register covering cloud hosting, telephony, speech-to-text, text-to-speech, large language models, analytics, monitoring, customer support, document processing, and messaging. For each provider, identify the legal entity, function, data elements, storage location, retention, model-training terms, and contractual coverage.

A downstream provider that creates, receives, maintains, or transmits PHI on behalf of a business associate is also part of the HIPAA business associate chain. The primary vendor must obtain appropriate contractual assurances from those subcontractors. HHS business associate guidance.

Expected outcome

The architecture diagram, subprocessor register, BAA, and SOC 2 report describe the same material provider chain. Changes to that chain trigger notice and security review under the contract.

Gotchas

  • An LLM provider described as a software tool rather than a subprocessor.
  • A telephony carrier that stores recordings or metadata but is absent from the register.
  • Subprocessors listed by product brand rather than contracting legal entity.
  • No mechanism for customers to receive notice before material subprocessor changes.
  • Contradictory training or retention terms between the vendor and its model provider.

Step 7: Test encryption, identity controls, and incident readiness

Estimated reviewer time: 60 to 90 minutes

Action

Confirm encryption in transit and at rest, including backups, file stores, recordings, text messages, administrative tools, and data transferred to subprocessors. Ask how encryption keys are protected, separated, rotated, and accessed.

Review role-based access, unique user accounts, MFA, SSO support, privileged account separation, workforce termination procedures, and time-limited support access. Require logs for administrative activity, PHI access, configuration changes, EHR writes, exports, and failed authentication. The HIPAA Security Rule requires access controls, authentication, audit controls, integrity protections, and transmission security for systems containing ePHI. HHS Security Rule summary.

Obtain the incident response plan or a customer-facing summary. Verify the notification path, contractual reporting deadline, evidence-preservation process, forensic support, recovery procedure, and date of the last tabletop exercise. HHS identifies encryption, MFA, incident preparedness, credential management, and vendor risk management as priority healthcare cybersecurity practices. HHS Healthcare Cybersecurity Performance Goals.

Expected outcome

Only authorized people and services can access PHI, sensitive actions are attributable to a unique identity, and the vendor can detect, investigate, contain, and communicate a material incident.

Gotchas

  • SSO is available, but local administrator accounts can bypass it without equivalent MFA.
  • Support engineers have standing production access rather than approved, logged, time-limited access.
  • Logs exist but are not reviewed, retained long enough for investigations, or exportable to the customer.
  • Encryption applies to databases but not recordings, logs, exports, or backups.
  • The incident plan covers the vendor’s cloud environment but not telephony or model providers.

Step 8: Review EHR permissions as production access, not an integration feature

Estimated reviewer time: 60 to 90 minutes

Action

Request an inventory of EHR credentials, applications, API scopes, endpoints, and read or write actions. Map each permission to a purchased workflow. Scheduling automation should not receive unrelated chart or billing access merely because broader permissions are technically available.

For athenaOne deployments, verify how credentials and tokens are created, stored, rotated, and revoked; how access is separated across practice IDs; and how each automated write is identified in audit logs. Athenahealth’s developer documentation uses OAuth-based authorization, workflow scopes, application identities, and auditing capabilities, giving reviewers concrete controls to compare with the vendor’s design. athenahealth API security documentation.

Require least privilege for both human and machine identities. Review procedures for approving new scopes, testing write actions, preventing duplicate transactions, handling failed writes, and disabling access at termination.

Expected outcome

The vendor can perform every approved workflow without broad standing access, shared credentials, or untraceable writes. Your IT team can identify what changed in athenaOne, when it changed, which service performed it, and whether the action succeeded.

Gotchas

  • One credential shared across unrelated sites, environments, or practice IDs.
  • A request for full read and write access justified only as easier implementation.
  • Middleware that expands the PHI chain but is missing from the architecture and subprocessor review.
  • Logs showing that an integration account acted, but not which workflow or patient request triggered the action.
  • No documented revocation and data-removal procedure for pilot termination.

Step 9: Verify the evidence and record a decision

Estimated reviewer time: 30 to 60 minutes

Action

  1. Confirm the legal entity on each report and certificate matches the contracting vendor or clearly covers it.
  2. Check issue dates, review periods, expiration dates, and the systems named in each scope statement.
  3. Verify HITRUST status through the certification letter and assessor details.
  4. Verify ISO certification through the issuing certification body when the vendor claims formal certification.
  5. Read SOC 2 exceptions and management responses rather than relying on the auditor’s opinion alone.
  6. Compare the subprocessor register with the architecture, BAA, data-flow diagram, and SOC 2 subservice organizations.
  7. Record unresolved risks, owners, due dates, pilot restrictions, and renewal requirements in the vendor decision.
Decision When to use it Required record
Approve Material controls are supported, contractual terms are acceptable, and the integration uses appropriate permissions Approved scope, evidence dates, owner, and annual review date
Approve with restrictions A bounded issue can be controlled through a limited workflow, site, data set, or permission scope Restriction, compensating control, remediation owner, and deadline
Pause The PHI chain, report scope, data use, critical findings, or EHR access cannot be reconciled Blocking issue and specific evidence required to reopen review

Expected outcome

The approval is reproducible and auditable. A future reviewer can see which version of each document supported the decision and which changes require reassessment.

Gotchas

  • Treating a marketplace listing, completed questionnaire, or security webpage as a substitute for underlying evidence.
  • Approving a vendor globally when only one workflow, site, or practice ID was reviewed.
  • Failing to set expiration dates for reports, certificates, penetration tests, and approved exceptions.
  • Allowing pilot credentials and copied PHI to remain active after the pilot ends.

Frequently asked questions

Is a vendor saying it is HIPAA compliant enough for an enterprise review?

No. HHS does not issue or recognize an official HIPAA compliance certificate, so a medical group must verify the vendor’s BAA, safeguards, data uses, subprocessor chain, technical controls, and supporting assurance evidence. A HIPAA statement is useful only when those underlying commitments and controls can be inspected. HHS certification guidance.

Does HITRUST i1 replace a SOC 2 Type II report or BAA?

No. HITRUST i1, SOC 2 Type II, and a BAA answer different questions. HITRUST i1 provides one-year assurance against a defined set of implemented cybersecurity controls. SOC 2 Type II examines the design and operating effectiveness of controls within a stated system and period. The BAA defines the vendor’s contractual authority and obligations when handling PHI. Enterprise reviewers commonly need all three, with each document scoped to the service being purchased. HITRUST assessment portfolio.

Should a medical group allow patient calls or transcripts to be used for AI training?

Do not approve training use unless the purpose, data types, model providers, retention, human access, deletion, and resulting model rights are explicit in the contract. Separate customer-specific configuration from training a shared model or improving a general product. The same restriction must extend to downstream LLM, transcription, and speech providers. An ambiguous “service improvement” clause is not a sufficient description of how PHI-bearing calls or transcripts will be used.

Does an athenahealth Marketplace listing prove that an AI vendor’s integration is secure?

No. A marketplace relationship can establish that a vendor participates in the ecosystem, but the medical group still needs to review the vendor’s actual API identities, permissions, data flows, subprocessors, audit logs, and access-revocation process. The decisive question is not whether the integration exists. It is whether production access is limited to the workflows being purchased and whether every material read and write action can be traced.

What should an athenaOne group pilot before deploying patient call automation across multiple practice IDs?

Start with one or two representative sites and a bounded workflow whose permissions and outcomes can be clearly audited, such as routine scheduling or after-hours request intake. Test practice-ID isolation, credential revocation, escalation, duplicate-write prevention, audit logs, retention, deletion, and incident contacts before adding more workflows. A successful operational demo without these controls proves that calls can be handled, not that the deployment is ready for enterprise expansion.

References