"We follow least privilege for PHI access" is the easiest HIPAA claim to make and among the hardest to prove. When the auditor — OCR after an incident, a hospital customer's security team, a HITRUST assessor — asks development leaders to demonstrate it, they don't want the policy; they want evidence that access to PHI-relevant systems is scoped to need, granted through governed process, reviewed on cadence, and observable per change. For dev teams, that proof spans identity systems, deployment permissions, and the release workflow — and assembling it retroactively is the archaeology that makes HIPAA audits dreaded. This step-by-step shows how to make the proof standing instead.
Least privilege starts as design: roles scoped to actual need, with PHI-relevant capabilities (production access, data export, deployment to ePHI systems) isolated in roles that few hold. In the delivery workspace, role and permission management defines who can develop, approve, deploy, and administer per area — and because it's data, "who could touch the clinical service" is a query, not an interview. Document the role-to-need rationale once; it becomes the map every auditor reads first.
Every elevation — a new grant, a temporary production access, an emergency break-glass — should ride the same governed workflow as a production change: a structured request with justification, policy-executed approval recording who authorized it and in what role, and an expiry where the need is temporary. Grants governed this way produce their own evidence; grants handled in chat produce the finding.
Access reviews are where least privilege is maintained — and where audits probe for theater. Run them on cadence with outcomes recorded as work: revocations as tracked items under SLA policies, closures with verification. The review evidence auditors credit shows decisions and follow-through, not a spreadsheet of checkmarks.
The layer identity tooling can't see: what access was actually exercised in delivery. Release-linked records supply it — every change to ePHI-relevant systems carries who developed, who approved (with role and timestamp), and who deployed, with CI/CD integrations binding the deployment identity. When the auditor asks "show me this engineer's production touches this quarter" or "who approved changes to the PHI store in March," the Release Compliance Dossier answers from records. This per-change context is also your segregation-of-duties proof — the adjacent control every HIPAA-plus-SOC-2 audit samples.
Quarterly, audit yourself both ways. By system: pick an ePHI service; produce current access with role rationale, last review with outcomes, and the quarter's changes with their approval/deploy identities. By person: pick an engineer; produce their grants, justifications, and exercised access across releases. Time both. Minutes means your least-privilege story will hold under any examiner; anything requiring memory is the gap to close this sprint. Compliance objectives mapping these records to the Security Rule keep the posture visible between drills.
Proving PHI least privilege is a four-layer evidence problem: designed roles, governed grants, real reviews, and exercised-access records per change. Build the layers into the delivery workflow and the dreaded audit question becomes a filtered query — the difference between claiming least privilege and being able to show it, on demand, in either direction.
Four layers: roles scoped to documented need, grants issued through governed workflows with recorded approvals, access reviews with evidenced outcomes, and per-change records showing what access was actually exercised in delivery.
Both directions: by system (who has access to this ePHI service, with what justification and review history) and by person (this engineer's grants, and the production access they exercised across releases).
Identity tools show who could act; they can't show who approved and deployed each change to PHI systems. Release-linked approval and deployment records supply the exercised-access evidence — and double as segregation-of-duties proof.
Quarterly, audit yourself both ways: one ePHI system's access, reviews, and quarterly changes with identities; one engineer's grants and exercised access. Minutes per query means the story holds under any examiner.