Business Associate Agreement: What It Commits an Indian Vendor To

A business associate agreement is the contract a US covered entity must sign before it lets a vendor touch protected health information, and it is how HIPAA reaches an Indian company with no US presence at all. Signing one commits you to use the information only as the contract permits, to run Security Rule safeguards over it, to report incidents and breaches to your client on a deadline, to bind your own subcontractors to the same terms, and to return or destroy the data when the work ends.

At a Glance

• Who needs one: any vendor that creates, receives, maintains or transmits protected health information for a US covered entity, and every subcontractor of that vendor.
• What it is not: a certification. The US Department of Health and Human Services does not certify HIPAA compliance and does not endorse any private certificate, so the agreement is enforced by your client's audit, not by a badge.
• The breach clock: a business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured protected health information (45 CFR 164.410, checked 2026-10-16). Most agreements set far shorter deadlines.
• Encryption: an addressable implementation specification under the current Security Rule (45 CFR 164.312, checked 2026-10-16), meaning implement it or document an equivalent measure. HHS proposed in January 2025 to remove that distinction; check whether the amendment has been finalised before you plan around it.
• Typical readiness time: two to four months for most Indian business associates, on the phase durations set out on our HIPAA compliance service page.

What a Business Associate Agreement Actually Is

The Privacy Rule allows a covered entity to disclose protected health information to a vendor only once it has satisfactory assurances, in a written contract, that the vendor will protect it. That contract is the business associate agreement, and 45 CFR 164.504(e) sets out what it has to say. For electronic health information, 45 CFR 164.314(a) adds the Security Rule's own contract requirements.

The consequence that surprises most Indian vendors is direct liability. Since the HITECH Act, the Security Rule and the Breach Notification Rule apply to business associates themselves, not only through the contract: a business associate can be investigated and penalised by HHS without the covered entity being at fault. Your location does not change that, because the rules bind the work rather than the office.

So the agreement does two jobs at once. It is a commercial document your client's counsel negotiates, and it is the instrument that passes a US regulator's obligations onto an Indian company. Reading it as procurement paperwork is the most common reason a vendor then fails the security review that follows it.

The Clauses, and the Rule Each One Comes From

Every agreement is drafted differently, but the obligations underneath are the same six. The mapping below is the one we use when we review a signed agreement against what a client actually has running.

The right-hand column is the part no template gives you. A clause is satisfied when the control behind it operates and leaves a record, and the record is what a covered entity's security team asks for in month three of the contract, not at signature.

What US Covered Entities Ask an Indian Vendor For

The questionnaire an Indian business associate receives is not the one a US vendor receives. Across medical coding, billing, transcription, claims processing and health-tech work, the questions added because delivery sits in India are consistent:

• Where does the data physically sit, and who can reach it from where? Expect to answer for cloud regions, for any copy that lands on a workstation in a delivery centre, and for remote staff.
• How is the delivery floor controlled? Workstation restriction, clear-desk and no-print rules, USB and screenshot controls, and physical access records for the room the work happens in.
• Who has standing access, and how is it reviewed? Joiner-mover-leaver evidence with dates, not a policy that says reviews happen quarterly.
• What happens on an Indian public holiday, or at 2 a.m.? Your client's clock starts when the incident is discovered, and a vendor whose escalation path is one person's phone fails this question.
• Can you sign our agreement as written? Including the shortened breach deadline and any encryption clause stricter than the Security Rule's addressable specification.

None of this is exotic. It is the same control set a SOC 2 or ISO 27001 programme builds, which is why the vendors who clear these reviews fastest are the ones already running one. Our guide to SOC 2 services in India covers what that audit involves, and ISO 27001 vs SOC 2 covers which to start with when US clients are the reason you are doing it at all.

Subcontractors: The Clause Vendors Miss

If you pass protected health information to anyone else to do part of the work, you are the one who must have an agreement with them, on terms at least as protective as your own. That includes the obvious subcontractors and the ones nobody lists: the hosting provider, the ticketing tool a record ends up pasted into, the transcription partner you overflow to, the backup service.

Two practical consequences follow. First, your vendor register has to be built from where the data goes, not from the finance system's supplier list. Second, a subcontractor who will not sign is a scoping decision rather than a procurement problem: either the data stops flowing there, or the engagement changes shape.

Timeline, and Why We Publish No Price

For most Indian business associates, reaching a position you can evidence to a US client takes two to four months: one to two weeks to confirm your role and map where health information lives, two to three for the security risk analysis the Security Rule requires, three to four for safeguard design, two to three for the privacy and breach processes, and two to four for agreement management, ending in a readiness review.

We do not publish a figure for HIPAA work, and that is deliberate rather than coy. The effort between a single-platform health-tech company and a revenue cycle business with several delivery centres, hundreds of workstations and dozens of signed agreements differs by more than any range would usefully communicate. We scope first, then quote the work in writing.

One thing to be clear about before you engage anyone, including us: there is no accredited HIPAA certifier, and we are not one. What we produce is the risk analysis, the safeguards, the policy set, the agreement review and the evidence pack your client's security team reads. Where an independent attestation is what the client wants, that is a SOC 2 or ISO 27001 engagement with an accredited body, and we build one control set that serves both.

Frequently Asked Questions

Do we need a business associate agreement if we never see patient names?

Probably yes. Protected health information is identifiable health information, and the identifiers that make it so run well beyond names: dates of service, member and account numbers, device identifiers, full postal codes and IP addresses among them. A billing or coding operation working from claim data is handling it even when no name appears on the screen, and a platform that stores only internal identifiers is usually still handling it once those identifiers can be tied back to a person by the covered entity. Properly de-identified data under the Privacy Rule's standard sits outside HIPAA, but de-identification is a documented process with a defined method, not a description of how the data looks to you. We confirm the position for each data flow during scoping, because the answer decides whether an agreement is required at all.

What happens if we sign an agreement we cannot actually comply with?

You take on direct liability for obligations you are not meeting, and you hand your client a contractual exit. The usual example is the breach deadline: an agreement requiring notification within five days of discovery is enforceable against you even though the Breach Notification Rule allows a business associate up to 60 calendar days, and discovery is counted from when any of your staff knew, not from when management was told. The second common example is an encryption clause written as an absolute requirement where the Security Rule treats encryption as addressable. Neither is a reason to refuse to sign; both are reasons to read the agreement before signing and to build the control the clause assumes exists. We review signed and draft agreements clause by clause and tell you which commitments have nothing behind them yet.

Is a security risk analysis really mandatory, or is a policy set enough?

It is mandatory, and a policy set is not a substitute for it. The Security Rule requires an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity and availability of the electronic protected health information you hold, and it requires you to manage what the assessment finds. It is the first document HHS asks for in an enforcement matter and among the most commonly missing. It has to cover every place the information lives or travels, including laptops, cloud accounts, email, backups and subcontractor systems, and it has to be refreshed when the environment changes rather than written once and filed away. We run it against HHS and NIST SP 800-66 Rev. 2 guidance, cover every system in scope, and leave you a risk register with named owners, treatment decisions and a review date, so the next client questionnaire has a current document behind it.

Can we tell a US client we are HIPAA certified once this is done?

No, and claiming it damages you with exactly the buyers you are trying to win. HHS does not certify organisations as HIPAA compliant and does not endorse any private certification scheme, so a certificate issued by a consultant or a platform carries no regulatory weight, and a security reviewer who sees one in your deck will discount the rest of the pack. The defensible claim is specific: a security risk analysis dated this quarter, an implemented safeguard set, signed agreements with every subcontractor that touches the data, training records, and a tested breach procedure. That is what answers a questionnaire. Where a client wants independent assurance rather than your own evidence, SOC 2 or ISO 27001 is the instrument that provides it, because an accredited third party signs the result and the reviewer can check who that party was.

Does a SOC 2 report satisfy a business associate agreement?

Not by itself, but it does most of the work. A SOC 2 Type 2 report gives your client independent evidence that access management, change control, logging, incident response and vendor management operated over a period, which is the bulk of what the Security Rule asks for, and many covered entities will accept it in place of their own audit. What it does not cover are the HIPAA-specific obligations: the documented security risk analysis in the form the Security Rule requires, the Privacy Rule's use and disclosure limits, the patient rights workflow, the breach assessment and notification procedure on your client's deadline, and the subcontractor agreements. We map the overlap so that one control set and one evidence trail serve the report and the agreement together, rather than running two programmes that duplicate the same access reviews, the same incident records and the same vendor assessments twice over.

Where to Start

If you have signed agreements already, start with a read of what you committed to and a check of which clauses have a working control behind them. If you are about to sign your first, scope the data flows first, so you know what you are agreeing to protect. Either way, request an assessment and we will tell you where you stand against the agreements in front of you.