HIPAA testing requirements for software

What does the HIPAA Security Rule require of your software?

The rule names no software. 45 CFR 164.302 puts the duty on a covered entity or business associate, which must comply with the applicable standards, implementation specifications and requirements of Subpart C with respect to electronic protected health information. A supplier arrives inside that sentence through the business associate definition at 160.103, which names data analysis, processing or administration, quality assurance and consulting among the functions that put an outside firm in scope. On what terms any given supplier may touch PHI is a question for that supplier, and it is one to raise at how we work with protected health information.

section 164.306(a), Security standards, general rules states what the safeguards have to achieve: confidentiality, integrity and availability of all ePHI the entity creates, receives, maintains or transmits; protection against reasonably anticipated threats or hazards to its security or integrity; protection against reasonably anticipated uses or disclosures that Subpart E does not permit; and compliance by the workforce.

Flexibility of approach, at 164.306(b), then allows any security measures that reasonably and appropriately implement those standards, taking into account the size, complexity and capabilities of the entity, its technical infrastructure and its hardware and software security capabilities, the cost of the measures, and the probability and criticality of potential risks to ePHI. Two products with the same architecture can therefore land on different safeguards and both survive an investigation. A test plan copied from another company proves nothing about yours.

The safeguards themselves sit in three sections: 164.308 administrative, 164.310 physical, 164.312 technical. Appendix A to Subpart C prints them as a matrix, each standard against its section number, each implementation specification marked (R) for required or (A) for addressable.

Read from 164.302 to 164.318, the rule mentions no penetration test, no vulnerability scan, no static or dynamic analysis, no code review, no test case, no test environment and no named security framework. One implementation specification carries the word testing in its title, 164.308(a)(7)(ii)(D), periodic testing and revision of contingency plans, and that one is addressable. Software testing enters the Security Rule as the evidence behind three required items: the risk analysis at 164.308(a)(1)(ii)(A), the information system activity review at 164.308(a)(1)(ii)(D), and the evaluation standard at 164.308(a)(8).

section 164.308(a)(8), Evaluation is required and runs to one sentence: perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of ePHI, that establishes the extent to which the entity's security policies and procedures meet the requirements of Subpart C. It sets no interval, names no method, and does not say the evaluator has to sit outside your company. Those decisions are the buyer's, and the file has to show they were made deliberately: how often, over what scope, by whom, and what counts as the trigger. "Environmental or operational changes" is the phrase that ties the evaluation to a release calendar, because a new integration or a new data store is such a change.

Which edition of the rule is in force today?

The text codified in 2013 is the one in force. Every section of Subpart C from 164.302 to 164.318 carries a source credit whose latest entry is 25 January 2013, at 78 FR 5693 to 5695, the HITECH Omnibus Final Rule; 164.314 carries an additional credit of 78 FR 34266, 7 June 2013. The eCFR reports title 45 current as of 31 August 2026.

HHS published a notice of proposed rulemaking, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information", at 90 FR 898 on 6 January 2025, under RIN 0945-AA22. The comment period closed on 7 March 2025. A Federal Register query on that RIN returns one document, the proposal itself, so no final rule has been published under it. HHS says on its own page for the proposal that while the Department is undertaking this rulemaking, the current Security Rule remains in effect.

One nearby amendment looks like a Security Rule change and is not. The definitions section at 45 CFR 160.103 was amended on 26 April 2024 and again on 24 March 2026, the second time by a transactions standards final rule at 91 FR 14350. The safeguard sections were untouched by it.

What does an addressable implementation specification oblige you to do?

More than the word suggests. 164.306(d) sorts implementation specifications into two kinds, marked in a parenthesis after each title. A required specification has to be implemented. An addressable one puts a decision procedure on the entity, and the procedure ends in a document whichever way it goes.

Nothing in that sequence permits a silent omission. The output of steps 4 and 5 is a record, and it is the record an investigator reads when a safeguard is absent.

The distinction decides most of the technical scope. Two of the seven implementation specifications under 164.312 are required: unique user identification at (a)(2)(i) and emergency access procedure at (a)(2)(ii). The other five are addressable: automatic logoff, encryption and decryption, the mechanism to authenticate ePHI, transmission integrity controls and transmission encryption. Six standards across the rule carry no implementation specifications at all and are themselves required, among them 164.312(b) audit controls, 164.312(d) person or entity authentication and 164.308(a)(8) evaluation.

Can we buy a HIPAA certificate?

There is no such thing, and the position is HHS's own rather than an interpretation of it. The OCR FAQ on certifying compliance answers: "No, there is no standard or implementation specification that requires a covered entity to 'certify' compliance." The same answer points at 164.308(a)(8), says the evaluation may be performed internally by the covered entity or by an external organization that provides evaluations or "certification" services, and then adds three statements a buyer should read closely: HHS does not endorse or otherwise recognize private organizations' certifications regarding the Security Rule; such certifications do not absolve covered entities of their legal obligations; and performance of a certification by an external organization does not preclude HHS from subsequently finding a security violation.

OCR repeats the point in its guidance on misleading marketing claims, where it states that HHS and OCR do not endorse any private consultants' or education providers' seminars, materials or systems, and do not certify any persons or products as "HIPAA compliant."

What a buyer can purchase is the evaluation itself, which that FAQ expressly allows as a business decision, and the records that answer the standards. A certificate on a supplier's site tells you which safeguards were examined only when it carries the scope, the date and the system version behind it. Where the request arrived through a customer's security questionnaire rather than from a regulator, HIPAA compared with HITRUST covers what that questionnaire is asking for.

What of the Security Rule can testing actually check?

Most of it lands in one section, the technical safeguards at 164.312, because each standard there describes the behaviour of a system rather than the behaviour of an organisation.

HIPAA Security Rule technical safeguards at 45 CFR 164.312, with required and addressable implementation specifications and what a test exercises for each.

45 CFR 164.312 standard	Implementation specifications	What a test exercises
(a)(1) Access control	Unique user identification (R), emergency access procedure (R), automatic logoff (A), encryption and decryption (A)	Access to ePHI attempted by a person and by a software program holding no granted rights
(b) Audit controls	None. The standard is required in itself	Whether the mechanism records a read of a record, and whether that entry can be examined afterwards
(c)(1) Integrity	Mechanism to authenticate ePHI (A)	Whether an alteration made outside the application path is detectable afterwards
(d) Person or entity authentication	None. The standard is required in itself	Every route that reaches ePHI, including password reset, session resumption and machine to machine calls
(e)(1) Transmission security	Integrity controls (A), encryption (A)	Each interface carrying ePHI off the host, including the ones added since the last release

section 164.312(a)(1), Access control rewards a verbatim reading, because it covers "those persons or software programs that have been granted access rights". A suite that exercises human roles alone leaves the second half untested, and that is where service accounts, integration jobs and background workers hold standing access to ePHI. Emergency access procedure at 164.312(a)(2)(ii) is required, and it is the path most suites never run, since it exists to bypass the controls the rest of the suite checks.

section 164.312(b), Audit controls asks for hardware, software or procedural mechanisms that record and examine activity in information systems containing or using ePHI. It names no retention period, no log format and no list of events, so the testable question becomes whether the log holds what your own policy says it holds, and whether a read of a patient record appears in it at all. Audit trail testing covers how that check is built.

Integrity at 164.312(c)(1) asks for protection from improper alteration or destruction, and 164.304 defines integrity as the property that data have not been altered or destroyed in an unauthorized manner. The addressable specification at (c)(2) asks for an electronic mechanism to corroborate exactly that, so a test for it alters a record outside the application path and looks for the corroboration afterwards.

Person or entity authentication at 164.312(d) is required and states one thing: verify that a person or entity seeking access to ePHI is the one claimed. No text between 164.302 and 164.318 mentions multi-factor authentication, so the requirement is coverage rather than a named factor. Every route to ePHI counts, including password reset, session resumption, support tooling and calls between services. Transmission security at 164.312(e)(1) makes the interface inventory load bearing in the same way: an interface nobody listed is an interface nobody assessed. A safeguard by safeguard list to run against your own system is in the HIPAA technical safeguards checklist.

Which records will an investigator ask to see?

The list starts at 164.316. Paragraph (a) asks for reasonable and appropriate policies and procedures. Paragraph (b)(1) requires them in written form, which may be electronic, and requires a written record of any action, activity or assessment that Subpart C requires to be documented. Paragraph (b)(2)(ii) requires that documentation to be available to the people implementing the procedures it covers, and (b)(2)(iii) requires periodic review and update in response to environmental or operational changes affecting the security of ePHI. 164.306(e) says the same of the security measures themselves.

A test result on this rule is therefore worth what its record is worth. A passing run with no written scope, no date and no system version answers nothing in 164.316, and the artefacts listed below are named for the section each one answers rather than for a heading in a report template. The written contract required by 164.308(b)(3) and 164.314(a)(2) sits in the same file, and it is the document that decides whether a supplier was allowed to hold the data it tested against.

Where does this go wrong in practice?

• Addressable specifications treated as optional. Encryption is off on one internal interface, and 164.306(d)(3) has produced no assessment and no alternative measure, so there is no record of a decision having happened.
• Audit controls that log the user action and not the record access, which leaves the information system activity review at 164.308(a)(1)(ii)(D) unable to show who opened a chart.
• Access control tested for humans only, while 164.312(a)(1) covers software programs, so integration jobs keep standing access nobody reviews.
• The emergency access procedure at 164.312(a)(2)(ii) documented and never exercised, so the first live use is the first test.
• An evaluation under 164.308(a)(8) performed once at launch, although 164.306(e) and 164.316(b)(2)(iii) both attach the review to environmental and operational change, and the release that added a data flow is such a change.
• Test environments seeded from a production dump. That copy is ePHI, it sits under the same 164.312 standards as production, and it usually inherits none of them. Testing with synthetic PHI data is the way out.
• A policy set kept as a PDF with no written record of the actions and assessments 164.316(b)(1) requires to be documented.

Where an investigation or an internal review has already produced findings, what to do after HIPAA audit findings covers the order to close them in.

What do we run against the Security Rule?

Work starts from the ePHI inventory, because 164.306(a)(1) is written around ePHI the entity creates, receives, maintains or transmits, and a safeguard cannot be tested against data nobody has located. From that inventory we derive the 164.312 checks, run them against a named build, and record the results in the form 164.316(b)(1) expects. The output is the artefact list above.

The evaluation under 164.308(a)(8), and the compliance position resting on it, stay with the covered entity or business associate. What we hand over is the evidence underneath. HIPAA compliance testing describes the engagement, and PHI security testing the deeper technical work on the safeguards themselves.

Section numbers and quoted text on this page were read in the eCFR text of 45 CFR Part 164 Subpart C, current as of 31 August 2026. The HHS statements on certification and on the pending proposal were read through Internet Archive captures of the HHS pages, because hhs.gov refuses automated requests. The live pages are the Security Rule, the certification FAQ and the misleading marketing claims guidance.