HIPAA Controls Matrix

Purpose

This document maps infrastructure controls to HIPAA Security Rule requirements. It covers Technical and Administrative Safeguards, shows the current implementation status of each control, and identifies where evidence can be found. This document is intended to support audit preparation and ongoing compliance monitoring.

How to Use This Document

Each control entry includes:

• Requirement — the specific HIPAA regulation reference
• Control — what is required
• Implementation — how it is implemented in this environment
• Status — current state of the control
• Evidence — where auditors can find proof the control is operating

Status Definitions

Status	Meaning
✅ Implemented	Control is fully in place and operating
🔄 Partial	Control is partially implemented, work in progress
📅 Planned	Control is planned but not yet implemented
❌ Gap	Control is not in place, risk accepted or being addressed

---

Technical Safeguards (§164.312)

Access Control (§164.312(a))

Requirement	Control	Implementation	Status	Evidence
§164.312(a)(1) — Unique user identification	Each user has a unique identity	Entra ID enforces unique user accounts across all environments	✅ Implemented	Entra ID user directory
§164.312(a)(2)(i) — Emergency access	Emergency access procedure exists	Break-glass account cirius-breakglass deployed across all three domains (ciriusgroup.com, ciriusdde.com, dr.ciriusgroup.internal). Scoped to Administrators group only — removed from Domain Admins, Enterprise Admins, Schema Admins	✅ Implemented	AD group membership, break-glass account documentation
§164.312(a)(2)(ii) — Automatic logoff	Sessions terminate after inactivity	AVD session timeout policies configured in DDE; Conditional Access session controls active in both tenants	✅ Implemented	AVD host pool settings, CA policy config
§164.312(a)(2)(iii) — Encryption and decryption	ePHI encrypted at rest	Azure Disk Encryption on all VM managed disks; storage account encryption; SQL TDE; Key Vault CMK; S3 and EBS encryption in AWS. Full encryption validation completed March 2026	✅ Implemented	Azure portal disk encryption status, S3 bucket policies, encryption validation report
§164.312(a)(2)(iv) — Encryption in transit	ePHI encrypted in transit	TLS 1.2+ enforced for all data transmission. SSL/TLS certificate monitoring with 30/60/90-day expiration alerts operational	✅ Implemented	Palo Alto decryption policy, TLS configuration

Audit Controls (§164.312(b))

Requirement	Control	Implementation	Status	Evidence
§164.312(b) — Hardware/software activity logs	Activity logging on all systems	Azure Monitor, AWS CloudTrail org trail enabled across all environments. Entra ID (9 categories) and Activity Log (4 categories) diagnostic settings active	✅ Implemented	Azure Monitor logs, CloudTrail S3 archive
§164.312(b) — Audit log review	Regular review of audit logs	Weekly HIPAA compliance audit email (ops-automation) surfaces compliance findings. Arctic Wolf MDR actively reviews security events. PIM and privileged access audit runs weekly on Mondays, including 7-day role activation history (who activated which role, duration, justification)	✅ Implemented	ops-automation HIPAA audit email, Arctic Wolf portal, PIM audit workflow
§164.312(b) — Log retention	Logs retained for minimum required period	SIEM-independent 6-year archive deployed across all three environments. Azure Storage with WORM immutability and lifecycle (Hot → Cool 90d → Archive 365d). AWS S3 with Object Lock GOVERNANCE mode (2190-day retention). All log sources wired: DCRs dual-destination (LAW + archive), NSG flow logs to archive, VPC flow logs to Object Lock bucket, all four firewall syslog VMs shipping to archive. AWS CloudTrail org trail with KMS encryption	✅ Implemented	Archive storage Terraform, S3 Object Lock config, Azure WORM policies, DCR diagnostic settings

Integrity (§164.312(c))

Requirement	Control	Implementation	Status	Evidence
§164.312(c)(1) — ePHI integrity protection	Mechanisms to authenticate ePHI	Database integrity enforced at application layer; Veeam backups validated March 4, 2026; Recovery Services Vaults with soft delete and immutability on all vaults	✅ Implemented	Veeam validation report, vault configuration
§164.312(c)(2) — Transmission integrity	Data not altered in transit	TLS with certificate validation enforced for all transmissions	✅ Implemented	Palo Alto SSL policy, TLS configuration

Person or Entity Authentication (§164.312(d))

Requirement	Control	Implementation	Status	Evidence
§164.312(d) — User authentication	Verify identity before granting access	Entra ID MFA enforced for all user accounts. Conditional Access policies active in both tenants (report-only grace period, transitioning to enforce). Maester M365 audit running weekly in both tenants to validate CA posture	✅ Implemented	Entra ID MFA policy, CA policy config, Maester audit reports
§164.312(d) — Service authentication	Automated processes use secure credentials	OIDC federated credentials for GitHub Actions across all three environments and ops-automation repo. No long-lived secrets	✅ Implemented	GitHub Actions workflow files, Entra ID app registrations

Transmission Security (§164.312(e))

Requirement	Control	Implementation	Status	Evidence
§164.312(e)(1) — Transmission security	Protect ePHI during transmission	Palo Alto firewall inspects all traffic across all environments. TLS enforced	✅ Implemented	Palo Alto security policies, network topology docs
§164.312(e)(2)(i) — Integrity controls	Guard against unauthorized modification	TLS with certificate pinning where applicable	✅ Implemented	TLS configuration
§164.312(e)(2)(ii) — Encryption	Encrypt ePHI in transit	TLS 1.2 minimum enforced across all environments. Certificate expiration monitoring active	✅ Implemented	Palo Alto decryption policy, application TLS config

---

Administrative Safeguards (§164.308)

Security Management Process (§164.308(a)(1))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(1)(i) — Risk analysis	Regular risk assessments	Monthly penetration testing (Nuclei + Nmap, 9 endpoints). Weekly vulnerability dashboard. Automated cloud vulnerability report operational	✅ Implemented	ops-automation pen test results, Cloud Vulnerability Report
§164.308(a)(1)(ii)(A) — Risk management	Implement security measures to reduce risk	Checkov HIPAA scanning on all PRs; Azure Policy HIPAA/HITRUST and ISO 27001 active on all subscriptions; AWS Security Hub NIST 800-53 R5 org-wide; AWS Audit Manager HIPAA Omnibus continuous assessment	✅ Implemented	CI/CD pipeline logs, Azure Policy compliance, Security Hub findings
§164.308(a)(1)(ii)(B) — Sanction policy	Consequences for policy violations	HR policy in place at organizational level	✅ Implemented	HR policy documentation
§164.308(a)(1)(ii)(C) — Information system activity review	Review logs and access reports	Weekly HIPAA audit email covering Azure Policy, AWS Security Hub, and GitHub security config. Cortex XDR weekly security report. PIM and privileged access audit weekly	✅ Implemented	ops-automation weekly emails

Assigned Security Responsibility (§164.308(a)(2))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(2) — Security officer designated	Named individual responsible for security	IT/Security role held by sole IT administrator	✅ Implemented	Organizational chart, job description

Workforce Security (§164.308(a)(3))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(3)(i) — Workforce access management	Control workforce access to ePHI	Entra ID RBAC; PIM and privileged access audit weekly — flags permanent assignments, stale accounts >90 days, accounts without MFA, service principals with privileged roles	✅ Implemented	Entra ID access reviews, PIM audit email
§164.308(a)(3)(ii)(A) — Authorization procedures	Process for granting access	Access provisioned through Entra ID	🔄 Partial	Access request process (formalization target: Q2 2026)
§164.308(a)(3)(ii)(C) — Termination procedures	Revoke access upon termination	Entra ID account disable/delete on termination	✅ Implemented	Entra ID offboarding procedure

Information Access Management (§164.308(a)(4))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(4)(i) — Access authorization	Authorize access to ePHI	Role-based access in Entra ID, least privilege enforced. Intune compliance policies enforce BitLocker, Secure Boot, TPM, Defender, OS version, and password requirements on all managed devices	✅ Implemented	Entra ID RBAC assignments, Intune compliance policy
§164.308(a)(4)(ii)(B) — Access establishment	Formal process to grant access	Access provisioned via IT request	🔄 Partial	Access request documentation (pending formalization)
§164.308(a)(4)(ii)(C) — Access modification	Update access when roles change	Managed through Entra ID role reassignment	✅ Implemented	Entra ID audit logs

Security Awareness and Training (§164.308(a)(5))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(5)(i) — Security training program	Train workforce on security policies	Security awareness training conducted	✅ Implemented	Training completion records
§164.308(a)(5)(ii)(B) — Malicious software protection	Protect against malicious software	MDE running in Passive Mode alongside Cortex XDR on all Azure servers. Arctic Wolf MDR active across all environments	✅ Implemented	Intune/MDE console, Cortex XDR console, Arctic Wolf portal
§164.308(a)(5)(ii)(C) — Log-in monitoring	Monitor log-in attempts	Entra ID sign-in logs to LAW + archive. Failed authentication alerting via Arctic Wolf. PIM audit flags accounts without MFA weekly	✅ Implemented	Entra ID sign-in reports, PIM audit email
§164.308(a)(5)(ii)(D) — Password management	Password policies enforced	Entra ID password policies and MFA enforced. Lockout duration standardized to 30 minutes across all three AD domains. AD audit now performs explicit pass/fail checks on all 8 password policy settings: min length ≥ 12, complexity enabled, max age ≤ 90 days, history ≥ 24, min age ≥ 1 day, lockout threshold ≤ 10, lockout duration ≥ 30 min, observation window ≥ 30 min	✅ Implemented	Entra ID authentication policies, AD domain policy, AD audit weekly email

Security Incident Procedures (§164.308(a)(6))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(6)(i) — Incident response policy	Policy for responding to incidents	Incident response runbook covering 5 incident types with severity levels, step-by-step procedures, and HIPAA breach notification requirements	✅ Implemented	Incident Response Runbook
§164.308(a)(6)(ii) — Incident reporting	Report and respond to incidents	Security incidents escalated to IT and leadership	🔄 Partial	Incident log (formalization planned Q2 2026)

Note: A ransomware incident occurred in November 2024. The environment was fully rebuilt following the incident. Lessons learned inform the current security architecture: network segmentation, Palo Alto IPS, DR environment design, MDE Passive Mode alongside Cortex XDR, soft delete + immutability on all backup vaults.

Contingency Plan (§164.308(a)(7))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(7)(i) — Contingency plan	Plan for emergency operations	DR environment exists in AWS, failover procedure documented	✅ Implemented	DR Failover Procedure, AWS DR Overview
§164.308(a)(7)(ii)(A) — Data backup plan	Back up ePHI	Veeam nightly replication to AWS S3 (validated March 4, 2026). Azure Recovery Services Vaults in all subscriptions including DDE	✅ Implemented	Veeam validation report, RSV backup jobs
§164.308(a)(7)(ii)(B) — DR plan	Restore operations after disaster	DR failover procedure documented, DR test scheduled June 2026	✅ Implemented	DR Failover Procedure
§164.308(a)(7)(ii)(C) — Emergency operations	Continue operations during emergency	AWS DR environment ready to receive workloads	✅ Implemented	AWS DR Overview, EC2 instance inventory
§164.308(a)(7)(ii)(D) — Testing and revision	Test contingency plans	DR test scheduled June 2026 and October 2026	📅 Planned	DR test plan (April 2026)
§164.308(a)(7)(ii)(E) — Applications criticality	Prioritize applications for recovery	Database servers identified as critical — first to restore in DR	✅ Implemented	DR Failover Procedure

Evaluation (§164.308(a)(8))

Requirement	Control	Implementation	Status	Evidence
§164.308(a)(8) — Periodic technical evaluation	Regular security evaluations	Monthly penetration testing (Nuclei + Nmap); Maester M365 weekly audit in both tenants; Weekly HIPAA compliance audit email; Cortex XDR weekly; Checkov continuous IaC scanning	✅ Implemented	ops-automation scheduled outputs, Maester reports, Checkov CI/CD logs

---

Summary Dashboard

Technical Safeguards

Status	Count
✅ Implemented	12
🔄 Partial	0
📅 Planned	0
❌ Gap	0

Administrative Safeguards

Status	Count
✅ Implemented	19
🔄 Partial	3
📅 Planned	1
❌ Gap	0

---

Known Gaps and Remediation Plan

Control	Gap	Remediation	Target
Audit log review	Formal documented review schedule not yet established	Create log review runbook	Q3 2026
Access request process	Informal process only	Formalize and document	Q2 2026
DR test	Not yet tested	Execute DR test	June 2026
GitHub and Intune audit logs	Not archived beyond default platform retention	Export to archive storage	Q2-Q3 2026

---

Document History

Date	Change	Author
April 2026	§164.312(b) audit log review: added PIM activation history (7-day window added to weekly PIM audit). §164.308(a)(5)(ii)(D) password management: added explicit list of 8 password policy checks now enforced by AD audit script	Kobe
March 2026	Updated break-glass to Implemented (cirius-breakglass deployed across all three domains, Administrators-only scope); updated log retention to Implemented (archive fully wired across all environments); updated audit log review to Implemented (weekly HIPAA audit email + PIM audit operational); updated malicious software to Implemented (MDE Passive Mode complete); updated contingency plan backup to Implemented (DDE vaults deployed, Veeam validated); added Intune compliance and Maester references; recalculated Summary Dashboard	Rory
March 2, 2026	Fixed log retention status, updated incident response to Implemented, recalculated counts	Rory
March 2026	Initial draft	Rory

Related Documentation

• CI/CD Pipeline Overview
• Checkov HIPAA Scanning
• Logging Architecture
• Azure Infrastructure Overview
• AWS DR Overview
• Palo Alto Firewall Overview
• Backup Architecture
• DR Failover Procedure