PHI security testing services

You asked for HIPAA penetration testing. Which section is that?

There is none. Read 45 CFR 164.302 through 164.318 in full and no testing technique is named anywhere in the Security Rule. What the rule names instead, safeguard by safeguard, and the single implementation specification whose title carries the word testing, are set out under HIPAA testing requirements for software. The practical consequence for a buyer is narrow: the report has to attach itself to a section, because the rule will not attach it for you.

Four provisions accept the attachment, and all four are Required. The risk analysis at section 164.308(a)(1)(ii)(A) asks for an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate. Risk management at 164.308(a)(1)(ii)(B) then asks for security measures sufficient to reduce those risks to a reasonable and appropriate level. The information system activity review at 164.308(a)(1)(ii)(D) covers the regular reading of audit logs, access reports and security incident tracking reports. The evaluation standard at 164.308(a)(8) is the periodic technical and nontechnical exercise that establishes how far your policies and procedures meet Subpart C. Who may hold that electronic protected health information while the work runs, and under what written agreement, is a separate question from the testing, and the place to raise it with us is how we work with protected health information.

Two words in the risk analysis sentence decide the shape of a usable report. "Held by" means the assessment is organised around your ePHI rather than around a scanner's catalogue of defects, so a list of findings keyed to package versions has to be rewritten before it can enter the risk analysis at all. "Accurate and thorough" is the standard the assessment is measured against, and a scope that omitted an interface is neither.

Ranking is affected in the same way. 164.306(b)(2)(iv) tells the entity to take into account the probability and criticality of potential risks to ePHI when it chooses its measures. A vendor severity score answers a different question: how bad this class of defect is in general, on somebody else's estate. The translation from one to the other is work, and it is work the buyer pays for whether or not the supplier does it. Which side of the arrangement carries it, and what has to be in writing before an outside team reaches the estate at all, belongs to what an outsourced QA arrangement has to contain.

Where does ePHI actually leave the system you are picturing?

Through the paths built for other reasons. The primary store is usually the part of the estate with an owner and an access review. ePHI arrives everywhere else as a side effect: in an export a clinician asked for, in a message queue feeding a downstream analytics job, in a nightly snapshot restored into a staging account, in a search index built for speed, in an application log line that captured a whole request body, and in the error payload a crash handler posts to a third party tracker. None of those were designed to hold patient data. All of them can, and each is a place where the access rules of the primary store stop applying.

The classes of product where this bites hardest are the ones holding ePHI by construction: record systems, telemedicine platforms, patient portals and claims software. In EHR and EMR testing the interface estate is the surface, because a record system earns its place by exchanging data with everything around it, and every exchange is a route the inventory has to name.

Authorisation is the other recurring failure, and it hides below the endpoint. Access control tests that check whether a role can call an endpoint pass on systems where the same endpoint returns another patient's chart when the identifier in the request is changed. The check has to run at the level of the record, using a second account that legitimately holds the same role, because one account cannot demonstrate a boundary it never crosses. Service accounts and integration jobs need the same treatment, since section 164.312(a)(1) grants access rights to software programs alongside persons.

How much of this work can run outside production depends on what survives the extract, because a reduction that removes the relationships between records also removes the routes an authorisation check needs to walk. How an extract is reduced before it leaves the production boundary is covered under PHI de-identification for test environments.

Which findings can a test produce, and where does each one land?

Each row below pairs work a buyer asks for by name with the Subpart C provision the result belongs to. The third column is what turns a test result into a record the rule recognises.

PHI security testing work a buyer requests by name, set against what each can evidence and the HIPAA Security Rule provision its result attaches to.

Work requested by name	What it can evidence	Where the result attaches
External test of the production estate	Whether an unauthenticated route reaches ePHI, and which one	164.308(a)(1)(ii)(A) risk analysis, against the access control standard at 164.312(a)(1)
Authenticated testing at the record level	Whether a role reaches records outside the set it was granted under 164.308(a)(4)	164.312(a)(1), which covers persons and software programs alike
Scheduled vulnerability scanning	Whether known defects are present on hosts that hold or transmit ePHI	164.308(a)(1)(ii)(A) first, then 164.308(a)(1)(ii)(B) for what was done about each one
Log review run alongside the test	Whether the activity was recorded, and whether the record can be examined afterwards	164.312(b) audit controls, feeding the review at 164.308(a)(1)(ii)(D)
Restore and failover exercise	Whether the backup, disaster recovery and emergency mode plans behave as written	164.308(a)(7)(ii)(D), which is Addressable, over the Required plans at (a)(7)(ii)(A) to (C)
Retest after remediation	Whether the chosen measure reduced the risk it was chosen for	164.308(a)(1)(ii)(B) risk management, and 164.306(e) maintenance

The log review row costs little to add, because the test is already generating the activity that the mechanism at 164.312(b) is supposed to record. Running the two together answers a question neither answers alone: whether a read of a patient record leaves a trace an investigator could follow. How that check is built is covered under audit trail testing.

What arrives at the end, and why is it not a severity list?

Six documents, each addressed to the section it answers. A severity list is ordered by how alarming a defect is; the rule orders by risk to specific ePHI, and by what was decided about it.

The finding register is the spine. One row per finding, carrying the system, the build, the date, the ePHI at stake and the section it attaches to. Rows that attach to nothing stay in the register and are marked, because a finding outside Subpart C is still a defect and its absence from the register is how it gets lost.

The risk analysis input pack exists because the person who signs the risk analysis is inside your organisation and reads a different document from the one an engineer writes. It restates each finding as a risk to identified ePHI, which is the form 164.308(a)(1)(ii)(A) is written in.

The risk management decision log covers what happens next. A finding can be fixed, mitigated by another measure, or accepted, and 164.308(a)(1)(ii)(B) is satisfied by any of the three provided the level of remaining risk is reasonable and appropriate. What the log preserves is which of the three happened, and the name against it.

The egress map lists every path that carries ePHI out of the primary store, with a result per path and a marker where there is none. A path missing from the map was never assessed, so the map is reconciled against the interface list and the export catalogue rather than against itself.

The attribution record and the contingency exercise report are described in the two sections below, because both exist for reasons that only appear once the work meets a live system.

Where the request reached you through a customer's security questionnaire rather than through your own risk analysis, what such a questionnaire asks for, and what a certified assessment does not stand in for, is covered under HITRUST testing requirements. Where the engagement is the wider one, over the addressable specification register and the evidence behind the periodic evaluation, that is HIPAA compliance testing.

Where does availability fit into a security test?

Inside the rule's first sentence. 164.306(a)(1) requires the entity to ensure the confidentiality, integrity, and availability of all ePHI it creates, receives, maintains or transmits, so an engagement that only asks whether someone can get in has answered one of the three. Availability is testable in the ordinary way, by taking a backup and trying to serve patients from it, and what comes back is a finding like any other.

The contingency specifications make the split explicit. Data backup plan, disaster recovery plan and emergency mode operation plan at 164.308(a)(7)(ii)(A), (B) and (C) are all Required. Periodic testing and revision of those plans, at 164.308(a)(7)(ii)(D), is Addressable, and it is the only implementation specification in the Security Rule whose title contains the word testing. An entity that never exercises its plans is therefore inside the rule, provided it recorded the assessment 164.306(d)(3)(i) asks for and the alternative measure where one is reasonable and appropriate. An entity that never exercises them and never wrote that down has an undocumented gap on a specification whose subject is failure.

How does this fit a production system and an on-call rota?

By agreeing the window and the attribution before the first request is sent. The rule supplies the reason. 164.304 defines a security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. An authorised test manufactures attempted unauthorized access on purpose, which is the same description. Response and reporting at 164.308(a)(6)(ii) is Required, and its output is a documented record of security incidents and their outcomes.

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. The statement that the Security Rule names no testing technique is an absence verified by reading 164.302 through 164.318 in full and searching that text for each technique named above. The HHS statement about the pending rulemaking was read through an archived capture of the HHS page, because hhs.gov refuses automated requests.