HIPAA, SOC 2, and your billing data: what to ask any RCM vendor

The fastest way to lose the security conversation is to treat billing data as if it were just billing data. It is not. A claim can carry a patient name, member ID, date of service, provider information, diagnosis code, procedure code, payer response, and payment details. Under the HIPAA Privacy Rule, protected health information (PHI) includes individually identifiable health information tied to the past, present, or future payment for healthcare. That puts claim data, eligibility files, remittance records, and posting data in the PHI conversation just as much as documentation in the EHR.

So the security conversation with any RCM vendor — autonomous or not — is a PHI conversation. The questions below are the ones we would ask if we were sitting on your side of the table.

Why your billing data is PHI

Under HIPAA, a healthcare organization is typically the covered entity. An RCM vendor that performs billing, claims processing, data analysis, or other services involving PHI on that organization's behalf is generally a business associate. That relationship should be governed by a Business Associate Agreement, or BAA.

A BAA is not optional paperwork. It defines how the vendor may use and disclose PHI, what safeguards they must apply, how breaches are reported, how subcontractors are handled, and what happens to PHI when the relationship ends. HHS publishes required BAA provisions, including limits on PHI use, breach reporting, subcontractor flow-down, and return or destruction of PHI at termination.

What is at stake is concrete. A breach involving claim data can be a reportable HIPAA event. Under the Breach Notification Rule, affected individuals must be notified without unreasonable delay and no later than 60 days after discovery. For breaches affecting 500 or more individuals, HHS notification is also required within 60 days. HHS also maintains a public breach portal for breaches affecting 500 or more individuals, and it includes billing companies, clearinghouses, and other healthcare vendors — not just hospitals and EHR systems. If a vendor treats eligibility files, claim data, or remittance records as low-sensitivity because "it is just billing," that is the answer. And it is a bad one.

The framing that should anchor every question is simple: this is PHI, the vendor is a business associate, and the controls have to match.

The questions to ask before you sign

Bring these to the evaluation. Good vendors answer them quickly, specifically, and in writing. Vague vendors talk around the point.

• Will you sign a BAA? This is table stakes. If the answer is anything other than an immediate yes with a document you can review, stop here. Ask what the BAA commits them to: permitted uses of PHI, breach notification timelines, subcontractor obligations, safeguards, and return or destruction of data at termination.
• How do you handle PHI day to day? Who inside the vendor can see claim data, and why? PHI access should be need-to-know and role-based, not "everyone on the support team." Ask how access is granted, reviewed, limited, and removed.
• What is your SOC 2 status? Ask whether they have a SOC 2 report, what type it is, when it was issued, what systems were in scope, and whether you can review it under NDA. SOC 2 focuses on controls relevant to security, availability, processing integrity, confidentiality, or privacy. Type I evaluates controls at a point in time; Type II evaluates whether controls operated effectively over a period of time. "Working toward SOC 2" is a different answer than "here is our current Type II report."
• How is data encrypted? You want encryption in transit and at rest. In transit means data is protected as it moves between you, the vendor, clearinghouses, payers, and connected systems. At rest means stored data is encrypted where it lives. The Security Rule treats encryption as an "addressable" implementation specification, which means the vendor must assess whether it is reasonable and appropriate, implement it when it is, or document an equivalent alternative when it is not.
• What are your access controls? The HIPAA Security Rule requires technical safeguards that limit ePHI access to authorized users. Look for unique accounts, multi-factor authentication, least-privilege roles, session controls, and prompt deprovisioning.
• Do you keep audit logs? Audit controls are a Security Rule safeguard, not a nice-to-have. Every access to PHI should be traceable: who viewed, changed, exported, or transmitted what, and when. Ask whether logs exist, how long they are retained, and whether you can request logs tied to your own data.
• Where does our data live, and who else touches it? Ask where data is hosted, which regions are used, and which third parties may handle PHI. That includes cloud providers, clearinghouses, subprocessors, and any other systems in the data path. Each one should be covered by the BAA's subcontractor flow-down terms.
• Do you train AI on our data? Increasingly, this is one of the most important questions. If a vendor uses your claims, codes, denials, payer responses, or remittance data to train shared models, your PHI may be improving a product other customers benefit from. The answer you want is a clear no, backed by contract language. The FTC has warned AI companies that privacy and confidentiality commitments still apply, including commitments about how customer data is used for model training or product improvement. In healthcare, that should live in the agreement.

How to read the answers

A confident, specific answer is the signal. "We take security very seriously" is not an answer. It is a slogan. Ask for artifacts: the BAA, the SOC 2 report, a data-flow description, a subprocessor list, access-control documentation, and the AI-training language.

Watch the gap between marketing and documentation. A vendor can claim "enterprise-grade security" on a landing page and still leave key questions unanswered in the contract. The website sells. The contract binds. The audit report shows what was tested. When they disagree, believe the documentation.

And separate certifications from practices. A SOC 2 report tells you an independent auditor evaluated specific controls. It does not, by itself, tell you every system you care about was in scope or that the controls match your risk. A vendor without a current SOC 2 report is not automatically unsafe either. Certifications are evidence. They are not the whole answer.

Ask AcuraClaim the same questions

AcuraClaim handles front-of-cycle work — census and Medicare Part A or B, coverage and benefit checks, coding, claim checks and submission, and payment posting — which means it touches claim-level PHI continuously. So every question above applies to us as much as to any vendor, and we would rather answer them on a call, in writing, with the documents in front of you, than summarize them in a blog post.

That distinction is the whole point of this post: ask for the document, read the answer, and decide whether the controls match the data. If you're evaluating RCM vendors and want to put these questions to AcuraClaim directly, book a demo and bring the checklist.