Docs

Appearance

HIPAA Physical Safeguards — §164.310 ​

Purpose: Document Cirius Group's implementation of HIPAA Physical Safeguards under 45 CFR §164.310.

Owner: Rory (Security Officer) Audience: Rory, auditors, Business Associates Review frequency: Annual (December) Last reviewed: May 2026

Environment Context ​

Cirius Group is a fully cloud-native, remote-first organization. There is no owned or leased data center. All ePHI lives in Azure (PROD tenant ciriusgroup.com, DDE tenant ciriusdde.com) and AWS (7-account organization). Physical security for the underlying infrastructure is delegated to Microsoft and Amazon under their respective Business Associate Agreements, both of which include SOC2 Type II attestation covering physical security controls.

Physical safeguard obligations for Cirius primarily cover workstations and managed devices — the endpoints the workforce uses to access ePHI systems.

§164.310(a)(1) — Facility Access Controls ​

Applicability: Not applicable to Cirius-owned facilities (none exist).

Cloud provider coverage: Microsoft Azure and AWS provide physical facility security for the data centers hosting Cirius ePHI. Both providers:

  • Maintain SOC2 Type II reports covering physical access controls (multi-factor badge access, 24/7 guards, CCTV)
  • Execute Business Associate Agreements with Cirius covering HIPAA obligations. BAAs stored in SharePoint → Legal/BAA Folder (Adriana manages)
  • Publish Infrastructure Security and Compliance documentation referenced during audits

Contingency access: Physical access to production systems during a disaster is not required. Recovery operations proceed via Twingate (primary), GlobalProtect (CEO/CTO), and AWS Systems Manager (SSM) for break-glass SSH — all remote.

§164.310(a)(2)(i) — Contingency Operations ​

All contingency procedures are remote. Physical access to a data center is not part of any Cirius DR or BCP procedure. See:

  • aws/dr-failover-procedure.md — DR failover to AWS
  • runbooks/break-glass-procedure.md — break-glass remote access
  • runbooks/out-of-band-comms-plan.md — communications if primary systems are unavailable

§164.310(a)(2)(ii) — Facility Security Plan ​

No owned facilities. Workforce is fully remote.

ePHI is not stored on local workstations. Azure Virtual Desktop (DDE environment) ensures that DDE-environment ePHI remains in the cloud tenant and never lands on the endpoint device. PROD environment access is through browser-based SaaS (M365, Azure Portal) or Twingate-tunneled connections — no local data caching.

Remote workforce ePHI handling policy: workforce members may access ePHI systems from home offices and remote locations. The following physical controls apply to any location where ePHI is accessed on screen:

  • Screen must not be visible to unauthorized individuals
  • Lock screen or close laptop immediately when leaving the workstation unattended
  • Do not access ePHI systems from public locations (coffee shops, airports) without a privacy screen

§164.310(a)(2)(iii) — Access Control and Validation ​

No colocation or co-managed data center facilities are currently in use. If Cirius were to place equipment in a colocation facility in the future, the following controls would apply:

  • Biometric or MFA badge access
  • Authorization from Rory required for all access
  • Access log maintained and reviewed quarterly
  • Escort policy for visitors

This section is forward-looking only. No action required under current architecture.

§164.310(a)(2)(iv) — Maintenance Records ​

Infrastructure: Cloud infrastructure maintenance is handled by Microsoft and AWS. Maintenance records are not held by Cirius for cloud resources. Azure and AWS provide audit logs of all platform maintenance events via Azure Activity Log and AWS CloudTrail respectively.

Managed devices: Hardware maintenance for workforce workstations is tracked in Intune (device compliance history, OS update status). Physical repairs to company-owned hardware are logged in Intune notes by Rory.

§164.310(b) — Workstation Use ​

All managed workstations are enrolled in Intune and subject to the following controls:

ControlImplementation
EnrollmentIntune — all managed devices
Endpoint protectionCortex XDR on all Windows VMs and managed devices
Network accessTwingate required for ePHI system access
Auto-lock15-minute idle screen lock enforced via Intune policy
Full disk encryptionBitLocker (Windows), FileVault (Mac) enforced via Intune
USB storageBlocked via Intune policy — see runbooks/intune-usb-storage-block.md
Remote wipeAvailable via Intune for any managed device

Workstations must be used only in private spaces when ePHI is on screen. Clean desk policy: no ePHI visible when the workstation is unattended, even in a home office.

§164.310(c) — Workstation Security ​

Physical workstation security requirements for all workforce members:

  1. Workstations used to access ePHI must be in a location where unauthorized individuals cannot view the screen
  2. Screen lock immediately when stepping away — Windows key + L (Windows) or Control + Command + Q (Mac). Auto-lock provides a backup
  3. No ePHI is to be printed unless absolutely necessary. Printed ePHI must be shredded immediately after use (cross-cut shredder)
  4. Laptop screens must not face public areas, windows, or shared spaces during ePHI work
  5. Shared household members are not permitted to use workforce devices

§164.310(d)(1) — Device and Media Controls: Policy ​

All devices that store or access ePHI must be enrolled in Intune before use. Personal devices (BYOD) are permitted only for accessing M365 via browser with Intune-enforced MAM policies — no local ePHI storage allowed on BYOD.

Lost or stolen devices:

  1. Notify Rory immediately
  2. Rory triggers remote wipe via Intune: Devices → [device] → Wipe
  3. Revoke device's Entra token: Entra → Users → [user] → Revoke sessions
  4. Document in SecOps as an informational incident (category: device-loss)
  5. Assess whether ePHI was stored locally (it should not be) — if yes, initiate breach risk assessment per compliance/hipaa-breach-notification-procedure.md

§164.310(d)(2)(i) — Disposal ​

Workstations must be wiped before disposal or reassignment.

Wipe procedure:

  1. In Intune: Devices → [device] → Wipe (full wipe, not retire). Confirm wipe completes
  2. If Intune wipe fails (device offline): use manufacturer recovery mode to factory reset
  3. Verify: device no longer appears in Intune enrollment or shows as Unenrolled
  4. Document disposal in SecOps with device serial number, wipe method, and date

For NIST 800-88 compliance, Intune full wipe is the standard method for SSDs and flash storage. Spinning disk HDDs require additional cryptographic erasure or physical destruction.

§164.310(d)(2)(ii) — Media Re-use ​

Before any managed device is reassigned to another user:

  1. Perform Intune full wipe (factory reset)
  2. Re-enroll the device under the new user's Intune profile
  3. Do not reassign a device without confirming the prior user's data is fully erased

§164.310(d)(2)(iii) — Accountability ​

Device inventory (source of truth): Intune — all enrolled managed devices with owner, serial number, last check-in, compliance status.

CMDB cross-reference: security/cmdb-guide.md. Intune is authoritative for device inventory; CMDB is authoritative for server/VM inventory.

All devices are tagged with the assigned owner. Unassigned devices must not be in use. Annual device audit (January) reconciles Intune inventory against expected devices.

§164.310(d)(2)(iv) — Data Backup and Storage (Physical) ​

Not applicable at the physical layer — backup is handled entirely in cloud:

  • Azure workloads: Veeam backup to AWS S3 (Backup account 863609217450) and Azure Recovery Services Vaults
  • AWS workloads: AWS Backup and S3 versioning
  • PostgreSQL: automated backups in Azure Database for PostgreSQL

See runbooks/backup-architecture.md for full backup topology.

  • compliance/hipaa-administrative-procedures.md
  • compliance/hipaa-controls.md
  • runbooks/intune-usb-storage-block.md
  • runbooks/employee-offboarding.md
  • runbooks/break-glass-procedure.md
  • security/cmdb-guide.md

Internal use only — Cirius Group