Update HIPAA policies for 2026

[tbrownio]

Summary

Updates the HIPAA policy repository for the 2026 review cycle, focusing on BAA timeline consistency, Part 2 handling, shared responsibility language, subprocessors, audit logging, and retention verification TODOs.

Work Completed

1. Immediate HIPAA Policy Cleanup

• Standardized customer-facing BAA notice timelines for breaches, successful security incidents, and improper non-breach PHI uses/disclosures to ten business days.
• Preserved stricter downstream/subcontractor BAA reporting timelines so BloomAPI keeps operational notice buffer.
• Replaced the stale HIPAA inheritance document with a BloomText shared responsibility matrix.
• Added Part 2 SUD records policy coverage and updated related definitions, incident, breach, vendor, access, and control-mapping language.
• Added a subprocessor summary for GCP/Cloud Armor, Sentry, PostHog, and self-hosted Grafana with cautious PHI/Part 2 approval status.
• Updated audit logging and data retention policies to describe current log sources and list verification TODOs instead of unsupported retention claims.
• Updated infrastructure wording to reflect the current Google Cloud/Cloud Armor stack without listing brittle obsolete technologies.

2. Future HIPAA Program Expansion Plan

• Added a ready-plan for future evidence-backed expansion covering log inventories, vendor review, customer onboarding classification, access reviews, incident evidence, and customer-facing compliance artifacts.

Pre-Merge Testing

• git diff --check passes
• Local markdown link check passes
• No-overclaim scan reviewed
• Stale BAA timeline scan reviewed
• Secret-pattern scan reviewed before commit

Build Verification

• Docs-only repository; no app build applicable
• No schema changes

Notes

• Existing signed agreements remain governed by their executed terms unless amended in writing.
• Remaining retention/vendor/configuration facts are intentionally tracked as TODOs for counsel and operational verification before stronger claims are published.

[tbrownio]

PR Review

Issue context: No linked issue in the PR body. I reviewed this as a policy/BAA consistency update for the 2026 HIPAA review cycle.

GitHub would not allow me to submit this as “request changes” because this PR is authored by the same account. Treat the Must-Fix item below as blocking before merge.

Quality Gates

• git diff --check: PASS
• Local markdown link check for repository-relative links: PASS
• App typecheck/lint: N/A, docs-only policy repository with no package/build config found

Must-Fix (1)

1. vulnerability_scanning_policy.md:17-18 overstates current controls. The policy now says authenticated production vulnerability scanning happens at least every six months and annual penetration testing is performed. Tyler confirmed regular penetration testing and external risk assessments are not currently performed, and the supported current-state answer is Snyk scanning. Please either remove these as completed controls or move them into a clearly labeled planned/future control section. Also update hipaa_mapping_to_bloomapi_controls.md:58 if penetration testing is not a current control.

Should-Fix (2)

1. systems_access_policy.md:43 and systems_access_policy.md:99 introduce quarterly privileged/production/ePHI access reviews, while the existing policy baseline and current questionnaire evidence support annual access review. If quarterly review is not already operating with evidence, this should stay annual or be marked as a target/TODO.
2. data_management_policy.md:31-32 adds annual backup restore testing and annual RPO/RTO documentation review as completed requirements. That may be a good control, but it should not be represented as already in force unless there is evidence. Given backup retention and Cloud Storage backup details are still being verified, consider moving these to a verification/TODO section or softening them to intended procedure.

Suggestions (1)

1. README.md:3-5 still says the policies have been through two HIPAA audits and one HITRUST audit. Because current customer questionnaires ask about current certifications/external assessments and Tyler confirmed those are not current controls, consider clarifying whether this is historical/template provenance rather than current BloomAPI certification or assessment status.

Summary

The BAA notification timeline cleanup and the move from “inheritance” to shared responsibility are directionally good and reduce several old overclaims. The remaining blockers are current-state claims around penetration testing, scan cadence, quarterly access review, and backup/RPO evidence. I would not merge until those are either verified or rewritten as planned/TODO controls.