HIPAA compliance testing services

What are you buying when the rule issues no certificate?

A tested position on each safeguard standard, and the written reasoning behind every safeguard you decided against. The second half is where section 164.306(d) puts most of the work.

The rule marks every implementation specification either Required or Addressable, in a parenthesis after its title. Across the safeguard sections and the documentation requirements at 164.316, seventeen are required and twenty-two are addressable; the organisational requirements at 164.314 add further required ones, and those are contract terms rather than build questions. A required specification is a build question with a yes or no answer. An addressable one is a decision procedure that ends in a document whichever way it goes: assess whether the specification is a reasonable and appropriate safeguard in your environment, implement it where it is, and where it is not, document why and implement an equivalent alternative measure where that is reasonable and appropriate.

Nobody can write that document from the code alone, and nobody can write it from the regulation alone. It needs a finding about how your system behaves and a judgement about your circumstances, and 164.306(b) makes the second one specific to you: the entity takes into account its own size, complexity and capabilities, its technical infrastructure, the cost of the measures, and the probability and criticality of the risks to ePHI. Two companies running the same architecture can land on different safeguards and both hold. This is why the size of an engagement tracks the addressable list rather than the required one, and it is the first thing to settle when working out what HIPAA compliance testing costs.

None of it moves the duty. The evaluation at section 164.308(a)(8) is performed by the regulated entity, and the statement it makes about the extent to which your policies and procedures meet Subpart C is your organisation's statement. An outside team produces what the statement rests on.

Which of your systems does the engagement reach?

Every system that creates, receives, maintains or transmits electronic protected health information, which is a shorter list than your estate and a longer one than your product. That phrase is 164.306(a)(1)'s own. 45 CFR 160.103 confines ePHI to information transmitted by or maintained in electronic media, so paper records answer to the Privacy Rule and stay outside Subpart C. Whether an outside team may hold any of it, and under which agreement, belongs to a different conversation, raised under how we work with protected health information.

Record systems, telemedicine platforms, patient portals and medical billing and claims software are inside by construction: holding ePHI is why each of them exists. Software as a medical device is not inside by construction. It reaches Subpart C only where it creates, receives, maintains or transmits ePHI for a covered entity or business associate, and a device classification decides the shape of its programme before HIPAA does.

Test environments are inside the same boundary. A copy of production is ePHI, and 164.502(e)(1) makes a disclosure of it to a supplier lawful only where the covered entity obtains satisfactory assurance that the supplier will safeguard it, documented under 164.502(e)(2) as a written contract meeting 164.504(e). That question is contractual before it is technical, and it decides a delivery date, because an environment cannot be built while it is open. Seeding the environment from synthetic records takes it off the critical path.

Which parts of HIPAA can a test evidence, and which stay with you?

Technical safeguards can be evidenced by a test. Administrative safeguards rest on a policy that a test can only feed. The individual rights sections close against product behaviour, and a patient can trigger them on any afternoon without warning you first.

The Privacy Rule gives an individual three requests a covered entity has to act on, at 45 CFR 164.524, 164.526 and 164.528, and each carries its own deadline and its own record on one shared extension of no more than 30 days. The deadlines, and what each request obliges the product to produce, are set out under patient portal testing. What belongs on this page is the scope consequence: a testing scope written from the safeguard sections contains none of them.

Two things decide how much work the accounting is. 164.528(a)(1) excludes nine categories of disclosure and the first three are treatment, payment and health care operations, so the build question is not how to log every disclosure but how to classify each one against those exclusions. And 164.524(e) makes two things documentation obligations in their own right: which designated record sets are subject to access, and the titles of the people or offices responsible for receiving and processing the requests. A product that can answer a request but cannot say which record sets it drew on has answered half of the section.

One more Privacy Rule provision shapes what any screen may return. 164.502(b)(1) applies minimum necessary to requests as well as to uses and disclosures, and 164.514(d)(2) turns it into a role requirement: identify the classes of workforce who need protected health information to do their jobs, identify the categories of information each class needs and the conditions on that access, and make reasonable efforts to hold them to it. 164.514(d)(5) then forbids using, disclosing or requesting an entire medical record unless the whole record is specifically justified as the minimum necessary. A role that returns the full chart because the query was easier to write fails that sentence, and an access review finds it. Treatment is the first of six exemptions at 164.502(b)(2), so the same breadth can be correct for a clinician and wrong for a billing analyst in the same release.

The safeguard by safeguard reading of Subpart C, with what each 164.312 standard admits as a test, is on HIPAA testing requirements for software.

What do you receive at the end of it?

Six documents. Each is addressed to one section of the rule, which is the granularity an investigator reads at.

The addressable specification register is the spine. One row for each of the twenty-two addressable implementation specifications, carrying the assessment 164.306(d)(3)(i) asks for, the decision that followed, the equivalent alternative measure where there is one, and the date. Rows with nothing behind them are marked as such, because an undecided row is itself the finding, and it is the finding reached first when a safeguard turns out to be absent.

The evaluation evidence pack is what whoever in your organisation puts their name to the 164.308(a)(8) evaluation reads first. That evaluation is a statement about the extent to which your policies and procedures meet the requirements of Subpart C, and a statement of that shape is worth what stands under each of its lines. The pack pairs each line with a result, a build identifier and a date.

The access route inventory is a list before it is a test. Every path that arrives at ePHI takes a row, an owner and a result. Non-interactive routes take a row too, because 164.312(a)(1) grants access rights to software programs alongside persons. A route missing from the inventory was never assessed, so the inventory is reconciled against the network policy and the service account list rather than against itself.

The individual rights execution report covers the three deadlines above, per request: when it arrived, when it was acted on, whether an extension was taken, and whether the written notice of that extension went out inside the first period. 164.524(b)(2)(ii)(A) makes that notice a condition of the extension rather than a courtesy, so a late notice loses the extra thirty days it was meant to buy.

The retention map answers a question that arrives years later. 164.316(b)(2)(i) requires Subpart C documentation to be retained for six years from its creation or from the date it was last in effect, whichever is later, and 164.530(j)(2) says the same of the Privacy Rule's documentation. The map names, per artefact, the system that holds it and the date the obligation ends.

The professional judgment routing evidence records who decided, in the two places where the rules reserve a decision to a licensed health care professional and the product must not answer on its own. Those two places are set out below.

Work that goes hunting for the failure rather than recording the state is scoped separately, under PHI security testing.

Where does the product decide something the rules reserve to a person?

In two places, and both are testable as routing rather than as outcome. Each of the three grounds for a reviewable denial at 164.524(a)(3) is written as a determination by a licensed health care professional, and section 164.502(g)(3)(ii)(C) reserves to one the decision on a parent's access where that parent is not the personal representative and state or other law, including case law, provides nothing. How a product has to model those grounds and the delegation behind them is set out under patient portal testing.

What an engagement adds is the record that the routing held. Two obligations fall on the product and both fail silently. It must be unable to issue a reviewable denial with no named professional attached, and it must route the review under 164.524(a)(4) to a different named professional and then honour the answer. A denial issued by a default looks exactly like a denial issued by a person, so an acceptance test for the second obligation fails when the same identifier can occupy both roles.

Both places share a failure mode: a system that resolves the case automatically, by rule, by age threshold or by a default either way, has taken a decision the regulation assigns to a named human role. That is what the routing evidence is built to show, one decision at a time.

How does this fit the release calendar you already run?

The rule attaches the work to change rather than to a date, which suits a release train better than an annual audit would. 164.306(e) requires the security measures to be reviewed and modified as needed to continue providing reasonable and appropriate protection. 164.316(b)(2)(iii) requires the documentation to be reviewed periodically and updated in response to environmental or operational changes affecting the security of ePHI. 164.308(a)(8) uses that same trigger for the evaluation. None of the three names an interval, so the interval is something you set and then have to defend.

The defensible version names in advance which rows each kind of change reopens. A new integration reopens the transmission security specifications at 164.312(e)(2)(i) and (ii) and the access authorisation specification at 164.308(a)(4)(ii)(B). A new class of user reopens 164.308(a)(3)(ii)(A) and the authorisation and modification pair at 164.308(a)(4)(ii)(B) and (C). Written that way, a re-run is proportionate to what shipped, and the register records why.

One obligation runs continuously rather than per release. section 164.308(a)(1)(ii)(D) requires procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports, and it is required rather than addressable. Where nobody performs that review, the audit control mechanism at 164.312(b) produces evidence that nothing consumes. Where findings already exist, from an investigation, an internal review or a customer's assessment, the order to close them in is set out under what to do after HIPAA audit findings.

Every section number and quoted phrase from 45 CFR part 164 on this page was read on 2 September 2026 against the eCFR compilation current as of 31 August 2026, and for Subparts D and E also against the CFR annual edition revised as of 1 October 2024. The two quotations from HHS OCR guidance come from pages on hhs.gov, read through archived captures of those URLs. Subpart C has carried no substantive amendment since 25 January 2013, the only later entry in a source credit being a June 2013 correction at 164.314.