HIPAA Field Guide for MSPs
A tactical playbook for managed service providers guiding healthcare clients through the Security Rule, the Privacy Rule, and the Breach Notification Rule, with a step-by-step ControlMap workflow for assessments, controls, policies, and evidence.
The Rules, Decoded
The Health Insurance Portability and Accountability Act (HIPAA) sets national standards for protecting health information in the United States. Its administrative simplification rules are enforced by the HHS Office for Civil Rights (OCR), and they don't just apply to doctors. The moment your MSP touches a healthcare client's data or systems, you become a regulated business associate.
Two Regulated Parties
Health plans, healthcare clearinghouses, and healthcare providers that transmit health data electronically: your clients, including clinics, dental groups, physio practices, behavioral health, specialty offices. The covered entity always owns its compliance program, including the Privacy Rule operations and patient-facing duties the MSP can support but never own.
Any vendor that creates, receives, maintains, or transmits protected health information (PHI) for a covered entity. MSPs hosting, backing up, monitoring, or remotely accessing client systems qualify, and are directly liable under the Security and Breach Notification Rules. The moment you touch a healthcare client's data or systems, you're regulated.
What counts as PHI? Any individually identifiable health information held or transmitted by a covered entity or business associate, in any form: electronic (ePHI), paper, or spoken. Names, dates, contact details, medical record numbers, billing data, device identifiers, and even IP addresses tied to health records all qualify. There are 18 identifier categories in total.
The Three Rules
Protect ePHI. Administrative, physical, and technical safeguards for electronic health data: the rule where MSPs do the heaviest lifting.
Govern PHI use. Who may see and share health information, the minimum-necessary standard, and patients' rights over their own records.
Respond when it goes wrong. Risk-assess incidents and notify individuals, HHS, and sometimes the media on strict timelines.
Why it matters: OCR civil penalties are tiered by culpability, from "did not know" up to "willful neglect, uncorrected", and can reach seven figures per violation category, per year, alongside corrective action plans, state attorney-general actions, and reputational damage. For an MSP, one client's breach can also become a contract, insurance, and liability event for the practice itself.
01
3 Families · 18 Standards
The Security Rule requires covered entities and business associates to ensure the confidentiality, integrity, and availability of all electronic PHI they create, receive, maintain, or transmit, protecting it against reasonably anticipated threats and impermissible uses. Its 18 standards sit in three safeguard families: administrative, physical, and technical.
Anatomy of the Rule
Policies, people, and process: risk analysis, training, access governance, incident response, contingency planning. Over half of the Security Rule lives in these nine standards: the program backbone.
Buildings, workstations, and hardware: facility access, workstation placement and use, device and media lifecycle, four standards where the client's front office and the MSP's asset practices meet.
The systems themselves: access control, audit logging, integrity protection, authentication, transmission security, five standards that map almost one-to-one onto the modern MSP security stack.
The Program Backbone
These nine standards establish the security management program your client must run, and that your MSP will largely operationalize.
| Standard | What it demands in practice | Type |
|---|---|---|
| Security management process | Conduct an accurate, thorough risk analysis of ePHI; implement risk-management measures; apply a sanction policy for violations; review system activity (logs, audit trails) regularly. | Required |
| Assigned security responsibility | Name one accountable Security Officer for the client organization, a person, not a vendor. | Required |
| Workforce security | Authorization/supervision procedures, workforce clearance, and termination procedures so departing staff lose access immediately. | Addressable |
| Information access management | Grant access to ePHI based on role; isolate clearinghouse functions; document how access is authorized and modified. | Required + addressable |
| Security awareness & training | Ongoing training program: security reminders, malware protection, login monitoring, password management, for the entire workforce. | Addressable |
| Security incident procedures | Identify, respond to, mitigate, and document security incidents and their outcomes. | Required |
| Contingency plan | Data backup plan, disaster recovery plan, emergency-mode operation plan; test and revise; analyze application/data criticality. | Required + addressable |
| Evaluation | Periodic technical and non-technical evaluation of safeguards, repeat whenever the environment changes materially. | Required |
| BA contracts & other arrangements | Written Business Associate Agreements with every vendor that handles ePHI, including the MSP and the MSP's subcontractors. | Required |
Spotlight
A missing or stale risk analysis is the single most common finding in OCR enforcement actions. If you run only one engagement deliverable this quarter, make it this one.
Where it lives, flows, and leaves, every system, device, vendor, and data path.
Vulnerabilities and threat sources, internal and external.
Likelihood × impact for each threat and vulnerability.
Remediate, accept, or transfer, with the decision written down.
And on any major change to systems, vendors, or the environment.
Required vs. addressable: two words that decide the build
Must be implemented, full stop, no alternatives, no opt-outs. Examples: the risk analysis, unique user identification, and breach-response procedures. Build these first; every required specification is a floor, not a suggestion.
Not optional. For each addressable specification: implement it, implement an equivalent alternative, or document why it isn't reasonable and appropriate for the environment. Every "addressable" decision must be written down: the paperwork is the compliance.
The Security Rule is technology-neutral and scalable: safeguards must be "reasonable and appropriate" for the organization's size, complexity, and risk. The required/addressable distinction is where that flexibility lives, and where undocumented shortcuts become findings. MSP tip: treat every addressable spec as required unless a documented risk decision says otherwise, that documentation is exactly what OCR asks for first.
The Other Nine Standards
The remaining two families split the work between the building and the systems. Physical safeguards govern facilities, workstations, and hardware; technical safeguards govern the systems that hold and move ePHI, and translate almost directly into the tooling a mature MSP already runs.
Two Families, Nine Standards
| Family | Standard | In practice |
|---|---|---|
| Physical4 standards | Facility access controls | Limit physical access to systems and facilities: locks, badges, visitor logs, contingency facility access, maintenance records. |
| Workstation use | Define proper use and physical surroundings of workstations that touch ePHI (e.g., screens away from waiting rooms). | |
| Workstation security | Physical restrictions: privacy screens, cable locks, auto-lock, restricted areas for servers and admin consoles. | |
| Device & media controls | Track hardware and media through receipt, movement, re-use, and disposal, sanitize or destroy before retirement; maintain an asset log; back up before moves. | |
| Technical5 standards | Access control | Unique user IDs, emergency access procedure, automatic logoff, encryption at rest. |
| Audit controls | Hardware/software mechanisms that record and let you examine activity in systems containing ePHI. | |
| Integrity | Mechanisms to confirm ePHI hasn't been improperly altered or destroyed (checksums, versioning, immutable backups). | |
| Person/entity authentication | Verify identity before access, strong passwords plus MFA as today's de-facto standard of "reasonable." | |
| Transmission security | Integrity controls and encryption for ePHI in motion: TLS, VPN, secure email/file exchange. |
Translate it to your MSP stack: MFA + conditional access → person/entity authentication · disk encryption (BitLocker/FileVault) → access control · SIEM/log retention → audit controls · email encryption gateway → transmission security · asset lifecycle & ITAD → device & media controls · RMM patching → risk management · EDR/MDR → malware protection · BCDR appliance + tests → contingency plan · offboarding runbook → workforce security · security awareness platform → training.
Who Does What
Typical allocation across the Security Rule for an MSP-supported practice: the BAA and your control map record the real split per client.
02
Rights Over All PHI
The Privacy Rule defines when PHI, in any form, not just electronic, may be used and disclosed, and gives patients enforceable rights over their own health information. The covered entity owns most Privacy Rule operations; the MSP's job is to know the rule well enough to configure systems, workflows, and access in a way that doesn't break it.
Use & Disclosure
Treatment, Payment, and healthcare Operations, plus disclosures to the individual, certain public-interest uses, and incidental disclosures that occur despite reasonable safeguards.
Marketing, sale of PHI, most psychotherapy-note uses, and anything outside TPO and the listed exceptions.
Even when use is permitted, access and disclose only the least PHI needed for the task: the standard that drives role-based access design.
Six Patient Rights
Inspect and obtain records, generally within 30 days, in the form requested where readily producible.
Request corrections to inaccurate or incomplete records: the practice must act on the request and document the outcome.
Request a list of certain disclosures made outside treatment, payment, and healthcare operations.
Ask to limit uses and disclosures, practices must honor self-pay restrictions to health plans.
Choose how and where they're contacted, an alternate address or number the practice must reasonably accommodate.
Receive a Notice of Privacy Practices and complain without retaliation.
Privacy Operations
| Core requirement | What the practice must put in place | How the MSP supports it |
|---|---|---|
| Privacy Officer | Designate an accountable Privacy Official and a contact for complaints. | Track the designation as evidence; route privacy tickets correctly. |
| Notice of Privacy Practices (NPP) | Publish and distribute a notice describing uses, disclosures, and patient rights; post on the website; obtain acknowledgment where required. | Host/post the NPP on web properties; version-control updates. |
| Minimum necessary & role-based access | Define which roles may access which PHI, for which purposes. | Configure it: security groups, EHR roles, share permissions, least-privilege admin. |
| Workforce privacy training | Train all staff on policies; retrain on material changes; keep records. | Deliver and track training via the awareness platform; surface completion reports. |
| Administrative safeguards for all PHI | Reasonable safeguards for paper and oral PHI too, shredding, fax cover sheets, private check-in areas. | Advise on printer/fax/scan-to-email flows and secure document handling. |
| Patient-rights fulfillment | Procedures and tracking for access, amendment, accounting, and restriction requests within deadlines. | Build export workflows from EHR/file systems; log disclosure events. |
| BAAs with all vendors | Identify every vendor touching PHI; execute and refresh agreements. | Maintain the vendor inventory; flag shadow-IT SaaS that touches PHI. |
Who Does What
As a business associate, your firm may use PHI only as the BAA permits, never for your own analytics, marketing, or AI training. If a technician can see PHI while fixing a server, that's permitted incidental access; browsing it is not. Put that in your own staff training.
Inventory where PHI lives and who touches it → define roles → enforce least privilege in every system → adopt the privacy policy set → train and attest → review access quarterly. Every step produces an artifact you can store as evidence.
When an incident isn't a reportable breach
Unintentional, good-faith access by a workforce member within their authority · inadvertent disclosure between similarly authorized people inside the organization · a good-faith belief the recipient couldn't have retained the information. Everything else starts the notification analysis.
PHI encrypted to NIST standards (with keys uncompromised) is not "unsecured", a lost encrypted laptop is generally not reportable. Encryption everywhere is the cheapest breach insurance an MSP can deploy.
The Breach Notification Rule presumes an impermissible acquisition, access, use, or disclosure of unsecured PHI is a breach unless a documented risk assessment shows a low probability that PHI was compromised. Two things keep an incident off the notification path: the rule's narrow exceptions, and encryption done right.
03
When PHI Is Exposed
When unsecured PHI is acquired, accessed, used, or disclosed impermissibly, the affected individuals, and regulators, have a right to know. The clock starts at discovery: the first day the breach is known, or would have been known with reasonable diligence. Run the four-factor risk assessment first, then work the notification clock.
Four Factors, Documented
Which identifiers, and how sensitive, SSNs and clinical detail raise the stakes more than a name alone.
Another HIPAA-regulated entity bound by the same rules, or an unknown external actor: the recipient changes the risk.
Forensics answer it: was data opened, exfiltrated, or merely exposed without being accessed?
A recovered device, a signed attestation of destruction, revoked access, document every answer to all four factors.
The Notification Clock
Contain, preserve evidence, and run the four-factor risk assessment with counsel and the cyber insurer, document the conclusion.
The business associate must notify the covered entity, 60 days is the legal maximum, but BAAs typically demand 24–72 hours. Know yours.
First-class mail (or email if agreed), day 60 at the outside; substitute web/media notice if 10+ are unreachable; 500+ in a state or jurisdiction means notifying prominent media too.
500+ affected: within 60 days of discovery. Under 500: log it, then report within 60 days after the calendar year ends.
All deadlines run "without unreasonable delay": the day counts are outer limits, not targets. Notice contents: what happened · the types of PHI involved · steps individuals should take · what you're doing to investigate, mitigate, and prevent recurrence · contact procedures.
The First 72 Hours
Isolate systems; keep logs and images intact.
Alert the client's Privacy/Security Officer in the contracted window.
Whose PHI, what fields, encrypted or not.
With counsel and the cyber insurer; document the conclusion.
Individuals, HHS, and media as required; fix the root cause.
Assessments, notices, and decisions are auditable records, keep them for six years.
Who Does What
ControlMap by ScalePad
ControlMap is ScalePad's multi-tenant GRC platform built for MSPs. Everything the previous sections demand, assessments, mapped controls, policies, training attestations, vendor BAAs, and audit-ready evidence, lives in one workspace per client, so you can run HIPAA as a repeatable, billable service instead of a yearly scramble.
The Five-Step ControlMap Workflow
Create a dedicated client workspace, select HIPAA from the framework library, and let ControlMap load the pre-mapped control set covering the Security, Privacy, and Breach Notification Rules. Cross-mapping means work done here also counts toward CIS, NIST CSF, or SOC 2 later.
Use built-in questionnaires to baseline the client against every safeguard, then build the risk register: assets, threats, likelihood × impact scoring, and treatment decisions. This is the documented risk analysis the Security Rule requires, exportable for the client's records.
Each control card explains what the safeguard means, what "implemented" looks like, and what evidence satisfies it. Assign owners: your engineers or the client's staff, set due dates, and track status from gap → in progress → implemented on the client dashboard.
Start from the HIPAA policy template library (security management, access control, contingency, privacy, breach response…), tailor to the practice, version-control approvals, and push to staff for electronic acknowledgment. Attestation records become evidence automatically.
Attach evidence to each control, screenshots, exports, configs, and automate what you can through integrations with the Microsoft/Google clouds and your MSP stack. Recurring evidence tasks re-prompt before items go stale, and dashboards turn it all into client-ready compliance reports for QBRs.
Multi-tenant design means one pane for every healthcare client. Productize it: Assess (one-time gap + risk engagement) → Remediate (project work) → Manage (monthly compliance-as-a-service with recurring evidence, reviews, and QBR reporting).
Walk the practice owner through the compliance dashboard: posture score, closed gaps, open risks with owners, upcoming evidence tasks. Compliance progress is the easiest security story a non-technical client will ever understand, and the strongest renewal argument.
HIPAA compliance decays: staff turn over, systems change, evidence goes stale. Set ControlMap's recurring tasks, quarterly access reviews, annual risk analysis refresh, annual policy review and re-attestation, and the program maintains itself on schedule.
Take Action
Where each rule lives in ControlMap and the evidence OCR expects; a realistic first-90-days arc per client; and the ten-point quick-start checklist to put the whole guide in motion.
ControlMap in Action
| Rule | Do this in ControlMap | Evidence you'll bank |
|---|---|---|
| Security Rule | Run the HIPAA gap assessment; build the risk register; assign the 18 safeguard standards as controls with owners and due dates; schedule recurring tasks for log review, access reviews, and DR tests; track training campaigns. | Completed risk analysis & register · control status history · access-review sign-offs · backup/DR test results · training completion records |
| Privacy Rule | Publish the privacy policy set from templates; record the Privacy Officer designation; manage the vendor register with BAA status for every PHI-touching vendor; push staff attestations; track patient-rights procedures as documented controls. | Approved & versioned policies · e-signed staff acknowledgments · vendor list with executed BAAs · NPP version history |
| Breach Notification | Load the incident-response and breach-notification policies; document incidents in the register; attach the 4-factor risk assessment to each event; store notification letters and HHS submission confirmations; run post-incident review tasks. | Incident log with timestamps · documented breach determinations · copies of notices · 6-year retention in one place |
| Your own MSP | Stand up a workspace for your own firm, as a business associate you carry direct Security and Breach Rule obligations. Reuse the same framework, policies, and evidence flows internally. | Your BA-side risk analysis · internal policies · subcontractor BAAs · proof for cyber-insurance and client due-diligence questionnaires |
Per Client
BAA signed · workspace created · HIPAA framework adopted · kickoff with the Privacy and Security Officers.
Gap assessment and risk register complete · remediation plan priced and approved.
High-risk controls implemented · policies approved · staff attestation and training launched.
Evidence flowing · recurring tasks scheduled · first compliance report delivered at QBR.
Take Action
With every healthcare client, and with your own subcontractors. No PHI touches your stack before it's signed.
The client must designate a Privacy Officer and a Security Officer, a person, not a vendor, in writing.
Every system, device, vendor, and data flow: the map the risk analysis and the BAA register both depend on.
In ControlMap: the keystone control, and the one OCR asks for first.
At rest and in transit, everywhere PHI lives or moves, today's de-facto standard of "reasonable."
Backup, disaster recovery, and emergency-mode operation, tested, revised, and with the test reports kept as evidence.
From ControlMap templates, tailored to the practice, version-controlled, and acknowledged with staff e-attestations.
Security and privacy training for all staff, with completion tracked as evidence.
Incident and breach procedures, including your BAA notification window, practiced before you need them.
Quarterly access reviews, annual risk analysis refresh, annual policy review and re-attestation, so the program maintains itself.
This guide is provided for general educational purposes and reflects the HIPAA rules as commonly understood at time of publication. It is not legal advice, and individual circumstances vary, covered entities and business associates should consult qualified healthcare counsel for compliance and breach-determination decisions. HIPAA, HHS, and OCR references are to U.S. federal regulation (45 CFR Parts 160 and 164).
ControlMap by ScalePad
See how MSPs run multi-client HIPAA programs, gap and risk assessments, mapped safeguards, signed policies, and audit-ready evidence, in one ControlMap workspace per client.
