Appearance
HIPAA Administrative Procedures
Purpose: Document the six Administrative Safeguard procedures required under HIPAA Security Rule §164.308. These procedures implement the policies in compliance/hipaa-policy-set.md and provide the operational steps the workforce follows day to day.
Owner: Rory (designated Security Officer under §164.308(a)(2)) Audience: Workforce (all employees and contractors), auditors, Business Associates Review frequency: Annual (December) and upon material environment change Last reviewed: April 2026
Procedure 1 — Security Management Process (§164.308(a)(1))
Purpose
Establish a continuous cycle of risk identification, risk reduction, workforce accountability, and activity review that reduces the likelihood and impact of ePHI compromise.
Scope
All systems, accounts, and third-party services that create, receive, maintain, or transmit ePHI. This includes Azure PROD (ciriusgroup.com), Azure DDE (ciriusdde.com), all 7 AWS accounts, SharePoint, psql-secops-prod, Cortex XDR, Arctic Wolf, Keeper, and Twingate.
Policy statement
Cirius Group maintains a written security management program. Risks are identified, ranked, mitigated or formally accepted, and the effectiveness of controls is verified on a documented schedule.
Procedures
1.1 Risk analysis (§164.308(a)(1)(ii)(A))
- Monthly penetration testing (Nuclei + Nmap across 9 endpoints) feeds the Cloud Vulnerability Report
- Weekly HIPAA compliance audit email surfaces control drift
- Annual third-party risk assessment (scheduled September, prior to SOC2 audit)
- Every material environment change (new vendor, new subscription, new PHI data store) triggers a targeted risk review recorded in SecOps as a
risk-analysisstory
1.2 Risk management (§164.308(a)(1)(ii)(B))
- Findings from risk analysis become SecOps findings with CRITICAL/HIGH/MEDIUM/LOW priority
- CRITICAL remediated within 7 days, HIGH within 30 days, MEDIUM within 90 days
- Any risk not remediated within SLA is escalated to the Risk Acceptance Register (
compliance/risk-acceptance-register.md) with Rory's written acceptance
1.3 Sanction policy (§164.308(a)(1)(ii)(C))
- Violations documented in SecOps incident with
category=policy-violation - First offense: documented coaching + mandatory refresher training
- Repeated or wilful violations: escalation to termination via HR process
- Sanctions recorded in the employee personnel file and in SecOps incident record
1.4 Information system activity review (§164.308(a)(1)(ii)(D))
- Weekly HIPAA audit email reviewed by Rory each Monday
- Monthly security review per
runbooks/monthly-security-review.md(covers identity, network, endpoint, PAM, credentials, backup, cloud posture, incidents) - Quarterly LPRIV audit per
compliance/annual-review-checklist.md - Annual Arctic Wolf MDR engagement review
Review frequency
Annual. The Security Officer verifies each sub-procedure has produced the expected artifacts in the preceding 12 months. Missing artifacts trigger a remediation plan within 30 days.
Procedure 2 — Assigned Security Responsibility (§164.308(a)(2))
Purpose
Name a single accountable individual for the security of ePHI.
Scope
All ePHI and supporting systems.
Policy statement
Rory is the designated HIPAA Security Officer for Cirius Group. He has authority and accountability for the design, operation, and verification of the Security Rule administrative, physical, and technical safeguards.
Procedures
- The Security Officer designation is recorded in the Business Associate Agreement register and in Cirius Group's HR records
- The Security Officer's contact information is distributed to all workforce members at onboarding via
compliance/onboarding-security-checklist.md - The Security Officer reviews and signs this procedure set annually
- If the Security Officer is unavailable for more than 5 business days, Kevin (T1 Domain Admin, DR) is the documented backup
Review frequency
Annual, or immediately upon personnel change.
Procedure 3 — Workforce Security (§164.308(a)(3))
Purpose
Ensure that only authorized workforce members have access to ePHI and that access is revoked promptly when no longer needed.
Scope
All Cirius Group employees, contractors, interns, and Business Associates who may access ePHI.
Policy statement
Access to ePHI is granted only after appropriate authorization, supervised during the access period, and revoked immediately upon termination or role change.
Procedures
3.1 Authorization and supervision (§164.308(a)(3)(ii)(A))
- New access requests captured as SecOps story with
category=access-request, approver = Rory - Sensitive role access (Global Admin, PIM eligible, break-glass documentation, psql-secops-prod) requires a second approver (Kevin or Greg)
- All privileged sessions recorded in Keeper Security PAM and reviewed monthly
3.2 Workforce clearance (§164.308(a)(3)(ii)(B))
- Background check required before ePHI access is granted
- HIPAA training completion verified (see
compliance/onboarding-security-checklist.md) - Confidentiality and acceptable use policy signed before account creation
3.3 Termination procedures (§164.308(a)(3)(ii)(C))
- Termination trigger (HR notification) opens a SecOps story with 4-hour SLA
- Kobe executes the termination runbook:
- Disable Entra ID account in both tenants
- Remove from all PIM eligible roles
- Revoke all Keeper shared records
- Disable Twingate user
- Expire any active AWS IAM access keys
- Remove from all SecOps and GitHub groups
- Return or wipe issued devices (Intune remote wipe for Windows, AWS SSM revoke for Cloud PC)
- All steps verified and documented in the termination story before close
Review frequency
Annual. Sample five terminations from the preceding 12 months and verify all runbook steps were completed on time.
Procedure 4 — Information Access Management (§164.308(a)(4))
Purpose
Control how workforce members obtain access to ePHI, matching access to job function.
Scope
All applications, directories, databases, and file shares containing ePHI, including SharePoint, psql-secops-prod, FTP customer data stores, and the DDE published application.
Policy statement
Access is granted on a least-privilege, need-to-know basis. Healthcare clearinghouse functions are logically isolated from other operations.
Procedures
4.1 Isolating clearinghouse functions (§164.308(a)(4)(ii)(A))
- DDE (customer-facing Medicare) environment is in a separate tenant (ciriusdde.com) and separate Azure subscription
- VNets are not peered between PROD and DDE
- No shared service accounts between tenants
- Cross-tenant B2B guest access is the only sanctioned path, logged in both tenants' SignInLogs
4.2 Access authorization (§164.308(a)(4)(ii)(B))
- Role-based access model enforced through Entra ID groups and PIM
- New access authorizations captured in SecOps with the approving manager recorded
- No standing access to Global Admin, Privileged Role Admin, or Owner roles — all via PIM eligibility
4.3 Access establishment and modification (§164.308(a)(4)(ii)(C))
- Access changes tracked in SecOps Changes tab
- Quarterly LPRIV audit validates that current access matches the documented baseline in
security/lpriv-baseline.md - Deviations corrected within 10 business days or documented as intentional
Review frequency
Annual access recertification (December). Each workforce member's access reviewed by Rory. Any access not explicitly recertified is revoked.
Procedure 5 — Security Awareness and Training (§164.308(a)(5))
Purpose
Equip the workforce to recognize and respond to security risks that affect ePHI.
Scope
All workforce members at onboarding and annually thereafter. Role-specific modules for IT, finance, and customer-facing staff.
Policy statement
Every workforce member completes security awareness training before receiving access to ePHI and annually thereafter.
Procedures
5.1 Security reminders (§164.308(a)(5)(ii)(A))
- Monthly KnowBe4 phishing simulation
- Quarterly written reminder from the Security Officer (email + SharePoint)
- Targeted reminders after any HIGH or CRITICAL incident involving human factors
5.2 Protection from malicious software (§164.308(a)(5)(ii)(B))
- Cortex XDR behavioral EDR on all Windows VMs and managed devices
- Arctic Wolf MDR provides 24×7 oversight
- Intune compliance policy blocks non-enrolled devices from corporate data
- Training module: "How ransomware gets in" (references Nov 2024 incident)
5.3 Log-in monitoring (§164.308(a)(5)(ii)(C))
- SecOps identity agent detects first-time sign-in from unmanaged device, impossible travel, and credential spray
- Users are encouraged to report unfamiliar MFA prompts immediately to the Security Officer
5.4 Password management (§164.308(a)(5)(ii)(D))
- Entra ID password policy enforced: 14 characters minimum, no reuse of last 24, no common-word dictionary entries
- FIDO2 keys planned for all privileged accounts (in progress — see Risk Acceptance Register)
- Keeper Security for personal privileged credentials (no shared spreadsheets, ever)
Review frequency
Annual curriculum review. Training completion audited quarterly — workforce members who have not completed in-window training are blocked from privileged resources until compliant.
Procedure 6 — Security Incident Procedures (§164.308(a)(6))
Purpose
Detect, respond to, document, and learn from security incidents involving ePHI or systems that process ePHI.
Scope
Any suspected or confirmed security incident, including but not limited to unauthorized access, malware infection, data exfiltration, lost device, social-engineering success, or HIPAA breach.
Policy statement
All suspected security incidents are reported immediately, investigated by the Security Officer, documented in SecOps, contained and eradicated on a defined SLA, and reviewed for lessons learned.
Procedures
6.1 Response (§164.308(a)(6)(ii))
- Detection: SecOps platform, Cortex XDR, Arctic Wolf, Palo Alto, user reports
- Response: follow the role-specific playbook in
runbooks/incident-response.md(Ransomware, Account Compromise, Data Exfiltration, Lost Device, Service Outage) - Containment SLA: P1 immediate, P2 within 1 hour, P3 within 4 hours
- Evidence preservation: do NOT remediate before capturing logs, memory, and endpoint state (Cortex XDR forensic collection if needed)
6.2 Reporting
- All incidents logged in SecOps within 1 hour of detection with
source_systemstamp - Breach-reportable events (unauthorized ePHI disclosure): Security Officer engages Adriana for BAA/breach notification workflow
- Workforce required to report suspected incidents to the Security Officer by phone or SecOps
- External reporting to HHS per §164.408 if PHI breach confirmed (≤60 days for breaches affecting 500+; annually for smaller)
6.3 Post-incident review
- Every P1 or P2 triggers a post-incident review within 10 business days
- Review output: root cause, control gaps, remediation owners, runbook updates
- Findings fed into the threat model (
security/threat-model/threat-model-2026.md) and into next quarter's tabletop scenario - November 2024 incident findings are permanently referenced in
runbooks/incident-response.md
Review frequency
Annual. Procedures tested twice yearly via tabletop exercise (see compliance/ir-tabletop-scenario-2026.md). Findings from each tabletop feed runbook updates within 30 days.
Cross-references
| Procedure | Related policy | Related runbook |
|---|---|---|
| Security Management | hipaa-policy-set.md §1, §8 | monthly-security-review.md |
| Assigned Responsibility | hipaa-policy-set.md §2 | onboarding-security-checklist.md |
| Workforce Security | hipaa-policy-set.md §5, §6 | onboarding-security-checklist.md |
| Information Access | hipaa-policy-set.md §1 | three-layer-access-architecture.md |
| Awareness and Training | hipaa-policy-set.md §7 | onboarding-security-checklist.md |
| Incident Procedures | hipaa-policy-set.md §8 | incident-response.md, ir-tabletop-scenario-2026.md |
Document history
| Date | Change | Author |
|---|---|---|
| April 2026 | Initial draft covering all 6 administrative safeguard procedures | Kobe |