SOC 2 & HIPAA-Compliant AI Voice Agents: 2026 Checklist

A SOC 2 or HIPAA label should start a verification process, not end one. A voice agent can touch caller identity, appointment details, symptoms, insurance context, or other information that a healthcare organization treats as sensitive. The buyer therefore needs to separate three questions: what an independent report actually covers, what the healthcare workflow and contract require, and whether the deployed call path behaves as approved.

This checklist is deliberately vendor-neutral. It does not establish that Novacall AI or any other provider currently has a SOC 2 report, will sign a business associate agreement (BAA), meets a healthcare organization's risk requirements, encrypts a particular data path, retains a particular record, or provides a particular integration. Those are verification items for the current vendor, plan, contract, and deployment.

Key Takeaways

• Treat SOC 2 as scoped evidence about controls described in a report, including the covered system, criteria, period, opinion, and exceptions.
• Treat HIPAA as a workflow and organizational obligation that must be mapped to the data being created, received, maintained, or transmitted.
• Do not use “SOC 2 compliant,” “HIPAA compliant,” or “HIPAA-ready” as a substitute for reading the report, signing the right contract, and testing the actual call path.
• Ask who owns the BAA, which subcontractors can receive the data, what happens at termination, and how the buyer retrieves or deletes records.
• Keep the first pilot narrow: one call purpose, one approved knowledge boundary, one human escalation owner, and a small set of synthetic test calls.
• Test notice, consent context, minimum necessary collection, access, correction, opt-out, appointment authority, recording, transcript visibility, and recovery from a failed write.
• A completed demo is not evidence of compliance. Keep artifacts: scope documents, contract language, test transcripts, access reviews, incident contacts, and sign-off.
• Make no assumption about Novacall AI or another named vendor’s current SOC 2 or HIPAA position without current, reviewable evidence.

What does SOC 2 evidence actually tell a voice-agent buyer?

According to AICPA & CIMA (SOC 2 reporting guide), a SOC 2 examination concerns controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. That description is useful, but it is not a reason to skip the report's boundaries.

The buyer should request the current report under an appropriate confidentiality process and read the system description before accepting a summary. Record the service, product edition, environment, locations, relevant subprocessors, trust service criteria included, examination period, auditor, opinion, tests, exceptions, and complementary user-entity controls. If the voice workflow uses a telephony carrier, speech service, transcription layer, calendar, CRM, analytics tool, or support console outside the described system, identify that boundary rather than assuming it inherits the same evidence.

A report can be relevant and still be insufficient for a particular healthcare workflow. A report describes a system and controls for a stated period. It does not answer every buyer question about a new number, a new feature, a new subcontractor, a new region, a new retention setting, or a prompt and routing policy that the buyer has not tested. A buyer should ask which controls are performed by the service organization and which controls remain with the customer.

What should you read first in a SOC 2 report?

Start with the system description. Find the exact service used for calls and identify what the report does not cover. Then read the auditor's opinion and the period. A marketing page might say “SOC 2” without showing whether the evidence is a current report, which criteria were examined, or whether the buyer's selected service is in scope.

Use this worksheet:

• Report type and examination period.
• Service name, edition, and environment.
• Trust service criteria included.
• Auditor name and opinion.
• Control exceptions and management responses.
• Subservice organizations and carve-out or inclusive treatment.
• Complementary user-entity controls.
• Data locations and support access boundaries.
• Evidence for incident response, access review, change management, backup, and recovery.
• Report expiration or bridge evidence requested by procurement.
• The person who can answer a scope question in writing.

Do not convert a clean-looking summary into a universal guarantee. The useful output is a list of controls and residual questions that match the proposed call flow.

Does SOC 2 answer whether a voice agent may handle PHI?

No single label should make that decision. This evidence may help a buyer assess a service organization's controls, but the healthcare organization still has to map its own use, contract, users, data, and safeguards. A voice agent may be used only for a narrow scheduling workflow in one practice and for a broader intake workflow in another. The data, people, permissions, disclosures, and operational owners can differ.

Write the proposed flow in plain language before reviewing the report: who calls, what the agent asks, what the caller may volunteer, what is written to a record, who can listen, what is sent to a calendar or CRM, what triggers a human, and what happens after the call. Mark each handoff to another system. Then ask the vendor to identify the matching scope and controls. If the answer is “the platform is certified,” ask which document and which system boundary that statement refers to.

What does HIPAA scope cover in an AI voice workflow?

According to NIST (Implementing the HIPAA Security Rule), the HIPAA Security Rule focuses on safeguarding electronic protected health information held or maintained by regulated entities, including ePHI that a regulated entity creates, receives, maintains, or transmits. This is a useful scope test for a voice workflow: do not decide from the product category alone; trace the information and the parties handling it.

According to Cornell Legal Information Institute (45 CFR § 164.304 Security Rule definitions), administrative safeguards are policies and procedures for managing security measures and workforce conduct, physical safeguards protect information systems and related facilities and equipment, and technical safeguards are technology and related policies that protect ePHI and control access to it. Use those definitions as control vocabulary, not as a vendor endorsement.

A call can begin with a name and callback number and then become a sensitive record when a caller volunteers a diagnosis, treatment detail, insurance identifier, or appointment context. The buyer should classify the fields the agent is allowed to request, the fields it may receive without prompting, and the fields it must not collect. The classification must travel with the transcript, recording, summary, message, calendar entry, and support ticket.

What is the difference between a compliance label and a compliance decision?

A compliance decision belongs to the organization that knows its covered-entity or business-associate role, purpose, data, workforce, contracts, and risk analysis. A vendor statement can be one input. It cannot silently define the buyer's permitted use, retention policy, access model, disclosure language, or incident process.

Use these boundaries:

• Scope includes the service is a scope question.
• “The contract covers this use” is a contract question.
• “The workflow collects only approved fields” is a configuration and test question.
• “The team can detect and respond to an incident” is an operating-control question.
• “The deployment is appropriate for this organization” is a buyer governance decision.

Do not promise a patient, caller, auditor, or regulator that a system is compliant merely because a salesperson used a compliance term. State exactly what evidence was reviewed, what remains unverified, who approved the use, and when the review must be repeated.

Which evidence proves what, and what remains unproved?

Use a two-column review so a strong artifact is not mistaken for a complete decision.

The right-hand column is as important as the left. It prevents a report, contract, or demo from carrying claims it was never designed to carry.

How should a buyer map the voice call before procurement?

Create a call inventory with one row per purpose. Do not start with a feature list. Start with the caller's reason for calling and the smallest record needed to complete the next safe action.

For each purpose, document:

1. The population and expected caller.
2. The source number or campaign context.
3. The greeting and notice language.
4. The allowed questions.
5. The fields that may be volunteered but should not be repeated.
6. The minimum information needed for routing or scheduling.
7. The approved answer set.
8. The stop words and uncertainty triggers.
9. The human owner and response window.
10. The systems that receive an audio file, transcript, summary, message, or appointment.
11. The retention and deletion rule for each artifact.
12. The evidence that the owner must inspect after a call.

A voice system should not ask for a full clinical history when the immediate task is to offer a scheduling window. It should not read back a sensitive detail in a voicemail or text merely because the detail appeared in the transcript. It should not turn an ambiguous caller statement into a definitive field without review.

Mark “must not collect” alongside “may collect.” This makes prompt and script review concrete. Include examples of caller disclosures that the agent should acknowledge without storing or repeating. Ask the vendor how a buyer can suppress recording, transcript creation, or downstream propagation for a particular workflow, and retain the answer as evidence rather than relying on a verbal promise.

What should a BAA and ownership review ask?

A BAA review is not a checkbox. It should match the actual service and the systems that can receive the information. The buyer should identify the legal and operational owner of the agreement, the permitted purposes, prohibited secondary use, safeguards, incident reporting, subcontractor chain, access to records, and termination process.

Ask for written answers to these questions:

• Which legal entity signs the agreement?
• What service, environment, and data types does the agreement cover?
• Which uses and disclosures are permitted?
• Can the vendor use recordings or transcripts to train, test, or improve a general model?
• Which subprocessors can receive audio, text, metadata, or support tickets?
• How are subcontractor obligations flowed down?
• Incident contact: identify who reports a suspected security incident, through which channel, and on what timeline.
• Who can retrieve a complete record for the buyer?
• What happens to recordings, transcripts, backups, indexes, and derived summaries at termination?
• How are deletion requests, legal holds, and restoration copies handled?
• Which controls remain the customer's responsibility?
• What evidence can be requested during a risk review?

Do not assume that a BAA changes the product's technical behavior. If a contract says records are returned or deleted, test the request against the configured systems and preserve the result. If the vendor cannot describe the subcontractor path, mark the deployment blocked until the gap has an owner and a decision.

How should access, logging, and retention be tested?

Use a test account for every role that can touch the workflow: intake operator, supervisor, administrator, support contact, integration account, and auditor. Confirm that each role sees only the records needed for its job. Verify that a departing user loses access and that an emergency access path is logged and reviewed.

Test the full record lifecycle:

• call starts;
• notice is delivered;
• audio and transcript are created or suppressed as configured;
• the summary is written to the approved system;
• a human corrects an error;
• an export is requested;
• a record is deleted or retained under policy;
• a support user attempts access;
• an integration fails;
• a replacement or restored copy is considered;
• the audit trail is reviewed.

Record timestamps, actor, action, object, result, and evidence location. A log that shows only “call completed” is not enough to investigate who viewed a transcript, changed an appointment, or exported a record. Ask whether a buyer can access logs, how long logs remain available, and what happens when the vendor or an integration is unavailable.

Retention must be field-specific. Audio, transcript, structured summary, appointment record, message, and audit event may have different purposes and owners. Do not write “delete the data” without naming each artifact and the systems that can retain it. If the vendor offers a setting, confirm which data it affects and run a deletion test with synthetic data.

How do you test consent, notice, and minimum necessary collection?

Write the approved opening and stop path before testing. The caller should understand that an automated system is involved when the organization's policy or applicable law requires notice. The system should not imply that a human has joined when one has not. The caller should have a clear route to a person and a clear way to stop an automated interaction.

Use cases that expose the boundary:

• caller asks whether the system is automated;
• caller refuses recording;
• caller asks to speak with staff;
• caller volunteers a diagnosis;
• caller gives another person's information;
• caller asks for a result or advice outside intake scope;
• caller requests a callback but does not want a text;
• caller changes the preferred communication channel;
• caller asks to correct a name or number;
• caller asks what will be stored.

For each case, inspect the spoken response, transcript, structured fields, outbound message, and human task. A correct voice answer followed by an overbroad CRM note is still a failed workflow. A correct opt-out response followed by a queued reminder is also a failed workflow. Test suppression against the actual job or integration that would send the next message.

Do not let the agent improvise legal, clinical, coverage, or emergency advice. Give it a short approved response and a human escalation path. Define what happens when the caller reports urgent symptoms or a safety concern; the appropriate organization and professional should approve that path before launch.

What should appointment authority and human handoff look like?

Booking an appointment is a state change, not a friendly promise. The agent should confirm the caller's identity and requested service to the degree approved, read back the date and time, and state that the booking is complete only after the scheduling system confirms it. If the calendar is unavailable or returns an ambiguous result, the agent should create a human task instead of inventing availability.

A handoff packet should include:

• caller request in the caller's own words where practical;
• approved fields captured;
• uncertain or missing fields;
• requested time window and timezone;
• whether notice or recording was refused;
• the reason for escalation;
• the owner and due time;
• transcript or recording reference under the approved access policy;
• any failed write or integration result.

Run a caller who asks to change an appointment, a caller who wants a different clinician, a double-booking response, a calendar outage, a caller who asks for medical advice, and a caller who requests an immediate human. The agent must distinguish “request received,” “task created,” and “appointment confirmed.” Those states should appear in the human record.

Assign ownership by role, not by a shared inbox alone. Name the person or team that handles unclassified calls, failed bookings, consent objections, record corrections, privacy requests, and suspected incidents. A handoff with no owner is an acknowledgement, not recovery.

How should a matched pilot produce evidence?

In practice, a buyer learns more from a small replayable test set than from a polished demonstration. Use synthetic callers and synthetic patient-like data. Keep the same call script across the vendor, configuration, and release being compared. Change one variable at a time so the team can explain why a result changed.

A useful pilot packet contains:

• versioned call scenarios;
• expected answer and stop conditions;
• allowed and prohibited fields;
• expected human owner;
• pass or fail rubric;
• transcript and event evidence;
• appointment or task result;
• access and retention observations;
• defect, owner, due date, and retest result.

Set a go/no-go rule before running the calls. A single high-consequence failure—such as an unapproved disclosure, false appointment confirmation, inability to stop an outbound sequence, or missing owner for an urgent handoff—should pause expansion until corrected and retested. Do not average away a failure because other calls sounded natural.

What is unverified about Novacall AI or another vendor?

This article does not claim that Novacall AI has a current SOC 2 report, a particular trust service criterion, a BAA, HIPAA eligibility for a buyer's workflow, a specific encryption design, a particular retention setting, a specific subprocessors list, a certain access-log capability, or a healthcare integration. It also does not claim that any other provider has those properties.

Verify the exact product and contract in use. Request the report or equivalent evidence through the vendor's approved process. Ask for a current system description, BAA terms, subprocessor list, data-flow answer, retention and deletion behavior, incident contact, and support-access model. Then run the matched tests above. If the provider cannot answer a question, record “unverified” rather than filling the gap with a feature assumption.

A Novacall conversation can be useful for scoping a test, but a conversation is not a report, contract, or audit artifact. The same standard applies to every provider. A buyer should be able to show why a particular workflow was approved, which evidence supported it, who owns the residual risk, and what event will trigger re-review.

What is the 2026 go/no-go checklist?

Before enabling a production voice workflow, confirm all of the following:

• The use case, caller population, and data classes are written down.
• The exact service and connected systems are named.
• SOC 2 evidence, if relied upon, is current enough for procurement and covers the service in use.
• The buyer has reviewed the report scope, period, criteria, opinion, exceptions, and customer controls.
• The BAA or other required contract has an owner and matches the actual data path.
• Subprocessors and support access have been identified.
• Notice, consent context, opt-out, and non-recording paths are approved.
• The agent's knowledge and prohibited actions are documented.
• Human escalation, appointment authority, and recovery owners are named.
• Access roles, logs, retention, export, deletion, and incident paths have been tested.
• Synthetic call results and unresolved defects are stored with version information.
• A rollback or pause procedure has been exercised.
• The review date and change triggers are on the calendar.

If an item is unknown, the right status is “not yet verified.” A cautious launch can start with a lower-risk, non-PHI workflow while the organization resolves scope and contract questions. It should not quietly expand from scheduling into clinical intake, payment, or sensitive follow-up because the first pilot sounded successful.

Discuss a compliance-scoped AI voice workflow with Novacall AI to define a narrow test set, human handoff boundary, and evidence checklist.