Most medical practices know they are supposed to be “HIPAA compliant,” and most are far less sure what that means for the server closet, the front desk workstations, and the email system. The regulation does not name products. It names outcomes. That vagueness is by design, because the Security Rule was written to be flexible and scalable, so a two-physician clinic and a hospital system can both comply without running identical programs. The cost of that flexibility is that someone has to translate it, and that is what this article does: the Security Rule’s safeguards in concrete IT terms, plus the risk analysis, Business Associate Agreements, and the basics of breach notification. One note up front: this is practical guidance from an IT provider, not legal advice, so bring your compliance counsel into questions about your specific obligations.
First, the vocabulary that makes the rule readable
Three terms unlock the whole regulation.
ePHI is electronic protected health information: patient data in electronic form, whether it lives in your EHR, an imaging system, a billing platform, email, or a spreadsheet someone exported and forgot about. The Security Rule protects ePHI specifically.
Required vs. addressable. The rule’s implementation specifications come in two flavors. Required ones must be implemented, full stop. Addressable ones must be assessed: implement them if reasonable and appropriate for your practice, or document why an alternative measure accomplishes the same purpose. Addressable is not a synonym for optional, and treating it that way is one of the most common findings when OCR reviews a practice after a breach. Encryption, notably, is addressable, and for nearly every modern practice the honest assessment lands on “implement it.”
Covered entity and business associate. Your practice is a covered entity. Any vendor that creates, receives, maintains, or transmits ePHI on your behalf is a business associate, and HIPAA requires a written Business Associate Agreement with each one. More on that below, because your IT provider is on that list.
Administrative safeguards: the program itself
The administrative safeguards are the largest section of the rule, and they are mostly about process rather than hardware.
A security risk analysis. This is a required specification and the foundation everything else stands on: an inventory of where ePHI lives, an honest evaluation of the threats and vulnerabilities to each system, and a determination of risk. OCR has said repeatedly that a missing or shallow risk analysis is among the most frequent problems it finds. It is also not a one-time document. HHS guidance treats it as an ongoing process, revisited periodically and after significant changes such as a new EHR or an office move. We cover how to actually run one in our security risk assessment guide.
Risk management. Having found the risks, you reduce them to a reasonable level. The rule leaves “reasonable” to your circumstances, which is precisely where a documented rationale matters.
A named security official. One person at the practice is designated responsible for the security program. Often that is the practice manager or a physician owner. You can lean on outside help for the technical work, but the designation belongs to the practice.
Workforce security and access management. People get access to ePHI based on their role, access is authorized before it is granted, and it is removed when someone leaves. In IT terms: individual accounts rather than shared logins, permissions that match job function, and an offboarding step that disables accounts the day employment ends, not the next time someone remembers.
Training and awareness. Staff are trained on security, including the attacks they will actually face. Phishing aimed at stealing EHR or email credentials is the realistic front door into a practice, which is why awareness training and email protection sit near the top of any ransomware defense plan for a medical practice.
An incident response process and a contingency plan. A documented procedure for responding to security incidents, plus a data backup plan, a disaster recovery plan, and an emergency mode operation plan so patient care can continue during an outage. The backup plan is a required specification, and it deserves more attention than it usually gets, because a practice’s data is scattered across the EHR, imaging, and Microsoft 365, each needing its own answer. Our guide to backing up EHR, imaging, and Microsoft 365 data walks through that.
Periodic evaluation. The program gets reviewed as the practice, its systems, and the threat landscape change. A risk analysis from three EHR versions ago no longer describes the practice it is supposed to protect.
Physical safeguards: the building and the devices
Shorter, but not skippable. Facility access controls limit who can physically reach systems holding ePHI, which for most practices means the server closet locks and the badge or key list is current. Workstation policies cover placement and use, the classic example being a screen at the front desk angled away from the waiting room, with screens locking automatically when idle. Device and media controls govern what happens to hardware that has held ePHI: laptops tracked, old drives wiped or destroyed with documentation rather than dropped in a dumpster, and a record of where devices go when they move or retire.
Technical safeguards: the part your IT provider builds
This is where the rule turns into configuration work.
Access control. Systems holding ePHI must support unique user identification (required), so every action traces to a person, plus emergency access procedures (required). Automatic logoff and encryption of stored data are addressable, and both are standard practice: idle sessions lock, and laptops, servers, and portable drives are encrypted. Multi-factor authentication is not named in the rule’s text, but it has become the baseline expectation for protecting the credentials that gate ePHI, and every cyber insurance application will ask about it regardless.
Audit controls. Required. The systems that hold ePHI must record activity, and someone must be able to review it. In practice this means logging is enabled in the EHR and Microsoft 365, logs are retained, and review actually happens rather than existing in theory. When something goes wrong, the audit trail is how you establish what was and was not accessed, which directly shapes your notification obligations.
Integrity and authentication. Mechanisms to ensure ePHI is not improperly altered or destroyed, and to verify that the people and systems connecting are who they claim to be.
Transmission security. ePHI encrypted when it moves across networks. Concretely: no patient information in plain email, secure messaging or an encrypted portal for anything leaving the practice, and VPN or equivalent protection for remote access to practice systems.
None of this requires exotic tooling. It requires the ordinary stack of a well-run network, MFA, endpoint protection, encryption, patching, logging, tested backups, deployed deliberately and documented. That is the core of what a managed cybersecurity service does, and it is why the Security Rule tends to be far more achievable than practices fear once someone maps it to real systems.
Business Associate Agreements: your MSP must sign one
Any vendor that touches ePHI on your behalf needs a BAA: the EHR vendor, the billing company, the cloud hosts, the transcription service, and yes, the IT provider. An MSP with administrative access to the servers, workstations, and email that hold patient data is a business associate, and HIPAA requires the agreement to be in place before that access exists. The BAA obligates the vendor to safeguard the data, report breaches to you, and accept direct liability under the rule.
This makes the BAA one of the cleanest screening questions when choosing an MSP for a medical practice. A provider who works with healthcare clients will say yes immediately and hand you their standard agreement. Braintek signs BAAs for practices where our role touches ePHI systems, and we treat the obligations in them as part of the service, not an add-on. A provider who stalls, or asks what a BAA is, is telling you they have not operated under the Security Rule before. The same logic applies inside your service contract itself, which is why BAA language is on our checklist of what belongs in a managed IT agreement for a medical practice.
Breach notification: the clock that starts when something goes wrong
The Breach Notification Rule sits alongside the Security Rule and is worth knowing in outline. When unsecured ePHI is breached, the practice must notify affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people must also be reported to HHS within that window and to media in the affected area; smaller breaches are logged and reported to HHS annually. Whether a specific incident is a reportable breach involves a risk assessment with legal judgment in it, so that determination belongs with your compliance counsel, not your IT provider.
Two IT facts change how these events play out. First, properly encrypted data that is lost or stolen generally is not “unsecured,” which can keep a stolen laptop from becoming a notification event. Second, audit logs are what let anyone establish the scope of what was accessed. Practices without them end up notifying broadly because they cannot prove anything narrower.
Who does what: the practice’s share and the IT provider’s share
The practice owns what cannot be delegated: designating the security official, adopting the policies, approving the risk analysis, making the risk decisions, and holding the vendor relationships including the BAAs. An IT provider carries the build and the evidence: implementing the technical safeguards, maintaining them as staff and systems change, coordinating with your EHR and imaging vendors on their security requirements, and producing the documentation, asset inventories, training records, log reviews, backup test results, that turns “we have safeguards” into something you can show an auditor or an insurer.
That division works under either support model. Some practices hand the whole environment to an MSP; others keep an internal person and bring in outside depth for security and compliance work, a tradeoff we walk through in internal IT vs. an MSP for medical practices.
Where a practice should start
Start with the risk analysis, because the rule expects everything else to trace back to it, and because it doubles as your gap list. Then close the highest-impact technical gaps first, MFA, encryption on portable devices, and tested backups, since those blunt the most likely incidents and anchor every insurance questionnaire. Then get BAAs current with every vendor touching ePHI, write down the policies you actually follow, and put training on the calendar. A practice of typical size can work through that sequence in weeks.
Braintek has supported Texas businesses since 2002, with teams serving Houston and Dallas–Fort Worth, and our sweet spot is exactly the 10 to 50 employee practice this article describes, fully managed or working alongside your existing IT. We keep the environment around your EHR and practice management systems secure and backed up and coordinate with your software vendors, and phone calls are typically answered within about a minute. If you want to see where your practice stands against the safeguards above, start with our healthcare industry page or the medical practices page, check the cost guide if budget is the open question, or send us a note through the form below and we will walk the checklist with you.