Engineers heading into a first healthcare customer often imagine HIPAA as a giant code audit. It is mostly not that. The Security Rule is a set of administrative, physical, and technical safeguards. The bulk of a HIPAA program is risk analysis, policies, workforce, and vendor contracts. Only a slice is decided by what your code does, and knowing which slice makes the whole thing less mysterious.
This page is about that code-facing slice. It is not a covered-entity determination, a BAA, or a promise that heygrc or ISMS Copilot handles ePHI.
The safeguards that touch code
The technical safeguards live in 45 CFR 164.312. The ones that actually change in a pull request are unique user identification (164.312(a)(2)(i)), emergency access (164.312(a)(2)(ii)), automatic logoff (164.312(a)(2)(iii)), encryption and decryption (164.312(a)(2)(iv)), audit controls (164.312(b)), integrity (164.312(c)(1)), person or entity authentication (164.312(d)), and transmission security (164.312(e)(1)). Automatic logoff and encryption/decryption are addressable specifications: implement them where reasonable and appropriate, or document why not and use an equivalent measure. If you can reason about who can reach ePHI, whether activity is recorded, whether it is encrypted at rest and in transit, and whether a change still authenticates the caller, you are reasoning about most of the code-facing surface of the Security Rule.
A lot of what feels HIPAA-ish in engineering lives outside the diff: access reviews, workforce training, a risk analysis, and a signed BAA when the business-associate rules apply (that last one is a required contract, not just evidence that a process ran). The code itself mostly speaks to 164.312.
The changes that become findings
A pull request that logs a full request body containing patient data can put ePHI in a store that more people can read than the system of record. A change that drops encryption on a records store, or that routes every access through a shared service account, is the same class of problem: the safeguard is weaker after the merge than before. Caught at the PR, the author still has the context to fix it. Caught in a customer security review or an investigation, it is a remediation with a paper trail.
That asymmetry is the argument for checking the 164.312 surface at the diff rather than discovering it after a customer asked for evidence.
Where heygrc fits, and the honesty boundary
heygrc is built to recognize those shapes when HIPAA is one of the frameworks you selected, and to cite the safeguard at the clause. It does not determine whether you are a covered entity or a business associate, write your risk analysis, sign a BAA, or store ePHI. Neither heygrc nor ISMS Copilot is a HIPAA business associate for your customer data in this product. Use it as a reviewer of the change, not as a compliance program. Whether HIPAA applies is a different question. See the ISMS Copilot HIPAA applicability checker in further reading.