How to choose a HIPAA compliance consultant

Choose by the problem you have, not the logo

Match the consultant to your problem. If a regulator has written to you, you need a lawyer. If a customer wants a risk analysis, you need an assessor. If the report is already done, you need engineers.

Most buyers search for a HIPAA compliance consultant before they know which of these they are. That is how they end up paying an audit firm for a document and then discovering nobody on the engagement can change the code.

Spend the first week working out which of three situations you are in: responding to an incident or inquiry, proving diligence to a customer or investor, or fixing known technical gaps. The shortlist changes completely depending on the answer, and the rest of this piece assumes you have answered it.

Four kinds of firm sell HIPAA help

Law firms, audit and advisory firms, specialist engineering partners and compliance-automation platforms all sell under the same label. They differ in what they hand you at the end and who is accountable for it.

Some firms straddle two rows. Check which one actually delivers the work and which one is on the logo.

Counsel owns the legal opinion

Hire a healthcare lawyer when the question is what the rule requires of you, or when something has already gone wrong. Interpretation, breach notification and enforcement correspondence are legal work.

The HHS Office for Civil Rights runs enforcement, and it publishes a public breach portal listing breaches affecting 500 or more people. Read it before you hire anyone. It shows what actually triggers investigations, and most entries are not exotic attacks.

A lawyer is also the right person for business associate agreements. HHS guidance on business associates explains when one is required, and drafting it is not engineering work.

The limit: counsel will not test your systems, and a legal memo does not satisfy a technical safeguard. You will still need someone to look at the actual configuration.

Audit firms write the risk analysis you will be asked for

The Security Rule requires a risk analysis, and it is the first document a regulator or a hospital customer asks for. An audit or advisory firm is built to produce it.

HHS guidance on risk analysis lays out the expected elements: scope, where electronic protected health information lives, threats, likelihood and impact. A good consultant works from that and from NIST SP 800-66 Rev. 2, the NIST guide to implementing the Security Rule.

Ask to see the structure of a sanitised past report. A real one traces specific data flows: which database, which backup, which vendor. A weak one is a spreadsheet of generic threats with your company name pasted in.

The honest limit is that audit firms stop at the finding. The remediation is yours, and a report with forty open items and no one to close them is worse than useless, because it is now discoverable evidence that you knew.

Engineering partners fix what the report finds

Remediation is software work: encryption at rest, audit logs that record who read which record, role-based access, retention and deletion, backups that are tested. This is where engineering firms earn their place.

Viithiisys has been building software since 2007, with engineering based in Mohali and a Canadian office in Markham, Ontario. Across 500+ projects for clients in the US, UK, Canada, India, China and Nigeria, access control and audit logging are the fixes that come up most often. We are not a law firm or an auditor, and we do not issue the risk analysis.

Where we fit is after it exists. Our QA and testing practice can verify that controls work, not just that they are documented. A fractional CTO can own the remediation plan if you have no senior engineer to do it.

Nobody can certify you

Any consultant who offers a "HIPAA certification" is selling a badge. HHS states it does not certify or endorse products, firms or individuals as HIPAA compliant.

What you can hold is evidence. That means a dated risk analysis, a remediation log showing findings closed, signed business associate agreements, training records and tested incident response. The Security Rule text on HHS.gov defines the safeguards those records should map to.

Third-party attestations such as SOC 2 or HITRUST are separate programmes with their own scope. They help in sales conversations and overlap with HIPAA controls, but passing one does not mean you satisfy the other.

If a bid promises a seal, ask who issues it. The answer is usually the consultant.

Test the bid before you sign

A short set of questions separates practitioners from resellers. Ask them in the sales call and note whether the answers are specific.

1. Who will do the work, and can I speak to them before signing?
2. Can I see the table of contents of a sanitised past risk analysis?
3. Which parts do you subcontract?
4. What do you do when a finding needs a code change?
5. How do you handle a scope that includes cloud services and AI vendors?

The fourth question is the most revealing. A good answer names who does the work, how it is verified and what the handover looks like. A bad one is "we recommend your team address it".

Also ask what happens in month six. Risk analysis is meant to be revisited when your systems change, and a consultant with no plan for that is selling a one-off document.

Red flags that predict a bad engagement

Three patterns turn up repeatedly in poor engagements. Others exist, but these are the ones worth screening for first.

The first is a fixed checklist applied to every client. Your risk depends on where your data lives, so two companies with identical scores usually mean the assessor did not look.

The second is a fixed timeline stated before scoping. Anyone who promises completion in a set number of weeks without knowing how many systems touch protected health information is guessing.

The third is a senior name on the proposal and a junior on the calls. That is common at larger firms, and it is why question one above matters.

None of these means the firm is dishonest. They mean the work will be thinner than the proposal suggested, and you will find out only when a customer's security team reads the report.

AI tools widen the scope of any assessment

If your product sends patient notes or records to a hosted language model, that model vendor is in scope. It needs a business associate agreement, and your risk analysis has to cover the new data flow.

This is the gap we see most often when teams add a chatbot or document summariser to an existing health product. The original assessment predates the feature, so the data flow is undocumented. Check whether the vendor will sign a BAA at all, and whether the plan you are on is covered by it.

Our AI consulting work covers exactly this decision: which model, hosted where, with which agreement, and what to redact first. For records and intake forms, document AI pipelines can strip identifiers before anything leaves your environment.

Raise this with whichever assessor you pick. Many have not yet updated their templates for it.

Buy in sequence and keep the work separate

Hire the assessor first, keep the lawyer on call, and bring in engineers once the findings are ranked. Avoid one firm that claims to do all of it unless you can name the person responsible for each part.

Keep the risk analysis independent of whoever fixes the systems, since reviewing your own work is hard to defend. Then give engineering a fixed scope drawn from the ranked list rather than an open-ended retainer.

If you are unsure which of the situations in the first section you are in, map the broken workflow first. It shows where protected health information moves through your product and which step has no owner, which is the input any assessor will ask for anyway.

For a specific system with a known gap list, send us the list and we will say whether it is engineering work we can scope.