HIPAA IT compliance checklist

1. Settle the boundary before touching anything

The most expensive failure on this list is not a misconfigured control — it is two parties who each believed the other was doing it. Write the split down before the engagement starts, because after an incident everyone remembers it differently.

• Sign a business associate agreement between the IT provider and the client

  Evidence: An executed agreement naming the services in scope, held by both parties

  164.502(e), 164.504(e), 164.314(a)

• Write down which safeguards the provider operates and which the client operates

  Evidence: A responsibility matrix attached to the agreement or the statement of work

• Record which subcontractors the provider uses that could reach client data

  Evidence: A subprocessor list, with agreements flowing the obligations down

  164.502(e)(1)(ii)

• Agree the incident notification path and how fast it runs

  Evidence: A written procedure naming who calls whom, and within how long

  164.410

2. Access control

The standard at 164.312(a)(1) is to allow access only to those persons or software programs that have been granted rights. Two of its four specifications are required outright; the other two are addressable, which does not mean optional.

• Give every user a unique identifier — no shared logins, including for the admin account

  Evidence: A user list showing one account per human, with join dates

  164.312(a)(2)(i) — required

• Establish a procedure for obtaining data during an emergency

  Evidence: A written break-glass procedure and a record of who can invoke it

  164.312(a)(2)(ii) — required

• Set automatic logoff on workstations and applications that reach patient data

  Evidence: Policy or GPO settings, with the timeout value recorded

  164.312(a)(2)(iii) — addressable

• Encrypt data at rest, or document why you did not and what you did instead

  Evidence: Disk encryption reporting per device, or a written equivalent-measure decision

  164.312(a)(2)(iv) — addressable

• Review who has access on a schedule, and remove leavers the day they leave

  Evidence: Dated access reviews and dated deprovisioning records

  164.308(a)(3)(ii)(C), 164.308(a)(4)

3. Audit controls and integrity

164.312(b) is one sentence and it is required with no addressable escape: implement hardware, software or procedural mechanisms that record and examine activity in systems containing electronic protected health information. Note the second verb — recording logs nobody reads does not meet it.

• Enable logging on every system holding patient data

  Evidence: A list of systems and what each one logs

  164.312(b) — required

• Actually examine the logs on a defined cadence, and record that you did

  Evidence: Dated review notes, including the reviews that found nothing

  164.308(a)(1)(ii)(D)

• Retain logs long enough to investigate an incident discovered late

  Evidence: A stated retention period and evidence the retention is enforced

• Protect records from improper alteration or destruction

  Evidence: Tamper-evidence, write-once storage or equivalent, described in writing

  164.312(c)(1)

4. Transmission security

Anything leaving your network. The commonest gap here is not the clinical system — it is email, file transfer to a lab or payer, and the remote-access path the IT provider itself uses.

• Encrypt patient data in transit wherever it crosses a network you do not control

  Evidence: TLS configuration, VPN configuration, and how it is verified

  164.312(e)(2)(ii) — addressable

• Protect against improper modification in transit

  Evidence: Integrity controls described, not assumed

  164.312(e)(2)(i) — addressable

• Require multi-factor authentication on remote access and administrative accounts

  Evidence: Enforcement policy and a report of accounts covered

5. Physical safeguards

The section IT teams skip because it sounds like facilities management. 164.310 is where lost laptops and unwiped disposals live, and those are a large share of reported breaches.

• Control physical access to servers, network equipment and areas where data is visible

  Evidence: An access list and a record of who holds keys or badges

  164.310(a)(1)

• Position and secure workstations so screens are not readable by passers-by

  Evidence: A written workstation-use policy and a walkthrough record

  164.310(b), 164.310(c)

• Track devices and media in and out, including repairs and reassignments

  Evidence: A device register with movements and current holder

  164.310(d)(1)

• Sanitise media before disposal or reuse, and keep the certificate

  Evidence: Dated destruction or wipe certificates, per asset

  164.310(d)(2)(i), 164.310(d)(2)(ii)

6. Contingency and backup

164.308(a)(7) exists because availability is a security property under this rule, not just an uptime concern. Ransomware turned this from paperwork into the most-tested section on the list.

• Maintain retrievable exact copies of patient data

  Evidence: Backup job reporting, with scope showing every system

  164.308(a)(7)(ii)(A) — required

• Write a disaster recovery plan that names systems, order and owners

  Evidence: The plan, dated, with a version history

  164.308(a)(7)(ii)(B) — required

• Define how you operate while systems are down

  Evidence: An emergency mode operation plan

  164.308(a)(7)(ii)(C) — required

• Test restores — not backups — and record the result

  Evidence: A dated restore test log, including failures and what changed after

  164.308(a)(7)(ii)(D) — addressable

7. Incident procedures

A security incident is not the same thing as a breach, and conflating them is why incident logs sit empty. The rule asks you to identify and respond to suspected or known incidents — most of which will turn out to be nothing.

• Define what counts as a security incident and how staff report one

  Evidence: A written procedure people have actually been shown

  164.308(a)(6)(i)

• Log every incident, including the ones assessed as not reportable

  Evidence: An incident log with the four-factor assessment and the reasoning

  164.308(a)(6)(ii), 164.402, 164.414(b)

• As a business associate, notify the client without unreasonable delay

  Evidence: A dated notification record, and the clock started from discovery

  164.410

8. The provider's own programme

If you are an MSP or IT firm with administrative access to client data, you are a business associate in your own right. Every obligation below is yours, about your systems, independently of anything your clients do.

• Conduct a risk analysis of your own environment, not just each client's

  Evidence: A dated analysis covering your tooling, RMM, and staff devices

  164.308(a)(1)(ii)(A)

• Train your own staff and keep per-person records

  Evidence: Completion dates and certificates for every engineer

  164.308(a)(5)

• Screen staff and subcontractors against the federal exclusion lists

  Evidence: Dated screening results, refreshed monthly

  42 USC 1320a-7, 42 CFR 1001.1901

• Retain all of this for six years from creation or last effect, whichever is later

  Evidence: Version history rather than overwritten files

  164.316(b)(2)(i)

The tools these controls actually apply to

Every item above lands on specific software, and the answer to “can we use this?” is usually a question about the vendor’s agreement rather than its feature list. These are the categories an IT provider gets asked about most, each with our per-vendor verdicts and the conditions attached.

• Cloud infrastructure →
• Productivity suites →
• Team messaging →
• File storage →
• Email providers →
• Databases and app builders →
• Automation tools →
• Form builders →

Common questions

Is an MSP a business associate under HIPAA?

Almost always, yes. A business associate is anyone who creates, receives, maintains or transmits protected health information on behalf of a covered entity — and “maintains” is enough on its own. An IT provider with administrative access to systems holding patient data maintains it, whether or not anyone at the firm ever opens a record. The narrow conduit exception covers pure transmission services like a telecoms carrier or postal service; it does not cover managed IT, which has persistent access by design.

Does HIPAA require encryption?

Encryption is addressable rather than required, which is widely misread as optional. 45 CFR 164.306(d) sets out what addressable actually means: assess whether the specification is reasonable and appropriate, implement it if it is, and if it is not, document why and implement an equivalent alternative measure where reasonable. Doing nothing and writing nothing down is the one response the rule does not allow. In practice, for laptops and anything crossing a network, the assessment rarely lands anywhere except “implement it”.

Who is liable if the IT provider causes the breach?

Both parties can be, separately. Since the 2013 Omnibus Rule business associates are directly liable for their own compliance with the Security Rule and for impermissible uses and disclosures — a client cannot absorb that liability on your behalf, and outsourcing the work does not outsource the obligation. The client meanwhile retains its own obligations, including having obtained satisfactory assurances from you in the first place.

How is this different from a general HIPAA compliance checklist?

Scope. The general checklist covers the whole programme — officers, policies, training, patient rights, agreements — and most of it is not an IT job. This page covers the physical and technical safeguards at 45 CFR 164.310 and 164.312 plus the contingency and incident standards, which is the part an IT team or MSP actually configures and can be held to. Run both: neither is a substitute for the other.

Does an MSP need its own risk analysis?

Yes, of its own environment. Running an assessment for each client covers the client's systems; it says nothing about your RMM, your credential vault, your engineers' laptops or your ticketing system — all of which typically hold or reach client data. This is the single most common gap we see in MSPs that are otherwise running good client programmes.