HIPAA Compliant IT Support
HIPAA compliant IT support for Michigan practices
Every technical safeguard in the HIPAA Security Rule, configured, documented, and evidenced. We sign a Business Associate Agreement and we can show our work.
What “HIPAA compliant IT support” actually means
Start with the part most vendors will not say out loud: there is no such thing as HIPAA certified software, and no IT provider can make your practice compliant on its own. HIPAA compliance is a property of your whole organisation, covering policies, workforce training, physical access, and business processes as well as technology. What an IT provider can do is own the technical safeguards, document them, and give you the evidence to hand an auditor. Anyone promising more than that is selling you something that does not exist.
The technical requirements live in the HIPAA Security Rule, 45 CFR Part 164 Subpart C. It groups safeguards into administrative, physical, and technical categories, and each safeguard is marked either required or addressable. Addressable does not mean optional. It means you must implement it, or document a reasoned analysis of why it is not reasonable and appropriate for your environment and then implement an equivalent alternative. Encryption of ePHI at rest is the classic example. Practices skip it, assume addressable meant optional, and discover during an audit that the missing piece was never the encryption. It was the written analysis.
The other half of the job is the Business Associate Agreement. Any vendor that creates, receives, maintains, or transmits electronic protected health information on your behalf is a business associate and must have a signed BAA in place. That includes your IT provider. If your current provider has remote access to workstations holding ePHI and has not signed one, that is a gap in your compliance posture regardless of how well the technology is configured. We sign a BAA before we touch anything.
What we actually deliver is a documented environment. A risk analysis that follows the Security Rule's own structure, safeguards configured against it, and a written record showing what was implemented, when, and why. When an auditor, a cyber insurance carrier, or a hospital system doing vendor due diligence asks how you protect ePHI, you have an answer with evidence behind it rather than a verbal assurance. You can read the Security Rule yourself at HHS.gov, and we encourage practices to do exactly that before hiring anyone, including us.
You probably need this if
- You handle ePHI and cannot produce a written Security Rule risk analysis
- Your IT provider has remote access to systems holding ePHI but has never signed a BAA
- You are not certain whether workstations and backups holding ePHI are encrypted
- Nobody has tested a full restore of your practice management or imaging system this year
- A cyber insurance application or hospital vendor questionnaire is asking technical questions you cannot answer
- You are opening a second location and want the compliance posture built in from day one
What is included
Deliverables
What you actually get, in writing
Not a vague promise of support. Specific artifacts you can point at, hand to an auditor, or take with you if you ever leave.
Security Rule risk analysis
A written risk analysis mapped to the administrative, physical, and technical safeguards, with each finding rated and assigned an owner. This is the document auditors ask for first and the one practices most often cannot produce.
Addressable safeguard rationale
For every addressable specification, either the implemented control or a written analysis of why it is not reasonable and appropriate here, plus the equivalent measure used instead. This is the paperwork that turns a configuration into a defensible position.
ePHI access and audit evidence
Role-based permissions, enforced MFA, and access logging with retention, exported on request. You can demonstrate who reached what, and when.
Verified restore documentation
Immutable off-site backups with restores we actually run on a schedule and record. A backup nobody has restored is a hypothesis, not a safeguard.
Breach response runbook
A written incident response plan with the Breach Notification Rule timelines built in, so the clock is not the thing you are figuring out during an incident.
Practice-aware change windows
Patching and maintenance scheduled around your schedule. Imaging, practice management, and the front desk stay up through a full patient day.
Questions
Questions about this service
Can an IT company make my practice HIPAA compliant?
No, and be wary of any that says it can. Compliance covers policies, workforce training, physical security, and business processes alongside technology. We own the technical safeguards in the Security Rule, document them, and hand you the evidence. The rest of the programme belongs to the practice, and we will tell you plainly which parts those are.
Is there such a thing as HIPAA certified software?
There is not. No product, vendor, or certification body can confer HIPAA compliance on a practice, and HHS does not endorse or certify any product. A vendor can support a compliant configuration and can sign a BAA. Those are real and worth asking about. ‘HIPAA certified’ on a sales page is a signal to look more carefully at everything else on it.
Does encryption count as required or addressable?
Encryption of ePHI is addressable, which is widely misread as optional. It means you implement it, or you document a reasoned analysis explaining why it is not reasonable and appropriate in your environment and then implement an equivalent safeguard. In practice, for a modern dental or medical office, encryption is almost always reasonable and appropriate, so the honest answer is that you should just encrypt. We do it and we write down that we did.
Do you sign a Business Associate Agreement?
Yes, before we are granted any access. Any vendor that creates, receives, maintains, or transmits ePHI on your behalf is a business associate and needs a BAA. An IT provider with remote access to machines holding ePHI qualifies. If your current provider has not signed one, that gap exists today regardless of how well your systems are configured.
What happens if we are audited or a patient complains?
You produce documentation. The risk analysis, the safeguard configuration record, the addressable rationale, access logs, restore test records, and the incident response plan. We maintain those as part of the engagement specifically so this moment is a retrieval exercise rather than a reconstruction. We will also work directly with your compliance consultant or attorney on the technical sections.
We already have an IT provider. Can you just do the HIPAA part?
Sometimes. If your provider handles day to day support competently and the gap is compliance documentation and security configuration, a scoped engagement can work and we will say so. If the underlying environment has no MFA, no tested backups, and no logging, layering compliance paperwork on top produces a document that describes a system you do not have. In that case we will tell you that instead of taking the smaller engagement.
Want to know where you stand right now?
The assessment documents your environment, scores it against a modern baseline, and hands you a written report you keep either way.
No pressure, no obligation. If we are not the right fit we will tell you and point you somewhere better.