Read this first
GitHub's terms of service prohibit PHI on GitHub.com. If you have ePHI in code today — hardcoded patient records in test fixtures, real patient names in commit messages, attached screenshots — you are out of compliance regardless of how locked-down your branch protection is. Step 1 of any GitHub-and-HIPAA conversation is removing the PHI, then signing a BAA with a host that will sign one.
The six-step checklist
1.Confirm you have (or do NOT need) a BAA with GitHub
GitHub does NOT sign Business Associate Agreements for the standard GitHub plan. If your code repo handles PHI (e.g. you commit test data with real patient data, store ePHI in attachments, or use GitHub Issues to discuss patient records), you are out of HIPAA compliance the moment that data enters GitHub. Either move that data out of GitHub entirely, or use a HIPAA-eligible Git host (e.g. AWS CodeCommit with a signed BAA, or self-hosted GitLab on HIPAA-eligible infrastructure).
2.Kill secrets in git history — they are PHI exposure vectors
A leaked database password gives a malicious actor live PHI access. Enable GitHub secret scanning (paid GHAS on private repos), set up Dependabot, and add a pre-commit hook (gitleaks) so secrets never enter history. Rotate anything that has ever been committed.
3.Branch protection that satisfies §164.312(a)(1)
Require PRs to main, require signed commits, require status checks (CI build + tests), block force-push and deletion, and require at least one approving review for any change to code that touches ePHI flows. HIPAA's access-control standard maps directly to this branch hygiene.
4.Audit log everything that mutates production
GitHub's audit log retains who merged what for the enterprise plan. For HIPAA §164.312(b), pipe the audit stream to a SIEM or tamper-evident store and retain for 6 years (HIPAA's general retention minimum).
5.Lock down GitHub Actions secrets and runners
Restrict Actions to verified marketplace + your own org. Use environment-scoped secrets, not repo-level. If a workflow touches production ePHI systems, require manual approval gates and run on a self-hosted runner you control (not GitHub-hosted) so the network path is auditable.
6.Workforce access reviews and offboarding evidence
HIPAA §164.308(a)(3) requires you to terminate access when a workforce member leaves. Quarterly access reviews of every GitHub team membership, with a signed attestation, satisfy this. KollGuard's personnel register tracks the dates.
HIPAA Security Rule mapping
| HIPAA citation | Safeguard | GitHub enforcement |
|---|---|---|
| §164.308(a)(3) | Workforce access | Team membership reviews + signed offboarding |
| §164.308(a)(5) | Security training | Tracked in KollGuard personnel register |
| §164.312(a)(1) | Access control | Branch protection + 1+ approving review |
| §164.312(b) | Audit controls | GitHub Enterprise audit log piped to SIEM, 6yr retention |
| §164.312(c) | Integrity | Required signed commits + force-push protection |
| §164.312(e)(1) | Transmission security | HTTPS-only push/pull (default; verify) |
Frequently asked
- Can I store PHI in a private GitHub repository?
- No, not on GitHub's standard SaaS plan. GitHub does not sign a BAA for GitHub.com. Even if you mark the repo private, GitHub's terms forbid PHI. You can use GitHub Enterprise Server (self-hosted) on HIPAA-eligible infrastructure with a BAA from the underlying cloud provider.
- Does GitHub Copilot create a HIPAA problem?
- If Copilot can read code that contains PHI (in comments, test fixtures, or hardcoded values), yes — your code is being processed by a third-party model without a BAA. Either disable Copilot for those repos, scrub the PHI before turning Copilot on, or use Copilot Enterprise with the data-handling controls your compliance team has reviewed.
- What HIPAA Security Rule sections apply to code hosting?
- Primarily §164.308 (Administrative Safeguards — workforce access, training), §164.312(a)(1) (Access Control), §164.312(b) (Audit Controls), §164.312(c) (Integrity), and §164.312(e)(1) (Transmission Security). Repo hygiene, branch protection, audit logs, signed commits, and TLS-only access cover most of these.
- Does KollGuard scan for PHI in source code?
- KollGuard scans for secrets (which are PHI exposure vectors), risky branch-protection settings, and missing audit signals. We do not currently scan source code line-by-line for PHI strings — that's a different problem (and risk) and we recommend keeping test data PHI-free at ingestion time rather than scanning to detect leaks after the fact.