HIPAA for Technology Vendors and MSPs: Business Associate Status, BAAs, Access, and Logging

HIPAA reaches past the practice that treats patients. A technology firm that stores, processes, or can reach electronic protected health information (ePHI) is a business associate, with obligations of its own. This post answers the questions that come up when a covered entity and its IT provider work out who is responsible for what. The full framework is on the HIPAA compliance page.

When does an IT provider become a business associate?

A business associate is an organisation that creates, receives, maintains, or transmits ePHI on behalf of a covered entity. In practice that includes:

• Healthcare IT vendors and managed service providers
• Cloud service providers hosting healthcare workloads
• Medical billing companies
• Transcription services
• Practice management companies
• Third-party administrators

The test is access, not intent. An MSP that never opens a chart but holds domain administrator rights over the servers where charts live is inside the boundary, because the access exists.

What does the business associate agreement have to cover?

Written agreements are required. A BAA should state:

• The safeguards the business associate will apply to ePHI
• The obligation to report security incidents and violations, and how quickly
• The permitted uses and disclosures, and the limits on them
• Flow-down to any subcontractor that will also touch ePHI
• What happens at termination — return or destruction of ePHI, and evidence of it

An unsigned or generic BAA is one of the first gaps found in a risk analysis, and it is the cheapest one to close.

How do the access-control standards apply to the vendor’s own staff?

The Security Rule’s technical safeguards apply to the systems the vendor administers, and to the vendor’s administrative access to them:

• Unique user identification — named accounts for every engineer, never a shared admin login
• Emergency access procedures — a documented break-glass path, with the use of it logged
• Automatic logoff — configured on workstations and on remote sessions into the environment
• Encryption and decryption — at rest and in transit, including backups and mobile devices, with key management the covered entity can ask about

The administrative safeguards sit alongside them: workforce clearance before access is granted, termination procedures that remove it the same day, and the minimum necessary principle applied to what each role can reach.

What does the audit controls standard require?

The audit controls standard calls for hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. For a vendor that means:

• Centralised log management rather than logs left on each host
• User activity monitoring and access tracking, including the vendor’s own administrators
• Log retention and protection, so records cannot be quietly edited
• Anomaly detection, so the logs are examined rather than merely kept

“Record and examine” is two verbs. A log nobody reads satisfies half the standard.

What about transmission security?

The transmission security standard requires integrity controls for ePHI in transit and encryption of it. In a typical MSP arrangement this covers remote support sessions, backup replication between sites, email carrying ePHI, and any file transfer with the practice or its other vendors.

What happens when there is an incident?

Security incident procedures have to be written: identification and reporting, documentation and analysis, mitigation and corrective action, and ongoing monitoring afterwards. On the covered entity’s side that connects to breach response — risk assessment, OCR notification, individual notification, and media notification where required. A business associate’s job is to get the covered entity the facts fast enough that those decisions can be made on time.

What evidence should a covered entity ask its vendor for?

• A signed, current BAA, with subcontractor flow-down
• The risk analysis covering systems that hold ePHI, and the remediation plan
• Named-account and MFA evidence for vendor administrative access
• Log retention settings, and proof that alerts are reviewed
• Encryption configuration at rest, in transit, and on backups
• The incident response plan, with the notification path and timing
• Workforce training records for the vendor’s own staff

Related pages

• HIPAA compliance — Security Rule safeguards, risk assessment, and breach response
• Healthcare IT — technology for practices and healthcare organisations
• Cybersecurity services — monitoring, detection, and response

This post covers the technology and compliance side of HIPAA for vendors. It is not legal advice and it is not medical advice.