HIPAA does not certify a technology stack. It defines outcomes, and covered entities are responsible for implementing the safeguards inside the tools they choose. This page maps the HIPAA Security Rule Technical Safeguards (and the technical pieces of the Administrative and Physical Safeguards) onto the specific Microsoft 365 tenant settings, Conditional Access policies, Intune policies, and Defender configurations that satisfy them.
Free to read, no email required. This is not legal advice. A Business Associate Agreement and a documented risk analysis are still required, and your covered-entity counsel is the source of truth for what your organization needs.
§164.312 Access Control, Audit Controls, Integrity, Person or Entity Authentication, Transmission Security.
The technical pieces of §164.308 (activity review, incident response) and §164.310 (workstation security, device wipe).
Each item maps to an exact admin path or PowerShell line. Paraphrased control titles. CIS, NIST, and CISA cross-references in the Veri-Tech registry.
The HIPAA Security Rule (45 CFR Part 164, Subpart C) sets three categories of safeguards: Administrative, Physical, and Technical. Each category lists required and addressable specifications. Required means you must implement it. Addressable means you implement it, document a reasonable equivalent, or document why neither is reasonable and appropriate. Addressable is not optional.
For a Microsoft 365 covered entity, the Technical Safeguards section is where most of the audit conversation happens. It defines unique identification, emergency access, automatic logoff, encryption, integrity verification, authentication, and transmission security. Microsoft 365 has native settings or services that satisfy each one. The challenge is wiring them all up at the same time and proving it on demand.
The checklist below organizes the controls by HIPAA section. Each item lists what the control does and the specific tenant setting that implements it. Controls in the Veri-Tech HIPAA coverage scope are paraphrased from our control registry. The registry cross-maps every HIPAA control to CIS, NIST 800-53, CISA SCuBA, and SOC 2, so a single tenant scan covers all of them at once.
The Security Rule requires unique user identification, emergency access procedures, automatic logoff, and verification that the person or entity touching ePHI is who they claim to be. In Microsoft 365 these land as Conditional Access policies, MFA configuration, and session controls.
A Conditional Access policy that blocks all legacy authentication protocols (SMTP AUTH, IMAP, POP, older Exchange ActiveSync) at the tenant edge.
Entra admin center, Conditional Access, New policy. Cloud apps = All. Conditions, Client apps = Exchange ActiveSync clients + Other clients. Grant = Block. Roll out report-only for 24 hours, address service accounts, then enable.
A Conditional Access policy that requires MFA when Identity Protection scores a sign-in as risky, satisfying the unique-identification and authentication requirements.
CA, New policy, Users = All, Cloud apps = All, Conditions, Sign-in risk = Medium and High. Grant = Require multifactor authentication. Requires Entra ID P2 license.
A documented break-glass account, FIDO2-bound, excluded from every CA policy so a misconfigured policy cannot lock the entire tenant out.
Create two cloud-only break-glass accounts with FIDO2 keys. Add them to a security group named "Break-Glass Exclusions." Add that group to the Excluded users field of every CA policy. Monitor sign-ins on those accounts via Sentinel or alert policy.
A Conditional Access session control that forces reauthentication on a defined cadence, satisfying the automatic logoff requirement.
CA policy, Session controls, Sign-in frequency = 8 hours for users (or org-defined value), Persistent browser session = Always persistent (corporate device) or Never persistent (personal device).
HIPAA requires that you record and examine activity in systems that contain ePHI, and that information system activity is reviewed regularly. In Microsoft 365 the foundation is the Unified Audit Log, mailbox auditing, and Exchange Admin auditing, with logs retained long enough to support investigation.
The tenant-wide audit log that captures admin actions, user activity, mailbox access, file access, and Defender events. Off by default in some legacy tenants.
Microsoft Purview, Audit, Start recording user and admin activity. Or PowerShell: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true.
Audit log retention extended past the default to a duration that supports incident investigation. HIPAA does not specify a retention period directly, but 90 days is the floor most regulators expect.
Purview, Audit, Audit retention policies, Create policy. Set retention to 1 year (E5 / Audit Premium) or use the default 90-day baseline at minimum. Consider exporting older logs to long-term storage.
Per-mailbox auditing turned on so mailbox access, item touch, send-as, and admin actions are written to the audit log.
PowerShell: Set-OrganizationConfig -AuditDisabled $false. Per-mailbox state defaults to enabled once the org-wide flag is on. Verify with Get-Mailbox | Select Identity, AuditEnabled.
Entra ID sign-in and audit logs streamed to Microsoft Sentinel, a third-party SIEM, or an Azure Storage account. The portal log retention is too short for HIPAA review cadence.
Entra admin center, Diagnostic settings, Add diagnostic setting. Send AuditLogs and SignInLogs to Log Analytics workspace, or to a Storage account with one-year retention.
The Security Rule lists encryption as an addressable specification for both stored and transmitted ePHI. In Microsoft 365 this is sensitivity labels with encryption, Office Message Encryption, DKIM and SPF for mail authentication, and TLS for inbound and outbound mail flow.
Microsoft Purview sensitivity labels that apply encryption (Azure Rights Management) to documents and emails marked as ePHI or Confidential.
Purview, Information protection, Labels. Create or enable the Confidential / Highly Confidential labels with Encryption = Apply. Publish via a labeling policy to relevant users. Train end users on the Sensitivity ribbon button.
OME enabled so external recipients receive encrypted email through a viewing portal or via attached encrypted message.
Verify Azure Information Protection is provisioned: Get-IRMConfiguration. Enable OME templates. Publish a mail flow rule (Exchange Admin Center, Mail flow, Rules) that applies the Encrypt template to messages tagged with sensitive content.
DomainKeys Identified Mail signing turned on for every accepted email domain in the tenant, with the two CNAMEs published in DNS.
Defender admin center, Email and collaboration, Policies and rules, Threat policies, Email Authentication, DKIM. Enable signing for each domain. Publish the two CNAME records (selector1, selector2) at your DNS provider.
Exchange Online connectors that enforce opportunistic or required TLS for inbound and outbound mail with partners.
Exchange admin center, Mail flow, Connectors. For partners that require TLS, set the connector to Always use TLS and validate the partner certificate (issued by a trusted CA matching the partner domain).
The Security Rule requires mechanisms to confirm that ePHI is not altered or destroyed in unauthorized ways. In Microsoft 365 the relevant controls are document versioning, retention policies, and the audit trail that supports forensic review of changes.
Versioning turned on across SharePoint and OneDrive document libraries so historical versions of any file are retained and recoverable.
SharePoint admin center, Sites, select site, Settings, Site settings, Versioning settings. Major versions = 100, Minor versions on as needed. Or set tenant-wide via SharePoint Online Management Shell: Set-SPOSite ... -EnableVersioning $true.
The Physical Safeguards rule covers workstations and removable media. In Microsoft 365 these are technical: Conditional Access requires compliant devices, Intune compliance policies enforce encryption, and device wipe capability lets you respond to lost or stolen hardware.
An Intune compliance policy that flags any device without disk encryption (BitLocker on Windows, FileVault on macOS, native on iOS) as non-compliant.
Intune admin center, Devices, Compliance policies. For Windows: System Security, Encryption of data storage on device = Require. For macOS: Device Health, Require encryption of data storage = Require. Pair with a CA policy requiring compliant devices.
A Conditional Access policy that requires Microsoft Intune compliance, hybrid Entra join, or both as a grant condition for accessing M365.
CA, New policy, Users = All, Cloud apps = Office 365. Grant = Require device to be marked as compliant + Require Hybrid Azure AD joined device (any of the selected). Enforce only after the compliance policy above is reporting cleanly.
Intune wipe action available on every managed device (full wipe for corporate, selective MAM wipe for personal).
Intune admin center, Devices, All devices. Verify Wipe action is available per device. For BYOD, App protection policies wipe just the corporate data when triggered. Document the runbook in your incident response plan.
Administrative Safeguards include log-in monitoring and security incident procedures. In Microsoft 365 these align to Identity Protection risk detection, Defender alert policies, and Purview alerts that trigger on data movement and admin activity.
Out-of-the-box alert policies enabled across Purview (DLP matches, eDiscovery activity) and Defender (admin operations, anomalous sign-ins, malware detections).
Purview, Solutions, Audit and Alert. Verify the default alert policies are in Active state. Enable email notification to security operations distribution group. Optionally route alerts to your SIEM via Microsoft Sentinel connector.
Entra ID Identity Protection actively monitoring user-risk and sign-in-risk signals, with alerts sent to security operations.
Entra admin center, Identity Protection, Notify, Users at risk detected alerts. Configure recipient list. Pair with the user-risk and sign-in-risk Conditional Access policies for automatic remediation.
The Veri-Tech HIPAA Pack is a 67-control framework registered in the same engine as our CIS, NIST, ISO 27001, and SOC 2 coverage. When a tenant is licensed for the HIPAA Pack, the Veri-Guard scan runs the HIPAA control set in addition to the others, generates a HIPAA-specific compliance report, and produces remediation runbooks scoped to the HIPAA Security Rule sections.
Coverage means the engine can read the relevant tenant state (audit log status, CA policy presence, Intune compliance conformance, sensitivity label deployment), score it against the HIPAA Pack, and generate a runbook for any failing control. It does not replace the Business Associate Agreement, the organizational risk analysis, or the legal review your covered entity counsel signs off on. Veri-Tech provides a BAA for customers on the HIPAA Pack tier.
The checklist on this page is a subset of the full HIPAA Pack and is publicly available. It is a useful starting point even for organizations that are not Veri-Tech customers.
The high-impact M365 controls as a printable PDF, plus full remediation runbooks generated by the same engine that runs HIPAA scans.
Open ResourcesWalk through Veri-Guard, Veri-Tune, Veri-Vault, and Veri-Docs against a populated demo tenant. The HIPAA-specific demo is on the way.
Open the demoThirty minutes with William. HIPAA readiness, BAA review, or where to start in your tenant if regulators are knocking.
Book a call