HIPAA compliance failures rarely happen because the technology was wrong.
They happen because someone shared a file the wrong way. Because a terminated employee’s account wasn’t deprovisioned on the same day their badge was deactivated. Because a vendor relationship existed without a signed BAA because procurement didn’t flag it. Because audit logs existed but no one was actually reviewing them.
The technology can be configured correctly, and an organization can still fail an audit — because the compliance posture is not the configuration. It’s the operational discipline that keeps the configuration meaningful over time.
I spent six years owning the IT compliance posture in a healthcare environment. Here’s what I learned about what it actually takes.
Compliance Is an Operational State, Not a Project Outcome
The most dangerous framing in healthcare IT compliance is treating it as a project.
Projects have completion dates. You implement the controls, you document them, you pass the audit, you move on. But HIPAA doesn’t have a completion date. The threat landscape changes. Personnel turn over. New systems get added. Vendors change their practices. Each of these events is a potential gap in your compliance posture if you’re not actively maintaining it.
The organizations that maintain clean compliance postures treat it as a continuous operational discipline:
- Access reviews happen on a schedule, not just after incidents
- New vendor relationships trigger a BAA review process automatically, not as an afterthought
- Terminated employees lose access same-day because the process is automated, not because IT manually handles every offboarding
- Policy exceptions are documented because the documentation requirement is built into the exception process
None of these require expensive tooling. They require process discipline and the organizational authority to enforce it consistently.
Microsoft 365 in Healthcare: What the Configuration Actually Needs to Include
M365 is the dominant productivity suite in healthcare, and Microsoft’s HIPAA BAA covers most M365 services. That coverage is meaningful — but it doesn’t configure compliance for you.
The M365 features that matter most for HIPAA operational compliance:
Data Loss Prevention (DLP) policies. PHI takes many forms — patient names with diagnoses, dates of birth with account numbers, Social Security Numbers. DLP policies can detect and block sharing of PHI patterns through email, Teams, and SharePoint. The default policies Microsoft provides are a starting point; the policies that protect your specific organization require customization based on your data patterns.
The critical configuration decision: block vs. audit. A block policy stops the sharing attempt. An audit policy logs it and notifies. In my experience, starting with audit-then-block gives you visibility into existing sharing patterns before enforcement, which prevents the operational disruption that comes from blocking workflows people didn’t know were non-compliant.
Retention policies and litigation holds. HIPAA requires a 6-year retention period for compliance documentation — policies, procedures, and training records. Medical record retention periods are governed by state law and vary, but are typically longer. M365 retention policies can enforce both, automatically preventing premature deletion and managing accumulation. Litigation hold capability is essential for legal and compliance purposes and should be tested before it’s needed.
Microsoft Defender for M365. Phishing and business email compromise are the leading vectors for healthcare data breaches. Defender’s anti-phishing, safe links, and safe attachments controls are not optional in a healthcare environment — they’re table stakes. The configuration that matters most: impersonation protection for executive and clinical leadership, whose email accounts are the highest-value targets.
Communication Compliance. For organizations subject to additional regulatory oversight or with specific compliance requirements, Communication Compliance provides the supervisory review capability that HIPAA-covered entities sometimes need. This is not a universal requirement, but it’s one to understand before an auditor asks whether you have it.
Conditional Access: The Identity Layer That Makes Everything Else Defensible
The most important security control in a Microsoft-first healthcare environment is Conditional Access.
A correctly configured Conditional Access policy answers the auditor’s core access control questions: who can access clinical systems, from what devices, under what conditions, and what happens when those conditions aren’t met?
The policies that matter most in a healthcare environment:
Require MFA for all users accessing clinical systems. This is not optional. The authentication event creates the audit record that demonstrates the person accessing the system was verified at the time of access. Multi-factor authentication is the most effective single control against credential-based compromise.
Require compliant or Microsoft Entra hybrid joined devices. A compliant device policy ensures that devices accessing clinical systems meet a minimum security standard: encrypted, up to date, managed by Intune. This prevents the scenario where a personal device — potentially compromised, potentially shared — accesses patient data without any organizational visibility.
Block legacy authentication protocols. Basic Auth doesn’t support MFA. Any device or application authenticating via Basic Auth — including IMAP and POP3 clients that haven’t been migrated to OAuth2 — is a gap in your MFA coverage regardless of how well your Conditional Access policies are configured. Blocking Basic Auth and requiring Modern Authentication closes that gap. Microsoft has been deprecating Basic Auth for Exchange Online protocols since 2022.
Implement risk-based Conditional Access for high-risk sign-ins. Entra ID evaluates sign-in risk in real time based on factors like impossible travel, anonymous IP usage, and known malicious IP ranges. A risk-based policy that requires step-up verification for high-risk sign-ins catches credential compromise scenarios that static policies miss.
The configuration of these policies is not the hard part. The hard part is maintaining them as the organization changes — new applications added to the tenant, new devices types introduced, new vendor access requirements. Conditional Access policy drift is a real operational risk.
Operational discipline required: a quarterly policy review, documented, that verifies the policy set still matches the current environment and access requirements.
The Vendor Management Problem
Healthcare organizations work with dozens of vendors who have some level of access to systems containing or adjacent to PHI. Each of those relationships requires a Business Associate Agreement.
The compliance failure mode I’ve seen most often: a vendor relationship exists without a current, signed BAA because the relationship predated the compliance program, or because procurement didn’t understand the BAA requirement when the contract was signed.
The operational fix is process, not technology:
Every new vendor relationship involving access to organizational systems goes through a review that includes: does this vendor have access to PHI? If yes, is a BAA in place? If no BAA exists, the relationship doesn’t proceed until one is executed.
That process needs to exist independently of any individual’s knowledge of the requirement — which means it needs to be documented, communicated to everyone involved in procurement and vendor onboarding, and owned by someone with the authority to stop a vendor relationship that hasn’t met the requirement.
At Premier Health, building that process into the vendor onboarding workflow eliminated the category of risk entirely. The BAA question became automatic, not exceptional.
What Auditors Actually Look For
HIPAA audits — whether OCR audits or third-party assessments — are fundamentally documentation reviews. The auditor wants to see:
- That controls exist. The policies, the configurations, the technical controls.
- That controls are maintained. Access reviews, policy updates, documentation that reflects the current state.
- That incidents were handled appropriately. Documentation of any security incidents, the assessment of whether PHI was affected, and the breach notification decision.
- That training happened. Evidence that employees received HIPAA training and understood their obligations.
The organizations that struggle with audits are usually the ones where controls exist technically but aren’t documented consistently, or where the documentation reflects an earlier state of the environment that doesn’t match what’s actually deployed.
The audit readiness discipline: treat every control change as a documentation event. When a Conditional Access policy changes, document why. When an access review happens, document the results. When a vendor BAA is signed, file it. The documentation burden is light if you do it continuously; it’s overwhelming if you try to reconstruct it before an audit.
The Leadership Dimension
Compliance is ultimately a leadership problem, not a technical one.
Technical controls can be configured correctly and still fail if leadership doesn’t enforce them consistently. If a senior clinical staff member is exempt from MFA because they complained loudly enough, the MFA policy has a hole. If a vendor relationship bypasses the BAA process because a department head wants to move fast, the vendor management process has a hole.
The IT leader’s job is to build the processes, configure the controls, and then hold the line when the organization pushes back — which it will.
The most useful thing I’ve found for holding that line: framing compliance requirements as organizational protection, not IT bureaucracy. The controls exist to protect the organization, the patients, and the staff — not to create friction. When that framing is consistent and credible, the compliance culture develops. When it’s absent, compliance becomes an adversarial relationship between IT and the rest of the organization.
The bottom line: HIPAA compliance in a cloud environment is achievable and maintainable. The technology — M365, Azure, Entra ID — provides the controls. What keeps those controls meaningful is the operational discipline to maintain them, the process to enforce them, and the leadership to make the organization take them seriously.
Get the process right. The technical configuration is the easier part.
Operating Microsoft 365 or Azure in a healthcare environment? The compliance requirements are real, but there are clear patterns that work. I’m happy to talk through specifics.
Discussion
Comments are powered by GitHub Issues via utterances. A GitHub account is required to comment.