Skip to content
Sign inBook an audit pilot
Open menuClose menu

Control map · 45 CFR Part 164

HIPAA

8 of 8 HIPAA controls code can evidence, with v1.4.0, plus 4 supporting

Code evidence for the technical safeguards and the Privacy Rule’s use and disclosure requirements, where they live in code.

  • Live8
  • Coming in v1.4.00
  • Supporting4
  • Planned0
  • Your organisation30
  1. 8 with code evidence todayPartial evidence, checked on every pull request.
  2. 4 with supporting evidenceToevan records related evidence; the duty stays organisational.
  3. 30 stay with your organisationListed in full below, so nothing is implied.

The Security Rule’s technical safeguards and parts of the Privacy Rule are visible in code: access control, audit controls, integrity, authentication, transmission security and how protected health information is used and disclosed.

The HIPAA blueprint gives code evidence for eight of them on every pull request. From v1.4.0, commit signatures and the binding of each merge to its code strengthen the integrity evidence. Administrative and physical safeguards stay with your programme.

Toevan gives evidence for controls; it never certifies them or claims a framework is covered. Whether the evidence is sufficient is your auditor’s judgement.

Live8

Code evidence today, sealed on every pull request. Always partial: the control also asks for things outside code. Code evidence today: rules in the HIPAA blueprint check part of this on every pull request.

  • 164.308(a)(4)

    Information access management

    164.308 Administrative safeguards

  • 164.312(a)(1)

    Access control

    164.312 Technical safeguards

  • 164.312(b)

    Audit controls

    164.312 Technical safeguards

  • 164.312(c)(1)

    Integrity

    164.312 Technical safeguards

    Strengthened in v1.4.0: commit signatures and the merge to code binding.

  • 164.312(d)

    Person or entity authentication

    164.312 Technical safeguards

  • 164.312(e)(1)

    Transmission security

    164.312 Technical safeguards

  • 164.502

    Uses and disclosures of protected health information: General rules

    Privacy Rule

  • 164.514

    Other requirements relating to uses and disclosures of protected health information

    Privacy Rule

Supporting4

Toevan records related evidence, today or in v1.4.0, but the duty is organisational, so it never counts as covered.

  • 164.308(a)(6)

    Security incident procedures

    164.308 Administrative safeguards

    Supporting evidence today: a rule records evidence related to this duty. The duty itself is an operational process.

  • 164.310(d)(1)

    Device and media controls

    164.310 Physical safeguards

    Supporting evidence today: a rule records evidence related to this duty. The duty itself is physical security.

  • 164.404

    Notification to individuals

    Breach Notification Rule

    Supporting evidence today: a rule records evidence related to this duty. The duty itself is regulatory procedure.

  • 164.504

    Uses and disclosures: Organizational requirements

    Privacy Rule

    Supporting evidence today: a rule records evidence related to this duty. The duty itself is contracts and vendors.

Your organisation30

Policy, people, physical security, contracts, regulatory procedure, operations or external audit. Your organisation evidences these.

Show all 30 controls

164.308 Administrative safeguards

  • 164.308(a)(1)Security management processan operational process
  • 164.308(a)(2)Assigned security responsibilityorganisational policy
  • 164.308(a)(3)Workforce securitypeople and HR
  • 164.308(a)(5)Security awareness and trainingpeople and HR
  • 164.308(a)(7)Contingency planan operational process
  • 164.308(a)(8)Evaluationan external assessment
  • 164.308(b)(1)Business associate contracts and other arrangementscontracts and vendors

164.310 Physical safeguards

  • 164.310(a)(1)Facility access controlsphysical security
  • 164.310(b)Workstation useorganisational policy
  • 164.310(c)Workstation securityphysical security

164.314 Organizational requirements

  • 164.314(a)(1)Business associate contracts or other arrangementscontracts and vendors
  • 164.314(b)(1)Requirements for group health planscontracts and vendors

164.316 Policies and procedures and documentation requirements

  • 164.316(a)Policies and proceduresorganisational policy
  • 164.316(b)(1)Documentationorganisational policy

Breach Notification Rule

  • 164.406Notification to the mediaregulatory procedure
  • 164.408Notification to the Secretaryregulatory procedure
  • 164.410Notification by a business associateregulatory procedure
  • 164.412Law enforcement delayregulatory procedure
  • 164.414Administrative requirements and burden of proofregulatory procedure

Privacy Rule

  • 164.506Uses and disclosures to carry out treatment, payment, or health care operationsorganisational policy
  • 164.508Uses and disclosures for which an authorization is requiredorganisational policy
  • 164.509Uses and disclosures for which an attestation is requiredorganisational policy
  • 164.510Uses and disclosures requiring an opportunity for the individual to agree or to objectorganisational policy
  • 164.512Uses and disclosures for which an authorization or opportunity to agree or object is not requiredorganisational policy
  • 164.520Notice of privacy practices for protected health informationorganisational policy
  • 164.522Rights to request privacy protection for protected health informationorganisational policy
  • 164.524Access of individuals to protected health informationan operational process
  • 164.526Amendment of protected health informationan operational process
  • 164.528Accounting of disclosures of protected health informationorganisational policy
  • 164.530Administrative requirementsorganisational policy

Using it in an audit

  1. Read the code evidence for the period

    Each pull request carries sealed code results against the blueprint’s rules, pinned to the commit and the rule-set version in force.

  2. Test a sample

    For each sampled record, check its results, then verify its signature and its place in the chain offline.

    toevan audit verify --path evidence-clone --pub-key toevan.pub

How each fact was obtained

Every fact in a record and a report carries one of six labels, so your auditor knows how far to rely on it.

Recomputed
Toevan computed it from the code or git history itself.
Re-perform it from the same inputs and get the same result.
Reported + sealed
GitHub reported it; Toevan captured it at the event and signed it.
Rely on it as far as you rely on GitHub. Any later change is detectable.
Declared + sealed
The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
See who declared what, when, and every later change.
Toevan record, not sealed
Held in Toevan’s database but not sealed in the ledger, such as a waiver today. Nothing protects it by a signature.
Treat it as Toevan’s statement, and ask the organisation for the approval behind it.
Consumed
Taken from another system’s signed record, such as build provenance, and linked by commit or digest. Planned.
Check the original record independently.
Not captured
No reliable source was available. Toevan does not infer it.
Obtain it from the organisation by other means.

See it in a report

The sample change evidence report shows the evidence as your auditor receives it, with every fact labelled.

Open the sample report

Test the mapping on a real audit.

Bring one repository and an upcoming audit. We’ll set up the blueprint and walk your auditor through verification.