HIPAA Security Rule
HIPAA Security Rule coverage
How LockList's Microsoft 365, Google Workspace, GitHub, AWS, Azure, and NinjaOne checks map to the HIPAA Security Rule (45 CFR Part 164), the Administrative, Physical, and Technical Safeguards that covered entities and business associates must implement to protect electronic protected health information (ePHI).
Technical safeguards evidence, not a HIPAA audit. LockList evidences workspace configuration controls relevant to the Technical and Administrative Safeguard requirements. A full HIPAA compliance programme also requires policies, risk analysis, training, physical safeguards, and BAAs. Use this to focus remediation; confirm scope with your privacy officer or counsel.
| Safeguard | What LockList assesses |
|---|---|
| 164.312(a)(1)Access control | Unique user identification via admin role assignments and directory role membership; emergency access procedures (privileged role inventory); MFA for admins and all users as an automatic logoff/authentication safeguard. |
| 164.312(d)Person or entity authentication | MFA registration coverage and methods (M365); 2-Step Verification coverage and admin enrollment (Google); legacy authentication blocking to prevent credential bypass. |
| 164.312(b)Audit controls | Sign in log and directory audit log accessibility (M365); login and admin audit log accessibility (Google), evidencing that activity logs for systems handling ePHI are enabled and accessible; activity log accessibility (NinjaOne). |
| 164.312(e)(1)Transmission security | SharePoint/OneDrive external sharing posture and external email auto forwarding, detecting unencrypted or uncontrolled ePHI transmission paths. |
| 164.308(a)(1)Security management process | Microsoft Secure Score and Defender / email security licensing posture as part of an ongoing risk management baseline; risky user detection via Identity Protection; OS patch status, open alerts, and stale / offline agents (NinjaOne). |
| 164.308(a)(3)Workforce security | Suspended and dormant account review; guest privilege review, ensuring workforce access is terminated or modified appropriately. |
| 164.308(a)(4)Information access management | Privileged role assignments, PIM (just in time) usage, and Conditional Access policy coverage, enforcing minimum necessary access to systems that may process ePHI. |
| 164.308(a)(5)Security awareness & training | App registrations with high risk Graph permissions, flagging third party apps that may represent unvetted access to organisation data; antivirus coverage across managed endpoints (NinjaOne). |
| 164.310(d)Device & media controls | Intune device management coverage and non compliant device count, relevant to controlling physical access to devices that handle ePHI; RMM device inventory and agent coverage (NinjaOne). |
GitHub
The GitHub connector assesses code platform controls relevant to HIPAA where source code repositories handle or process ePHI adjacent systems.
| Safeguard | What the GitHub connector assesses |
|---|---|
| 164.312(a)(1)Access control | Org wide 2FA enforcement, SAML SSO, and admin/member role review, ensuring only authorised personnel access repositories containing ePHI related code or configuration. |
| 164.312(b)Audit controls | Secret scanning and push protection, detecting committed credentials or secrets that could provide unauthorised access to ePHI systems. |
| 164.308(a)(4)Information access management | Deploy key inventory and outside collaborator access review, enforcing minimum necessary access to production critical repositories. |
| 164.308(a)(1)Security management process | Default branch protection rules, ensuring code changes to ePHI processing systems go through a review process before deployment. |
Every finding in your LockList Report carries its HIPAA safeguard reference alongside SOC 2, ISO 27001, CIS, HITRUST CSF, and CMMC 2.0 mappings. Run a free assessment →